04-26-2018 09:56 AM - edited 03-18-2019 02:04 PM
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
Solved! Go to Solution.
05-19-2018 07:36 AM
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"
05-28-2018 01:27 PM
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.
05-15-2018 12:38 PM - edited 05-15-2018 12:39 PM
It's recommended that early be enabled for video calls, this can be configure on the SIP Profile that the VCS is using.
05-17-2018 04:55 AM
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
05-22-2018 12:58 PM
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.
05-17-2018 11:49 AM
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.
05-17-2018 12:43 PM - edited 05-18-2018 05:10 AM
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
05-18-2018 01:25 AM
Hi,
Something is wrong with the attachment as I am unable to download it. Please re-attach it
05-18-2018 05:16 AM
Hi Ayodeji
I did the upload again and now it seem to be OK.
Thank you for letting me know.
Regards,
Gilmar Silva
05-19-2018 07:36 AM
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"
05-22-2018 11:36 AM
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
05-28-2018 01:27 PM
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.
05-29-2018 04:18 AM
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
05-18-2018 02:29 AM
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).
05-18-2018 05:25 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide