On 4/21/15 4:37 AM, ashish rawat 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.
The above are all "traditional" reasons. They imply that the SHOULD is
followed most of the time.
Until recently it was usual (with SIP) that there is only one media
stream in each direction within an RTP session, and the above made sense
in that context.
More recently we are seeing use cases where an RTP session carries
multiple media streams. Within the RTP session these are distinguishable
by SSRC or other means. And then each of those will likely behave as
above, with rare codec changes for 2833, etc. But each may use a
different codec, or not.
There are a lot of *drafts* related to this. You might want to start
with
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-19.
Note that *that* uses a separate m-line for each media stream, but ties
several m-lines together on a single RTP session. So you are still
negotiating codecs separately per-m-line, so the change isn't so great.
But your RTP implementation sees them all mixed together and must
concurrently support multiple codecs.
Of course, bundle only gets used if both the offerer and the answerer
support it, so you won't get into it accidentally.
But this indicates that styles of usage are evolving. So you may see
things now that were always legal but weren't normally seen in the past.
The case where codec switching has been common practice forever is with
a "regular" audio codec plus the 2833 telephone-events codec. But there
isn't anything *fundamentally* different about that and switching
between H.264 and VP8.
Thanks,
Paul
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
<mailto: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 <mailto: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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
