Trunked PBX to ASL - PBX Phone Disconnects after ASL Command

App_rpt-users
1

I’m seeing an interesting issue when connecting via phone to my ASL node. The setup is a virtualized ASL hub node with an IAX Trunk to my Asterisk PBX. I’m able to dial-in to my ASL node no problem from any of my Polycom IP450 or IP331 phones or via an Analog ATA attached to the separate PBX. However, when ever I issue a DTMF command - regardless of phone (or command via allmon2) after ~32 seconds all Polycom phones disconnect. Even more interesting, the ATA device does not suffer from this problem, nor does the PSTN reverse-autopatch which also connects through the PBX to ASL. Additionally, if I don’t issue any commands, I can leave the phone connected seemingly indefinitely without issue - last test it stayed connected for ~6hours before I issued a command…

I’ve found several threads on the topic already experiencing what I am, however, all of them are with Polycom phones (in general) directly attached to an ASL node. So I don’t think it’s something in the PBX, but rather ASL or the Polycom phones themselves. I’ll also note, I have no issues using the PBX feature codes and there’s no overlap (disabled all of them in testing).

Here’s some links to other threads for reference, all of them either died with no solution, or had ‘fixes’ that don’t work (at least not in my implementation).

Below is the configuration currently:

Asterisk PBX Trunk to ASL:

[ASLtoPBX]
username=PBXtoASL
host=asl-hub.domain.us
secret=NHzRWxTNmACdVgrYBC9nNXUOfdZOLG9M
type=friend
dtmfmode=rfc2833
qualify=yes

ASL Node Trunk to PBX:

[PBXtoASL]
type = friend
username = ASLtoPBX
context = radio-control
host = pbx.domain.us
disallow = all
allow = ulaw
transfer = no
qualify = yes

ASL Node - extensions.conf

[radio-control]
exten => ${NODE},1,Answer
exten => ${NODE},n,Wait(2)
exten => ${NODE},n,Playback(rpt/node)
exten => ${NODE},n,Playback(digits/5)
exten => ${NODE},n,Playback(digits/7)
exten => ${NODE},n,Playback(digits/2)
exten => ${NODE},n,Playback(digits/7)
exten => ${NODE},n,Playback(digits/0)
exten => ${NODE},n,Wait(1)
exten => ${NODE],n,Playback(rpt/connected)
exten => ${NODE},n,rpt(${NODE}|P)

I get the following packets immeately after issuing a *70 (status), and only heading to the Polycom phones - the ATA is not sent these packets:

Sending text T 57270 STATUS,57270,0 on SIP/200-000000c0
Reliably Transmitting to 10.14.65.50:5060:
MESSAGE sip:200@10.14.65.50;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.14.65.2:5160;branch=z9hG4bK00d507e9;rport
Max-Forwards: 70
From: <sip:57270@10.14.65.2;user=phone>;tag=as1d725256
To: "200" <sip:200@10.14.65.2:5160>;tag=F2679BF5-97CE6A04
Call-ID: 5b27e2e9-f7ecb368-b550f31b@10.128.128.50
CSeq: 102 MESSAGE
User-Agent: FPBX-15.0.23.11(16.2.1)
Content-Type: text/plain;charset=UTF-8
Content-Length: 22

T 57270 STATUS,57270,0
---

<--- SIP read from UDP:10.14.65.50:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.14.65.2:5160;branch=z9hG4bK00d507e9;rport
From: <sip:57270@10.14.65.2;user=phone>;tag=as1d725256
To: "200" <sip:200@10.14.65.2:5160>;tag=F2679BF5-97CE6A04
CSeq: 102 MESSAGE
Call-ID: 5b27e2e9-f7ecb368-b550f31b@10.128.128.50
Contact: <sip:200@10.14.65.50>
User-Agent: PolycomSoundPointIP-SPIP_450-UA/4.0.15.1009
Accept-Language: en
Content-Length: 0

After ~32 seconds I then see all connected Polycom’s send a SIP BYE to the PBX, terminating the call.

<--- SIP read from UDP:10.14.65.50:5060 --->
BYE sip:57270@10.14.65.2:5160 SIP/2.0
Via: SIP/2.0/UDP 10.14.65.50;branch=z9hG4bKfc400763715CC71A
From: "200" <sip:200@10.14.65.2:5160>;tag=1D03F192-A47758E9
To: <sip:57270@10.14.65.2;user=phone>;tag=as0818d96c
CSeq: 3 BYE
Call-ID: af79e6ae-52405085-2d61d0fc@10.14.65.50
Contact: <sip:200@10.14.65.50>
User-Agent: PolycomSoundPointIP-SPIP_450-UA/4.0.15.1009
Accept-Language: en
Authorization: Digest username="200", realm="asterisk", nonce="75841764", uri="sip:57270@10.14.65.2:5160;user=phone;transport=udp", response="6ee97035ebed6b6ce819097835e9f480", algorithm=MD5
Max-Forwards: 70
Content-Length: 0

<------------->
--- (12 headers 0 lines) ---
Sending to 10.14.65.50:5060
Scheduling destruction of SIP dialog 'af79e6ae-52405085-2d61d0fc@10.14.65.50' in 6400 ms (Method: BYE)

