Hi Nitin, I think it is valid to change the codec on fly. We often see it during DTMF RFC2833.here isn't any change in existing offer. It's using one of listed codes in the offer/answer ealier.
https://www.ietf.org/rfc/rfc3264.txt The reason this is a SHOULD, and not a MUST (its also a SHOULD, and not a MUST, for the answerer), is because there will oftentimes be a need to change codecs on the fly. For example, during silence periods, an agent might like to switch to a comfort noise codec. Or, if the user presses a number on the keypad, the agent might like to send that using RFC 2833 [9]. Congestion control might necessitate changing to a lower rate codec based on feedback. Thanks,Ashish On Saturday, 18 April 2015 5:36 AM, NK <nitinkapo...@gmail.com> wrote: Hi Michael, Thanks for a lot for you reply. Its making sense to me, however its created 1 confusion to me. As you can ideally when we have multiple codec from UAS in 183 or 180 so ideally UAC accept the first codec whatever is there in "m" line and as far as i know if we have change any codec before 200 OK we should use UPDATE method. 1) But in this case as you can see there was no media changed in "m" line in 180 after 183 which means no UPDATE required then how without UPDATE method RTP stream have different codec. 2) Secondly since we have first codec G729 in m=audio 21280 RTP/AVP 18 8 101 of 180 then how RTP stream selected the second preference. I assume that when we have multiple codec in Answer then UAC select First In First out method(i mean it will select the first codec) Regards, Nitin Kapoor On Fri, Apr 17, 2015 at 4:02 PM, Michael Bain <mike@redpoint.systems> wrote: > Yes this is valid. When you make an SDP offer, you are saying you are > willing to receive any of those codecs at anytime during the session. See > the third paragraph of this section: > http://tools.ietf.org/html/rfc3264#section-5.1 > > "If multiple formats are listed, it means that the offerer is capable of > making use of any of those formats during the session. In other words, the > answerer MAY change formats in the middle of the session, making use of any > of the formats listed, without sending a new offer." > > Mike > > On 17 April 2015 at 12:47, NK <nitinkapo...@gmail.com> wrote: > > > Dear All, > > > > I am facing the problem where my vendor changed the codec in RTP > > packet only. Below is the explanation to this issue. > > > > 1) We sent the Invite to vendor and Vendor replied 183 w/SDP along with > > below m line. Also since its early media RTP started and agreed to use > G729 > > Codec as below and UAC is also agreed on same. > > > > m=audio 21280 RTP/AVP 18 8 101 > > > > RTP > > > > Media Destination Port = 41354 > > Direction = InBound > > *Payload = G.729* > > > > 2) Here after we received 180 w/SDP from vendor and SDP remain the same, > > but the RTP packet which redirect to UAC from UAS changed the codec as > > below. > > > > m=audio 21280 RTP/AVP 18 8 101 > > > > RTP > > > > Media Destination Port = 41354 > > Direction = InBound > > *Payload = PCMA* > > > > Can you please help me on this if this is accetpable and i cannot see > much > > information on this. > > > > Thank you in advance. > > > > Regards, > > Nitin Kapoor > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
