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,
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
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.
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.
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.
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.
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