Authorization Codes and Unmanaged Gateways

[pmkr...@gmail.com]

We have a lab system at 15.06 set up with authorization codes for DISA service. When the incoming call comes in via SipXbridge, DISA works as documented. However when the call arrives via an unmanaged gateway (via SBC), the prompt for the authorization works, system responds with short chime, and then number to call is entered. Whether the number is an internal extension or external number, Sipxcom fails to place the call. Sipxproxy log shows the following message (for internal transfer)  -  "SipProxy::proxyMessage authoritative authorization decision is DENY by 200_xfer for 1d7550a2-b4cd-1233-b994-000c290a1daf".

I am probably missing something - any insights are appreciated.

Peter

[George Niculae]

Peter,

this looks exactly like the issue we committed this fix for: https://github.com/sipXcom/sipxecs/commit/42267017431c79c21ba0e978ddec390c3b939731

Would be great if you could load up a 15.08 and validate it works

Thanks,

George

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at http://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/f9e2fad7-596d-4044-924f-8ba30b4e153c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pmkr...@gmail.com]

Thanks George - I just updated the lab system to 15.08. Same issue persists.

Peter

[George Niculae]

Thanks Peter, than probably something different, Joegen could share some more insights about I think

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/0973c1dd-cd4d-4bf3-9cf1-392aa97f8ef2%40googlegroups.com.

[Joegen Baclor]

I am sure it is somehow related to that tracker George pointed out.   sipX needs the X-Auth-Identity header in the resulting INVITE for a REFER so that INVITE inherits the authority that the auth code granted.  If the gateway did not insert that either as a new header (which is the compliant behavior) or simply preserved it as a header parameter in the To (non-compliant but we want to be nice), then the call will fail.   Just take a look at the INVITE the GW produced after it received the REFER.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/0973c1dd-cd4d-4bf3-9cf1-392aa97f8ef2%40googlegroups.com.

[pmkr...@gmail.com]

Thanks Joegen and George. Let me rebuild this lab system tomorrow evening when I'm back home and test again on a fresh system. I'll look for this information and report back.

Peter

[Steve Daniel]

Wait....15.06 now has DISA capabilities?  When was this added, and how to I apply?  I've been wanting DISA since transitioning from our prior Elastix server.  

[Tony Graziano]

This has been around since 4.4

See the wiki

http://wiki.sipxcom.org/display/sipXcom/Authorization+Codes

[pmkr...@gmail.com]

Think I know what is going here - the SBC is not processing the REFER correctly and does not issue the INVITE for transfer to an internal extension. I'll open a ticket with Sangoma.

See attached.

Quick question - does Sipx/DISA deliver MOH with unmanaged gateways in the same manner as when Sipxbridge is used?

Peter

On Monday, August 3, 2015 at 7:59:19 PM UTC-4, pmkr...@gmail.com wrote:

[Tony Graziano]

I think you are onto something...

[Tony Graziano]

It needs to be able to pass DTMF/ Audio is coming back from the ACC session to process the codes and send chimes/tone to the user to let them know about the progress of their call. Obviously if the DISA session is hitting an auto attendant or the user is dialing "internal numbers' (normally you use an AA or a DID for that and not DISA/ACC) that has MOH, the MOH should work. 

I don't know that MOH would be an issue if it wasn't being sent though since its not part of a transaction from calling into the ACC function, getting tone/chimes and hearing the outbound call ring.

[pmkr...@gmail.com]

Thanks Tony for the response. The DTMF / Audio is indeed processed correctly by the ACC session - it's setting up the other call leg where the issues surface. One issue is getting the SBC to process the REFER - Sangoma is built on top of Freeswitch, and one needs to build custom dialplan rules on the SBC that maps the REFER to the correct dialplan variable which will then trigger the re-invite to the new destination.

The other issue is more problematic as I think about this - cable company ESGs, like some ITSPs, do not process REFERs on unregistered SIP trunks. I suspect a similar feature to what was done with IVR call bridging may need to be considered on the DISA side. Mike, do you have access to your TWC Business customer to validate this - ours is still connected via Sipxbridge.

btw I tried to simulate this by accessing DISA from a second Sipxcom system connected via an unmanaged gateway - when the REFER comes back, the second system requests authentication credentials and the DISA call then times out.

Peter

[Tony Graziano]

I understand. The other call session does not have MOH, it should be a normal "call". Your question had to do with MOH.

Be aware that you are more than likely identifying "call forking" which the ITSP or gateway may not be able to support. So I think the issue is still with the dialplan in your gateway. It might not like the call just because it "thinks" it is insecure.

Have you tried to create a separate gateway (by name) with the same IP address and specify a valid callerID in the gateway that the ITSP would not reject and set your dial plan for the outbound call to use this gateway? I would suggest this to see if it eliminates the appearance of call forking. Your dialplan would be something like "56+10 digits and send just 10 digits to that gateway and your ACC users would need to know to dial the extra digits.  

You could also make sure the gateway knows how to handle the call and make sure the provider supports call forking.

I use sipXbridge with an ITSP that supports call forking. So it works for me. 

--
You received this message because you are subscribed to a topic in the Google Groups "sipxcom-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sipxcom-users/0gSPLgP83xQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sipxcom-user...@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at http://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/702542ca-31bb-4ba8-90b3-1aff8042e4ec%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~

Helpdesk Needs
Call: 434-984-8426
Email: help...@myitdepartment.net
Portal: myit.freshdesk.com

LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

sip: help...@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net

Blog: http://blog.myitdepartment.net

[Michael Picher]

Peter,

I don't have convenient access to this.

Thanks,

  Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/702542ca-31bb-4ba8-90b3-1aff8042e4ec%40googlegroups.com.

[pmkr...@gmail.com]

Thanks. I've opened SIPX-244 as an Authorization Codes improvement that allows external DISA calls to be placed without use of SIP REFER. I've also updated the MSO / ESG Interoperability wiki http://wiki.sipxcom.org/pages/viewpage.action?pageId=36864184 with a cautionary note on DISA functionality and a suggested workaround.

Peter

[pmkr...@gmail.com]

Tony, I was able to partially get Sipxcom DISA for internal calls going through the Sangoma SBC  using this procedure found in their wiki http://wiki.sangoma.com/NSC-SIP-Refer-Handling - you are correct, there is no MOH for unmanaged gateways. I have a ticket open with Sangoma to work through the external DISA call setup with their SBC.

Peter

[Tony Graziano]

MOH can use a SIP URI. Sipx has a SIP URI for MOH. other SBC's support MOH this way and also can "have their own'. I'm not sure if that's a feature request to Sangoma instead.

I was holding my lips on the idea of having the proxy/acc allowing a transfer without the REFER (the proxy wants REFER unless you have a gateway or sbc that is going to intercede). This is what Sangoma should have been doing. if that is what it is doing now then super dee duper!

--
You received this message because you are subscribed to a topic in the Google Groups "sipxcom-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sipxcom-users/0gSPLgP83xQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sipxcom-user...@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at http://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/25c752df-3a2f-4a07-acf5-a7dfa8958b5a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~

Helpdesk Needs
Call: 434-984-8426
Email: help...@myitdepartment.net
Portal: myit.freshdesk.com

[pmkr...@gmail.com]

I'm less concerned about the MOH issue - it came up doing stare/compares of call traces with Sipxbridge versus unmanaged gateways.  I saw moh SIP traffic with Sipxbridge and not with unmanaged gateways, so asked the question. The Sangoma SBC has an upper registration feature that allows remote phones to register to Sipxcom sitting behind the SBC with a DMZ to a firewall. I have this working for external vendor access.

Did not see a proxy capability that you describe in the SBC but will ask Sangoma when they reach out - their tech support is great to work with. That would be the easier road to travel ...

Peter

[pmkr...@gmail.com]

I spent some time with Sangoma support this afternoon we got external Sipxcom DISA calls successfully routed through the SBC. Briefly, one needs to take the REFER from Sipxcom for the external call and map it to the external trunk via the dialplan.

If time permits and there is interest, I may write this up as an interoperability guideline.

After working with Sangoma and observing the quality of their engineers, I can see why MSOs may be reluctant to enable REFER support on their edge Enterprise SIP gateways.

Peter

[Michael Picher]

It's a bit of the Wild West out in ITSP land. Hard when customers don't understand that there's no one cookie cutter solution.

The more documentation we can get on the Sangoma the better. We started something and Sangoma was to finish it but its yet to get done.

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/2d3eaa17-12ca-463e-ad8c-1eb59546ec08%40googlegroups.com.