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
