I was using Asterisk 1.8.22.0 and configured more than 100 extensions and 4 to 5 SIP trunks some years ago. Suddenly I planned to upgrade my asterisk box. I configured the new asterisk server with Asterisk 16.29.0. every thing is working fine but my one sip trunk is registered but when incoming or outgoing calls land on this server both receiver and caller can not hear the voice of each other.
I investigate the RTP Packet and found that my asterisk server user new SSRC after 200 OK.
Below are the configuration details.
[general]
context = default
allowguest = yes
allowoverlap = yes
bindport=5060
udpbindaddr = 0.0.0.0
tcpenable = no
tcpbindaddr = 0.0.0.0
transport = udp
srvlookup = yes
videosupport = yes
localnet=10.5.0.0/255.255.0.0
externip = 0.0.0.0
qualify=yes
nat=yes
subscribecontext = default
[PTCL]
fromuser = XXXXXXXXXXX
authname = XXXXXXXXXXX
host = XX.XX.XX.XX
type = peer
nat = comedia
dtmfmode=inband
allow = ulaw
allow = alaw
qualify = yes
directmedia=no
context = UAN-Calling
Kindly help me for the same and Thanks in advance.
There’s no Asterisk Team here; this is a peer support forum.
That’s probably more correct (Asterisk failed to track SSRCs properly before), but no-one else seems to have reported a problem. What phones are you using and who is your service provider? Also, it is not clear to which direction of call setup this applies. Seeing an outgoing SSRC before OK on an outbound call, means various things have to have been set up for early media.
chan_sip is no longer supported, so, if you do find a bug, it is unlikely to get fixed.
You haven’t specified any codecs. I’m not sure if the default is none or all, but none obviously won’t work, and all breaks Asterisk with some versions, and can break things generally by making requests excessively large.
This is not meaningful. I’m not sure if this will be taken literally or treated as unset. In the former case, it could well end up with the SDP indicating on hold.
Although this is questionable, it is usually harmless, and presumably worked before.
I assume PTCL is a provider. If they really need this, they don’t understand how to use SIP. If they really need this, you need to be be very sure that your externip is correct, as, if it isn’t, there will be a standoff, with neither side able to work out the media address of the other.
Really, to see what is happening, we need the sip set debug on output, showing the SDP handshake.
This is unusual, and if rfc2833 really isn’t the correct setting, is another mark against the provider, but shouldn’t have an impact.
I assume these are being used with the FreePBX meanings, as Asterisk extensions only appear in extensions.conf, not in sip.conf, and trunk is note a defined term for SIP.
This is normally considered a security problem, but can be necessary, on chan_sip, if there are too many possible source addresses from a provider. However, in that case, context, nat, codecs, dtmfmode, etc., for general should be the same as those for the provider. The equivalent setting for chan_pjsip should not be necessary, as address ranges can be given.