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

[Shaun Stokes]

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20200907/42263fac/attachment-0001.html>