VCS to CUCM incoming h323 to SIP interworking calls disconnecting with cause 47

[Gilmar Silva]

Hello Community,

I am facing an issue with incoming h323 to SIP interworking calls. All of them disconnect after the CUCM endpoint answer the call.

The call flow is:

External Party --H323--> VCS Expressway --H323--> VCS Control --SIP--> CUCM --SIP--> Endpoint

The VCS has the interwork option key, but only non-interworking SIP calls are working.

I noticed that when it is not an traversal call, the VCS to CUCM leg uses Early Offer.

I am not sure if it is related, but I would like to know if its possible to force VCS to use Early Offer in traversal calls.

If anyone knows anything else that might be causing this behavior, I will also be grateful.

Thank you,

Gilmar Silva

[Patrick Sparkman]

It's recommended that early be enabled for video calls, this can be configure on the SIP Profile that the VCS is using.

[Gilmar Silva]

Hello Patrick,

Thank you for replying.

Do you know how to force VCS to always send SDP in the invite? Now, it only sends in non traversal calls.

Regards,

Gilmar Silva

[Ayodeji Okanlawon]

In response to VCS and early offer. VCS is a proxy server and that means it forwards what it receives. It has no capability to negotiate SDP,hence it doesn't do EO or DO. If the SIP UAC or UAS sends EO, then VCS forwards it, if it sends DO, VCS forwards it.

[Randy Valverde Rojas]

Hi Gilmar!

The VCS/Expressway platform will always prefer early offer when possible.

Due to how interworking from H323 to SIP works, it has to be delayed offer.

On the H323 protocol, the media negotiation happens until after the connect, which translates to the 200ok on SIP so the VCS can't send any media on the invite because it has to wait for the media negotiation to happen on the H323 leg, and this will only happen after the 200ok.

As far as the disconnection, we would need logs to determine where the disconnect comes from and the possible reason.

[Gilmar Silva]

Hello Randy,

I will be very grateful if you may help.

I uploaded some logs (see the attached file Trace.zip). You will see three folders (CUCM, VCS-C and VCS-E) and the image "Call-Flow.tar" that shows the messagens in the TranslatorX with the following call flow:

External Party --DNS Zone/H.323--> VCS-E External IP (with NAT) --H.323--> VCS-E Internal IP --Traversal Zone/H.323-->  VCS-C --SIP--> CUCM

For the test, I used the tool "B2B call tester" under the "Collaboration Solutions Analyzer" (link bellow). So the calling party is 6342268364@b2b.ciscotac.net.

https://cway.cisco.com/tools/CollaborationSolutionsAnalyzer/

In the traces you will see two calls. One of them is a SIP call that worked properly and the other is an H.323 call that disconnected with the cause 47.

Thank you,

Gilmar Silva

[Ayodeji Okanlawon]

Hi,

Something is wrong with the attachment as I am unable to download it. Please re-attach it

[Gilmar Silva]

Hi Ayodeji

I did the upload again and now it seem to be OK.

Thank you for letting me know.

Regards,

Gilmar Silva

[Ayodeji Okanlawon · Accepted solution]

Hi,

I have analysed your logs and the issue you are having is that VCS-E is not receiving H245 negotiation from the far end, hence VCSC and CUCM cannot negotiate any media parameters for the call. Here is my analysis

+++ Call proceeds normally and CUCM sends 200 OK with SDP to VCSC +++

+++ VCSC sends H225 Connect to VCS_E and VCS-E sends H225 Connect to the far end indicating the IP and port to use for H245 negotiation +++

Detail="Sending H.225 Connect "
2018-04-26T08:45:36-03:00 br1nivce01 tvcs: UTCTime="2018-04-26 11:45:36,089" Module="network.h323" Level="DEBUG": Dst-ip="173.38.154.84" Dst-port="15087"
Sending H.225 PDU:
Q931
{
Message Type: Connect
Call reference flag: Message sent to originating side
Call reference value: 0x8029
Info Element : Bearer Capability
{
Type: Default
Multirate: True
Rate Multiplier: 31
Transfer Capability: Unrestricted
User Info: H323
}
Info Element : User User
{
Length = 97
}
}
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body connect :
{
protocolIdentifier { 0 0 8 2250 0 6 },
h245Address ipAddress :
{
ip 'B12BE299'H,
port 15004
},
destinationInfo
{
vendor
{
vendor
{
t35CountryCode 130,
t35Extension 1,
manufacturerCode 256
},
productId '54616E6462657267'H,
versionId '34313332'H
},
terminal
{
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 130,
t35Extension 1,
manufacturerCode 256
},
data '54616E6462657267'H
}
},
mc FALSE,
undefinedNode FALSE
},
conferenceID '4228ABDD602B4930AF2BA2C0D62F519C'H,
callIdentifier
{
guid '44E19BA934394110965897B78A0C979B'H
},
multipleCalls FALSE,
maintainConnection FALSE
},
h245Tunneling FALSE
}
}

++ after  13sec we get a H225 release complete from the far end. We never received any H245 negotiation +++

