Direct Media Issue with Dial application annoucement

bchuter · February 7, 2024, 3:30am

Hi there

I need some help with an issue I’m seeing when using the Dial() application with the “A” option which allows to play an announcement to both parties.

I have the following contexts in my dialplan

I have a CUCM SIP trunk terminated on the Asterisk which uses the “incoming” context.

[incoming]
exten => _[12]0XX,1,GotoIf($[${DEVICE_STATE(PJSIP/${EXTEN})} != UNAVAILABLE]?10:15)
exten => _[12]0XX,10,Dial(PJSIP/${EXTEN},300,aA(call-recorded-2:call-recorded-2))
exten => _[12]0XX,11,Busy(10)
exten => _[12]0XX,15,Congestion(10)

I have a device registered directly on the Asterisk and it uses the “outbound” context

[outbound]
exten => _3XXX,1,GotoIf($[${DEVICE_STATE(PJSIP/${EXTEN})} != INVALID]?10:15)
exten => _3XXX,10,Dial(PJSIP/${EXTEN},300)
exten => _3XXX,n,Congestion(10)
exten => _3XXX,15,Dial(PJSIP/${EXTEN}@CUCM,300,aA(call-recorded-2:call-recorded-2))
exten => _3XXX,n,Congestion(10)

All devices are set with “direct_media = yes”

I have the following SIP end devices:
Flex SIP Device registered directly on Asterisk on Extension “1002”
Cisco Phone (Ext 3100) which is connected through a SIP trunk terminated on the Asterisk

Now the above is working, in that it does play my required audio announcement to both called and calling parties.

However, when making a call from the Flex SIP Device registered on the Asterisk outbound to Cisco phone on the CUCM over the SIP trunk, then direct media is working as intended.
I have check a Wireshark capture as well.
The initial setup is with RTP flowing to/from the Asterisk to both devices for the announcement and then you see new INVITE from the Asterisk to both devices with new SDP which sets the RTP to flow directly. This is perfect and exactly what I need/want.

I have checked the verbose output on the Asterisk CLI and get the following output when making this call

Executing [3100@outbound:1] GotoIf("PJSIP/1002-00000051", "0?10:15") in new stack
    -- Goto (outbound,3100,15)
    -- Executing [3100@outbound:15] Dial("PJSIP/1002-00000051", "PJSIP/3100@CUCM,300,aA(call-recorded-2:call-recorded-2)") in new stack
    -- Called PJSIP/3100@CUCM
    -- PJSIP/CUCM-00000052 is ringing
       > 0x7f320001b790 -- Strict RTP learning after remote address set to: 192.168.30.130:19012
    -- PJSIP/CUCM-00000052 answered PJSIP/1002-00000051
       > 0x560740f33e60 -- Strict RTP learning after remote address set to: 192.168.25.21:10150
       > 0x560740f33e60 -- Strict RTP switching to RTP target address 192.168.25.21:10150 as source
    -- <PJSIP/CUCM-00000052> Playing 'call-recorded-2.slin' (language 'en')
    -- <PJSIP/1002-00000051> Playing 'call-recorded-2.slin' (language 'en')
       > 0x7f320001b790 -- Strict RTP switching to RTP target address 192.168.30.130:19012 as source
    -- Channel PJSIP/CUCM-00000052 joined 'simple_bridge' basic-bridge <bbfd13bf-6211-4ca8-9ab4-c9c8c76ad704>
    -- Channel PJSIP/1002-00000051 joined 'simple_bridge' basic-bridge <bbfd13bf-6211-4ca8-9ab4-c9c8c76ad704>
       > Bridge bbfd13bf-6211-4ca8-9ab4-c9c8c76ad704: switching from simple_bridge technology to native_rtp
       > Remotely bridged 'PJSIP/1002-00000051' and 'PJSIP/CUCM-00000052' - media will flow directly between them
    -- Channel PJSIP/1002-00000051 left 'native_rtp' basic-bridge <bbfd13bf-6211-4ca8-9ab4-c9c8c76ad704>
    -- Channel PJSIP/CUCM-00000052 left 'native_rtp' basic-bridge <bbfd13bf-6211-4ca8-9ab4-c9c8c76ad704>
  == Spawn extension (outbound, 3100, 15) exited non-zero on 'PJSIP/1002-00000051'

