Telepresence CTS 500 over GRE tunnel

[Marek Tarnoci]

Hello,

I would like to install Telepresence CTS 500 in remote office via public internet (Cisco TelePresence Extended Reach) I’ve configured pure GRE tunnel Between HQ and Branch and registered CTS over this tunnel to CUCM. Now, if I start the call, signaling pass, telepresence pick up the call but video nor audio does not start. If I place only voice call from phone, everything works fine, RTP stream starts I can hear other site, we can hear each other.

I don't understand why it is problem with video call from telepresence. It looks like when RTP stream packets are encapsulated to tunnel, there is some problem. In wireshark I can see that RTP packets have "Wrong sequence number"

As I've read in documentation Tunneling TelePresence traffic over GRE/IPSec tunnels is supported.  Could you give me some advice how should be tunnel, network or telepresence devices configured to support telepresence traffic over GRE tunel?

If I register Telepresence over internet to CUCM which has public IP address (not via tunnel) it works, no problem with video and audio.

[antigles]

Hi,

Assuming you dont use FW or NAT on any case I am wondering if your end to end minimum MTU when tunneling is big enough. Network should allow packets of 1200 bytes to travel unfragmented from CTS to CTS. Can you try an extended ping from the LAN of the spoke router to the central office CTS with a packet size of 1200 and the dont fragment option set?

Other than that, hopefuly you can find some hints on the following links

Extended Reach: Implementing TelePresence over Cisco Virtual Office

www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns430/guide_c07-581216_v2.pdf

Cisco TelePresence Network Systems 2.0 Design Guide www.cisco.com/en/US/partner/docs/solutions/Enterprise/Video/TP-Book.html

Best regards.

[Marek Tarnoci]

Hi,

Thank you for your answer.

I'm trying it first in the lab. I'm not using FW. NAT is applyed on both side, on HQ and BR as well. Between HQ and BR is GRE Tunnel. I can reach through tunnel private networks each other. CTS is registered to CUCM in HQ private network behind NAT. MTU between both ends through GRE Tunnel is 1476 bytes.

C:\Documents and Settings\mta>mturoute 172.29.2.29

* ICMP Fragmentation is not permitted. *

* Speed optimization is enabled. *

* Maximum payload is 10000 bytes. *

- ICMP payload of 1472 bytes is too big.

+ ICMP payload of 92 bytes succeeded.

+ ICMP payload of 782 bytes succeeded.

+ ICMP payload of 1127 bytes succeeded.

+ ICMP payload of 1299 bytes succeeded.

+ ICMP payload of 1385 bytes succeeded.

+ ICMP payload of 1428 bytes succeeded.

- ICMP payload of 1450 bytes is too big.

+ ICMP payload of 1439 bytes succeeded.

+ ICMP payload of 1444 bytes succeeded.

+ ICMP payload of 1447 bytes succeeded.

+ ICMP payload of 1448 bytes succeeded.

- ICMP payload of 1449 bytes is too big.

Path MTU: 1476 bytes.

C:\Documents and Settings\mta>mturoute  -t 172.29.2.29

mturoute to 172.29.2.29, 30 hops max, variable sized packets

* ICMP Fragmentation is not permitted. *

* Speed optimization is enabled. *

* Maximum payload is 10000 bytes. *

1  +-  host: 192.168.1.1  max: 1500 bytes

2  -++++++-++++-  host: 10.10.10.1  max: 1476 bytes

3  +-  host: 172.29.2.29  max: 1476 bytes

172.29.2.29 is IP Address of CTS 500 in HQ"

C:\Documents and Settings\mta>ping 172.29.2.29 -f -l 1430

Pinging 172.29.2.29 with 1430 bytes of data:

Reply from 172.29.2.29: bytes=1430 time=20ms TTL=62

Reply from 172.29.2.29: bytes=1430 time=20ms TTL=62

Reply from 172.29.2.29: bytes=1430 time=20ms TTL=62

Reply from 172.29.2.29: bytes=1430 time=20ms TTL=62

Ping statistics for 172.29.2.29:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 20ms, Maximum = 20ms, Average = 20ms

I've attached snapshot from wireshark, captured on tunnel interface on router.

[antigles]

Thanks Marek,

In that case, at this point, the range os possible causes is so wide that I would go back to the basics and would check syslog on both CTS looking for any evident issues. Comparing the log of good and bad calls should help.

I see that you are using wireshark. You can benefit of using the VOIP call graph analisys that will show you call singalling and flows negotiations. Again comparing graphs for calls working and failing could help you.  Following link intruduces this graph feauture of wireshark. http://wiki.wireshark.org/VoIP_calls

Last but not least, NAT adds complexity to all this. You might try witout NAT first and once it is working you can try adding NAT. Following link contains some guidance about CTS and NAT. http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/tpfirewall.html#wp1046399

Best regards.

[Marek Tarnoci]

OK let me summarize what I found and configured:

1. I tried it without NAT on HQ side first

    - I had Call manager with Public IP address

    - On HQ I had CTS with Public IP

    - On BR I had 1 Public address (NAT 1:1)

I've registered CTS from BR to CUCM, first I had some issue with ALG on router, CTS was registered with private IP address on CUCM, but I found some workaround to fix this issue and I registered CTS with pulic IP address.

I did make test call, everything has worked. I attached snapshot from wireshark named Good_Call

2. I configured GRE tunnel between HQ and BR,

    - on HQ NAT -  subnet 172.29.2.0/24

    - I had CUCM with Private IP  172.29.2.10

    - on HQ CTS on private IP from 172.29.2.29

    - on BR same as before => NAT - internal subnet 192.168.1.0/24

    - CTS IP Address 192.168.1.7

I did make test call, signalling pass, seems as RTP strem was started but packets have been marked as packets with wrong sequence numbers (was captured with Wireshark on tunnel interface). I've attached snapshot from wireshark named Bad_Call.

If I made simple phone call from IP telephone to CTS, everything is working fine (look on Voice_Call.jpg). Backward way from CTS to CTS with IP phone - result - blank black screen, no video, no audio. Interesting is that stream was not broken, only packets were marked as with wrong sequence numbers and were not processed.

[antigles]

Hi Marek,

On your call graph you can see that RTP flows dont actually get to be stablished bidirectionally. In fact, the messaging of good and bad video calls diverse quite significantly after just a few steps.

A deeper look into each SIP message should be done. I would suggest you to engage TAC to assist.

Best regards.

[Marek Tarnoci]

Hi,

FYI:

We solved the issue. We were using 192.168.1.0/24 subnet on BR site. That is problem, because telepresence is using this subnet for internal purposes (another codecs, camera ...). So RTP flows don't get to be stablished bidirectionally, because one of codec routed traffic somewhere inside the device. After changing IP addresses range on BR site to different subnet, it start working :-)

Have a nice day