Hi,
Your conclusion appears to be a misinterpretation of SHOULD. I mention it
because not following the SHOULD can have 3PCC related interoperability
limitations.
RFC 2119: "3. SHOULD
This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances
Hi,
The following are a few RFC snippets. As shown within RFC 3725 section
10.2, 3PCC is one of the users of re-INVITE without SDP. If a device does
not support re-INVITE without SDP or doesn't offer all codecs that the UA
is currently willing and able to use, it hinders interoperability during
Just to elaborate - 3pcc is one of my touch stones. When considering any
O/A behavior I always ask the question: will this do the right thing if
3pcc is being used? And remember, the receiver of an offerless invite
doesn't *know* if 3pcc is in use - it had better assume that it might
be,
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
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
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
