You can always lock down a codec by updating the initial offer. Take a look at section 10.2 of RFC 3264.
Raj > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 22, 2007 5: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
