SIP Paging Device

[SteveJ]

We have installed station alerting devices in our fire stations.  This allows our firefighters to be alerted to an incident through the system.  It utilizes overhead speakers and lights to do this.  The system is a Honeywell USDD G2 Station Alerting system  https://buildings.honeywell.com/us/en/brands/our-brands/usdd.  The specific device in each of the stations is a ATX Station Controller.  The system allows SIP connection to allow connection to a phone system so overhead paging can occur over the system.  This allows not only internal paging for that station but our dispatch center can connect and give additional information after the initial dispatch. 

We have been working to try and get our Mitel system to connect without success.  Our outside phone vendor has some basic SIP knowledge but it appears this is beyond his scope of expertise.  The vendor of the ATX has told us that the system is built on PJSIP but can provide no other information other than what is in the manual which is:  The ATX has a built-in SIP client for receiving VoIP phone calls. The ATX can be configured to register one or more extensions with a phone
switch that supports SIP, and when a call is directed to one of the extensions the ATX will answer the call and route the audio to the station

[dilkie]

does it come with a manual telling you how to program configuration sip on this device

[SteveJ]

It looks like my first post was cutoff.  Basically the two systems see each other they just don't know what to do.  Our tech is unsure how to program the SIP Profile in the Mitel Director page to communicate with the device.  There are some files attached showing some logs.

In regards to the manual, unfortunately it only has this:  "The ATX has a built-in SIP client for receiving VoIP phone calls. The ATX can be configured to register one or more extensions with a phone switch that supports SIP, and when a call is directed to one of the extensions the ATX will answer the call and route the audio to the station

[dilkie]

It looks like my first post was cutoff.  Basically the two systems see each other they just don't know what to do.  Our tech is unsure how to program the SIP Profile in the Mitel Director page to communicate with the device.  There are some files attached showing some logs.

In regards to the manual, unfortunately it only has this:  "The ATX has a built-in SIP client for receiving VoIP phone calls. The ATX can be configured to register one or more extensions with a phone switch that supports SIP, and when a call is directed to one of the extensions the ATX will answer the call and route the audio to the station

well that's less than useful... how "can the ATX be configured to register one or more extensions"... that's the most important part... other than that, it's just MiVB programming and it could be as simple as a phone DN you call to send an announcement... But i'm sure there's MiVB folks here who know a lot more than I do wrt MiVB programming.

Does the ATX have a model number and manufacturer?

[SteveJ]

It's a Honeywell US Digital Design ATX Station Alerting Controller.

[dilkie]

It's a Honeywell US Digital Design ATX Station Alerting Controller.

google search turned up this, which has a section for programming sip.

https://prod-edam.honeywell.com/content/dam/honeywell-edam/hbt/en-us/documents/manuals-and-guides/installation-guides/usdd-installation-manuals/hbt-fire-LS10392-USDD-EN-A-ATX-Install-Manual.pdf

[SteveJ]

That part we have figured out.  It's the SIP Phone Profiles in Mitel we aren't able to resolve.  For example:
https://freeimage.host/i/dbCrNEB

[dilkie]

not my area.. what call server is that?

[johnp]

If they are extensions on the Mitel PBX, think they should be set as generic sip, and have a sip device configured for them. Likely on the Mitel they would be in a hunt group, unless they are site specific. Usually only change in sip device is to set the Replace System based with Device based In-Call Features to yes, there may be additional settings but would start with that. Also may want to turn off prack.

[SteveJ]

We are still working on this and made a bit of progress.  We found that the user_agent was not defined on the Honeywell device and has now been resolved through an update from the vendor.  We appear to have a connection now with Mitel but it still is not working.  I was hoping someone might be able to review the log and provide any feedback you might have.  On the Honeywell device, we are getting "Sip Registration Failed Status Status=500 Server internal error"

Here is the log from Mitel:

