Non-traversal Stumper

[Justin Ferello]

Hey all,

Looking at the network digram below, could anyone tell me why endpoint 192.168.10.10 registered via SIP only to the VCS-E Starter calls endpoint 10.1.1.246 which is registered SIP only to the VCS-C and the call is non-traversal?  Besides the call being a non-traversal call, 192.168.10.10 endpoint is unable to see or hear 10.1.1.246.  When doing packet sniff, I found that 10.1.1.246 is trying to send media to 192.168.10.10 instead of 2.2.2.2.       

Thank you,

Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
http://www.kbz.com
e/v: justin.ferello@kbz.com       

[Martin Koch]

The diagram does not say much, whats especially lacking is the zone types and when NAT is done,

also what kind of endpoints are used and if you use something like ice/stun/turn.

Also on things like the VCS-E-SP, if the dual interface option is present (would be required if

its IP is nated) and where the 192.168.10.10 endpoint is registered (would need to register to

2.2.2.2).

If there is no NAT changing the source address of the 192.168.10.10 endpoint and no ice

detecting the real flow this is the expected behavior on a vcs-e deployment on a sip call.

I had commented it before that there are clearly impovents needed regards the NAT/Media handling.

Search a bit, I had posted some comments before on that, ...

What happens is that the VCS-E-SP (same would happen on the standard VCS-E as well).

sees that the contact header ip/port and the source ip/port are the same and defines: oh, no nat,

its reachable, traversal call not needed.

What I would recommend, as you have to have the dual interface option anyhow, use the

second interface to directly be 2.2.2.2 (or place it in some additional network so you can nat 2.2.2.2 to the

lan2 ip (lan2&1 can not be in the same logical subnet btw!).Calls in between LAN1&LAN2 will

always cause a traversal call, so that part of the problem is solved.

But I would not expect 10.1.1.246 send traffic to neither 192.168.10.10 nor 2.2.2.2), in a standard deployment

I would expect to have a traversal zone in between the vcs-c and vcs-e which should cause the media

to flow from ep->vcs-c->vcs-e->vcse-sp>sp

If you use sip/tcp (I would strongly recommend using sip/tls) and one of your firewalls has some l3

capability that can mess things up in addition.

[Justin Ferello]

Martin,

All the endpoints are C series.  There is no STUN/ICE involved.  The VCS-E Starter has DI key, hence the NAT on it.  The 192.168.10.10 endpoint is registered to the 2.2.2.2 address.

Anyway, I think you hit the nail on the head, the endpoint is most likely not getting NAT'ed so the VCS-E Starter assumes it is directly available.

Thanks for the head check.  So to summarize I would need to NAT the endpoints regestered to the VCS-E Starter or impliment DI with both interfaces.  Would a 3rd option be to enable STUN/ICE and that would resolve the problem too?

Thank you,

Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
http://www.kbz.com
e/v: justin.ferello@kbz.com

[Martin Koch]

Regards STUN, as the C-Series do not supoprt STUN, so no that would not help.

In en enviroment with Jabber Video I had something similar and it helped, though

that was a standard VCS-E not SP.

Yes you could put a nat router on the left side between the endpoints and the VCS-E-SP

but the side effect would be that the local calls would also be traversal calls.

Licensing wide it might not matter as it most likely only has traversal call licenses,

but maybe you do not want to bind the media to the VCS-E-SP, ...

In short everything what forces the call to become a traversal call would do.

(so also interworked calls or a h323-assent/h.460.18 calls)

The option I like the best is to use the external ip on lan2 or to add an additional

DMZ and NAT the external IP to that new address on lan2 on the VCS-E-SP.

I do not fully agree with Ahmad. Sure call routing optimal can be sometimes add confusion,

but here it should not change mcuh. The media could still flow directly and thats your issue here.

And vice versa if you have an traversal call it would bind the call anyhow to the VCS

Please rate all answers!

[ahmashar]

Hi,

most likely you have VCSs set to route the call on optimum basis, meaning they get out of the way and let endpoints talk directly. to resolve it do this:  VCS configuration > Call > Configuration > Routing Mode   (change it to ) - Always.

I hope this resolves the issue for you.

regards, Ahmad