VCS-E and external calling

[George Thomas]

Hello,

I have a VCS-E configured in the DMZ. I can call in and out from the corporate network. However when I register to VCS-E from the Internet using a movi client and try to call to an endpoint on the Internet , I don't get audio/video. Can someone point me in the right troubleshooting path? What path does the media take?

Sent from Cisco Technical Support iPhone App

[Tomonori Taniguchi]

For movi call you mention, does VCS-E handle the call as traversal call (you may check this from call status)?

Please note that VCS will handle as traversal call for call between SIP UA and one or both of SIP UA’s sip contact address differs from source IP address (consume traversal call license).

Therefore media go through VCS-E.

And VCS will handle as non-traversal call for call between SIP UA and both SIP UA’s have same sip contact address and source IP address (consume non-traversal call license).

Therefore media does not go through VCS-E.

From your description, assume VCS-E in DMZ with NAT IP address and VCS-E has proper NAT configuration.

The “debug” level of diagnostic log from VCS-E should give more clarification what is going on for media routing.

Please be careful for posting any log from VCS on public forum as it contain personal information (I’d suggest open for TAC case for further investigation with debug level diagnostic log, if needed).

[George Thomas]

Thanks, it does consume a traversal license. I will take a look at the debuts.

Sent from Cisco Technical Support iPhone App

[Tomonori Taniguchi]

OK, then your case VCS-E stay in media routing.

Currently VCS-E use “Media Latching” for SIP NAT traversal which media (RTP&RTCP) is sent to remote end after media packet is received (this opens up the NAT binding).

Possibly firewall block ACK message for Invite or block actual video/audio RTP payload.

The debug level diagnostic log should give more clarification about ACK message reachability (if you kept see continue 200 OK with SDP from call receiver side although 200 OK send back to call receiver, highly suspect this packet doesn’t reached to far end device).

[George Thomas]

I only see 200 OK twice once the call is connected. Anything else I can look other than opening a case?

[Tomonori Taniguchi]

To clarify more, I’d suggest to open the TAC case with log from VCS and Movi/Jabber client.

If your Movi/Jabber client configure to use TCP for transport session, you may double check media payload in/out destination and source by taking sniffer log on PC (i.e using wireshark).

[Martin Koch]

Hi George!

Some short side notes:

* as you mention that you use  the VCS in a DMZ, do you use NAT (like having the vcs on a private ip  and nat it to the public ip)? If so, this requires the dual interface  option (even if only one interface is used, but the nat feature is part

of that license as well) There are more forum entries about this topic.

* check that no application layer gateway / nat helper, ... is in the path of the VCS/endpoints/infrastructure/...

* check that your firewall allows in and outbound traffic to all media ports of the vcs-e. The default udp ports on X7.1 are

* 2776-2777 (multiplexed rtp)

* 50000-52399 (generic rtp media)

* 60000-61799 (turn - might not be used)

* 56000-57000 (b2bua - most likely not be used on vcse)

* outbound must be from these ports to >=1024 as you never know which high ports the remote site will use

* do you use turn/stun/ice with movi?

that  might change the traffic flow drastically as it also supports direct media in  between clients as well as the usage of the turn relay which adds  additional ports.

Anyhow, a tac case might bring the quickest results, but please update us what caused your issue.

George and all others: please rate the answers using the stars below!