Voice Payload size with ATT to FreePBX (asterisk 13) to Riedel intercom payload error expected 120 get 240

General Help
1

Hi

running FreePBX 10.13.66-22, and Asterisk 13 recently switched to Asterisk 13.

Our service comes from ATT VoIP and the call is processed thru the FreePBX the out as a trunk to the Riedel intercom.

When using asterisk 11 all was OK

After switching to Asterisk 13 the Riedel Artist intercom is no linger happy when a call comes in from ATT VIA a cell phone or a POST line i get the error below

Invalid RTP Payload Length,Node/002/Client/05/VoIPLocal/7,Major,Received RTP payload type 0 with invalid length 240 (expected 160).

calls within the FreePBX with asterisk 13 and calls from another number (different locations) from ATT VOIP service properly.

thsi leads me to believe that ATT is sending the call as Payload 160 on one type of call and as 240 on another. Furthermore it appears that the Asterisk 11 masked the change and Asterisk 13 does not. I do not know if this is normal behavior of asterisk. If i switch back to asterisk 11 (nice how FreeBPX lets me do this)
the failure goes away and if i switch back to asterisk 13 the problem reappears.

Otherwise the FreePBX with asterisk 13 works as expected.

i have the following questions.

  1. how can i tell on a call by call basis what payload is ATT sending?
  2. assuming i am correct is it normal to receive different payloads on different call types?
  3. is there a way to set the FreePBX 10.13.66-22 with asterisk 13 to behave as asterisk 11 did and mask the issue bu always have a payload of 160 on the trunks going toward the Riedel intercom?

Thank you

2

You might try cross-posting this to one of the Asterisk forums, since it appears to be the underlying Asterisk (version 13) that’s giving you problems. While there’s every possibility someone here might be able to help you, going to the source (as a backup) can’t hurt.

Short of that, I think there is a way to set the system to use a shorter RTP packet size in one of the config files in /etc/asterisk.

3

I’ve seen after doing a distro and asterisk upgrade that some settings under SIP Settings were confused after the upgrade.

Go over your SIP Settings and [i assume you use] ChanSIP settings to make sure everything is in place.

After making changes please reboot your system.

4

thanks you for the ideas, the cross post to asterisk org was done, and i checked the settings and all looks normal

also a ticket was opened with ATT.

does anyone know of a way i can look at a call to see what payload type ATT is using?

5

Just a guess here: the AT&T<->Asterisk link is using g729 (which normally uses 30 ms packetization) and Asterisk is transcoding to ulaw on the Riedel side. There are several ways to see what is actually happening.

You can issue
sip set debug on
at the Asterisk command line, which will cause all SIP packets to appear in the Asterisk log (along with what would normally be there).

Or, you can run tcpdump in a root shell to capture all packets (including SIP and RTP) to a file, which you can then move to your workstation e.g. with sftp and view / analyze with Wireshark.

Here is the SDP for a typical INVITE from my trunking provider (not AT&T):

v=0
o=Sonus_UAC 483212 586479 IN IP4 67.231.5.112
s=SIP Media Capabilities
c=IN IP4 67.231.5.79
t=0 0
m=audio 45708 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

The ‘a’ attributes indicate they can handle PCMU (a.k.a. G.711U or ulaw) and G729.
ptime indicates that the provider wants 20 ms of audio in each RTP packet.
You may also see maxptime, which means they will accept up to the amount specified.

When Asterisk responds, the SDP in the 183 or 200 response indicates the codec selected and the amount of audio it wants or will accept per RTP packet.

A similar negotiation occurs for the Asterisk<->Riedel part of the call.

The actual RTP will show the payload type being used and its length. ulaw requires eight payload bytes per millisecond of audio; g729 only one.

Please report what happens in the failing case (with Asterisk 13) as well as on your working system.

1 Like
6

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