Jabber 9.7 via Expressway 8.1.1 / CUCM 10.0 - Calls from PSTN

[btmulgrew]

Hi - we have deployed Expressway C and E with CUCM 10.0 and have (evenutally) got devices registering.  We have came across an issue with inbound calls from the PSTN to the Jabber clients registered via Expressway (MRA) - we see the call disconnecting with a SIP 503 error as below:

SIP/2.0 503 Service Unavailable Via: SIP/2.0/TCP 10.x.x.x:5060;branch=z9hG4bK244171eb9519;received=10.4.51.10;ingress-zone=CEtcpCUCM01customercomau Call-ID: bb360800-37c190b9-23f4-a33040a@10.x.x.x CSeq: 101 INVITE From: < sip:+61424XXXXX@10.x.x.x> ;tag=209628~6914b4f0-6ac3-dfe5-ca2d-d895a4eb3dfa-28329826 To: < sip:8882@CUCM01.customer.com.au> ;tag=44023455d8cba015 Server: TANDBERG/4129 (X8.1.1) Warning: 399 10.4.51.16:5061 " No License Available" Content-Length: 0 

My understanding is we did not require Traversal licenses for MRA? 

Our PSTN is ISDN via SIP Trunk to CUCM.

We can make MRA Jabber external calls outbound to the PSTN and all clients work fine when registered on the enterprise network.

Thanks

Brian

[bernhardczapp]

Hello Brian,

we do have Expressway working with a similar deployment. There are no traversal licenses needed.

There must be some kind of configuration issue.

Best regards,

Bernhard

[heathrw]

Hi,

I just checked my deployment which does not have ISDN but a CUBE to an ITSP. My expressways do not have anything that resembles the Invite with the From and To sections. I have attached an example of a working output.

It appears that the call manager is routing the call from the gateway to the ExpresswayC as if it was a B2B URI call and not as a MRA registered device. Hence why internal calls are working and not calls from the gateway.

Do you have a SIP trunk and/or neighbour zones setup between the UCM and ExpresswayC along with SIP Dial Pattern?

Please attach the following:

- debug ccsip messages on your voice gateway from a PSTN to see what info is being sent to the UCM

- copy of your dial peers pointing the the UCM

- Grab the search history from the ExpresswayC and C for the call (Status --> Search History)

[mcibanez]

Hi Brian,

I've seen that problem in my deployment and it was not related to license in any way, in spite of what it seems.

I could make outbound calls, although with no audio, but inbound calls were failing and I got the same error message.

I guess you've got Exp-E with just one leg and you are NATting at the FW. If that's the case you can try to use a two-leg Exp-E (I didn't try that way but I was told that it could fix it too) or you can use the NAT (public) IP address to build the traversal zone.

I mean, my Exp-C was using the real Ip address as the peer in the traversal zone. I changed it to the NAT address (which by the way, you have to specify in the IP address section of the Exp-E) and everything began to work.

Hope this helps.

Regards,

Carmen

[btmulgrew]

Thanks Carmen -  yeah,  I am a little confused by some of the config requirements.  We are using a single interface deployment and DNS/FQDN for secure Traversal Zone (to match CN in cert).  The customer DNS is split horizon so I have a feeling we are resolving to the internal Exp-E address as opposed to the external NAT address.  I am going to ask them to remove the internal DNS entry and force the lookup to resolve the internet address (basically peer with this)  and see if this works.

Thanks

Brian

[mcibanez]

You're welcome, Brian. I don't know too much about DNS but we are also using FQDN to match cert so I asked the DNS guy to resolve to the external NAT address instead of the internal one.

Also, bear in mind that media is sent from the Expressway-C to the NAT address of the Expressway-E so you must ensure that your firewall allows this

Rgds,

Carmen

[btmulgrew]

Thanks everyone, this works fine using the external DNS / IP for Traversal. As a side note the Traversal Zone uses NAT reflection to route via the DMZ interface (as opposed to the external interface) on port 7001.

Cheers

Brian