Expressway to CUCM calls

[maciej_wilk]

Hi guys,

I have an interesting scenario, which looks like this:

The E20 is registered with VCS Expressway, while the 9951 phone is VPNed to the same network as CUCM and registered with it.

Now when the E20 uses TLS as the default transport the call to 9951 works fine. When I switch to UDP, the call gets set up but no media goes through.

From the logs on VCS-E I can see that the first call is treated as traversal and gets routed through the traversal subzone. The second doesn't go to the traversal subzone and no media gets to Expressway so I assume the call is treated as non-traversal.

The question is why?

Kind regards

Maciek

[awinter2]

Hi Maciek,

the first thing that comes to mind when you mention that the Expressway does not take media for the UDP scenario is that one or both of the ASA's might be configured to do SIP inspection for SIP over UDP. SIP and H323 ALGs are known to disrupt the firewall traversal mechanisms built into the E20 and VCS-E, in the case where the firewall performing ALG/inspection modifies or strips parts of the SIP and H323 payload.

In this scenario, you should at least make sure to disable any SIP inspection (and H323 for that matter) for the ASA sitting in between the E20 and the VCS-E, and probably on the one between VCS-E and CUCM as well.

I assume there is no NAT between the VCS-E and CUCM?

Also, out of curiosity, why would you prefer registering the E20 over UDP rather than TCP/TLS?

- Andreas

[maciej_wilk]

Hi Andreas,

Thanks for the answer. I do not want to use UDP, I am just curious why it does not work when UDP is used.

What you said makes sense, as ASA is not able to perform SIP inspection for SIP over TLS.

Also I looked into the packets and for UDP the SDP part has public IP addresses in the o and c fields:

o=tandberg 15 1 IN IP4 81.x.x.x

c=IN IP4 81.x.x.x

while for TLS it has private IP addresses:

o=tandberg 13 1 IN IP4 10.x.x.x

c=IN IP4 10.x.x.x

Are there some kind of requirements for the SIP fields format in order for Expressway to do it's job?

Kind regards

Maciek

[awinter2]

Hi Maciek,

the VCS-E looks at the c-line (c=IN ...) when determing if a remote endpoint, in this case the E20, is located behind a NAT or not. If the ASA in between the E20 and VCS-E modifies the c-line and changes this from IN IP4 10.x.x.x to IN IP 4 81.x.x.x, the VCS-E will assume that the E20 is not behind a NAT but rather assigned with a public IP address, and will therefore not take media for the E20.

Regards

Andreas

[maciej_wilk]

Thanks Andreas, makes perfect sense.

So what is the general rule? VCS-E takes the media only if an endpoint is behind a NAT?

The admin guide states:

- a SIP to SIP call when one of the participants is behind a NAT (unless both endpoints are using ICE for

NAT traversal)

In this scenario both participants are behind a NAT. CUCM has a static 1:1 NAT.

Kind regards

Maciek

[awinter2]

Hi Maciek,

Since CUCM is behind a 1:1 NAT, what is CUCM presenting in its c-line when sending INVITE requests towards the VCS-E? Has CUCM been configured to represent that it has a public IP address?

Reason for asking is because if you see the VCS-E not taking media, it must think that neither the E20 nor CUCM is behind a NAT, so I'm guessing that CUCM is either configured to advertise a public IP address in its signaling, or that the ASA on the CUCM-side is performing ALG/inspection as well.

A diagnostics log from the VCS-E should provide answers to these questions.

- Andreas

[maciej_wilk]

Hi Andreas,

I can't perform additional tests right now but I have the previous session log when the call is initiated from the E20 to the 9951. In the 183 session progress message received from CUCM I can see:

o=CiscoSystemsCCM-SIP 2000 1 IN IP4 81.x.x.x (this is the public IP of CUCM)

s=SIP Call

c=IN IP4 81.x.x.x (this is the public IP of the outside interface of the ASA appliance)

So I assume the Invite would look the same, is that correct?

I am not aware of a settting that can enforce CUCM to advertise a public IP address in its signaling, do you know where can this be set?

Kind regards

Maciek

[awinter2]

Maciek,

yes if the SDP in the 183 response has a c-line of IN IP4 81.x.x.x, I would expect that an INVITE coming from CUCM would have the same.

You can in any case check the 200 OK response for the INVITE in the E20 to CUCM call logs to check if the c-line in the 200 OK SDP also shows the outside IP of the ASA.

- Andreas