SIPIntf : TRX  : New Request - REGISTER
SIPIntf : SIP  : sip_msg_map_to_extn
SIPIntf : SIP  :   - From URI    = sip:1119@192.168.216.2
SIPIntf : SIP  :   - Via SentBy  = 192.168.15.16
SIPIntf : SIP  :   - Contact URI = sip:1119@192.168.15.16:5060
SIPIntf : DVC  : sip_msg_get_contact_urn : fail to get urn 0
SIPIntf : SIP  : Found 0 matches #2 to 0.0.0.0
SIPIntf : SIP  : Failed to find match -- process by TRUNK
SIPIntf : TRX  : NEW Transaction (0x652b498)
SIPIntf : TRX  : [0x652b498] Setting Trx Timers
SIPIntf : TRX  : [0x652b498] Request Received. Method = REGISTER
SIPIntf : TRX  : [0x5b34b80] SS_TRANSC_OBJ_REGISTER ALLOC - Page=0x5b34b60
SIPIntf : TRX  : [0x5b6bad0] SS_TRANSC_OBJ  ALLOC - Type=REGISTER  Page=0x5b6bab0 handle=0x100f672
SIPIntf : TRX  : [0x652b498] Type=REGISTER State=SERVER_GEN_REQUEST_RCVD, Reason=REQUEST_RECEIVED
SIPIntf : RGST : [0x5b6bad0] SIPIntf_TrxHandleRegisterReq
SIPIntf : DVC  : sip_msg_get_contact_urn : fail to get urn 0
SIPIntf : SIP  :  bIsPseries  = 0 Path = 0
SIPIntf : SIP  :  calling  sip_msg_map_to_extn
SIPIntf : SIP  : sip_msg_map_to_extn
SIPIntf : SIP  :   - From URI    = sip:1119@192.168.216.2
SIPIntf : SIP  :   - Via SentBy  = 192.168.15.16
SIPIntf : SIP  :   - Contact URI = sip:1119@192.168.15.16:5060
SIPIntf : DVC  : sip_msg_get_contact_urn : fail to get urn 0
SIPIntf : SIP  : Found 0 matches #2 to 0.0.0.0
SIPIntf : SIP  : Failed to find match -- process by TRUNK
SIPIntf : RGST : [0x5b6bad0] New Register Data:
SIPIntf : RGST :    - handle        = 0x0100f672
SIPIntf : RGST :    - status        = 11
SIPIntf : RGST :    - switchIp4     = 0x00000000
SIPIntf : RGST :    - extHandle     = 0x00000000
SIPIntf : RGST :    - authType      = 2
SIPIntf : RGST :    - contact       = sip:1119@192.168.15.16:5060
SIPIntf : RGST :    - aor           = sip:1119@192.168.216.2
SIPIntf : RGST :    - btmViaHost    = 192.168.15.16
SIPIntf : RGST :    - userAgent     = fireatx
SIPIntf : RGST :    - urn           =
SIPIntf : RGST :    - callID        = a3ed6353-8caf-4988-af5d-5313c1fc76b3
SIPIntf : TRX : [0x652b498] AuthSucceed=No
SIPIntf : RGST : [0x5b6bad0] AuthSucceed=No
SIPIntf : TRX  : [0x5b6bad0] Message To Send.
SIPIntf : DVC  : [ADD] User-Agent : ShoreGear/22.11.9300.0 (ShoreTel 15)
SIPIntf : TRX  : [0x652b498] final destination resolved
SIPIntf : Transport : Buffer to Send [576] - Remote (192.168.15.16:5060:UDP - 0x0) AppHandle=0x0 "Unknown"
---
SIP/2.0 401 Unauthorized

From: <sip:1119@192.168.216.2>;tag=619762c4-d03f-4f21-b71c-0e8fa5a31879

To: <sip:1119@192.168.216.2>;tag=652b498-0-13c4-6006-66d181-3e3d6d3-66d181

Call-ID: a3ed6353-8caf-4988-af5d-5313c1fc76b3

CSeq: 53586 REGISTER

WWW-Authenticate: Digest realm="ShoreTel",domain="sip:192.168.216.2",nonce="652b4986f90b",opaque="0",stale=false,algorithm=MD5

Via: SIP/2.0/UDP 192.168.15.16:5060;rport=5060;branch=z9hG4bKPj141e5d77-8765-46f0-8d46-0e58329f10d5

Supported: timer,replaces,info

User-Agent: ShoreGear/22.11.9300.0 (ShoreTel 15)

Content-Length: 0



---

SIPIntf : TRX  : [0x652b498] Type=REGISTER State=SERVER_GEN_FINAL_RESPONSE_SENT, Reason=USER_COMMAND
SIPIntf : TRX  : [0x5b6bad0] App Status = 11
SIPIntf : Transport : Buffer Rcvd [520] - Remote (192.168.15.16:5060:UDP - 0x0) AppHandle=0x0 "Unknown"
---
REGISTER sip:192.168.216.2 SIP/2.0

Via: SIP/2.0/UDP 192.168.15.16:5060;rport;branch=z9hG4bKPj141e5d77-8765-46f0-8d46-0e58329f10d5

Max-Forwards: 70

From: <sip:1119@192.168.216.2>;tag=619762c4-d03f-4f21-b71c-0e8fa5a31879

To: <sip:1119@192.168.216.2>

Call-ID: a3ed6353-8caf-4988-af5d-5313c1fc76b3

CSeq: 53586 REGISTER

User-Agent: fireatx

Contact: <sip:1119@192.168.15.16:5060;ob>

Expires: 300

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Content-Length:  0



---

[dilkie]

why is the auth domain "ShoreTel" and the UA "ShoreGear"? that's not an MiVB.

[sarond]

why is the auth domain "ShoreTel" and the UA "ShoreGear"? that's not an MiVB.

I would say it is MiVoice Connect. (Legacy Shoretel Connect)
https://www.mitel.com/articles/what-happened-shoretel-products

Mitel products have expanded again with buying Unify. Believe we're going to see a bit more of their SBC (OpenScape SBC)

[dilkie]

why is the auth domain "ShoreTel" and the UA "ShoreGear"? that's not an MiVB.

I would say it is MiVoice Connect. (Legacy Shoretel Connect)
https://www.mitel.com/articles/what-happened-shoretel-products

Mitel products have expanded again with buying Unify. Believe we're going to see a bit more of their SBC (OpenScape SBC)

well, yes, but the OP said this was MiVB call server, or at least I thought he did..... MiVB doesn't use that domain for authentication. I had thought this was the MiVB call server. So, other than that, I haven't a clue.