Subject: [dispatch] RFC 3261 section 14.2 - "brand new call" does not specify whether the SDP should modify media attributes of an existing session containing a=sendonly or a=recvonly

From: Shaun Stokes <[email-masked]>
Date: Sat, 5 Sep 2020 09:43:02 +0000

Hi,

We are struggling with some of the interpretation used in RFC 3261 section 14.2 which is creating a conflict between the software we use (FreeSWITCH) and another environment (based on Cisco previously Broadsoft equipment) both of which claim to be RFC 3261 compliant and claim that the other is not.

The problem occurs when the 3rd party sends an SDP with the media attribute 'a=sendonly' on an existing session then follow with a RE-INVITE with-out an SDP, they claim that our 2xx offer in response should contain an SDP with-out 'a=sendonly' (or replace with 'a=sendrecv') based on the interpretation of a "brand new call" used below. Anthony Minessale II (FreeSWITCH lead) claims that "brand new call" is only intended to refer to codecs (not all media attributes) and that the 3rd party (Broadsoft) invented this concept on their own.

RFC 3261

14.2 UAS Behavior
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 [13] in the case of SDP.
Specifically, this means that it SHOULD include as many media formats
and media types that the UA is willing to support.  The UAS MUST
ensure that the session description overlaps with its previous
session description in media formats, transports, or other parameters
that require support from the peer.  This is to avoid the need for
the peer to reject the session description.  If, however, it is
unacceptable to the UAC, the UAC SHOULD generate an answer with a
valid session description, and then send a BYE to terminate the
session.

Source: https://tools.ietf.org/html/rfc3261#section-14.2

The 3rd party have also stated that this isn't a call going on hold as it's routing to an ACD group, according to RFC 6337 section 5.3 "the use of sendonly/recvonly is not limited to hold".

In the following discussion on this subject involving the authors of RFC 3261 there is a clear indication that a RE-INVITE with-out an SDP should not modify 'a=sendonly', unfortunately this isn't enough to support our argument and our service providers protocol lead have determined that the 3rd party is acting correctly and have asked for more evidence.
http://marc.info/?t=98738614300001&r=1&w=2

We have also pointed out that RFC 3264 section 8 states that the offer MAY be identical to the last SDP provided but are promptly referred back to "brand new call" in RFC 3261 section 14.2.

RFC 3264

8 Modifying the Session
At any point during the session, either participant MAY issue a new
offer to modify characteristics of the session.  It is fundamental to
the operation of the offer/answer model that the exact same
offer/answer procedure defined above is used for modifying parameters
of an existing 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.  We refer to the last SDP provided as the "previous
SDP".  If the offer is the same, the answer MAY be the same as the
previous SDP from the answerer, or it MAY be different.  If the
offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below.

Source: https://tools.ietf.org/html/rfc3264#section-8

I'm struggling to find anything more in RFC which can support our argument, is it possible to update RFC 3261 14.2 to be more specific in the terminology for "brand new call" or is this answered elsewhere?

Hope someone here can help.

Regards,
Shaun

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 5 Sep 2020 11:16:51 -0400

Shaun,

Take a look at RFC6337 (especially section 5.1) and see if it helps.
That RFC was written to respond to many questions about O/A that came up 
over time. It is not normative, but rather simply clarifies things that 
are implicit upon analyzing an assortment of normative RFCs.

BTW, dispatch isn't really the right place for a question like this. A 
better place is <[email-masked]>.

	Thanks,
	Paul

