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 q
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. 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
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Ramesh Babu
Kuppili
Sent: Monday, January 18, 2016 3:06 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Codec negotiation when in
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 constra
lumbia.edu] On Behalf Of Basu Chikkalli
> Sent: Tuesday, January 19, 2016 12:40 AM
> To: ankur bansal
> Cc: sip-implementors
> Subject: Re: [Sip-implementors] Codec negotiation when incoming re-INVITE
> has
> no SDP
>
> We have following two RFC references:
>
>
>
> R
mplementors-boun...@lists.cs.columbia.edu] On Behalf Of Ramesh Babu
Kuppili
> Sent: Monday, January 18, 2016 3:06 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] Codec negotiation when incoming re-INVITE
has no
> SDP
>
> Hello SIP experts,
>
> I
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 exist
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 no
Hi,
hmI 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 p
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 wi
10 matches
Mail list logo
