Dear All, Thank you very much for your help its clear my doubt and problem is fixed.
On Tue, Apr 21, 2015 at 1:37 AM, ashish rawat <ashish_rawat1...@yahoo.co.in> wrote: > Hi Nitin, > > Yes that is correct! ( Based on the media > direction.send-recv,recvonly,sendonly) > > I once again pasting the same RFC, I think this has the answer to your > question. > > https://www.ietf.org/rfc/rfc3264.txt > > Offerer Processing of the Answer > > When the offerer receives the answer, it MAY send media on the > accepted stream(s) (assuming it is listed as sendrecv or recvonly in > the answer). > > *It MUST send using a media format listed in the answer, and it SHOULD > use the first media format listed in the answer when it does send.* > > > > *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. > > There has been no change in the initially exchanged offer/answer. Vendor > is using once of the codes already listed in the answer hence a new > offer/answer or update isn't required. > > Thanks, > Ashish > > > > On Tuesday, 21 April 2015 6:05 AM, NK <nitinkapo...@gmail.com> wrote: > > > 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 > > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
