Frequent Asked Questions

-          How does Tiphone handle ‘#’ in the TO field?

o        On the SIP side:

# should not be directly used in an URI. ‘#’ sign is a notion for fragments in an URI. it is same to HTTP URL similar to http://www.something.com/news.html#today. The ‘#’ here means a fragment. So using ‘#’ without escape is definitely not correct.

 The HSS stack treats the '#' as illegal.

-          How Tiphone handles Non-FQDN?

o        Go to /etc/

o        Vi hosts and add the IP and Non-FQDN into the list

o        This is because DNS will fail query and cause SIPUA send wrong message

-          Does Contact Header mandatory in registration?

o        No, it is not.

o        So the 200OK will respond without Contact Header

-          What is the usage of maddr in REQuest line?

o        If the Request-URI has a maddr

parameter with a value the proxy is responsible for, and the request

was received using the port and transport indicated (explicitly or by

default) in the Request-URI, the proxy MUST strip the maddr and any

non-default port or transport parameter and continue processing as if

those values had not been present in the request.

-          What is the usage loose route and strict route?

o        The way how record routing works has evolved. Record routing according to RFC2543 rewrote the Request-URIii.

That means the Request-URI alwayscontained URI of the next hop (which can be either next proxy server which  inserted Record-Route header field or destination user agent). Because of that it was necessary to save the original Request-URI as the last Route header field. This approach is called strict routing.

Loose routing,

as specified in RFC3261, works in a little bit different way. The Request-URI is no more overwritten, it always contains URI of the destination user agent. If there are any Route header field in a message, than the message is sent to the URI from the topmost Route header field. This is significant change--Request-URI doesn't necessarily contain URI to which the request will be sent. In fact, loose routing is very similar to

 IP source routing.

Because transit from strict routing to loose routing would break backwards compatibility and older user agents  wouldn't work, it is necessary to make loose routing backwards compatible. The backwards compatibility  unfortunately adds a lot of overhead and is often source of major problems.

In case of loose routing in the responce sent to a request ,Request-URI would contain the final destination to be reached and the Route header is used as the path to reach the same Where as in strict routing the Request-URI would say the next hop to be reached and the last entry in route will be the final destination to be reached

-        

DICE: Disributed Interactive Connectivity Establishment

The Interactive Connectivity Establishment (ICE) draft, developed by the IETF's MMUSIC working group, provides a framework to unify the various NAT traversal techniques. This enables SIP-based VoIP clients to successful traverse the variety of firewalls that may exist between a remote user and a network.

ICE defines a standardized method for SIP-enabled clients (or clients based on other multimedia session protocols) to determine what type of NAT firewall(s) exist between clients and determine a set of IP addresses by which clients can establish contact. Using a number of protocols and network connectivity mechanisms, such as STUN, Traversal Using Relay NAT (TURN) and Realm Specific IP (RSIP), ICE learns about the network topology in which the clients exist and the various sets of network addresses by which these devices can communicate.

When an ICE-enabled client (the initiator) wishes to communicate with another device (the responder), it first collects as many sets of IP addresses as possible from sources such as STUN, TURN, RSIP and locally configured addresses that can provide information on addresses where the client can receive IP traffic. A key benefit that ICE provides is the ability to unify the information provided by these various sources of IP address information to create as many paths as possible by which the endpoints can be reached.

Micah networks has developed a distributed model ICE technology which can break through symmetrical, full cone, IP restricted and port restricted types of NAT/Firewall.