But when making a call from the Cisco phone inbound through the Asterisk to the Flex SIP Device, it is still working for the announcement which is playing on both parties
But now after the announcement is completed it is NOT moving the RTP stream to direct media and remains with the RTP now flowing through the Asterisk for both devices.

I have again checked the verbose output on cli for this call (see below) and you can clearly see it does not behave the same as the first instance shown above.
I can’t see the two messages “switching from simple_bridge technology to native_rtp” and “media will flow directly between them”, it simply keeps the RTP and NO new INVITE (with SDP) from Asterisk are seen in a wireshark capture. It also shows that this is “Strict RTP learning complete - Locking on source address” which tells me it is keeping the RTP on the Asterisk.

Executing [1000@incoming:1] GotoIf("PJSIP/CUCM-00000053", "1?10:15") in new stack
    -- Goto (incoming,1000,10)
    -- Executing [1000@incoming:10] Dial("PJSIP/CUCM-00000053", "PJSIP/1000,300,aA(call-recorded-2:call-recorded-2)") in new stack
    -- Called PJSIP/1000
    -- PJSIP/1000-00000054 is ringing
       > 0x7f320001b790 -- Strict RTP learning after remote address set to: 192.168.25.21:10154
    -- PJSIP/1000-00000054 answered PJSIP/CUCM-00000053
       > 0x560740f33e60 -- Strict RTP learning after remote address set to: 192.168.30.130:19878
       > 0x560740f33e60 -- Strict RTP learning after remote address set to: 192.168.30.130:19878
       > 0x560740f33e60 -- Strict RTP switching to RTP target address 192.168.30.130:19878 as source
    -- <PJSIP/1000-00000054> Playing 'call-recorded-2.slin' (language 'en')
    -- <PJSIP/CUCM-00000053> Playing 'call-recorded-2.slin' (language 'en')
       > 0x7f320001b790 -- Strict RTP switching to RTP target address 192.168.25.21:10154 as source
    -- Channel PJSIP/1000-00000054 joined 'simple_bridge' basic-bridge <1b7bc93d-93f0-443f-8ad2-ef6aefa5669b>
    -- Channel PJSIP/CUCM-00000053 joined 'simple_bridge' basic-bridge <1b7bc93d-93f0-443f-8ad2-ef6aefa5669b>
       > 0x7f320001b790 -- Strict RTP learning complete - Locking on source address 192.168.25.21:10154
       > 0x560740f33e60 -- Strict RTP learning complete - Locking on source address 192.168.30.130:19878
    -- Channel PJSIP/1000-00000054 left 'simple_bridge' basic-bridge <1b7bc93d-93f0-443f-8ad2-ef6aefa5669b>
    -- Channel PJSIP/CUCM-00000053 left 'simple_bridge' basic-bridge <1b7bc93d-93f0-443f-8ad2-ef6aefa5669b>
  == Spawn extension (incoming, 1000, 10) exited non-zero on 'PJSIP/CUCM-00000053'

Now I must add that I have tested again with a small tweak to the Dial() string in my contexts
As seen in both the “inbound” and “outbound” I have shared above, I had to add an additional option “a”, without using the additional “a” option in both call scenarios I then only get the announcement on the called party end, and not the calling party end. The only way I could fix this was to enable the additional “a” option (which states: Immediately answer the calling channel when the called channel answers in all cases)

If I remove the “a” option in the scenario where my direct media is failing above (Cisco calls Flex SIP Device on Asterisk) then the RTP does flow directly after the annoucement, BUT then I only hear my announcement on the Called party end and not the calling party end.

It seems when I force the Calling party end to answer immediately with the “a” option enabled, this is what breaks the Direct Media

Here is the verbose output of the CLI when the “a” option is removed from the “inbound” context used by the CUCM trunk
You can then immediately see it says “media will flow directly”

