Asterisk not receiving RTP packets in recording setup with Cisco CUCM

Asterisk Asterisk Support
1

I am trying to setup a call recording via a cisco unified callmager (cucm), asterisk and a softphone client. The SIP signaling appears to be correct, but asterisk does not receive any rtp packets from the softphone client.

The Setup in more detail:
The CUCM registers a sip trunk. On inbound calls on the sip trunk, the cucm sends a variety of invites to establish a two way connection between the softphone client and the sip trunk with asterisk as recording participant:

  1. CUCM invites asterisk in sendonly mode; tells asterisk the media address of the softphone. Asterisk accepts the invite as expected (twice a call for two separate udp ports)
  2. CUCM invites the softphone client and tells the client the media address of the sip trunk
  3. CUCM invites the softphone client and tells the client the media address of asterisk in receiveonly mode (twice a call for the two different udp ports from 1.)
  4. CUCM invites the softphone client without a media address in inactive mode (I assume to enable future sip signaling)

The asterisk console logs and wireshark captures indicate, that the sip signaling (media addresses and ports) is correct. The sip trunk caller can also talk to the softphone client, proving that the rtp stream between the sip trunk and the softphone client is setup correctly (wireshark capture also shows inbound and outgoing rtp packets between the softphone client and the sip trunk).
The network capture also shows outgoing rtp packets from the softphone client towards asterisk. Wireshark captures show that these packets also reach the asterisk machine on the port specified in the sdp but are not received by asterisk. The recording contains only silence and the enabled rtp debug shows no incoming packets in the asterisk console.
The asterisk recording dialplan consists of four statements; answer, start mixmonitor, wait till the call is finished, hangup. The asterisk log shows that these steps are executed as expected. the recording is started and finished accordingly but contains only silence.
A control routing directly between asterisk and the cucm (without the softphone client) is working as expected and recording successfully.

Further analysis with netstat on the asterisk machine indicates, that asterisk is not listening on the udp ports from the sdp, even though the invite was successful and not rejected. When using the direct routing without softphone the udp ports are listed in the netstat output.

Without any error message it is very difficult to figure out why asterisk is not listening on the udp ports / not receiving the rtp packets. Therefor i would be very thankful for any suggestion or advice on potential issues or where to investigate further.

2

What do you mean by SIP Trunk. It is not a term used in RFC 3261 and is not, normally at least, a term used in relation to Asterisk.

Also, with CUCM I would identify by IP address, not register.

I got lost later on. I think you need to provide diagrams and complete logs. (As a technical point, a SIP client can never receive an INVITE, but I don’t think you really mean a SIP client, I think you mean a phone, as a against a PABX.)

Also CUCM tends to be a law unto itself,

3

Hi David, thanks for the reply. Sorry if the setup description is confusing, i will try to narrow it down to the specific issue i am having with asterisk:

Asterisk receives an invite for a configured endpoint. The SIP exchange is successful and asterisk enters the dialplan. Here is the problem: asterisk does not receive any rtp packets after successful session initiation.

A capture of the traffic shows, that rtp packets are arriving at the machine. The ip address of the mediastream, the source and destination ports are exactly as specified by the sdp.

Do you have any idea why asterisk might reject the incoming packets (as asterisk does not open the port for incoming packets)? Netstat also indicates, that the udp ports specified by the sdp are not bound. So it looks like asterisk is not listening for incoming packets.

This is the answer from asterisk (172.xx.xx.xx → 82.yyy.yyy.yyy) to the invite:


Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 310702126 310702126 IN IP4 172.xx.xx.xx
    Session Name (s): Asterisk
    Connection Information (c): IN IP4 172.xx.xx.xx
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 29338 RTP/AVP 9 8 0 112 3 97 101
    Media Attribute (a): rtpmap:9 G722/8000
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): rtpmap:0 PCMU/8000
    Media Attribute (a): rtpmap:112 AAL2-G726-32/8000
    Media Attribute (a): rtpmap:3 GSM/8000
    Media Attribute (a): rtpmap:97 iLBC/8000
    Media Attribute (a): fmtp:97 mode=20
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-16
    Media Attribute (a): ptime:20
    Media Attribute (a): maxptime:150
    Media Attribute (a): sendrecv
    [Generated Call-ID: 3e77a300-1ef19da4-704366-65dad252@82.yyy.yyy.yyy]

And this is the final sdp from the ACK step (82.yyy.yyy.yyy → 172.xx.xx.xx):

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): CiscoSystemsCCM-SIP 53591281 1 IN IP4 10.zzz.zzz.zzz
    Session Name (s): SIP Call
    Connection Information (c): IN IP4 10.zzz.zzz.zzz
    Bandwidth Information (b): TIAS:64000
    Bandwidth Information (b): AS:80
    Time Description, active time (t): 0 0
    Session Attribute (a): cisco-mari:v1
    Session Attribute (a): cisco-mari-rate
    Media Description, name and address (m): audio 24504 RTP/AVP 8 98
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): sendonly
    Media Attribute (a): rtpmap:98 telephone-event/8000
    Media Attribute (a): fmtp:98 0-15
    [Generated Call-ID: 3e77a300-1ef19da4-704366-65dad252@82.yyy.yyy.yyy]

As far as i understand, the media address is agreed to be 10.zzz.zzz.zzz and the following trace shows an stream of rtp packet arriving at 172.xx.xx.xx on port 29338 originating from 10.zzz.zzz.zzz port 24504. But as previously described asterisk does not listen on the specified port 29338. The address and port in the following sample rtp packet look correct to me.

Internet Protocol Version 4, Src: 10.zzz.zzz.zzz, Dst: 172.xx.xx.xx
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)
    Total Length: 200
    Identification: 0x0bff (3071)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 121
    Protocol: UDP (17)
    Header Checksum: 0x20d8 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 10.zzz.zzz.zzz
    Destination Address: 172.xx.xx.xx

User Datagram Protocol, Src Port: 24504, Dst Port: 29338
    Source Port: 24504
    Destination Port: 29338
    Length: 180
    Checksum: 0xb294 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 2]
    [Timestamps]
    UDP payload (172 bytes)

I would be very thankful for any idea why asterisk is not listening on the specified port.

4

The Cisco has set the call on hold, so Asterisk will play music on hold to the other party.

SDP doesn’t agree addresses. Each side says which address it is receiving on.

172.xx is excessively redacted. It isn’t possible to tell whether it is a public or a private address. If the latter, there seems no point in redacting any of the addresses.

5

If i understand sdp correctly, the sendonly attribute should result in an unidirectional media stream. From RFC 3264:

5.1 Unicast Streams
If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the “a=sendonly” attribute.

Is this known behavior of the CUCM to place calls marked with sendonly on hold? The rtp capture shows inbound packets on the asterisk machine and there is no music being played when accepting the call. It doesn’t look like the call was set on hold.

6

It’s also the standard way of signalling on hold, and the one used by phones. Asterisk traditionally sources:

https://www.rfc-editor.org/rfc/rfc3264#section-8.4

7

That could explain quite a lot. I will look into this, thanks.

8

That was in fact the problem. Adjusting the settings in the cucm solved the issue. Thank you very much for your help!

9

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