Ringing from bridge b-leg not relayed to the a-leg

[miclast]

Describe the bug

When incoming call going to the bridge if called gateway peer send back 180 ringing this SIP message is not relayed to the caller channel at all.

To Reproduce
Steps to reproduce the behavior:

1. Using this dialplan:
   extension name="public_711"
   condition field="destination_number" expression="^711(\d+)$"
   action application="set" data="domain_name=$${domain}"
   action application="set" data="outbound_caller_id_number=${caller_id_number}"
   action application="log" data="WARNING CID Num is ${outbound_caller_id_number}"
   action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"
   action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"
   action application="set" data="absolute_codec_string=PCMA,PCMU"
   action application="bridge" data="{absolute_codec_string='PCMA,PCMU'}sofia/gateway/SS2/$1"
   condition
   extension

Expected behavior

INVITE (SDP)
100 Trying
180 Ringing
other messages ...
on both bridge legs if 180 coming from dialed by bridge channel.

Package version or git hash

• Version 1.10.0

![incoming](https://user-images.githubusercontent.com/16573520/174262228-f0d4f224-baa5-4944-9919-d37d638ab7b2.png)
![outgoing](https://user-images.githubusercontent.com/16573520/174262233-096a5852-3bfd-487e-988b-6f7f13341355.png)
#

[ThomasLobker]

Unfortunately FreeSWITCH is dropping a 180 (without SDP) if it's preceded by a 183 with SDP.

Assuming that the B leg is not currently sending any early media, the 180 Ringing should actually trigger a local generated ringback tone. So depending on whether FreeSWITCH is bypassing media or not, the proper behavior of FreeSWITCH would be to generate a local ringback tone and send it to the A leg (when not bypassing media) or forward the 180 Ringing to the A leg (when bypassing media).

[haeferer]

Hi, any new Informations on this behavior ?

It can still be reproduced (or is it simple a feature).

Bridge with ByPass Media works as expectet.

Bridge without bypass (for instance to Record) -> Ringing ist Hidden / translated to 183/SDP ?

[ThomasLobker]

@dragos-oancea your help would be much appreciated! If there is anything I can do in regard to additional testing or providing more information, please let me know. Cheers!

[wmasilva]

Hi, jut hit this issue... would be nice to have it support/solved., there are similar reports here: #2596 and here #2612

[skainz92]

#2490

[haeferer]

(from #2490)
It shouldn't, the numbers should never go down, once you've hit 183 you can't go back to 180.

This is some kind of "recommendation" or "historical best practice". The RFC does not define an order for provisional responses.

[wmasilva]

In the RFC3260, https://datatracker.ietf.org/doc/html/rfc3960#section-3.2 , about ringing and tone generation:

     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.

Probably we could have an option to change the policy, instead of just ignore it.

[wmasilva]

On solucion could be to play the ringback using a lua script in the event execute_on_ring:

<action application="bridge" data="{disable_rtp_auto_adjust=true}[execute_on_ring=lua execute_on_ring.lua][^^:codec_string=PCMA][^^:absolute_codec_string=PCMA]sofia/main/sip:00310@192.168.10.1:6070"/>

when the 180 arrives it executes the file execute_on_ring.lua, but i can't managed to play nothing to aleg... it only play my file once it answered...

This is my lua:

dofile("/usr/local/freeswitch/scripts/utils.lua")

freeswitch.consoleLog("info", "execute on ring \n")
   

--session:execute("info")
endpoint_disposition = session:getVariable("endpoint_disposition") or ""
originating_leg_uuid = session:getVariable("originating_leg_uuid") or ""

log.info("endpoint_disposition: ".. endpoint_disposition)
log.info("originating_leg_uuid: ".. originating_leg_uuid)

if (endpoint_disposition == "EARLY MEDIA") then
		
	--log.info("uuid_ring_ready ".. originating_leg_uuid .. "")
	--api:execute("uuid_ring_ready", originating_leg_uuid)

	--log.info("uuid_pre_answer ".. originating_leg_uuid .. "")
	--api:execute("uuid_pre_answer", originating_leg_uuid)
	
	log.info("uuid_broadcast ".. originating_leg_uuid .. " /usr/local/freeswitch/sounds/suite-espanola-op-47-leyenda.wav") 
	api:execute("uuid_broadcast", originating_leg_uuid .. " /usr/local/freeswitch/sounds/suite-espanola-op-47-leyenda.wav")


	--log.info("uuid_broadcast ".. originating_leg_uuid .. " playback::/usr/local/freeswitch/sounds/suite-espanola-op-47-leyenda.wav") 
	--api:execute("uuid_broadcast", originating_leg_uuid .. " playback::/usr/local/freeswitch/sounds/suite-espanola-op-47-leyenda.wav")

end

Edit: full log when making the call when trying to play local audio in aleg when ringing received:

freeswich.log.txt

[skainz92]

In my opinion freeswitch should not try to generate the ringing, but just relay the ringing message.
What if - you are in the united states and you have a customer in Mexico. Most likely they have a different ringback tone than the US.
Lets say this customer calls somebody in Russia.
In that case - if the called party doesn't provide the russian ringback in early media, i think the ringback should be generated by the calling-side. The calling party will be used to their default ringback.

[haeferer]

In some countries, the correct detection of ringing (SIP 180, with audio detection as a fallback) is part of the regulatory rules for B2C outbound calls. These regulations specify the minimum number of seconds a customer’s phone must ring before the calling company can hang up, and the maximum number of seconds the phone is allowed to ring before the calling company must hang up.

In the end, a SIP 180 "Ringing" signal should only be generated by a device that is actively informing a user, and it should simply be passed down to the originating caller.

[ThomasLobker]

• Sending 180 after 183 is not illegal behavior according to any RFC
• 180 and 183 are not the same and cannot be treated as the same
• If FreeSWITCH is bypassing media, then it should just relay the 180 after a 183
• If FreeSWITCH is not bypassing media, then it should generate local ringback tone when the 180 arrives and there is no incoming early media (yet)

Especially the third point should be fairly easy to fix I think. Hoping this will get some priority.

[skainz92]

Found two similar issues in the sofia-sip rep:

freeswitch/sofia-sip#117
freeswitch/sofia-sip#106

The first one is about 100rel and PRACK's not getting sent when a 180 is received. ( after an 183 )
We're using 100rel too, and i can confirm the PRACK's do not get sent in this scenario.
I think this should be considered too.

[wmasilva]

I think in this case is not a sofia issue (or i couldn't see it), here it is a full log with sofia debug level for the sipp scenario:

freeswich-sipdebug.log.txt

sipp_uas.xml.txt

[skainz92]

Has anybody found a workaround?