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

[Shaun Stokes]

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?

Thanks,
Shaun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20200828/95e7150d/attachment.html>