On 1/19/16 10:31 AM, Ramesh Babu Kuppili wrote:
Hello Everyone,
Based on the discussion so far I am convinced that we have to offer the
list of codecs supported by UA and not the codec list previously
negotiated.
Ah, good! My job is done. :-)
We have avoided having somebody else here asking questions later when
they can't interoperate with you.
Thanks,
Paul
Thanks for clarifying.
- ramesh
On 1/19/2016 8:39 PM, Paul Kyzivat wrote:
On 1/19/16 12:40 AM, Basu Chikkalli wrote:
We have following two RFC references:
Rfc3261
Sect 14.2 UAS Behaviour
A UAS providing an offer in a 2xx (because the INVITE did not contain an
offer) SHOULD construct the offer as if the UAS were making a
brand new call, subject to the constraints of sending an offer
that updates
an existing session, as described in [rfc 3264] in the case of SDP.
========The significance is use of word “SHOULD” instead of
“MUST”=================
Rfc 3264 sect 8 modifying session
The offer MAY be identical to the last SDP provided to the other party
(which may have been provided in an offer or an answer), or it
MAY be different
My conclusion is "200-OK will have the codec list already negotiated
in the
dialogue" not the list of codec supported by UA
You have a lot of latitude in what you do in this case. But some
choices are likely to give better results than others. RFC6337 is a
more thorough analysis than 3261 and 3264 provide.
In your initial O/A you have negotiated down to the common subset both
endpoints are willing and able to do at that time. Often
implementations can only support a variety of codecs but only one at a
time. So they end up selecting a subset of what they can do.
When a new offer is sent there is an opportunity to revisit that
choice. And the offerless invite is sometimes used to initiate a
transfer to a different device, that may support different codecs.
When you receive that invite you don't know if that will happen, so
best to respond in a way that will work best in all cases. To maximize
your chances, offer everything you are willing and able to do at that
time. In general that ought to include what is currently being used,
so that in simple cases the call can continue without change.
Note that this includes dealing with multiple media. If your current
call is only audio, but you are willing and able to do video then you
should consider including video in the new offer. For instance, this
might be relevant if the other end is transferring the call from an
audio-only device to a video phone.
Of course there are reasons you might not want to do that. For
instance, if you are handling the call on your computer, including
video might require that the app first consult the user for permission
to enable video. And you might not want to do that then.
So there is no hard and fast answer here. But only offering the subset
that was last negotiated is generally the *wrong* thing to do.
Good luck,
Paul
----Basu Chikkalli
On Tue, Jan 19, 2016 at 10:26 AM, ankur bansal <abh.an...@gmail.com>
wrote:
Hi Ramesh
Normally it should be full set of codec capabilities in first reliable
response to REINVITE without SDP ,
as this offer SDP might be used to send offer to third person UE-C so
sending negotiated codecs of A-B wont help UE-C.
Having said that it should be full set of codecs ,still its not
always same
as if initial INVITE offer sent by same UE.
You can refer RFC 6337 Section 5.2.2
Thanks & regards
Ankur Bansal
On Tue, Jan 19, 2016 at 2:01 AM, Harald Radke <harry...@gmx.de> wrote:
Hi,
hm....I would say for a start that RFC3264 applies (8.3.2):
" The list of media formats used in the session MAY be changed. To do
this, the offerer creates a new media description, with the
list of
media formats in the "m=" line different from the corresponding
media
stream in the previous SDP. This list MAY include new formats,
and
MAY remove formats present from the previous SDP."
Since an INVITE with no SDP merely "moves" the offer role to the other
side, I'd say above still holds, so you are pretty much free to put in
any codec you want, as long as:
(again RTC3264 8.3.2):
" However, in the
case of RTP, the mapping from a particular dynamic payload type
number to a particular codec within that media stream MUST NOT
change
for the duration of a session"
so you can leave out 101 our put in like 97 referring to the same
codec
as 101 did previously but you cannot reassign 101 to another one
My two cents,
Harry
Am 18.01.2016 um 21:06 schrieb Ramesh Babu Kuppili:
Hello SIP experts,
I have a question about codec negotiation when a UA receives
re-INVITE
with no SDP.
Lets say, the codec negotiation between UA and Proxy ended up with
G711
and RFC 2833 (m=audio 60146 RTP/AVP 0 101). However after the call
gets
established, if the proxy sends re-INVITE with no SDP, what should be
the codec list in the "200 OK" response for the reINVITE. My proxy
vendor claims that the "200 OK" should contain the list of the codecs
supported by the UA. Not the codec list already negotiated in the
dialogue. Can someone point me in the right direction for this
scenario
as to what the RFC says and if possible a section number in the RFC.
UA Proxy
----------------------------------------->
(INVITE SDP: codecs 0 18 101)
<------------------------------------------
(200 OK SDP: codecs 0 101)
-------------------------------------------->
ACK (no SDP)
<-------------------------------------------
(re-INVITE no SDP)
---------------------------------------------->
(200 OK SDP: codecs ?????)
- ramesh
_______________________________________________
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
