Calls dropping after 15 minutes after reinvite

[Paul Richardson]

Hi,

This is a weird one.  Client A places an outgoing call from a Cisco Telepresence unit registered to a VCSE cluster to another Cisco endpoint at Client B via a traversal zone to Client B VCSC.  The call starts and runs for 15 minutes and then drops.  At first I thought SIP refresh timer problem, but running the Expressway diagnostic log through TranslatorX showed that client A receives a reinvite with SDP from client B and client A responds with a 200 with SDP.  After this exchange client B sends a BYE with the reason stated as "Invalid crypto profile in answer"

Both client endpoints do not have issues calling any other endpoints.  This only occurs between these two endpoints.

Any ideas would be very much appreciated.

Cheers, Paul R.

[Michael Rubin]

Its a SIP timer.  Check the timer's  Check also check Deep packet inspection on firewall. Here is a link from Cisco about SIP timers:

https://www.cisco.com/c/en/us/td/docs/routers/7600/install_config/sbc_config_guide_2/sbc-7600-config-guide/sbc_str.pdf 

[Michael Rubin]

Sorry did not read whole issue, do a route trace from the codec and see if there is a unexpected route.

[Ray Boland]

The call path doesn't seem right

Is this the call scenario?

Endpoint>VCS-E <traversal zone> VCS-C>Endpoint

Are the VCSE and C part of the same organisation? 

I agree with the other comments, you need to look at the differences in each unit's LAN setup. There is something that is SIP aware impacting the call leg

[Paul Richardson]

Spoiler

Hi Ray,

The call scenario is correct.  The VCSC and VCSE cluster are in different organizations in the health sector.  The VCSE cluster acts as a central point for directing VC calls between a number of different health providers via their VCSC's and traversal zones.

The SIP message in the BYE is one I haven't seen before.  If it was a crypto issue, I would expect that call setup would fail initially.

Will have to keep digging.

Cheers, Paul R.

[Tanveer Ahmad Mubsher]

is there a WebEx participant involved in the call, if so you might be missing WebEx CA certs on Expressway E

[Paul Richardson]

Hi,



There are no Webex participants, purely standard Cisco VC endpoints.



Cheers, Paul R.

[Ray Boland]

From a high level (ignoring the organisational side of it) you're describing a standard traversal call failing between two endpoints.

Is there an endpoint C (internal or external) that works? If so, you'll need to compare all aspects of the calls

For instance, if there is an endpoint C is on the same VCS Control as A, where calls from C->B work, but calls from A-> B fail

You would need to compare A and C

- Firmware

- LAN/Network config

- Endpoint configuration (copy the xconfig from both units into an excel file and remove the duplicates is an quick way of doing it.

-Call Direction

We've had customer's where a traversal call fails due to firewalls/WAN optimizers recognising the session as a VOIP protocol. They don't through an alarm or block any traffic, but they do try to proxy the SIP session, which might be why you are seeing the odd crypto stuff. You're firewall admin will look at the logs and see no blocked traffic for the VC units, but really they should be comparing the working call with the failed call.

It would be good to hear the solution!

[tarukum25]

Hi Paul,

Well, if issue is with crypto lines post 15 minutes of call, could you please check/share the following:

1. What information is shared in initial Invite under SDP information with respect to crypto parameters?(Comparison can be done with working scenario as well)

2. Is it encrypted/ un-encrypted call?

3. If it is un-encrypted, please check Encryption mode under device configuration, which should be set as Best effort/ None? (You may check with this option)

4. What firmware is being used on Servers and Endpoints?

5. If it is un-encrypted call, you may bring SIP connectivity to TCP 5060.