<--- Transmitting (NAT) to 10.14.65.50:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.14.65.50;branch=z9hG4bKfc400763715CC71A;received=10.14.65.50;rport=5060
From: "200" <sip:200@10.14.65.2:5160>;tag=1D03F192-A47758E9
To: <sip:57270@10.14.65.2;user=phone>;tag=as0818d96c
Call-ID: af79e6ae-52405085-2d61d0fc@10.14.65.50
CSeq: 3 BYE
Server: FPBX-15.0.23.11(16.2.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


<------------>

At least one of the threads I linked suspects the “-- Hungup ‘DAHDI/pseudo-13XXXXXXXX’” after command may be causing this, but I disagree. You see those same hungup messages after a “Force ID”, both local only and global. Personally, I think it’s likely related to the packets only the Polycom phones are getting as they contain STATUS information for my node “57270”.

If you made it this far, sorry for the novel… But figured dataoverload is better than not enough data :slight_smile:

1 Like
2

Additional Links (new users are link limited per post)

3

Some additional info.

Using the default [iax-client] context, PBX Polycom phones calling ASL over the IAX trunk will disconnect after 35 seconds. Phones connected to the PBX via an ATA are fine.

Something in the dialplan the Polycom’s don’t like???

4

As I remember it, there are quite a few quirks with polycom equipment based on exact model.
I think your issue is something similar to a ‘qualify’ issue in in a sip phone when NAT’d…
Check your setting in the phone itself along those lines.

5

Hi Mike,

The PBX & ASL node is NAT’d reaching out to the internet. However, the ASL node I’m trunking to from my PBX to is sitting on the local network. No NAT between the PBX and ASL node.

6

Well, as I mentioned, I would look internal settings in the phone for setting similar to ‘qualifying time’.
It’s a registration alive test.
Just the timing of it rings out to me that it is similar.
But you may also have default phone commends built-in that needs cleared/nulled.

7

I took another gander though the settings on the phone.
The only setting for ‘qualifying time’ is “Register” Enabled/Disabled and “Expires”
Register is set to enabled and Expires is set to 3600. I tried decreasing it to 10 to no effect.

As far as I can tell, Polycom phones don’t have any local (*) codes to clear/null…

8

Trying to wrap my head around this…

Can you show your entire stanza for the sip phone.

Also, can you test this as well with a softphone for same result ?

9

Sure.

I’m setup as follows, Phone(s) → FreePBX → ASL Node. Where “Phone(s)” are 3 Polycoms, one IP335 and two IP450, as well as one Obi ATA. Also, for additional reference, I’ve enabled SIP on the ASL node and moved to a SIP trunk between FreePBX and ASL to see if that has any effect, no dice…

Just finished testing using a softphone - that works just fine, even get the T 57270 STATUS,57270,0 as a message in the softphone application - neat!

Below is the stanza for one of the Polycoms configured to the PBX.

[200]
deny=0.0.0.0/0.0.0.0
secret=supersecret
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
defaultuser=
trustrpid=yes
user_eq_phone=no
sendrpid=pai
type=friend
session-timers=accept
nat=force_rport,comedia
port=5060
qualify=yes
qualifyfreq=60
transport=udp
avpf=no
force_avp=no
icesupport=no
rtcp_mux=no
encryption=no
namedcallgroup=
namedpickupgroup=
dial=SIP/200
accountcode=
mailbox=200@default
mailbox=100@device
permit=0.0.0.0/0.0.0.0
callerid=Michael - Desk <200>
recordonfeature=apprecord
recordofffeature=apprecord
callcounter=yes
faxdetect=no

Out of all the methods I’ve tried so far, only the Polycom phones are causing disconnects… From the debug output, the Polycoms are simply sending BYE ~32 seconds after the issuance of a *70, *1,*2 or *3.
*99 & # seem fine, they are also the only two that I’ve tested which don’t send a “STATUS” SIP message.

10

Update! It’s working!

In sip.conf under [general] (or, if using FreePBX, Settings → Asterisk SIP Settings → Other SIP Settings) I added the following: disallowed_methods=MESSAGE and tried my node again… It works! No more dropped calls!

So either Polycom lies in it’s SIP Allow header, and doesn’t actually support the SIP MESSAGE method, or it does, and ASL is formatting it in such a way that Polycom doesn’t understand… IMHO, probably the former…

Now is this the proper location for this? probably not. I still might want that message (or any SIP messages) for endpoints that handle it properly. Next is to figure out is where to put that on a per-endpoint basis. But that’s a bit out of scope of this post…

https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample

; When a dialog is started with another SIP endpoint, the other endpoint
; should include an Allow header telling us what SIP methods the endpoint
; implements. However, some endpoints either do not include an Allow header
; or lie about what methods they implement. In the former case, Asterisk
; makes the assumption that the endpoint supports all known SIP methods.
; If you know that your SIP endpoint does not provide support for a specific
; method, then you may provide a comma-separated list of methods that your
; endpoint does not implement in the disallowed_methods option. Note that
; if your endpoint is truthful with its Allow header, then there is no need
; to set this option. This option may be set in the general section or may
; be set per endpoint. If this option is set both in the general section and
; in a peer section, then the peer setting completely overrides the general
; setting (i.e. the result is *not* the union of the two options).
;
; Note also that while Asterisk currently will parse an Allow header to learn
; what methods an endpoint supports, the only actual use for this currently
; is for determining if Asterisk may send connected line UPDATE requests and
; MESSAGE requests. Its use may be expanded in the future.
;
; disallowed_methods = UPDATE
1 Like
11

Polycom’s always have issues somewhere

Thanks for posting info for others.

12

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.