Just got a Digium phone to test out. DPMA is installed and loading successfully, correct settings have been added to sip.conf but Asterisk refuses to acknowledge the phone’s MESSAGE requests. I can see them making it through iptables, definitely not a firewall issue, but even with core set debug 255 I see nothing in Asterisk. Any suggestions?
Asterisk 11.19.0
Digium D65 2_0_3_1_50e24a6
accept_outofcall_message=yes
outofcall_message_context=dpma_message_context
auth_message_requests=no
Hi miken32,
Do you have something populated already in your extensions.conf context [dpma_message_context] ?
If not, you may just start by setting a NoOp to check that Asterisk sees the message; something like:
[dpma_message_context]
exten => _X.,1,NoOp(Message Receiving Dialplan)
Thanks,
Mike
Yeah that’s configured automatically by DPMA:
pbx*CLI> dialplan show dpma_message_context
[ Context 'dpma_message_context' created by 'digium_phone_module' ]
'digium_phone_module' => 1. Set(MESSAGE(custom_data)=mark_all_outbound) [digium_phone_module]
2. Set(TMP_RESPONSE_URI=${MESSAGE_DATA(X-Digium-AppServer-Response-URI)}) [digium_phone_module]
3. Set(MESSAGE_DATA(Request-URI)=${MESSAGE_DATA(X-Digium-AppServer-Response-FullContact)}) [digium_phone_module]
4. Set(MESSAGE_DATA(X-Digium-AppServer-Response-URI)=) [digium_phone_module]
5. Set(MESSAGE_DATA(X-Digium-AppServer-Response-FullContact)=) [digium_phone_module]
6. MessageSend(${TMP_RESPONSE_URI},proxy) [digium_phone_module]
7. Hangup() [digium_phone_module]
'proxy' => 1. Set(MESSAGE(custom_data)=mark_all_outbound) [digium_phone_module]
[recvaddr] 2. Set(MESSAGE_DATA(X-Digium-AppServer-Response-URI)=sip:${MESSAGE_DATA(SIP_RECVADDR)}) [digium_phone_module]
[fullcontact] 3. Set(MESSAGE_DATA(X-Digium-AppServer-Response-FullContact)=${MESSAGE_DATA(SIP_FULLCONTACT)}) [digium_phone_module]
[send] 4. MessageSend(digium_phone:blah) [digium_phone_module]
5. Hangup() [digium_phone_module]
-= 2 extensions (12 priorities) in 1 context. =-
sip set debug on doesn’t show the SIP packets either. It’s as though Asterisk isn’t even receiving them. But this is a live PBX with a dozen other endpoints registered on port 5060. Definitely not a firewall problem.
Here’s the full sip.conf general section, for the record:
faxdetect=no
vmexten=*97
useragent=FPBX-13.0.192.8(11.19.0)
disallow=all
allow=ulaw
allow=g722
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
limitonpeers=yes
notifycid=ignore-context
t38pt_usertpsource=yes
qualify=yes
accept_outofcall_message=yes
outofcall_message_context=dpma_message_context
auth_message_requests=no
callcounter=yes
callevents=yes
rtpstart=10000
tcpenable=no
rtpend=20000
jbenable=no
g726nonstandard=no
notifyringing=yes
t38pt_udptl=yes,redundancy,maxdatagram=400
srvlookup=no
registerattempts=0
registertimeout=20
tlsenable=no
rtpholdtimeout=300
videosupport=no
allowguest=yes
notifyhold=yes
tlsbindaddr=[::]:5061
tlsclientmethod=sslv2
defaultexpiry=120
checkmwi=10
canreinvite=no
maxcallbitrate=384
maxexpiry=3600
minexpiry=60
rtpkeepalive=0
rtptimeout=30
nat=force_rport,comedia
ALLOW_SIP_ANON=no
callerid=Unknown
language=en
Hmmm … so I’ve assumed that voice calls are working, but only messages are not … is that correct? I just want to double check my assumption, since the packets are reaching the server, but they’re not reflected when you use sip set debug on.
If voice is working, then:
Yes the PBX is fine, it’s got 10 Polycoms and a couple Cisco ATAs working. Near as I can tell the configuration for DPMA is fine, but as I said the messages aren’t getting to the point where asterisk even recognizes them so if there are errors in the configuration I can’t tell. Is has been reloaded, as evidenced by the dial plan being present. Just set up a 13.16.0 instance with the same behaviour.
Just pulled the output from tcpdump into Wireshark, and noticed the SIP packets are fragmented. I assume Asterisk can deal with this, since the phones are pushing out huge SIP messages with a certificate and tons of extra headers…
OK, if all the configs are fine, then I should just sit back, watch this thread and learn … maybe one of the “Moves like Spencer” guys will chime in.
Just to clarify, my understanding with DPMA is that you need a sip.conf entry for the Digium phone (as per usual), but you’ll also need to link that sip.conf entry to phone profile (‘type=phone’) and line profile (‘type=line’) entries configured in res_digium_phone.conf. These res_digium_phone.conf entries would not have been required for your Polycom phones and Cisco ATAs.
But if you have these profiles configured in res_digium_phone.conf already, then this should not be the cause. Can you share those profiles here along with your sip.conf entry for the phone?
Aloha.
How do you see them making it through iptables? Are you dumping traffic off the backside of the INPUT chain somehow? FreePBX installs usually include fail2ban. I’d double-check to make sure there wasn’t a DROP put in place for the IP of the phone.
What version of DPMA do you have installed?
w.r.t. large packets, if the phone’s going across a router or ALG that eats large packets, phone firmware 2.2.1.8 added support to split the Handshake packets so that they don’t get gobbled for going over UDP limits. You’ve got 2.0.3.1. If the phone can’t handshake w/ DPMA, it can’t be told to load new firmware that way. You could use the phone’s web UI to load an updated firmware on it. The latest firmware file can be retrieved from http://dphone.dl.digium.com/firmware/asterisk/2_2_2_2/2_2_2_2_D65_firmware.eff
Your sip.conf settings:
accept_outofcall_message=yes outofcall_message_context=dpma_message_context auth_message_requests=no
Those are in the [general] section, yes?
How did you point the phone at the server? Perhaps it’s been sent to the wrong place, or it’s been wrongly sent (Fetch Configuration File from URL or manual SIP Account instead of Digium Configuration Server).
Cheers
Thanks for the input! I put an iptables logging rule in place for any dropped packets and did not see my SIP packets getting dropped.
I have the latest DPMA, just downloaded yesterday. 3.4 maybe?
I will definitely try upgrading the firmware next week when I’m in the office. The fragmented packets aren’t getting dropped, I see all the pieces make it to the PBX, but worth a shot.
Those settings are in general.
Phone is provisioned via option 66 to point to sip:proxy@pbx:5060
The first MESSAGE packet from the phone will be a Handshake packet w/ an encrypted body. If you’re not seeing that in Asterisk’s sip debug logs, then it’s almost assuredly one of the following:
Try factory defaulting the phone. If you previously configured the phone using the phone’s web interface, the phone won’t attempt to contact a new server, even if Option66 newly directs it, it’ll continue attempting to use the original config server type (manual and non-DPMA) that it was passed.
When the phone comes up, does it pop up any attempting to contact proxy messages? If you don’t see those, then the phone’s not talking DPMA. If you do see those, you should, unless disabled, see the URI the phone is trying to contact to provision itself.
No network problems, or I wouldn’t be seeing the packets with tcpdump. They just don’t get acknowledged by Asterisk for some reason. The phone gets the correct provisioning server or the MESSAGE requests wouldn’t be getting to the server. The phone seems to be working as expected from everything I could see. New out of the box yesterday!
Looks like the new firmware fixed things up. Whereas before the initial SIP MESSAGE request was fragmented into two parts, I now see two separate MESSAGE requests, each containing part of the body, and Asterisk seems much happier to recognize it.
I’m very surprised Asterisk wouldn’t process a fragmented request AT ALL. Like, not even to complain about it.
Thanks for the assistance!
DPMA’s been capable of processing multi-packet requests. I’m suspicious of something in between the phone and the Asterisk process. …not that it matters though, as you’re up and going.