[Freeswitch-users] Late Codec Negotiation between FreeSWITCH and Broadsoft equipment when responding to RE-INVITE without SDP

[Shaun Stokes]

We've had a response from Roman Shpount on SIP Implementors who "got the language about handing re-INVITE without SDP into RFC 3261 as a brand new call", conversation below. I'll raise this as an issue on GitHub when I have some time to build and test on master. I've also noticed FreeSWITCH doesn't respond to "a=sendonly" with "a=recvonly" possibly because the ACK SDP from 3rd party was immediately followed with a RE-INVITE with-out SDP so FreeSWITCH carries over the ACK SDP with no change.

Hi Roman,

Thank you for your response.

We are using FreeSWITCH as a SIP and RTP media server to connect the caller (leg a) to the callee (leg b), the caller is expecting the media state sendrecv but this is influenced by the 3rd party.

The call flow is as follows.

-> = generated by FreeSWITCH (caller)
<- = generated by 3rd party (callee)

-> 0.000000s INVITE with SDP 'codec list'
<- 0.012557s 100 Trying
<- 0.083254s 200 OK with SDP 'codec list'
-> 0.085348s ACK

<- 0.071315s INVITE with-out SDP 'RE-INVITE for existing session'
-> 0.086461s 100 Trying
-> 0.087391s 200 OK with SDP 'codec list'
<- 0.154249s ACK with SDP 'codec list and a=sendonly'

<- 0.155111s INVITE with-out SDP 'RE-INVITE for existing session'
-> 0.166856s 100 Trying
-> 0.167631s 200 OK with SDP 'codec list and a=sendonly'
<- 0.202331s ACK with SDP 'codec list and a=recvonly'

<- 0.337532s INVITE with-out SDP 'RE-INVITE for existing session'
-> 0.346448s 100 Trying
-> 0.347170s 200 OK with SDP 'codec list and a=sendonly'
<- 0.390116s ACK with SDP 'codec list and a=recvonly'

FreeSWITCH currently interprets a RE-INVITE with-out SDP for an existing session as 'no change' for the hold state so it's carrying 'a=sendonly' over from the existing session as it was in the ACK SDP generated by the 3rd party. Based on your explanation I believe this is wrong and we should be responding with-out 'a=sendonly' (default behaviour) or with 'a=sendrecv'.

Thanks,
Shaun
________________________________
From: Roman Shpount <roman at telurix.com>
Sent: 07 September 2020 08:44
To: Shaun Stokes <shaun at sysconfig.cloud>
Cc: sip-implementors at lists.cs.columbia.edu <sip-implementors at lists.cs.columbia.edu>
Subject: Re: [Sip-implementors] 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,

I am the person who actually got the language about handing re-INVITE without SDP into RFC 3261 as "a brand new call". The initial intent was to enable a third party call control to initiate a new call by sending a re-INVITE without SDP to an existing call and then place another call to a new party.

If I understand correctly, FreeSwitch is sending a response with "a=recvonly" to a re-INVITE with no SDP? If this is the case, since they are a media server, in this particular situation they are probably wrong, but generally the answer is "it depends". Because of this, you are not going to find an RFC that specifies the one and only correct procedure. The general idea is that sendonly/recvonly in every SDP exchange should reflect the preferences for the user agents, not what was previously negotiated.

Imagine that one UA is putting another UA on hold. In this case this phone sends a re-INVITE with a=inactive (or a=sendonly which only makes sense if the UA plans to play the music on hold).  The second UA will respond with a=inactive or a=recvonly. If the second UA later sends a re-INVITE without SDP, the first UA will still respond with SDP with a=inactive (or a=sendonly), since it is still on hold. If the UA which is currently on hold sends a re-INVITE with no SDP, then the other UA should respond with a=sendrecv (since it is not on hold), but the first UA should respond with a=inactive (or a=sendonly) in SDP in ACK, since it is still on hold.

