Calls drop on a Jabber (Video) client after 30 seconds when dialling into a TelePresence Server - Cisco Community

2253

Views

0

Helpful

4

Replies

Hi Guys,

Calls drop on a Jabber (Video) client after 30 seconds when dialling into a TelePresence Server. This happens if the client is connected to the customer wireless. If the Jabber client is connected through the customer LAN or from home (only had one user to test) the call was fine. Points to point calls are also fine.

It was initially thought that this was due to a VCSc/e upgrade from X7.2.3 to X8.6.1 but after rolling the VCS’s back to X7.2.3 the wireless calls were still not working but the customer is sure that it has been working.

Either way,it’s not working now and I can see in the TPS event log that there’s an “INVITE” timeout:

40176 2015/11/06 22:40:47.203 SIP Error call 4775: Ending call due to INVITE transaction timeout

~

~

40195 2015/11/06 22:40:47.204 SIP Error call 4775: BYE transaction failed due to network error

The Windows Jabber SIP log from C:\~\ AppData\Local\Cisco\JabberVideo\Logs, has the following snippet, which shows a “SIP_INVITE_REJ”:

2015-11-06 22:58:17,526 WARNING PID 7260 TID 14300 SIP

Failed to find flow for outbound proxy: 91.212.138.52:5060, using default registration, 0

2015-11-06 22:58:17,526 DEBUG PID 7260 TID 14300 SIP

fsm-S: SipTrnsp-0 -> SipReg-0 SipTrnsp_Connection_Lost_Ind

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

fsm-S: SipTrnsp-0 -> SipTrLay-0 SipTrnsp_Msg_Excpt

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

fsm-S: SipTrnsp-0 -> SipTrLay-0 SipTrnsp_Msg_Excpt

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

fsm-R: SipReg-0 (Active) <- SipTrnsp-0 [I] SipTrnsp_Connection_Lost_Ind

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

SipTransport indicates that connection to was lost.

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

fsm-R: SipTrnsp-0 (Ready) <- SipTrans-27 [I] SipTrnsp_Trans_Term_Req

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

fsm-R: SipTrnsp-0 (Ready) <- SipTrans-28 [I] SipTrnsp_Trans_Term_Req

2015-11-06 22:58:17,527 INFO PID 7260 TID 14300 SIP

SipDialog(ui=3,s=0) InviteSent_doSIPTransRej: received iTUCookie = b

2015-11-06 22:58:17,527 INFO PID 7260 TID 14300 SIP

SipDialog(ui=3,s=0) sendInviteRejToStack (0:Connection closed by remote side)

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

fsm-R: SipEvNotify-0 (Active) <- SipUa-0 [I] SIPTrans_Rej

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

rejected transmission:transid 53

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

Got 481 on Subscribe, ment for uk-bridge-12@laingorourke.com, expires: 0

2015-11-06 22:58:17,527 INFO PID 7260 TID 14300 SIP

SipUa GRUU added OK

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

fsm-R: G2FSM-0 (Ready) <- SipStack-0 [I] SIP_Invite_Rej

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

_status_code_to_ended_reason: reason=5

2015-11-06 22:58:17,527 DEBUG PID 7260 TID 14300 SIP

_taf_sip_call_agent_invite_rej: reason: 0: 0: Connection closed by remote side

I’ve read other threads and most suggest that it’s a “network/firewall/ALG” issue but what precisely is the problem? Telling the customer it’s a “firewall” issue isn’t very helpful unless you tell them what to look for. I’ve asked them to check the firewall for any packet drops but they don’t see anything.

I can add logs if they'll help.

The current versions are:

VCSc/e – X7.2.3

TPS - 4.0(2.8)

Conductor – X2.3

Thanks,

David

4 Replies 4

Hi David,

It's difficult to tell exactly what is wrong here without the TelePresence Server logs directly, but in general a TS will attempt to re-INVITE back to a client calling in withing a few seconds of the start of the call (basically after the lobby screen) and if it gets no response to this message it will hang up the call after 30 seconds (the same thing will happen after ~15 minutes depending on your session refresh interval.) The exact destination IP address for this message will depend on what was included in the original SIP INVITE message from the Jabber client and will have been modified by each of the intermediate SIP proxies.

I'm assuming that depending on whether or not the client is connected wired ro wirelessly affects what IP address it is assigned and thus affects only the routing of the final hop (between the UCM and the Jabber client.) If a firewall is a fault here you will need to look into anything blocking that link. Alternatively if the different IP address causes it to register to a different device, this could affect further call routing and prevent the upstream re-INVITE. I'd certianly recommend you look at the differences in the signalling between the two cases to see if the wireless case is travelling to a completely different destination.

Regards,

James

Hi James,

Thanks for your assistance.

I’ll speak with the customer about the points you raise.

