Hi, >>>I am surprised that this caused any confusion. RFC 3264 seems pretty >>>clear to me. >>> >>>Citing from section 6.1: >>> "The answerer MUST send using a media format in the offer >>> that is also listed in the answer, and SHOULD send using the most >>> preferred media format in the offer that is also listed in >>> the answer." >> >>The question is not what the offerer is supposed to send, >>but what he should be able to receive. >> > >So what's the problem? The text talks about what the answerer >is supposed to send, not the offerer.
Correct, my misstake. When reading the text again, I agree that it is clear: whatever codec the answerer is going to send must be both in the offer AND in the answer. >Initially the offerer must expect any format that he included in the offer. But >once the answer has arrived, an answerer that conforms to RFC >3264 WILL send only formats included in the answer, so the >offerer CAN stop listening for all other formats. > >> >>>and from section 7: >>>"The offerer MAY immediately cease listening for media formats that >>>were listed in the initial offer, but not present in the answer." >> >>Yes. The problem with the "MAY" is that the other party doesn't know >>whether the offerer will listen or not, so therefor I think it's more >>saft to only use codecs which BOTH entities include in the SDP. > >No, the MAY gives a conformant offerer the permission to stop >listening immediately on arrival of the answer. That means >for the conformant answerer that he MUST NOT assume that the >offerer is still listening for formats that were not in the >answer. I know, auxiliary verbs can be tricky, but the two >cited excerpts from RFC 3264 are entirely consistent. Yes, when re-reading the first citing the second citing makes sense. Regards, Christer > > >So, why should the offerer be expected to deal with formats not > > >present in the answer? (Of course, the offerer must be prepared to > > >receive ALL offered formats BEFORE the answer arrives) > > > > In many cases the offerer will not - due to different kind > of reasons > > - accept anything before he receives the answer (yes, yes, > I know what > > RFC3261 says...). > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, November 22, 2007 11:34 AM > > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > > [email protected] > > > > Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about > > > > > > > > > > > > Hi, > > > > > > > > I agree with Ravi. > > > > > > > > Eventhough you in theory is supposed to be able to > > receive what you > > > > offer - no matter what you get in the answer - I think > > that in real > > > > life the only codecs that participants will be prepared to > > > > send/receive are the ones sent both in the offer and the > > > answer. That > > > > is also the reason why the answer normally doesn't contain > > > additional > > > > codecs - it mostly contains a subset of the codecs in the offer. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > >I was surprised to find > > > > > > > > > >>* There were implementations that offered an m-line with > > > > codecs A, B, > > > > >>and C, got an answer with C, then got upset when they got > > > > RTP with A > > > > >>(which is quite legal). > > > > > > > > > >On the list (like others who argued about it I think). > > > > > > > > > >I had some offline discussions with some of the > members on this. > > > > >While I agree this seems legal, this seems very > > > counter-intuitive and > > > > >may result in wasted resources, would it not? > > > > > > > > > >For example, if the offerer is a conference bridge or a > > > transcoder, > > > > >and has a limited number of codecs of each type he offers, > > > why should > > > > >it hold on to one codec of each type for the duration of > > > the session, > > > > >even though the answerer has not supported it? > > > > > > > > > >Any particular reason why this should be continued as a legal > > > > >scenario? > > > > >Would it not be possible change it to say that the Offerer > > > needs to > > > > >expect only those codecs which answerer has explicitly > > > supported in > > > > >the answer? > > > > > > > > > >Regards, > > > > >Ravi. > > > > > > > > > > -- > > > > > > > > > > Ravishankar. G. Shiroor > > > > > Wipro Technologies, Bangalore. > > > > > > > > > > [EMAIL PROTECTED] > > > > > -- > > > > > > > > > > > -----Original Message----- > > > > > > From: Robert Sparks [mailto:[EMAIL PROTECTED] > > > > > > Sent: Tuesday, November 20, 2007 2:38 AM > > > > > > To: sip List > > > > > > Subject: [Sip] SIPit 21 : Topics that attendees argued about > > > > > > > > > > > > Digging through my notes: > > > > > > > > > > > > Here are some of the topics where people were arguing. I'm > > > > > capturing > > > > > > the smaller topics here. Larger arguments will get their > > > > > own message. > > > > > > > > > > > > * There were arguments about the dynamic payload map from > > > > > numbers to > > > > > > codecs (identified in the SDP and sent in the RTP) being > > > > > the same in > > > > > > the offer and the answer . The spec says they SHOULD. Some > > > > > > implementations were insisting they MUST. > > > > > > * There were arguments around preserving the relative order > > > > > of codecs > > > > > > on an m-line between the offer and the answer. The specs > > > > say SHOULD. > > > > > > * There were implementations that offered an m-line with > > > > > codecs A, B, > > > > > > and C, got an answer with C, then got upset when they got > > > > > RTP with A > > > > > > (which is quite legal). > > > > > > * There were arguments about deleting rejected m-lines on > > > > > re-invites > > > > > > (which you cannot do), and on reusing the slot they > > > occupy in re- > > > > > > invites (which you can do). > > > > > > * There were implementations that didn't add the > > > > refresher tag in a > > > > > > session-refresh message when they were the refresher and > > > > there were > > > > > > arguments about whether that meant the other side could > > > > > take the role. > > > > > > * Several implementations handled a=sendonly as a session > > > > > attribute, > > > > > > but not a media attribute - it can appear in either place. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP > Protocol Use > > > > > > [EMAIL PROTECTED] for questions on > > > current sip Use > > > > > > [EMAIL PROTECTED] for new developments on the > > application of sip > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use > > > > > [EMAIL PROTECTED] for questions on > > current sip Use > > > > > [EMAIL PROTECTED] for new developments on the > application of sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > [EMAIL PROTECTED] for questions on > current sip Use > > > > [EMAIL PROTECTED] for new developments on the application of sip > > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