Executing [1000@incoming:1] GotoIf("PJSIP/CUCM-00000055", "1?10:15") in new stack
    -- Goto (incoming,1000,10)
    -- Executing [1000@incoming:10] Dial("PJSIP/CUCM-00000055", "PJSIP/1000,300,A(call-recorded-2:call-recorded-2)") in new stack
    -- Called PJSIP/1000
    -- PJSIP/1000-00000056 is ringing
       > 0x560740f33e60 -- Strict RTP learning after remote address set to: 192.168.25.21:10158
    -- PJSIP/1000-00000056 answered PJSIP/CUCM-00000055
    -- <PJSIP/1000-00000056> Playing 'call-recorded-2.slin' (language 'en')
    -- <PJSIP/CUCM-00000055> Playing 'call-recorded-2.slin' (language 'en')
       > 0x560740f33e60 -- Strict RTP switching to RTP target address 192.168.25.21:10158 as source
       > 0x7f320001b790 -- Strict RTP learning after remote address set to: 192.168.30.130:25584
    -- Channel PJSIP/1000-00000056 joined 'simple_bridge' basic-bridge <c966bf6e-9345-41bb-a204-c9debfe63499>
    -- Channel PJSIP/CUCM-00000055 joined 'simple_bridge' basic-bridge <c966bf6e-9345-41bb-a204-c9debfe63499>
       > Bridge c966bf6e-9345-41bb-a204-c9debfe63499: switching from simple_bridge technology to native_rtp
       > Remotely bridged 'PJSIP/CUCM-00000055' and 'PJSIP/1000-00000056' - media will flow directly between them
       > 0x7f320001b790 -- Strict RTP learning after remote address set to: 192.168.30.130:25584
    -- Channel PJSIP/1000-00000056 left 'native_rtp' basic-bridge <c966bf6e-9345-41bb-a204-c9debfe63499>
    -- Channel PJSIP/CUCM-00000055 left 'native_rtp' basic-bridge <c966bf6e-9345-41bb-a204-c9debfe63499>
  == Spawn extension (incoming, 1000, 10) exited non-zero on 'PJSIP/CUCM-00000055'

My requirement is to have the announcement play to BOTH called and calling parties, and it must move the RTP to direct media once the announcement is completed.

Any of the experts able to assist me would be grateful.
If there are any suggestions on any alternative methods to try and achieve the same, I welcome them all

Thanks
Brad

jcolp · February 7, 2024, 9:57am

A debug level log[1] will generally include information about why things are being decided, such as not sending a re-INVITE.

[1] Collecting Debug Information - Asterisk Documentation

bchuter · February 7, 2024, 11:41pm

Hi @jcolp

Thank you very much for your helpful tip!

I have identified the issue after reviewing the debug output.
It was of course an issue in my configuration which was causing the issue.

The issue as seen in the below snipet of the debug, is that the two channels were negotiating with different codecs and thus causing a different outcome in the bridge.

[Feb  8 09:34:47] DEBUG[7162][C-0000000d] chan_pjsip.c:  PJSIP/1000-00000015 Native formats (ulaw)
[Feb  8 09:34:47] DEBUG[7162][C-0000000d] chan_pjsip.c:  
[Feb  8 09:34:47] DEBUG[7162][C-0000000d] chan_pjsip.c:  PJSIP/CUCM-00000014 Native formats (alaw)
[Feb  8 09:34:47] DEBUG[7162][C-0000000d] chan_pjsip.c:  
[Feb  8 09:34:47] DEBUG[7162][C-0000000d] bridge_native_rtp.c: Bridge '372e1d36-f86a-475e-ab13-d1baf20dab5f': Channel codec0 = (ulaw) is not codec1 = (alaw), cannot native bridge in RTP.

I had the order of the codecs swapped for my CUCM termination, which meant it is preferring ulaw over alaw. My system is all setup for alaw as the primary.
Once I had corrected this, I now have the desired result in both call directions and both are now reverting back to Direct Media after the announcement has been played.

Extension Defaults had:
allow = !all,alaw,ulaw

Trunk Defaults had:
allow = !all,ulaw,alaw

Many thanks
Brad

system · March 8, 2024, 11:41pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.