In a trace I took last week on the TPS, I’ve removed/replaced the customer domain name with <domain> to hide it. I’ve done the same with the SIP log from my laptop that was used for some Jabber video client calls.

They have a pair of TPS’s on 10.80.120.2 & 10.80.120.3

They have a pair of Conductors on 10.80.120.10 & 10.99.120.10

Client 192.168.0.4 (and maybe 192.168.0.13)

{Note: there's no CUCM in this}

Looking for INVITE message in the TPS log I see the following only referencing the client address 192.168.0.4:

39723 2015/11/06 22:40:09.400 SIP Detailed top line label = "INVITE" value = sip:88811482@10.80.120.2 SIP/2.0

~

~

39729 2015/11/06 22:40:09.401 SIP Detailed Found "To" = "<sip:88811482@10.80.120.2>" 39730 2015/11/06 22:40:09.401 SIP Trace Extracting URI from "<sip:88811482@10.80.120.2>"

39731 2015/11/06 22:40:09.401 SIP Detailed Found "From" = ""Steve Carlisle" <sip:scarlisle@<domain>>;tag=fb0b29d54f9d8f8e"

39732 2015/11/06 22:40:09.401 SIP Trace Extracting URI from ""Steve Carlisle" <sip:scarlisle@<domain>>;tag=fb0b29d54f9d8f8e"

39733 2015/11/06 22:40:09.401 SIP Detailed Found remote tag fb0b29d54f9d8f8e

39734 2015/11/06 22:40:09.401 SIP Detailed Found "Call-ID" = c21d05b3189203a1@192.168.0.4

~

~

39738 2015/11/06 22:40:09.401 SIP Info Incoming call from 10.99.120.10:39525

39739 2015/11/06 22:40:09.401 SIP Trace Connection c2130003 received Request PDU INVITE

39740 2015/11/06 22:40:09.401 SIP Trace Extracting URI from "<sip:88811482@10.80.120.2>"

~

~

39748 2015/11/06 22:40:09.402 SIP Trace Handling INVITE request

39749 2015/11/06 22:40:09.402 SIP Trace Extracting URI from "<sip:10.99.120.10:5073;transport=tls>"

39750 2015/11/06 22:40:09.402 SIP Trace Extracting URI from ""Steve Carlisle" <sip:scarlisle@<domain>>;tag=fb0b29d54f9d8f8e"

39751 2015/11/06 22:40:09.402 SIP Trace Received remote tag

39752 2015/11/06 22:40:09.402 SIP Trace Extracting URI from "<sip:88811482@10.80.120.2>"

39753 2015/11/06 22:40:09.402 SIP Trace Extracting URI from "<sip:88811482@10.80.120.2>"

39754 2015/11/06 22:40:09.402 SIP Trace Extracting URI from ""Steve Carlisle" <sip:scarlisle@<domain>>"

39755 2015/11/06 22:40:09.402 SIP Trace Received remote tag

39756 2015/11/06 22:40:09.402 SIP Trace Sending response 100 Trying no content

39757 2015/11/06 22:40:09.402 SIP Trace Extracting URI from "<sip:88811482@10.80.120.2>"

39758 2015/11/06 22:40:09.402 SIP Trace Sent 100 Trying to 10.99.120.10:5073

39759 2015/11/06 22:40:09.402 SIP Trace Handling Incoming Call

39760 2015/11/06 22:40:09.402 SIP Detailed Searching for handle for TLS connection to 10.99.120.10:5073

39761 2015/11/06 22:40:09.402 SIP Trace Found exisiting TCP handle for 10.99.120.10:5073

39762 2015/11/06 22:40:09.402 SIP Detailed incTCPRxUsage; handle: 0x657 count: 3

39763 2015/11/06 22:40:09.403 SIP Trace Route 1 for c2130003 linked to 00000657

39764 2015/11/06 22:40:09.403 SIP Trace Analysing SDP

39765 2015/11/06 22:40:09.403 SIP Trace New connection accepted

~

~

39921 2015/11/06 22:40:09.465 APP Info call 4775: "Steve Carlisle" now joined conference "UK-Bridge-12@<domain>"

~

~

39929 2015/11/06 22:40:09.465 SIP Trace Queueing up new INVITE transaction

~

~

39933 2015/11/06 22:40:09.466 SIP Trace Starting INVITE transaction

~

~

39951 2015/11/06 22:40:09.469 SIP Trace Sent INVITE to 10.99.120.10:5073

~

~

39966 2015/11/06 22:40:09.501 SIP Detailed Found "From" = ""UK-Bridge-12@<domain>" <sip:88811482@10.80.120.2>;tag=0048AEAEC2130003"

39967 2015/11/06 22:40:09.501 SIP Trace Extracting URI from ""UK-Bridge-12@<domain>" <sip:88811482@10.80.120.2>;tag=0048AEAEC2130003"

39968 2015/11/06 22:40:09.501 SIP Detailed Found local tag 0048AEAEC2130003, 16

39969 2015/11/06 22:40:09.501 SIP Detailed Found "To" = "<sip:scarlisle@<domain>>;tag=fb0b29d54f9d8f8e"

39970 2015/11/06 22:40:09.501 SIP Trace Extracting URI from "<sip:scarlisle@<domain>>;tag=fb0b29d54f9d8f8e"

39971 2015/11/06 22:40:09.501 SIP Detailed Found remote tag fb0b29d54f9d8f8e

39972 2015/11/06 22:40:09.501 SIP Detailed Found "Call-ID" = c21d05b3189203a1@192.168.0.4

~

~

39978 2015/11/06 22:40:09.501 SIP Trace Call-ID OK

~

~

40080 2015/11/06 22:40:15.196 SIP Trace Queueing up new INVITE transaction

~

~

40084 2015/11/06 22:40:15.196 SIP Trace Starting INVITE transaction

~

~

40093 2015/11/06 22:40:15.197 SIP Trace Sent INVITE to 10.99.120.10:5073

~

~

40173 2015/11/06 22:40:47.203 SIP Trace Unable to complete failover due to lack of alternative servers, clearing route

40174 2015/11/06 22:40:47.203 SIP Detailed decTCPRxUsage; handle: 0x657 count: 2

40175 2015/11/06 22:40:47.203 SIP Trace Route 1 for c2130003 unlinked from 00000657 40176 2015/11/06 22:40:47.203 SIP Error call 4775: Ending call due to INVITE transaction timeout

40177 2015/11/06 22:40:47.203 SIP Trace Freed client transaction. 1604 free

40178 2015/11/06 22:40:47.203 SIP Trace Enter SIP Connection closed

4079 2015/11/06 22:40:47.203 SIP Trace SIP Connection closed

40180 2015/11/06 22:40:47.203 CMGR Info call 4775: disconnecting, "scarlisle@<domain>" - timeout

40181 2015/11/06 22:40:47.203 APP Info call 4775: tearing down call from "Steve Carlisle" - destroy at far end request; timeout

40182 2015/11/06 22:40:47.203 SIP Trace Queueing up new BYE transaction

In the attached desktop client SIP file I see the IP address 192.168.0.4 in all of the application/sdp messages:

Content-Type: application/sdp

Content-Length: 2184

v=0

o=tandberg 1 4 IN IP4 192.168.0.4

s=-

c=IN IP4 192.168.0.4

However, I also see the address 192.168.0.13 being received from an external address (hidden 2^nd & 3^rd octets) 193.x.x.102 which I assume is their wireless?

Via: SIP/2.0/TLS 192.168.0.13:19527;branch=z9hG4bKbf17a742911864b99929963c05d49f63.1;received=193.x.x.102;rport=19527;ingress-zone=DefaultSubZone

Is the 192.168.0.13 a red herring, or is this part of the issue?

Thanks again,

David

1912 KB

69 KB

Hi,

Can the jabber users ring eachother over the WLAN?

It looks like SIP ALG is enabled on the WLAN maybe.

It look like your Jabber Video is registering to the VCS E at its public IP address and in my understanding, you´want to reach the TLPS internally.

Check at the VCSs for this endpoint URI registration and confirm if it is registered at the VCSE or the VCS C.

REGISTER sip:<domain> SIP/2.0
Via: SIP/2.0/TCP 192.168.0.4:29095;branch=z9hG4bKa6d66bcb02505778342c6f49c7d4524a.1;rport
Call-ID: e790551ae192d481@192.168.0.4
CSeq: 21282 REGISTER
Contact: <sip:scarlisle.jabber@192.168.0.4:29095;transport=tcp>;+sip.instance="<urn:uuid:457eac8c-5f2a-501b-84b6-91fd5b651ebb>"
From: <sip:scarlisle.jabber@<domain>>;tag=86a6c76ad55cfa0f
To: <sip:scarlisle.jabber@<domain>>
Max-Forwards: 70
Route: <sip:91.212.138.52:5060;lr>

If you need to register at the VCSC, you can try to remove the external address from the Jabber Video (leave empty) and configure the Internal Server field only, pointing to the VCS C IP Address. In this way you will overrride any DNS misconfiguration and can confirm that it is registered at the VCS C and try again.

When in a call, check at VCS Call status for the path if it is what you expect and check the IPs.

PS: If the call is going to outside using the wi-fi, the Internet Firewall may have some SIP configuration do inspect SIP call. Try to use TLS intead TCP to check if it works, but if thi wi-fi have connectivity with the corporate network where VC infra resides, the Jabber Video should register at the VCS C.

Regards

Learn, share, save

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

Log in to Community