In other words, re-INVITE does not change the local UA hold status, only a user action does this. Based on the local hold status and the remote direction attribute the UA should respond with an appropriate direction attribute in the answer. If you are using FreeSwitch as a media server, then the local call status is likely not on hold and it should be able to send/recv media, which should be indicated in the response to a re-INVITE with no body. In general case, the local call status is something that depends on the application running on FreeSwitch, which you do not specify. This is why the general answer "it depends".

I hope it helps,
_____________
Roman Shpount

________________________________
From: FreeSWITCH-users <freeswitch-users-bounces at lists.freeswitch.org> on behalf of Shaun Stokes <shaun at sysconfig.cloud>
Sent: 07 September 2020 08:24
To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
Subject: Re: [Freeswitch-users] Late Codec Negotiation between FreeSWITCH and Broadsoft equipment when responding to RE-INVITE without SDP

Hi All,

I raised the issue with IETF dispatch and had the following response from Paul Kyzivat, based on this response I believe the correct default behaviour according to RFC (as it is now) is that we should be offering an SDP with 'a=sendrecv' in response to a RE-INVITE with-out SDP (3PCC) rather than carrying over 'a=sendonly' from the existing session.

On 9/5/20 4:10 PM, Shaun Stokes wrote:
> 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.

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

> 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 <pkyzivat at alum.mit.edu>
> *Sent:* 05 September 2020 17:16
> *To:* Shaun Stokes <shaun at sysconfig.cloud>
> *Cc:* dispatch at ietf.org <dispatch at ietf.org>
> *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,
>
> 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 <sip-implementors at lists.cs.columbia.edu>.
>
>          Thanks,
>          Paul

I have also raised this with SIP Implementors as this contradicts a previous discussion on this issue involving the authors of RFC 3261 (http://marc.info/?t=98738614300001&r=1&w=2).

Thanks,
Shaun

________________________________
From: FreeSWITCH-users <freeswitch-users-bounces at lists.freeswitch.org> on behalf of Mike Jerris <mike at freeswitch.org>
Sent: 31 August 2020 17:46
To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
Subject: Re: [Freeswitch-users] Late Codec Negotiation between FreeSWITCH and Broadsoft equipment when responding to RE-INVITE without SDP

Yes sip_unhold_nosdp does exactly what you are asking.


On Aug 28, 2020, at 6:05 AM, Shaun Stokes <shaun at sysconfig.cloud<mailto:shaun at sysconfig.cloud>> wrote:

Hi All,

We are using '3pcc-enable' to allow late codec negotiation where an INVITE (or RE-INVITE) does not include an SDP but have recently noticed unexpected behaviour on certain calls with Broadsoft equipment.

The problem is on outbound calls from FreeSWITCH to BT IP Exchange which are handled by a 3rd Party using Cisco (previously Broadsoft) equipment, calls to the 3rd party that are routed to an IVR then to a hunt group (ACD) have the 'a=sendonly' attribute set in the SDP by the 3rd party (Broadsoft) which they expect us to remove in our 2xx response to a RE-INVITE with-out an SDP (from 3rd party) according to 'RFC 3261 section 14.2' as we "SHOULD construct the offer as if the UAS were making a brand new call" and "this means that it SHOULD include as many media formats and media types that the UA is willing to support", I've read into this further and find the interpretation to be somewhat ambiguous as there is a reference to 'RFC 3264 section 8' when an offer "updates an existing session" then "the offer MAY be identical to the last SDP" so technically both arguments are correct but unfortunately BT is siding with Broadsoft at this stage which is used by a variety of large service providers whom all agree on this interpretation. 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".

It's not very well documented but I suspect setting 'sip_unhold_nosdp' in FreeSWITCH may resolve the problem as a workaround but this requires further testing.

Should the default behaviour of FreeSWITCH be changed when '3pcc-enable' is used in this situation so FreeSWITCH creates a brand new SDP or are Broadsoft wrong and does 'RFC 3261 section 14.2' need to be updated and if so how?

-
T :
E :
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20200909/f54d0fa7/attachment-0001.html>