H323 Video call dropped after 44min29sec : B2BUA disconnected call on the Ingress saying "Session expired".

[yamenmjendel]

Hey all,

I am using the following topology:

Video Endpoint (Public IP) <--(H323)-->cisco VCS-Exp(v7.2)<---SIP TLS---> cisco VCS-control(v7.2)<--H323 -> AA/MCU (cisco 8710)

The video call was initiated from a Public VC endpoint using H323 protocol to our VCS-exp Public IP. The call is established at the first time with the AA and then with the MCU Virtuel room. Some calls are terminated after 44min and 29sec for others are dropped after 1H16min. Looking to VCS control call history i found that the was call ended by the VCS control with the cause  : B2BUA disconnected call on the Ingress saying "Session expired".

Any idea why the VCS B2BUA is disconnecting the call? have you ever seen such behavior when interconnecting H323 to SIP ?

Is there any VCS timers to verify ? 

Best regards

Yam

[Ayodeji Okanlawon]

You might want to change your session refresh timer on the sip configuration page of your VCS

Go to VCS configuration>protocols>sip>configuration

Session refresh interval (seconds):

Try and increase this value and test again..

[yamenmjendel]

Hi Ayodeji, 

First of all thanks for your prompt reply :)

I changed the session refresh interval to the maximum time allowed 7200 but in vain. Should I set the same timer value in all VCS oe VCS-E ? or just the one responsible of the disconnection? 

Best regards,

[Ayodeji Okanlawon]

You should set it on both vcs-c and vcs-e. Alternatively you could send us the diagnostics logs for the vcs-c and we can look at the session expire timer and see what it is set to. Ensure that you set the log level to debug

[yamenmjendel]

I will set it in both system and try to run the test one more time. I will keep you updated.

thx

[yamenmjendel]

Hi, 

I changed the refresh timer on all VCS-C and VC-E included in this call but in vain. The call was disconnected after 60min10sec with the disconnection reason (Egress disconnected call saying "Gave up retrying to send a re-INVITE"), see attached.

In VCS-C diagnostic logs I noticed that the B2BUA try many times to send an Invite to it self (127.0.0.1) but without getting an answer. So after many attempts he decided to give up the call. 

According to cisco bug tool kit a nearly error was identified before with another call type using G729 codec (see description in bug notes CSCty97265). 

Is there any reason why the B2BUA try to send an invite to him self after a certain period? and is there any known issue with such call ?

Best regards,

[Ayodeji Okanlawon]

You may be interpreting the logs wrongly. Its not the b2bua that is sending the re-INVITE its the VCS.

VCS needs to send a refresher INVITE (re-INVITE) to refresh the session before the session timer expires. If it doesn't do this, the other party assumes the session is no longer active and terminates the call..

In this log, because VCS is acting as a proxy, it sends the Re-invite to itself and everyone in the route header

This is the route header: (looks like vcs is 10.182.112.10)

Route: <sip:proxy-call-id=9158ff72-4997-11e4-9b30-0010f321eafe@127.0.0.1:5061;transport=tls;lr>
 Route: <sip:proxy-call-id=9158ff72-4997-11e4-9b30-0010f321eafe@10.182.112.10:5061;transport=tls;lr>
 Route: <sip:proxy-call-id=9156b668-4997-11e4-a46d-0010f325de94@172.21.254.132:7005;transport=tls;lr>
 Route: <sip:proxy-call-id=9156b668-4997-11e4-a46d-0010f325de94@127.0.0.1:5061;transport=tls;lr>

+++Here is the re-INVITE VCS sends to itself+++

2014-10-01T19:20:12+00:00 vcs-contr200-01 b2bua[6121]: UTCTime="2014-10-01 19:20:12,177" Module="network.sip" Level="DEBUG":  Dst-ip="127.0.0.1"  Dst-port="5061"
 SIPMSG:
 |INVITE sip:127.0.0.1:5073;transport=tls SIP/2.0
 Via: SIP/2.0/TLS 127.0.0.1:5071;branch=z9hG4bK99109cc47df9506b912b86daa926d030707904;rport
 Call-ID: 67e0a556162b7734@127.0.0.1
 CSeq: 108 INVITE
 Contact: <sip:127.0.0.1:5071;transport=tls>;isfocus
 From: <sip:1287@localdomain.com>;tag=52e9ad8176cd97d1
 To: <sip:testuser007@127.0.0.1>;tag=0a23bf25fe8da7c3

