SBCE Initial setup 2

[avAyATEKky]

I have installed EMS/SBCE in a virtual environment with a 50 license on a stand alone weblm all v6.3.

First issue I am having is having the SBCE connect to the WebLM it keeps error out I did the

http://(ip

Address):52233/WebLM/LicenseServer and all sorts of break downs.

Second I install a device but I am completely confused on setting it up waht IPs go where etc.. and reading the Docs make me more confuse Avaya has no straight forward documents that I came across on the support site.

Also this is a test environment where the SBCE ove has been setup for two dedicated VM NICs. Me assuming 1 for internet and 1 for intranet. So my plan was to put an IP Phone ont the internet side and see if I could connect to the Intranet through the SBC.


Today Makes Tomorrow

 

[wpetilli]

Looks TLS all the way. This is the tracSM. Not sure if it matters, but the register attempt shows the extension@ipaddress instead of the domain. I was thinking SM doesn't know what to do with that IP address, even though it's the security module IP.

SM LabCM
SM100 10.254.105.118
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
12:33:30.130 |--OPTIONS->| | | (1) sip:test.blackstone.com
12:33:30.130 | |--OPTIONS->| | (1) sip:test.blackstone.com
12:33:34.844 | |<-------REGISTER-------| (2) <sip:6499@10.192.144.83:5061> Exp:3600
12:33:34.844 |<--REGISTE-| | | (2) <sip:6499@10.192.144.83:5061> Exp:3600
12:33:34.845 |--Unautho->| | | (2) 401 Unauthorized
12:33:34.846 | |-----Unauthorized----->| (2) 401 Unauthorized
12:33:34.964 | |<-------REGISTER-------| (2) <sip:6499@10.192.144.83:5061> Exp:3600
12:33:34.964 |<--REGISTE-| | | (2) <sip:6499@10.192.144.83:5061> Exp:3600
12:33:34.965 |--Forbidd->| | | (2) 403 Forbidden (Unauthorized)
12:33:34.965 | |--Forbidden (Unauthor->| (2) 403 Forbidden (Unauthorized)
12:33:36.424 |--OPTIONS->| | | (3) sip:10.192.144.76
12:33:36.425 |<--OPTIONS-| | | (3) sip:10.192.144.76
12:33:36.426 |--200 OK-->| | | (3) 200 OK (OPTIONS)
12:33:36.426 |<--200 OK--| | | (3) 200 OK (OPTIONS)


Expanding the firt 'Unatho' on line 5 ---

10.192.144.76:15061 --TLS-> 10.192.144.83:38434 |
|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
|SIP/2.0 401 Unauthorized |
|

http://WWW-Authenticate:

Digest realm="blackstone.com",qop="auth",opaque="1234567890abcedef",nonce="1574d98627da5aacee924d5a8785d7fe67dd4a05dd0",algorithm=MD5,stale=fa|
|lse |
|Call-ID: A7CC0810-66E8-4233-9074-C0919FBC87F8 |
|CSeq: 1 REGISTER |
|From: <sip:6499@10.192.144.83:5061>;tag=BCB2400C-9D37-4FAD-802F-7E8967FF6AD1 |
|To: <sip:6499@10.192.144.83:5061>;tag=35966048509278925_local.1430827291340_25807620_25807633 |
|Via: SIP/2.0/TLS 10.192.144.83;branch=z9hG4bK-s1632-000712273971-1--s1632--AP;ft=156804;received=10.192.144.83;rport=38434 |
|Via: SIP/2.0/TLS 10.254.105.119:5061;branch=z9hG4bK-s1632-000712273971-1--s1632-;received=10.254.105.118 |
|Av-Global-Session-ID: 240872d0-8019-11e6-975d-b4b52f645a70 |
|Server: AVAYA-SM-6.3.9.0.639011 |
|Content-Length: 0

 

[kyle555]

oh, that's easy i think.

something like default domain in the SIP entity for the SM if not explicitly defined. And maybe your SBC guy goofed if the registration isn't passing thru from the phone to SBC to SM as set@domain.com but set@10.10.10.10 instead

 

[wpetilli]

I altered the topology hiding profile on the sbc to overwrite the domain and now I registered. finally.. now, no media on a call.. on to the next issue.

 

[kyle555]

OK, so on remote workers, the SBC needs to see audio from the outside phone before it opens the path from the inside out.

That's how your phone on your home router at 192.168.1.x translates out the public side to the SBC

Anyway, check the SDP offers in a traceSBC and figure out where it's setting up.

What's between the SBC and the set? I've seen firewalls with SIP application layer gateways mungling things up and needed to turn them off

 

[wpetilli]

If I'm making the call from the registered iPhone and dialing a 4 digit call that goes over the internal company network to a completely separate CM would the far ends udp port range not matching cause this (35000-40000)? I have to peel a PRI from my prod system to test outbound calls, which I can't do until later. I can try registering another phone to this cm to see if I have the same audio issue.

 

[kyle555]

Maybe you're trying to shuffle the SBC interface to a DSP or the endpoint of the other PBX
Can you pin media down from the SBC to to gateway on that CM to a gateway on the other?

Or, be easy to start and call an internal station on the same PBX the iphone's on?

 

[wpetilli]

eh, no luck on a local phone on the same CM. Call connects no problem, with no audio in either direction.

 

[kyle555]

check your sdp on traceSBC - see what it's trying to get setup

 

[wpetilli]

What leg of the path should I be looking in... Going through the lines of the trace there is sdp info in a bunch of them.

 

[kyle555]

I guess the last SDP from SBC to iToy and SBC to SM

 

[wpetilli]

I pulled the pcap from the sbc and will try and make heads or tails of it. Is there something specific you have in mind that should stand out in that trace?

 

[kyle555]

Yeah... private IPs from the LAN of the mobile client advertised in the SDP to the public SBC interface and maybe private LAN IPs inside the SBC advertised outside.

Or otherwise, just SDP IPs in the c lines that the SBC can't ping from the interface it should be able to reach.

 

[wpetilli]

One of my network engineers has gone through the pcap from the sbc and he's seeing no UDP packets, so either the fw is not being nice to them or something else. The fw for this area of the network is very old so the logs are not usable. They have to do a pcap from the switch it's attached to. I don't recall seeing UDP anywhere in the sbc setup.. just tls and tcp. The SM definitely has udp setup, as does the MG.

 

[kyle555]

Well, your audio is RTP in UDP and that absolutely needs to come from outside on the remote worker to the SBC before anything happens in setting up a two way call

 

[JuanAvaya]

Taking this thread back to life.
I am having the same no audio issue ONLY when registering from the outside. If I point the registration from an internal WIFI to the B1 interface of the SBC, it works just fine. As I cannot see any RTP packets neither in the good and bad examples I wonder what the audio path is.
From traces it shows RTP goes directly from the client to the MG however, it does not make sense to me.

Can anybody explain how audio path is established?

Regards

 

[kyle555]

The SBC needs to get audio from the remote worker first.

Consider me at home on my 192.168.1.0/24 registering through my public IP to the SBC - look at the SDP that the SBC will get in my client's invite - probably on my local 192 IP. The SBC should setup media between the remote client on the public IP in it's SDP - there's a spot in the network configuration for your external interface's corp IP and public IP mapped to it.

Then, the SBC will switch the invite internally to the PBX and the SDP exchange should be between the internal endpoint - like a phone if shuffled, or a gateway, and the SBC's internal IP and the SBC should juggle the forward and reverse audio on both sides.

You can do a PCAP from the SBC webpage on both interfaces to see what's being set up.

 

[JuanAvaya]

I guess I need to read/learn more about SDP as I do not exactly know what to look in it.

So far I capture both examples on .pcap. The bad one shows RTP packets going only from the MG to the SBC and nothing else. On the other hand, in the good call I see MG -> SBC -> Client and the other way around RTP packets.

 

[kyle555]

SDP is the media stuff in the SIP invites and OKs and stuff

look for the c= line - that's where your SIP endpoint is asking for audio to be sent to

 

[JuanAvaya]

Got it
So it fails when the cell phone with the client(Avaya communicator) gets a private ip from the provider which is then NAT'ed to a public one. The SBC receives the packets from the public one with the SDP stating to send audio to it's private. I guess there is some routing confussion at some point in the path

 

[kyle555]

Oh wow. Your mobile gets a private IP from the provider?

Yeah, so that's like being at home on your wifi. Except you can't slap your dlink router. You might be stuck