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
