Wrong SDP details, RTP and NO Audio


#1

Hello Team,

As a carrier we have a customer using Asterisk version 13, and we authenticating the SIP registration over an IP. [ Trunk is Registered ]
On her INVITES header, here is what I noticed,

v=0
o=root 1995318922 1995318922 IN IP4 192.168.3.17
s=Asterisk PBX 13.16.0-rc2
c=IN IP4 41.58.129.215
t=0 0
m=audio 11300 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

While doing a RTP stream analysis on a dialed call, I noted that the source and destination IP’s differs just as shown on her SDP shared above.

For the SIP trunk registration herein customer config on her ASTERISK Server

host = 42.74.2.20
trunkname = VOIPsgn ; GUI metadata
context =
hasexten = no
hasiax = no
hassip = yes
registeriax = no
registersip = no
trunkstyle = voip
port=5060
qualify = no
insecure = port
;fromdomain = 42.74.2.20
disallow = all
allow = alaw,g729
;allow = ulaw,alaw,g729
trustpid = yes
sendrpid = yes
cid_number =

We the above peering, we having NO Audio and I am thinking customer should add the following on her SIP Trunk header between us the carrier and her Asterisk

type = transport
protocol = udp
bind = 0.0.0.0:5060 [ I don’t know if customer actually need this but no error in trying ]
allow_reload = yes
; NAT settings
local_net = 192.168.3.0/24
external_media_address = 41.58.129.215 [customer server IP where the call is originating from]
external_signaling_address = 41.58.129.215
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
canreinvite=yes
canreinvite=update,nonat
directrtpsetup= yes

I need help as calls aren’t having Audio


#2

This seems to be a mixture of several different configuration files. I suspect it comes from users.conf, which nobody, except possibly FreePBX uses.

Some of the parameters seem to relate to pjsip.conf, some to sip.conf, and some to iax.conf. The first two are alternative SIP channel drivers, which would not both be present in normal configurations. IAX is an alternative VoIP protocol.

Of the chan_sip options, directrtpsetup has never been officially supported, and may well be the real problem, and canreinvite should be called directmedia, but, more importantly, only the last one wins (at least when present in sip.conf.

I think external signalling and external media address only apply in pjsip.conf.

If they are using FreePBX, we would normally redirect them to https://community.freepbx.org/ as we are not experts on how the GUI constrains the use of configuration files.


#3

Thank you. I appreciate.

pjsip.conf was what I added which only work on FreePBX.

what exactly can we now look at to fix this issue?


#4

Your post is all over the place, so it’s hard to answer that. You haven’t specified which SIP channel driver is in use - they are vastly different. You also haven’t specified what about the SDP is wrong (the fact that the o= line is 192.168.3.17 won’t itself cause a problem, and in current 13 I believe no longer occurs). You also didn’t specify what about the RTP is wrong. You need to give specifics.


#5

The file you provided contains lines that cannot all appear in the same file.

pjsip.conf is a standard Asterisk file, although FreePBX probably takes ownership of it and stops you directly modifying it.


#6

The source IP on the RTP streams differs from the RTP destination IP on the same stream.


#7

Without specifying which SIP channel driver I can’t really help then, as they vastly differ. If you are using PJSIP then I’d suggest using the latest version of 13 - as the version you are referring to is almost a year and a half old, and things may have changed. Also there is an option in pjsip.conf which can be used to bind RTP to a specific IP address, otherwise we rely on the operating system itself to choose.


#8

The SIP channel driver the customer is using is === chan_sip.so


#9

Then perhaps someone else can provide assistance. I don’t recall its precise behavior and don’t help with it.


#10

Thank You Heartily @jcolp


#11

If FreePBX weren’t involved, I would say that your customer needed to start over in configuring sip.conf, and read the actual documentation and sample configuration.

It appears that chan_sip thinks it is in a non-NATed environment, which is probably true because they have neither externhost nor externaddr. I think the only way it would give a different media and signalling address is if directmedia (historic name canreinvite) was enabled, which it would be with that configuration, if it doesn’t think there is NAT. The use of the, unsupported, directrtpsetup may cause this, even when externaddr and directmedia are set appropriately.

Please note that I have not, personally, used NAT configurations in anger, so I’m not the best person to give chan_sip NAT settings.


#12

truly no NAT on the customer network, IP block 192.168.X.X/24 all the way. I will request customer add canreinvite = yes. I will let you know status afterwards. @david551 Am taken time out to thank you guys heartily. cheers


#13

I think they want to delete all canreinvite’s and add directmedia=no. Also delete directrtpsetup.

directmedia is the new name for canreinvite.


#14

Not related to the ongoing discussion, just for readers…FreePBX doesn’t use users.conf.