Detail="Received H.225 ReleaseComplete Q.931 Cause:Normal, unspecified, H.225 Cause:Undefined reason, Additional Info:None"
2018-04-26T08:45:49-03:00 br1nivce01 tvcs: UTCTime="2018-04-26 11:45:49,477" Module="network.h323" Level="DEBUG": Src-ip="173.38.154.84" Src-port="15087"
Received H.225 PDU:
Q931
{
Message Type: Release Complete
Call reference flag: Message sent from originating side
Call reference value: 0x29
Info Element : Cause
{
Location: Usr
Cause Value: Normal, unspecified
}
Info Element : User User
{
Length = 23
}
}
value H323-UserInformation ::=
{
h323-uu-pdu
{
h323-message-body releaseComplete :
{
protocolIdentifier { 0 0 8 2250 0 6 },
reason undefinedReason : NULL,
callIdentifier
{
guid '44E19BA934394110965897B78A0C979B'H
}
},
h245Tunneling FALSE

++ Afterwards VCSC sends ACK with no SDP to CUCM ++

2018-04-26T08:45:49-03:00 br1nivcc01 tvcs: UTCTime="2018-04-26 11:45:49,482" Module="developer.iwf" Level="DEBUG" CodeLocation="ppcmains/oak/calls/iwf/IWFOfferAnswerFuncs.cpp(128)" Method="Interworking::sendSipAck" Thread="0x7f972821c700": State="IWFConnectingSipOutLegState" Global-CallId="1f319aa8-049e-439d-804f-df5c18c4599e" Local-CallId="278c0eb2-de8b-47b9-8b06-6e0e71fe33fa" Sending Ack with no SDP:
ACK sip:551135737473@10.55.199.4:5560;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1;branch=z9hG4bK0deb24cd6bd410b53822abfc06d0d0521399338
Call-ID: f8a7e69e-746c-4864-a3cd-4ff58fe7de09
CSeq: 954261384 ACK
From: "6342268364@b2b.ciscotac.net" <sip:6342268364@b2b.ciscotac.net>;tag=880089c1624cebad
To: <sip:551135737473@nimbus.local>;tag=7050585~6c395a93-e832-416e-9ae7-9648bc375904-18853166
Max-Forwards: 70
Route: <sip:proxy-call-id=278c0eb2-de8b-47b9-8b06-6e0e71fe33fa@10.55.191.11:5060;transport=tcp;lr>
User-Agent: TANDBERG/4132 (X8.7.3)
Content-Length: 0

++ CUCM sends a BYE with cause code 47 +++

75579154.001 |08:45:49.493 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.55.191.11 on port 5060 index 189988
[18934398,NET]
BYE sip:6342268364@b2b.ciscotac.net SIP/2.0
Via: SIP/2.0/TCP 10.55.199.4:5560;branch=z9hG4bK14ff7a61b49f66
From: <sip:551135737473@nimbus.local>;tag=7050585~6c395a93-e832-416e-9ae7-9648bc375904-18853166
To: "6342268364@b2b.ciscotac.net" <sip:6342268364@b2b.ciscotac.net>;tag=880089c1624cebad
Date: Thu, 26 Apr 2018 11:45:49 GMT
Call-ID: f8a7e69e-746c-4864-a3cd-4ff58fe7de09
User-Agent: Cisco-CUCM11.5
Max-Forwards: 70
Route: <sip:proxy-call-id=278c0eb2-de8b-47b9-8b06-6e0e71fe33fa@10.55.191.11:5060;transport=tcp;lr>
CSeq: 101 BYE
Reason: Q.850;cause=47
Session-ID: 00001bb000105000a0001c39475b5e8f;remote=e2c11892910d7096f4deaa0ab7050585
Content-Length: 0

++ Summary ++

Call is failing because the far end is not sending H245 negotiation: (MS, TCS and OLC.)

You need ot verify that the far end can connect to you on the ephemeral port used for h245 negotiation. In this log the port is "15004"

[Gilmar Silva]

Hi Ayodeji,

Thank you for the analysis.


We are reviewing the firewall.


In fact, I think it problem began when the administrators replaced the ASA for a Cisco FirePOWER FTD.

Regards,

Gilmar Silva

[Randy Valverde Rojas · Accepted solution]

Sorry I forgot to follow up on this one, the analysis above seems accurate, on incoming calls the VCS is the one who will set the port for h245, this port is advertised on the connect message sent to the far end.

Make sure your firewall allows incoming TCP traffic on port range 15000-19999 (From internet to dmz or your VCSE)

If the far end is attempting to connect, this should fix your problem.

[Gilmar Silva]

Thank guys,

I did a packet capture and I was able to see the far end sending a message with the destination port 15014. It also tries to retransmit two time, but none of them arrives into the VCS.

The FirePOWER administrator is trying to find what exactly is blocking the messages because it is not seems there are rules to block these ports (maybe it's related to inspection).

Regards,

Gilmar Silva

[Nick Halbert-Lillyman]

Have you got interworking turned on on the VCS?

You could also try creating a SIP only traversal zone and having the VCS-E perform the interworking (again, make sure to turn interworking on on the VCS-E).

[Gilmar Silva]

Hi Nick,

The interworking is on in both VCS-C and VCS-E.

I will try to disable H.323 in the current traversal zone to make the interworking in the VCS-E.

Thank you for the suggestion.