On 9/5/20 5:43 AM, Shaun Stokes wrote:
> Hi,
> 
> We are struggling with some of the interpretation used in RFC 3261 
> section 14.2 which is creating a conflict between the software we use 
> (FreeSWITCH) and another environment (based on Cisco previously 
> Broadsoft equipment) both of which claim to be RFC 3261 compliant and 
> claim that the other is not.
> 
> The problem occurs when the 3rd party sends an SDP with the media 
> attribute 'a=sendonly' on an existing session then follow with a 
> RE-INVITE with-out an SDP, they claim that our 2xx offer in response 
> should contain an SDP with-out 'a=sendonly' (or replace with 
> 'a=sendrecv') based on the interpretation of a "brand new call" used 
> below. Anthony Minessale II (FreeSWITCH lead) claims that "brand new 
> call" is only intended to refer to codecs (not all media attributes) and 
> that the 3rd party (Broadsoft) invented this concept on their own.
> 
>     RFC 3261
> 
>     14.2 UAS Behavior
> The 3rd party have also stated that this isn't a call going on hold as 
> it's routing to an ACD group, according to RFC 6337 section 5.3 "the use 
> of sendonly/recvonly is not limited to hold".
> 
> In the following discussion on this subject involving the authors of RFC 
> 3261 there is a clear indication that a RE-INVITE with-out an SDP should 
> not modify 'a=sendonly', unfortunately this isn't enough to support our 
> argument and our service providers protocol lead have determined that 
> the 3rd party is acting correctly and have asked for more evidence.
> We have also pointed out that RFC 3264 section 8 states that the offer 
> MAY be identical to the last SDP provided but are promptly referred back 
> to "brand new call" in RFC 3261 section 14.2.
> 
>     RFC 3264
> 
>     8 Modifying the Session
> I'm struggling to find anything more in RFC which can support our 
> argument, is it possible to update RFC 3261 14.2 to be more specific in 
> the terminology for "brand new call" or is this answered elsewhere?
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Shaun Stokes <[email-masked]>
Date: Sat, 5 Sep 2020 20:10:43 +0000

Hi Paul,

Thanks for your response.

RFC 6337 section 5.1 refers us back to RFC 3261 in case of a RE-INVITE and "without regard for what the other party in the call may have indicated previously" would suggest we should be using 'a=sendrecv' in our offer.

I previously tried to touch base with Henning and was directed to the dispatch mail list.

I'll post the question to the sip-implementors mail list.

Thanks,
Shaun
________________________________
From: Paul Kyzivat <[email-masked]>
Sent: 05 September 2020 17:16
To: Shaun Stokes <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [dispatch] RFC 3261 section 14.2 - "brand new call" does not specify whether the SDP should modify media attributes of an existing session containing a=sendonly or a=recvonly

Shaun,

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 5 Sep 2020 16:50:10 -0400

On 9/5/20 4:10 PM, Shaun Stokes wrote:
> RFC 6337 section 5.1 refers us back to RFC 3261 in case of a RE-INVITE 
> and "without regard for what the other party in the call may have 
> indicated previously" would suggest we should be using 'a=sendrecv' in 
> our offer.

As one of the authors of 6337 I will agree that sendrecv is probably 
what the UAS should be offering given the circumstances. But it 
ultimately comes down to what it "wants" to be doing at that time.

The folly comes when it offers something less than what *it* wants 
because it imagines (based on prior o/a) that the answerer wants less 
than it does. This can get you into "stuck on hold" scenarios or other 
trouble.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> *From:* Paul Kyzivat <[email-masked]>
> *Sent:* 05 September 2020 17:16
> *To:* Shaun Stokes <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [dispatch] RFC 3261 section 14.2 - "brand new call" does 
> not specify whether the SDP should modify media attributes of an 
> existing session containing a=sendonly or a=recvonly
> Shaun,
> 
> Shaun Stokes -
> T : 	0800 0489300
> E : 	[email-masked]
> W : 	www.sysconfig.cloud
> 
> SYSCONFIG is a trading name of ITEC Support LTD which is a limited 
> company registered in England and Wales. Company Registered Number 
> 06908001. Registered office: Suite 2, Prospect House, Bath Road Trading 
> Estate, Stroud, GL5 3QF. VAT Number GB971629981
> 
> CONFIDENTIALITY NOTICE
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they are 
> addressed. If you have received this email in error; please notify the 
> system manager. This message contains confidential information and is 
> intended only for the individual named. If you are not the named 
> addressee you should not disseminate, distribute or copy this e-mail. 
> Please notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system. If you are 
> not the intended recipient you are notified that disclosing, copying, 
> distributing or taking any action in reliance on the contents of this 
> information is strictly prohibited.
> 
> WARNING: Although the company has taken reasonable precautions to ensure 
> no viruses are present in this email, the company cannot accept 
> responsibility for any loss or damage arising from the use of this email 
> or attachments.