search

signalwire / freeswitch

FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a versatile software implementation that runs on any commodity hardware. From a Raspberry PI to a multi-core server, FreeSWITCH can unlock the telecommunications potential of any device.
https://freeswitch.com/#getting-started
Other
3.55k stars 1.41k forks source link

Configuration option to control relaying of 180 Ringing after 183 Session in progress #2596

Open prashan-abey opened 3 weeks ago

prashan-abey commented 3 weeks ago

Is your feature request related to a problem? Please describe. FreeSwitch doesn't relay 180 Ringing downstream if there was a 183 session in progress message from the upstream before the 180. We are increasingly seeing this behaviour from mobile network providers, sending a 183 with SDP without early media and then sending a 180 Ringing when the B party is alerted. FS doesn't process this 180 message and we are finding it extremely difficult to handle this behaviour.

Please refer to the attached pcap for your reference.

Describe the solution you'd like

RFC3960 Section 3.2 describes how to handle a similar scenario. Is it possible to have a configuration to control this behaviour based on RFC recommendations?

RFC3960 section 3.2

A UAS can send early media without using reliable provisional responses (very simple UASs do that) or it can send an answer in a reliable provisional response without any intention of sending early media (this is the case when preconditions are used). Therefore, by only looking at the SIP signalling, a UAC cannot be sure whether or not there will be early media for a particular session. The UAC needs to check if media packets are arriving at a given moment.

  An implementation could even choose to look at the contents of the
  media packets, since they could carry only silence or comfort
  noise.

With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS ("Plain Old Telephone Service")-like SIP User Agent (UA) could implement the following local policy:

  1. Unless a 180 (Ringing) response is received, never generate
     local ringing.

  2. If a 180 (Ringing) has been received but there are no incoming
     media packets, generate local ringing.

  3. If a 180 (Ringing) has been received and there are incoming
     media packets, play them and do not generate local ringing.

     Note that a 180 (Ringing) response means that the callee is
     being alerted, and a UAS should send such a response if the
     callee is being alerted, regardless of the status of the early
     media session.

Describe alternatives you've considered

The only available workarounds are to ignore early media or provide instant ringback to the A party which is not ideal.

Additional context

Package version or git hash

skainz92 commented 1 week ago

i would also like to see that :)