Firewall / NAT features lacking

[Martin Koch]

Hello Tomonori/Andreas/Alok/...

If SIP endpoints are firewall and have public ips (3g networks, governmental organizations, ...)

we run into issues. Sure there are some workarounds to force it to a traversal call but thats not realy good.

What I lack is the capability to set based on source ip or source alias a forced NAT (or also forced no-NAT (not

only for sip also for h323 h460.18)) handling on the VCS.

Also the STUN server seems to lack the test with the secondary ip address to detect "symmetric" firewalls/nat.

Also the endpoints could have settings to disable h460.18 as well as for sip a setting to force traversal calls (on endpoints, but also on Jabber Video)

Also ICE support on TC/TE endpoint is missing.

Are there any plans to have an improved firewall handling for sip on the VCS and endpoints?

What are suggestions / workarounds regards that?

[Tomonori Taniguchi]

As you know VCS currently handle SIP call as following condition and no plan for making a change for this as of today.

• Traversal Call: The call between SIP UA and one or both of SIP UA’s sip contact address differs from source IP address
• Non-Traversal Call: The call between SIP UA and both SIP UA’s have same sip contact address and source IP address

Can you explain a bit more detail what exact SIP firewall issue you are experiencing?

Of course current SIP firewall traversal relay on “Latching”, this might not work on all firewall especially firewall has tight source/destination port configuration.

• Media (RTP&RTCP) is sent to remote end after media packet is received (this opens up the NAT binding).
• Media sent to network address from which the media packet is received

And this require (or have requirement) that endpoint must use symmetric RTP (able to receive RTP from where it sent RTP).

BTW, Cisco is planning for implementing ICE on TC/TE software on next major release software after TC6.0/TE6.0 software release.