+++Here is the re-INVITE sent to the other device..Which should be a VCS-E (172.21.254.132)

2014-10-01T19:20:12+00:00 vcs-contr200-01 tvcs: UTCTime="2014-10-01 19:20:12,182" Module="network.sip" Level="INFO":  Dst-ip="172.21.254.132"  Dst-port="7005"   Detail="Sending Request Method=INVITE, Request-URI=sip:127.0.0.1:5073;transport=tls, Call-ID=67e0a556162b7734@127.0.0.1"
2014-10-01T19:20:12+00:00 vcs-contr200-01 tvcs: UTCTime="2014-10-01 19:20:12,182" Module="network.sip" Level="DEBUG":  Dst-ip="172.21.254.132"  Dst-port="7005"
 SIPMSG:
 |INVITE sip:127.0.0.1:5073;transport=tls SIP/2.0
 Via: SIP/2.0/TLS 10.182.112.10:5061;egress-zone=TraversalZonetoVCSInternet;branch=z9hG4bKceb38e8294fabaa3da26422e4939a8135633529;proxy-call-id=9158ff72-4997-11e4-9b30-0010f321eafe;rport

This is where the call breaks. Because this device doesn't respond back to the re-INVITE, rather it sends a request pending
 Via: SIP/2.0/TLS 127.0.0.1:5071;branch=z9hG4bK99109cc47df9506b912b86daa926d030707904;received=127.0.0.1;rport=45860;ingress-zone=DefaultZone
 Call-ID: 67e0a556162b7734@127.0.0.1

+++This is the response from vcs-e+++

2014-10-01T19:20:12+00:00 vcs-contr200-01 tvcs: UTCTime="2014-10-01 19:20:12,231" Module="network.sip" Level="DEBUG":  Src-ip="172.21.254.132"  Src-port="7005"
 SIPMSG:
 SIP/2.0 491 Request Pending
 Via: SIP/2.0/TLS 10.182.112.10:5061;egress-zone=TraversalZonetoVCSInternet;branch=z9hG4bKceb38e8294fabaa3da26422e4939a8135633529;proxy-call-id=9158ff72-4997-11e4-9b30-0010f321eafe;received=10.182.112.10;rport=26192;ingress-zone=TraversaltoVCSBerlin
 Via: SIP/2.0/TLS 127.0.0.1:5071;branch=z9hG4bK99109cc47df9506b912b86daa926d030707904;received=127.0.0.1;rport=45860;ingress-zone=DefaultZone
 Call-ID: 67e0a556162b7734@127.0.0.1
 CSeq: 108 INVITE
 From: <sip:1287@localdomain.com>;tag=52e9ad8176cd97d1
 To: <sip:testuser007@127.0.0.1>;tag=0a23bf25fe8da7c3
 Server: TANDBERG/4352 (X7.2-b2bua-1.0)
 Content-Length: 0

So you need to look at the vcs-e logs and see what is going on there

[Martin Koch]

Could you explain a bit more how your setup is?

Is there no h323 active on the traveral zone? I would expect that path to be active and used and on a x7.2 deployement.

That the sip session timer kicks in at one point is more a symptom rather a cause.

I would check if there is any other kind of firewall, router, sip/h323 aware device or something similar

present in the setup which brings in the trouble.

[yamenmjendel]

Hi Martin,

As stated before the topology used is as flowing:

Public Video End-device (Internet)<--(H323)-->cisco VCS-Exp(v7.2)<---SIP TLS---> cisco VCS-control(v7.2)<--H323 -> AA/MCU (cisco 8710). All traversal communications between VCS and VCS-Express are established using SIP TLS. For some limitation on the cisco MCU with SIP we are just allowing the H323 on the neighbour zone communication between VCS-C and MCU8710. 

The call was initiated from the Public device to our VCS-E Public IP and then forwarded to the Auto attendant. An unexpected call disconnection is initiated from the VCS-C most of the time after 44min29sec or 1H16min. 

Regarding the FW and sip/H323 aware devices I have already checked with our security team one more time but it seems that no rules or reject was found.

Best regards

[dc-csa-blr]

Hi Martin,

Is this issue fixed? if yes what was the resolution, please share the details.

[veeranagowdaberigi3169]

Hi,

Am also facing same issue for traversal calls and getting the same error in the VCSE, is this issue resolved ?