Bahadir M
asked on
Asterisk - Random RTP problem
Good day,
I am trying to trace and fix a RTP problem on our Asterisk PBX (13.21), to remote SIP carrier(s). Our PBX setup is like following:
Webphone (with STUN) -> PBX (No NAT) -> Intermediary Carriers -> Carriers (Tier1, Tier2)
Calls are working most of the time, however, sometimes some calls are reported to blank or dead calls when it reaches to the web phone. Investigating these calls through network, 5060 connection seems fine like following:
Checking RTP messages, I can clearly see that the RTP coming from carrier stops at second 56 and no other media is received from carrier after that point, however PBX still tries to send the media to carrier after the answer is received.
The above screenshot is when the RTP from carrier stops and RTP from PBX starts.
The puzzling thing is that this happens randomly, and intermediary carrier states that this happens on the tier 1 carriers as well and shoots the ball to my side. Unfortunately trying another intermediary carrier, I still face those blank call issues, but of course there is no guarantee that these two independent carriers are not using the same tier 1 or 2 carriers. It is also possible that, we just missing a small detail for this to happen.
More debug information:
Peer entry:
Dial plan entry:
Any help, comment or direction would be much appreciated on to spot why this is happening and what can be done.
Many Thanks
B.M.
I am trying to trace and fix a RTP problem on our Asterisk PBX (13.21), to remote SIP carrier(s). Our PBX setup is like following:
Webphone (with STUN) -> PBX (No NAT) -> Intermediary Carriers -> Carriers (Tier1, Tier2)
Calls are working most of the time, however, sometimes some calls are reported to blank or dead calls when it reaches to the web phone. Investigating these calls through network, 5060 connection seems fine like following:
Checking RTP messages, I can clearly see that the RTP coming from carrier stops at second 56 and no other media is received from carrier after that point, however PBX still tries to send the media to carrier after the answer is received.
The above screenshot is when the RTP from carrier stops and RTP from PBX starts.
The puzzling thing is that this happens randomly, and intermediary carrier states that this happens on the tier 1 carriers as well and shoots the ball to my side. Unfortunately trying another intermediary carrier, I still face those blank call issues, but of course there is no guarantee that these two independent carriers are not using the same tier 1 or 2 carriers. It is also possible that, we just missing a small detail for this to happen.
More debug information:
Peer entry:
host=XXX.XXX.XXX.XXX
type=peer
disallow=all
allow=ulaw
allow=alaw
allow=gsm
dtmfmode=rfc2833
context=default
qualify=no
insecure=port
nat=auto_force_rport ; tried one by one and together when I can, no, comedia or force_rport, doesn't make a difference
directmedia=nonat ; no or yes doesn't make a difference
prematuremedia=no ; giving yes, doesn't make a difference
progressinband=yes ; never or no, doesn't make a difference when prematuremedia=yes
sendrpid = yes ; no doesn't make a differenceDial plan entry:
Dial(SIP/33#1${EXTEN:-10}@CarrierA,30,tToR)Any help, comment or direction would be much appreciated on to spot why this is happening and what can be done.
Many Thanks
B.M.
ASKER
Hi Noci,
Many thanks. I should have mentioned that 5060 src and RTP src is different. Sorry, that is my bad description indeed. 5060 is connected by the proxy carrier while RTP is connected from the tier 1 or tier 2 carrier, media is not proxied by the intermediary carrier. The sample given above, SDP sample is from proxy while of course RTP is from the real carrier.
NAT wise, the asterisk server is on a public network, has a public IP and there is only iptables with no SIP ALG module. UDP 5060 and RTP ranges are properly whitelisted on iptables and is same as on rtp.conf. So as having externip correctly specified on sip.conf.
After checking your point, I re-read the SDP messages. Checking 183 & 200, "Connection info" & "Media", I see that the IP address and port is as same with the RTP received as shown above. You are right that probably the first RTP is for dial tone/ring, however, it is strange that no other RTP activity is done after the ring tone.
Side note, I forgot to check RTCP, and seeing also now this:
I wonder if RTCP that is failed to be sent to Carrier would cause any issues? Though this repeats several times between 183 to 200, I think it is 5 seconds.
So further comments would be appreciated considering the details above. I am also open for advice on what I can do to find where this is caused by as I am out of options :)
B.M.
Many thanks. I should have mentioned that 5060 src and RTP src is different. Sorry, that is my bad description indeed. 5060 is connected by the proxy carrier while RTP is connected from the tier 1 or tier 2 carrier, media is not proxied by the intermediary carrier. The sample given above, SDP sample is from proxy while of course RTP is from the real carrier.
NAT wise, the asterisk server is on a public network, has a public IP and there is only iptables with no SIP ALG module. UDP 5060 and RTP ranges are properly whitelisted on iptables and is same as on rtp.conf. So as having externip correctly specified on sip.conf.
After checking your point, I re-read the SDP messages. Checking 183 & 200, "Connection info" & "Media", I see that the IP address and port is as same with the RTP received as shown above. You are right that probably the first RTP is for dial tone/ring, however, it is strange that no other RTP activity is done after the ring tone.
Side note, I forgot to check RTCP, and seeing also now this:
I wonder if RTCP that is failed to be sent to Carrier would cause any issues? Though this repeats several times between 183 to 200, I think it is 5 seconds.
So further comments would be appreciated considering the details above. I am also open for advice on what I can do to find where this is caused by as I am out of options :)
B.M.
Any other ICMP traffic available? Appearantly the carrier doesn't know how to route the packets it was sent. (Check inside the ICMP for which packet they apply).
ASKER
The RTCP problem, we get over with rctp-mux=yes on the carrier settings so that we can send RTCP from RTP port. However, that wasn't a solution for the RTP problem. We found one of the intermediary carriers we use also proxies RTP from underlying carriers and they keep the packet logs except the content. I am waiting now for them to send me the logs for some sample calls so I can see if they have sent the RTP. At least this way I can be sure if it is caused by the datacenter network having some sort of a SIP ALG causing these random issues.
Many thanks for the comment. I expect it to receive the logs hopefully today. I will update this thread with the results.
Many thanks for the comment. I expect it to receive the logs hopefully today. I will update this thread with the results.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
56.39.... ACK is sent
56.28... Last RTP received... are you sure those RTP isn't from the dial tone?... (That is sent from the remote system).
--
The RTP doesn't need to come from the same address as the SIP server. The media might go through different channels.
The RTP session can be built between the ACTUAL endpoint with several SIP intermediates... (not a commonly seen thing, but it can happen).
Most VOIP ISP run a proxy to be able to provide "lawful intercept" and all media go through the proxy.., the proxy still doesn;t need to have the same IP address as the SIP server..
This whole issue looks like one-sided calls, which might happen with incompattible NAT settings.
Do you have ALL possible RTP ports (UDP) forwarded to YOUR VOIP server on your router.
(Or does your setup handle Near end Nat and Far End Nat correctly?).
You're not receiving data can you verify the data in the 183 SDP & 200 Accept messages to hold valid port numbers?