I have an external handset at home, which can register properly, and in the SIP registration, it shows the phones WAN IP. But there’s no audio during calls.
I did a packet capture, and all RTP traffic is being sent from the PBX to the phones LAN IP, 192.168.1.2 which is obviously unreachable, not the WAN IP. I also don’t see any return RTP from the phone in my capture, so it’s most likely sending to the PBX LAN IP also.
I’m sure I have something misconfigured somewhere, any thoughts on what?
Answer these questions for yourself - we don’t need the answers, but it’s got to be at least one of them:
Thanks for the advice cynjut.
I’ve already confirmed SIP-ALG isn’t in place, and added a STUN server on the phone, prior to posting.
I’ll check out the NAT on the phone.
Is there anything else I can try?
I’ll bet you find the phone NAT is set wrong.
The only other possibility is that you might need to redirect UDP ports 10000-20000 to your PBX on the network router back at the office.
So it appears this is an issue specific to the phone model we mainly use (Yealink T46S, latest firmware) in that it doesn’t properly utilize STUN. Other phone models and softphones work fine with STUN.
Thanks for the advice cynjut.
Except as an absolute last resort, don’t use STUN. A typical setup uses a ‘public’ STUN server – if it goes down, your phones stop working and you have no idea why. You’re not paying the owner and he offers no support; your only recovery is to use some other STUN server (until that too goes down). There are also technical reasons (beyond the scope of this thread) why they are often unreliable.
In the phone, for the account in question, set NAT to Disabled. In Advanced, set RPort to Enabled.
In the settings for the extension, set nat=yes (if using chan_sip).
In Asterisk SIP Settings, make sure that External Address and Local Networks are correctly set. If using chan_sip, check NAT settings there. If you change any network settings, restart Asterisk; Apply Changes is often insufficient.
As @cynjut noted, be sure that your RTP port range is forwarded to the PBX.
If you still have trouble, post which driver you are using and the settings for the extension (except of course for extension number, username and password).
Stewart1,
Thanks for the additional advice.
On the phone, I enabled rport and disabled nat.
On the pbx, I confirmed the external address and local networks were right, and also rebooted.
A TCP dump still shows the pbx is trying to ship the UDP packets to the phones local IP, 192.168.1.2
I have a different model that uses STUN, and it works, same extension config. It wont work with STUN disabled tho.
Heres the extension config. Driver is pjsip
[8000]
type=endpoint
aors=8000
auth=8000-auth
allow=g726,ulaw,alaw,gsm
context=from-internal
callerid=redacted
dtmf_mode=rfc4733
mailboxes=8000@device
mwi_subscribe_replaces_unsolicited=yes
transport=0.0.0.0-tls
aggregate_mwi=yes
use_avpf=no
rtcp_mux=no
ice_support=no
media_use_received_transport=no
trust_id_inbound=yes
media_encryption=sdes
timers=yes
media_encryption_optimistic=yes
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en
If it were working properly:
The phone sends an INVITE initiating the call. When audio is available (183 or 200 response), the SDP should contain c=IN IP4 with the PBX public IP address. This instructs the phone to send RTP to the proper address/port. Once the PBX receives RTP from the phone, it starts sending RTP back, using the same address and port that the incoming RTP came from. (Because of network delay, Asterisk may attempt to send a few RTP packets to the phone’s private address.)
I suspect that the PBX is putting its private IP address in the SDP. Can you please confirm that? If so, I’m guessing that it may be caused by Asterisk incorrectly treating the external phone as on the PBX LAN. Does that subnet also include 192.168.1.2? With the different model and STUN enabled, does the 183 or 200 response have Asterisk’s correct public IP in the SDP?
Stewart1, thanks for the advice. I grabbed 2 pcaps, one w/ no audio no stun, the other w/ audio and stun.
In the SDP packet body, both properly show “IN IP4 69.x.x.x” (redacted my WAN IP, but it showed correctly in the packet.) This seems weird to me, cause the RTP stream clearly still gets sent to the 192 local IP in the no-audio call, even tho the IN IP4 line is right.
As I looked through, found these in the SDP packet headers
No audio, no stun, capture: “sent-by address 192.168.1.2”
Working audio, using stun, capture: “sent-by address 69.x.x.x”
What do you make of that?
It appears that the RTP port range is not properly forwarded to the PBX. The range is set in Settings -> Asterisk SIP Settings, RTP Port Ranges (default is 10000 to 20000).
In your office router, check that this range of UDP ports is forwarded to the LAN IP address of the PBX. If this router is separate from your modem, confirm that it gets the 69.x.x.x address on its WAN interface. If not, your modem is also configured as a router – put it in bridge mode or forward the RTP port range to your separate router. Make sure that there aren’t any firewall settings in modem or router that would block incoming UDP packets in the RTP port range. If running FreePBX firewall or another software firewall that manages iptables, test with it disabled.
If no luck, see whether a packet capture shows RTP packets from the phone arriving at the PBX. If so, is there something wrong with them (incorrect port, incorrect codec, etc.)? If not, try the Yealink’s packet capture feature to see whether RTP is being sent to the correct 69.x.x.x address.
If you still have trouble, please post: Modem make/model? Separate router, if any? Special settings in these devices?
Stewart1, all working now! Spot on advice, thanks!
For reference, after banging my head on a wall, I cleared and recreated all the forwarding rule for the RTP stream ports pointing into the pbx on the external router, enabled and redisabled any and all the sip “helper” options I could find, saved the config, and rebooted the router. I’m guessing either the port rule was not being applied correctly, or one of those sip options was somehow still being applied and screwing with it.
Thanks again!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.