You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The telco is sending:
100 trying
183 Session in progress -> this is forward to the Phone and i can listen the audio
180 Ringing -> the issue... silence on Phone
200 OK -> audio on Phone again.
Not sure what would be the correct solucion:
option 1: FS reproducing the ringback to the phone when the 180 Ringing arrives
option 2: FS forwarding the 180 Ringing to the phone
NOTE: i try to change sofia.c and clear the channel flag "CF_EARLY_MEDIA" when a 180 arrives to see if the SIP messages is forward to aleg, but no luck.. the call is ended in audio_bridge_thread with the message: "ending bridge by request from write function".
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.
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:
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
180_after183.zip
The text was updated successfully, but these errors were encountered: