Avaya SBCE + EMS + SIP-UA

[RedTech443]

Hello all.

I am attempting to add to my test lab a SBCE with a SIP connection to SIP-ua.com (a free sip trunk for testing)

I have just installed a fresh 6.3 ASBCE + EMS on my VM running version 6.3. I have used the intelligent workbook provided by avay to configure the device as best I could and I am able to log into the shell and run traceSBC to see some information.

I have what I think is all the proper media and signaling interfaces, and also opened the whitelist up to the SBCE on my session manager.

I have added my sip trunk under server configuration and also added authentication with my provided username and password. (I have verified it works using xlite to login)

My problem I am getting is when it tries to register I get a 401 unauthorized and I am not sure why.

Below is a Trace and also what each line states in detail.


208.110.65.18
SBC
---------------------------------------------------------------------------------------------------------------------
11:30:33.806 |<--REGISTE-| | | (0) <sip:525101@proxy.sip-ua.com>
11:30:33.806 |--Trying-->| | | (0) 100 Trying
11:30:33.806 |--Unautho->| | | (0) 401 Unauthorized



| 192.168.168.10:5060 --UDP-> 208.110.65.18:5060 |
|-----------------------------------------------------------------------------------------------------------|
|REGISTER siproxy.sip-ua.com:5060 SIP/2.0 |
|From: <sip:525101@proxy.sip-ua.com>;tag=21572d5d182a |
|To: <sip:525101@proxy.sip-ua.com> |
|CSeq: 11 REGISTER |
|Call-ID: c8a66045ecb89a1c819f932d0ca5cd2504157b35482fecf062bd886df5aa169 |
|Contact: <sip:525101@xxx.xxx.xxx.xxx:5060;transport=udp> |
|Max-Forwards: 69 |
|Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK-s1632-001708694035-1--s1632- |
|Content-Length: 0 |
\-----------------------------------------------------------------------------------------------------------/





/----------------------------------------------------------------------------------------------------------- | 208.110.65.18:5060 --UDP-> 192.168.168.10:5060 |
|-----------------------------------------------------------------------------------------------------------|
|SIP/2.0 100 Trying |
|From: <sip:525101@proxy.sip-ua.com>;tag=21572d5d182a |
|To: <sip:525101@proxy.sip-ua.com> |
|CSeq: 11 REGISTER |
|Call-ID: c8a66045ecb89a1c819f932d0ca5cd2504157b35482fecf062bd886df5aa169 |
|Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO |
|Supported: replaces |
|User-Agent: SIP-UA Proxy |
|Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK-s1632-001708694035-1--s1632-;received=xxx.xxx.xxx.xxx |
|Content-Length: 0 |
\-----------------------------------------------------------------------------------------------------------/






|-----------------------------------------------------------------------------------------------------------|
|SIP/2.0 401 Unauthorized |
|From: <sip:525101@proxy.sip-ua.com>;tag=21572d5d182a |
|To: <sip:525101@proxy.sip-ua.com>;tag=as1dad147e |
|CSeq: 11 REGISTER |
|Call-ID: c8a66045ecb89a1c819f932d0ca5cd2504157b35482fecf062bd886df5aa169 |
|Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO |
|Supported: replaces |
|User-Agent: SIP-UA Proxy |
|Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK-s1632-001708694035-1--s1632-;received=xxx.xxx.xxx.xxx |
|

http://WWW-Authenticate:

Digest algorithm=MD5, realm="sip-ua.com", nonce="657aa033" |
|Content-Length: 0 |
\-----------------------------------------------------------------------------------------------------------/


I removed my IP address and replaced with xxx.xxx.xxx.xxx.

I suspect that the user-agent line SIP-UA Proxy might have something to do with why I am being rejected but I do not understand SBC well enough to know.
I think this setup would be similar to an AT&T sip trunk or something of that nature, however I have never set one up and not sure of the gotchas.

 

[kyle555]

What's 525101? I'd reckon they might want the phone number or user name associated with the account. That's basically a rejection of your login attempt. Can you use those credentials with any other generic SIP client to doublecheck?

 

[RedTech443]

Yeah 525101 is my login ID for the service, I verified that ID + password works using xlite, testing according to their documentation. However they only have this tested with Cisco routers for sip trunking. So I think I am in the dark for some of this. Although I have reached out to their support for any help.

In lite of this, if I can get all this working using SIP-ua as my test SIP trunk, it would make for nice technical document / video on how to for testing purposes..
Just need to get past the authorized part before I can move on.

 

[kyle555]

Right, so the 401 has a line like

http://WWW-Authenticate:

Digest algorithm=MD5, realm="sip-ua.com", nonce="657aa033" |

That's where your SBC should register again and send the user name and the password hashed in MD5 + that nonce. That'd be the normal flow.

This doc has traces at the end that show the flow and I'm thinking cause MD5 is junk that it might be turned off in the SBC by default and you might need to enable it somewhere.

https://downloads.avaya.com/css/P8/documents/100176272

 

[RedTech443]

I was able toget it to register with 200 ok by removing the proxy information in the heartbeat message in server configuration on the SBCE. However I now get proxy authentication required. Which I think might be related to my sip entity links possibly.


13:40:16.212 |--Trying-->| | | (12) 100 Trying
13:40:16.212 |--OPTIONS->| | | (13) sip:525101@xxx.xx.xx.xxx
13:40:16.212 | |--OPTIONS->| | (14) sip:525101@xxx.xx.xx.xxx
13:40:16.212 |--200 OK-->| | | (12) 200 OK (REGISTER)
13:40:16.212 | |<--Proxy A-| | (14) 407 Proxy Authentication Required
13:40:16.212 |<--Proxy A-| | | (13) 407 Proxy Authentication Required


###
13:3/-----------------------------------------------------------------------------------------------------------13:3| 208.110.65.18:5060 --UDP-> 192.168.168.10:5060 |
13:3|-----------------------------------------------------------------------------------------------------------|
13:3|SIP/2.0 100 Trying |
13:3|From: <sip:525101@proxy.sip-ua.com>;tag=757dae7532a3 |
13:3|To: <sip:525101@proxy.sip-ua.com> |
13:3|CSeq: 4 REGISTER |
13:3|Call-ID: 15ea864148b4265f158a4c1d0ca5cd2504157b35482fecf062bd886df5aa169 |
13:3|Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO |
13:3|Supported: replaces |
13:3|User-Agent: SIP-UA Proxy |
13:3|Via: SIP/2.0/UDP xxx.xx.xx.xxx:5060;branch=z9hG4bK-s1632-001024332470-1--s1632-;received=xxx.xx.xx.xxx |
13:3|Content-Length: 0 |
13:3\-----------------------------------------------------------------------------------------------------------/
###
13:3/-----------------------------------------------------------------------------------------------------------13:3| 10.1.30.171:5060 --UDP-> 10.1.30.91:5060 |
13:3|-----------------------------------------------------------------------------------------------------------|
13:3|SIP/2.0 407 Proxy Authentication Required |
13:3|From: "asterisk" <sip:asterisk@208.110.65.18>;tag=as5b1228a4 |
13:3|To: <sip:525101@xxx.xx.xx.xxx:5060;transport=udp>;tag=6938280589522359_local.1484590185539_43251_43256 |
13:3|CSeq: 102 OPTIONS |
13:3|Call-ID: 641f7d48f6bef40cc1db9d2159393405 |
13:3|Via: SIP/2.0/UDP 10.1.30.91:5060;branch=z9hG4bK-s1632-001448861441-1--s1632- |
13:3|Via: SIP/2.0/UDP 208.110.65.18:5060;branch=z9hG4bK31f75cc1;rport=5060 |
13:3|Proxy-Authenticate: Digest realm="homelab.com",qop="auth",opaque="1234567890abcedef",nonce="159adb49c6b1d166|
13:3|df85c1ac6f0b4c5b5717f1c2a1d",algorithm=MD5,stale=false |
13:3|Server: AVAYA-SM-6.3.17.0.631705 |
13:3|Av-Global-Session-ID: 729f2ca0-dce3-11e6-9435-000c291a55ea |
13:3|Content-Length: 0 |
13:3\-----------------------------------------------------------------------------------------------------------/
##
13:3/-----------------------------------------------------------------------------------------------------------13:3| 208.110.65.18:5060 --UDP-> 192.168.168.10:5060 |
13:3|-----------------------------------------------------------------------------------------------------------|
13:3|OPTIONS sip:525101@xxx.xx.xx.xxx:5060;transport=udp SIP/2.0 |
13:3|From: "asterisk" <sip:asterisk@208.110.65.18>;tag=as0a0becff |
13:3|To: <sip:525101@xxx.xx.xx.xxx:5060;transport=udp> |
13:3|CSeq: 102 OPTIONS |
13:3|Call-ID: 21c9786a23fe32d93d80aee13c9c5268@208.110.65.18 |
13:3|Contact: <sip:asterisk@208.110.65.18> |
13:3|Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO |
13:3|Supported: replaces |
13:3|User-Agent: SIP-UA Proxy |
13:3|Max-Forwards: 70 |
13:3|Via: SIP/2.0/UDP 208.110.65.18:5060;branch=z9hG4bK1e782608;rport |
13:3|Date: Tue, 17 Jan 2017 18:33:31 GMT |
13:3|Content-Length: 0 |
13:4\-----------------------------------------------------------------------------------------------------------/
##
13:3/-----------------------------------------------------------------------------------------------------------13:3| 208.110.65.18:5060 --UDP-> 192.168.168.10:5060 |
13:3|-----------------------------------------------------------------------------------------------------------|
13:3|SIP/2.0 200 OK |
13:3|From: <sip:525101@proxy.sip-ua.com>;tag=757dae7532a3 |
13:3|To: <sip:525101@proxy.sip-ua.com>;tag=as739efc94 |
13:3|CSeq: 4 REGISTER |
13:3|Call-ID: 15ea864148b4265f158a4c1d0ca5cd2504157b35482fecf062bd886df5aa169 |
13:3|Contact: <sip:525101@xxx.xx.xx.xxx:5060;transport=udp>;expires=120 |
13:3|Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO |
13:3|Supported: replaces |
13:3|User-Agent: SIP-UA Proxy |
13:3|Via: SIP/2.0/UDP xxx.xx.xx.xxx:5060;branch=z9hG4bK-s1632-001024332470-1--s1632-;received=xxx.xx.xx.xxx |
13:3|Expires: 120 |
13:3|Date: Tue, 17 Jan 2017 18:33:31 GMT |
13:3|Content-Length: 0 |
13:4\-----------------------------------------------------------------------------------------------------------/

 

[kyle555]

Proxy-Authenticate: Digest realm="homelab.com",qop="auth",opaque="1234567890abcedef",nonce="159adb49c6b1d166|

homelab.com is making me suspicious

 

[RedTech443]

It is my internal domain name. It is not real. But I have edited every hosts file to point correctly to it with in system manager and session manager.

 

[RedTech443]

I was able to fix everything by changing some settings in Topology hiding, My home network is a bit funny as my firewall sites behind an ISP provided cable modem and throws me a 192.168.0.1 WAN address to my pfsense firewall so when the SIP connections were coming in, they were getting a header of sip:xxxx@192.168.0.1 which was unknown, so by fixing the topology hiding that seemed to fix some of the problems.


to - ip/domain = overwrite = homelab.com
request-line = overwrite = homelab.com
from = overwrite = homelab.com

The sip trunk was able to register with 200 ok and no other problems, I did not have trunking setup to CM setup so it had no route available to work but I was only trying to get it to register for today anyway. Tomorrow I will work on all the proper routing to and from CM.

 

[wpetilli]

Same topic, but different sub-topic.. To move forward with SBC for remote worker I'm confused on licensing. If you don't have entitlements and have to purchase ala carte:
* I assume you have to purchase an SBC license for however many HA pairs you want. Once purchased does it matter in what geographic region of the world I deployed in, as far as my global dispersed data centers?
* For the remote worker licenses, do those get tied to a specific SBC if there were multiple SBC licenses purchased?
* Also, if I have 3 different CM clusters do any of the above licenses tie directly to specific CM's or they can be used by either of them?

I have 3 different cm clusters (by region)and was hoping I can purchase whatever I need from one party and be able to deploy/use wherever. Instead of having to find different regional partners to purchase separate.

 

[kyle555]

1. Maybe. Should be ordered in the country it'd be used in. Might stop hardware support. Not so much software support. I hope you don't have offices in Iran or North Korea

2.Entitlements - you get about 7:1 users:sessions on the SBC. You can activate them in PLDS on any host with enterprise licensing. So it shouldnt be a big deal.

3. SBC licenses are for the SBC. SM would proxy to the CM app sequence handling that user.

 

[wpetilli]

Well these would be all virtual SBC's-

We aren't using the core suite yet and are still using enterprise licensing, so we'd have to purchase each SBC license and remote worker licenses individually. Wasn't sure if CM had to be specified anywhere. Guess any CM user can be provisioned as long as the SBC it flows through has available sessions.

 

[kyle555]

Exactly. SBC session and CM license usage are different things. Nothing precludes you from using those SBC sessions to pass remote workers over to any other brand of PBX.

 

[wpetilli]

On a technical front I have 2 public IP's assigned to the B interface per the doc and have the relay services section configured properly for the configuration file server access. The remote phone registers fine, but when trying to force a firmware upgrade it fails. As a very quick test our network team opened port 80 (public facing) and I modified the relay service to be http:80 all the way and pulling of the firmware works fine. Obviously and unfortunately 80 cannot be left open. FW is not dropping traffic. Anyone come across this?

 

[kyle555]

Maybe relay a different port, and use HTTPPORT in 46xxsettings.txt to change it. Open 80 one more time, kick em all, watch em grab the new settings, see if another reboot makes them hit

http://SBCPUBLIC:12345

instead of :80?

Maybe push a trustcert out to them to hit https only?

 

[RedTech443]

States of the firewall need to be reset?