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
