Hi Paul, Your explanation making sense to me. As you said.
- If X offers two codecs, and Y answers with both of those, then there is no choice of codec. Either side can send either codec at any time. # Is that mean, if "Y" replied with 2 codec and so any codec can be use by X (it will not accept as which codec is first) is that correct? # So is that valid even without sending another offer, Y RTP can use different codec towards to X for 183 & 180 (whereas we know there is no change in "m" line of 183 and 180).. Is that correct? Can you please advise if there is any rfc or document i can check for the same? Regards, Nitin Kapoor On Mon, Apr 20, 2015 at 4:42 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > Anish, > > It is a little hard to follow you, but I think you still aren't "getting" > how it works. > > - If X offers two codecs, and Y answers with both of those, > then there is no choice of codec. Either side can send > either codec at any time. > > - If X offers two codecs and Y answers with one of those two, > then X can only send the chosen one to Y, but Y can still > send either codec to X at any time. (Even though this is > probably unlikely to happen.) > > If you, as X, offer two codecs, and you only want one of them used at a > time, then after receiving the first answer from Y, you should send another > offer with only one codec (one that you now know Y supports). > > It doesn't matter what messages the offers and answers are carried it. > Except of course that can be times when you aren't yet allowed to send > another offer. During those periods you just have to cope with things as > they are. > > Thanks, > Paul > > > On 4/20/15 4:58 PM, NK wrote: > >> Hi Ashish, >> >> Thanks for the information. But Michael replied it is clear to me now, but >> its created 1 confusion as below. Can anyone please help me to get the >> answer on this. >> >> 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 >> On Sat, Apr 18, 2015 at 1:03 AM, ashish rawat < >> ashish_rawat1...@yahoo.co.in> >> wrote: >> >> 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 >> >> > _______________________________________________ > 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
