Comments inline... Regards, Nataraju A B > -----Original Message----- > From: Horvath, Ernst [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 22, 2007 4:28 PM > To: Christer Holmberg; RaviShankar Shiroor (WT01 - Telecom > Applications and Solutions); [EMAIL PROTECTED]; [email protected] > Subject: RE: [Sip] SIPit 21 : Topics that attendees argued about > > 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." > > 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." > > 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) > [ABN] this looks to me that, UAC upon reception of answer is not expected to listen for any codec's not listed in the answer. But accepting even the other codec's published in offer but not in answer makes it lineant in accepting the packets from the other peer. But this clearly outside the scope of standards.
But if we turn off the accepting other codec's not listed in answer would yield better hardware resource utilization. Just for instance, Offer: g711u, g711a, g729 Answer: g711u, g711a In this case after the o/a negotiation completes, then if we tune the hardware resources @ UAC for g711 codec handling only, then the bandwidth/resource utilization @ UAC would be optimal. The same resources could be utilized for other calls which need g729 packet handling capability. Hope this makes sense to turn off particular codec handling (@UAC) not listed in answer, but published in offer. > Regards, > Ernst Horvath > > > > -----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 codec's 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 > > codec's - it mostly contains a subset of the codec's in the offer. > > > > Regards, > > > > Christer > > > > > > > > >I was surprised to find > > > > > >>* There were implementations that offered an m-line with > > codec's 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 codec's 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 codec's 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 > > > > codec's (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 codec's > > > > on an m-line between the offer and the answer. The specs > > say SHOULD. > > > > * There were implementations that offered an m-line with > > > codec's 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 > _______________________________________________ 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
