How does a caller find its proxy server?
Calls typically proceed directly to the callee's domain. For example, when calling alice@example.com, the INVITE request would be sent to the SIP server for the domain example.com, found via DNS.
If a "local" (outbound) proxy is needed for outgoing calls, it currently needs to be manually configured, similar to the configuration of web proxies in browsers. Another possibility is to use DHCP or SLP through one of the extensions listed in http://www.cs.columbia.edu/~hgs/sip/drafts_dhcp.html.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:26pm
What's the difference between a stateless and a stateful proxy server?
Stateless proxies forget about the SIP request once it has been forwarded. Stateful proxies remember the request after it has been forwarded, so they can associate the response with some internal state. In other words, stateful proxies maintain transaction state. Stateful implies transaction state, not call state.
Stateless proxies scale very well, and can be very fast. They are good for network cores. Stateful proxies can do more (they can fork, for example, see the next question) and can provide services stateless ones can't (call forward busy, for example). They don't scale as much as stateless ones. An admininstrator gets to decide which to use. These are also logical entities; a physical proxy is likely to act as a stateless proxy for some calls, stateful for others, and as a redirect server for even others.
Neither stateful nor stateless proxies need to maintain call state, although they can, but will need to make sure that they are part of subsequent transactions via the Record-Route header.
A proxy must be stateful if one of the following conditions hold:
1. It uses TCP,
2. It uses multicast,
3. It forks.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:37pm
Why can a forking SIP proxy not be stateless?
A forking SIP proxy cannot be stateless because it needs to perform a filtering operation, returning (in general) one response out of the many it receives. For example, a forking proxy with three branches, that receives a 200-class, 400-class, and 500-class response on each branch respectively, should return only the 200-class response upstream. If the proxy were stateless, it would end up returning all three of the responses upstream (since it won't remember that it had received prior responses when it gets another one). The result of this is (1) response implosion at the client, and (2) inconsistent responses at the client. (In this example, depending on the order the responses received, the client might think that the call failed, just to get a success indication some time later.) Thus, a forking proxy must be stateful.
Also note that a proxy that uses TCP must be stateful as well, whether it forks or not. This has to do with reliability issues.
Why do you want state in a proxy? Certain services (like forking) simply require it. A sequential search proxy requires state; sequential search is the heart of services like follow-me and personal mobility. It's at the discretion of the implementor whether to use a stateful or stateless proxy. You can even be "super stateful", and use the Record-Route header to allow a proxy to be on the signaling path of all subsequent exchanges. This allows a stateful proxy to maintain call state in addition to transaction state.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:48pm
How does a caller find the remote SIP client of the callee?
The process is similar to the delivery of email: The caller uses the SIP host name to look up the destination host, first trying a SRV record and then "regular" DNS, just like an email client (MTA) looks up the MX record. (SRV records are generalized MX records applicable to any network service, including, but not limited to, SIP and RTSP.) For example, when contacting sip:bell@cs.columbia.edu,
the client finds a SRV record pointing to erlang.cs.columbia.edu
as the SIP server for the domain cs.columbia.edu. As for email, a single domain name can resolve to multiple servers, allowing load sharing and redundancy.
The server located in this manner can then proxy or forward the call to another server.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:51pm
How does SIP get through a firewall?
There are several possible approaches to SIP-capable firewalls. One of the difficulties is that, unlike for, say, HTTP, connections are originated both by hosts inside and outside the firewall. A likely arrangement is that a SIP proxy sits "on" the firewall and relays SIP requests between the Internet and the intranet. Thix proxy would also open up the necessary ports in the firewall to let audio and video flow through, for example using Socks V5.
As an alternative, if a firewall or NAT allows outgoing TCP connections, the inside client can open up a TCP connection to an outside proxy. All outgoing and incoming calls would then be handled by that TCP connection. (The client would still have to use SOCKS or similar mechanism to convince the firewall to let RTP packets through.)
Take a look at the two dratfs at http://www.cs.columbia.edu/~hgs/sip/drafts_firewall.html for a more detaled discussion of getting SIP through firewalls and NATs.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:56pm
Does SIP do keep-alive?
SIP itself does not have a keep-alive mechanism during the call. It was felt that loss of connectivity would be detected rapidly by the absence of media packets, typically sent at a much higher rate than any signaling keep-alive messages could be sent. In addition, the signaling path is not needed during the conversation and may well be completely different (due to proxy and redirect servers) than the media path, so that keep-alives have a limited functionality. If it is desired to test the liveness of a signaling server, it is always possible to send either OPTIONS or (re)INVITE messages.
However, knowing the call state might be useful for certain applications (e.g., when billing is involved, when firewall permissions need to be set etc.). Session timer extension has been defined to solve this. The draft can be found at http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-session-timer-01.txt and it basically allows the servers indicate a desired refresh interval. The call is considered terminated if a re-INVITE is not received within that interval.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 10:29pm
Why does SIP not have a Content-Transfer-Encoding header?
The Content-Transfer-Encoding header was primarily meant to allow message bodies to be transformed into formats that could be transferred on channels that were not 8 bit clean. HTTP, which makes use of many of the MIME headers, is 8 bit clean, and thus did not need Content-Transfer-Encoding. SIP followed suit, and so does not use it either. Content-Encoding is used for things like compression, which is different. (J. Rosenberg)
See also RFC 2616 (HTTP/1.1), Section 19.4.5.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 10:53pm
I want SIP to be more compact. What can I do?
First, one should realize that in general, SIP exchanges are only going to be a tiny fraction of the overall session bandwidth. A typical SIP call setup takes less than 1000 bytes, or the equivalent of one second of highly compressed (G.729) audio. Some additional space savings can be realized by using short headers. (A realistic example for an audio call setup takes a total of about 640 bytes, of which about 69 bytes are SIP headers.)
In general, more substantive savings are possible by using either payload compression (RFC 2393) or link-layer compression, e.g., at the PPP layer. For the example above, the total size is reduced to about 520 bytes with gzip compression.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 10:55pm
What are the different addresses in SIP?
SIP INVITE requests involve three addresses:
1.The host address where the request came from. Responses are sent back to the same host address, regardless of what the From header indicates. Note that different requests for the same call can come from different hosts.
2.The From address contains the logical source of the request. It remains unmodified as a SIP request traverses proxies, for example. The From address may not be the same as the host address that generated the SIP request, although that's the typical case.
3.The session description (e.g., SDP) contains one or more addresses where the caller expects media data (audio, video) to be sent. For some services, this address may not be the same as the From address.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-04 11:12pm
The BNF for header <put your favorite header here> allows a parameter to appear more than once. What does this mean?
ABNF is not sufficient to express all the rules about what constitutes a legal or illegal message. Rules about repitition, for example, are difficult to express in ABNF. You must also look at the text that defines a header to obtain a complete picture about proper message syntax and semantics.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-05 11:33pm
Can the request URI include a port number and/or transport parameter?
It can have a port number. But, let me explain when this is needed and when its not.
Lets say I send a request to joe@example.com, and the server for example.com is listening on 5061. The request URI might look like:
INVITE sip:joe@example.com:5061 SIP/2.0
this arrives at example.com. Since the request is for that server, it looks up joe in some database and translates the request URI (for example, to sip:joe@engineering.example.com). It looks up engineering.example.com in DNS, and finds an A record for that machine, forwarding the request to the given IP address. The outgoing request URI looks like:
INVITE sip:joe@engineering.example.com SIP/2.0
Note that in this case, the presence of port 5061 in the request URI sent to example.com didn't make a difference. Thats because the example.com just translated the request URI. Whether it had contained the port number or not would have had no effect on processing.
However, had the request instead been sent to a local outbound proxy instead of example.com, the port number would NEED to be there. Thats because the local outbound proxy won't translate the request URI, it will example it, determine its not for itself, look up the domain in the request URI in DNS, and forward the request there. So, the request URI needs to contain this port so that the local outbound proxy knows to forward it to 5061 as opposed to 5060 at example.com.
So, the rule of thumb is this:
if you send a request to the server listed in the domain of the request URI, URI parameters like port, transport, ttl etc MAY be present but are not needed. If you send a request to a server which is NOT the one identified in the request URI, you MUST include these parameters if they are not the defaults. Always inclduing them, when not default, means you don't need to determine which is the case, and is always the safest bet.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 11:25am
Transport in Via
If a proxy sends a request by UDP (TCP), the spec currently does not disallow placing TCP (UDP) in the transport parameter of the Via field, which it should.
If such a request is received, it should be responded to with a 400 Bad Request. The protocol used for the request should also be used for the response.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 9:03pm
What should I do if my re-INVITE fails?
Here is what you should _not_ do: you should _not_ terminate the call. re-INVITE failure means that the request to change the media was declined and you should keep using the old media codecs you negotiated previously.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 9:02pm
How long can SIP host names be?
DNS (RFC 1035, Section 3.1) limits labels (each component of a host name) to 63 characters. The total length of a domain name (i.e.,label octets and label length octets) is restricted to 255 octets or less. http://www.networksolutions.com/help/long-domains.html, however, claims that host names can be up to 80 characters long.
Note, however, that SIP implementations MUST be prepared to handle host names of any length, subject to any maximum message size restrictions that are part of local policy.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ, mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 9:06pm
Can a User Agent also act as a Registrar?
Being a UA is a logical role, as is a registrar. If an entity accepts REGISTERs and stores location information, its a registrar. So, you can write a piece of code that is both a UA and a registrar if you want. (Jonathan Rosenberg)
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 9:19pm
Can I remove an m= line from SDP in response or re-INVITE?
No. Once an "m=" line made it into SDP of a request or response, it cannot be removed until the call is terminated. The only way to decline a media session is by setting its port number to 0. The only way to offer a new media session is by adding it to the end of the list.
The reason for this is that we need to ensure that it is always possible to match media sessions (i.e., "m=" lines) in requests and responses. Consider an INVITE with the following SDP:
...
c=IN IP4 1.2.3.4
m=audio 54678 RTP/AVP 0 1 3
m=video 7346 RTP/AVP 28 31 (face)
m=video 7880 RTP/AVP 26 28 (presentation)
If the response contained something like
...
c=IN IP4 3.4.5.6
m=audio 6540 RTP/AVP 0 1
m=video 6578 RTP/AVP 28
the caller would not be able to tell which of the two offered video streams was accepted.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 11:16pm
I'm a UAC. I sent an INVITE, and then decide I want to hang up before getting a final response. Do I send BYE or CANCEL?
If the caller wants to hang up a call, but hasn't yet received a final response, it can send a CANCEL or a BYE. Sending a BYE would seem easiest, but there are issues. First off, you won't have gotten a tag yet from the UAS, nor will you have received Record-Route or Contact headers (obtained in the 200 OK response). This means the BYE will be routed "afresh" by proxies. Its possible that routing logic may have changed (perhaps there was some time of day routing or randomized routing), in which case the BYE may reach a different set of participants than reached by the original INVITE. So, if the original INVITE forked, and reached A and B, and the BYE reaches B and C, B will send a 200 OK, and C a 481. The forking proxy forwards the 200 OK upstream, and the caller gets the 200 OK. However, A is still ringing, and might later send a 200 OK. This yield inconsistent call state, which will persist until the UAS times out, as it will never get an ACK.
Sending CANCEL helps solve many of these problems. CANCEL will reach the same set of recipients as the original INVITE, and it doesn't need a REcord-Route or tag in it. The drawback, however, is that the CANCEL and a 200 OK from one of the UAS might pass on the wire. Thus, the UAC may still need to ACK the 200 OK, and then send BYE. The other drawback is that you wouldn't send CANCEL if the call was already established, you'd send BYE. Folks complained they didn't want to have state-dependent mechanisms for hanging up. Given the unlikelihood of the problems with sending BYE, it seems reasonable to allow it.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-07 12:12am
I'm a proxy, and I forked a request, and forwarded multiple 200 OK upstream. Now, I get an ACK. What do I do with it?
Normally, using Route headers which should be present in the ACK. In the bis draft, the final 200 OK response MUST contain a Contact header. This means that either (1) the proxy record-routes, in which case the ACKs will each contain (different) route headers which tell the proxy where to send the request, or (2) the proxy doesn't record-route, in which case it gets sent directly to the UAS, since there was a contact.
That aside, should it arrive anyway, the ACK should be routed just as any other new request. Apply routing logic, which presumably causes it to be forked to both locations. The tags will help identify for which UAS the ACK is meant.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-08 1:10am
If I get a new SDP body in the ACK, and I don't like the media type, how can I indicate its unacceptable to me?
It doesn't work that way. You should not get a "new" SDP in the ACK. SDP goes in ACK only if there was no SDP in INVITE, then SDP was included in the 200 OK. This SDP should represent a subset of the media "offered" in the 200 OK. In other words, a normal SIP transaction has one SDP in the INVITE, and another in 200 OK. Now, we have the same two phase process, but the first SDP is in the 200 OK, and the second in the ACK.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-11 4:16pm
Can a SIP UA register with multiple registrars?
Yes. A SIP UA will register with registrars of any domain where it maintains an identity. For example, a UA belonging to Alice, with identities alice@big-company.com, alice@myportal.com and alice@home-isp.net will register with three different registrars.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2000-Jul-19 11:45am
Is it possible for a UA to make a call to itself, and have the result be two separate calls on the same machine?
If you have a table of transactions by transaction keys (To, From, Call-ID, CSeq), you should be sure to have the direction of the request (sent or received) as part of the key, or use separate transaction tables even for incoming and outgoing requests.
If you have a table of calls by Call-ID only, you will run into problems as you may think this is a re-INVITE for the same call. You really want the incoming and outgoing messages to be associated with totally different calls. It can be distinguished as a separate call if, again, you allow for direction in your lookups. There are many ways to do this; the easiest is to include your local address as part of the call key. For incoming requests, the key is callID + from, for outgoing, callID+ to.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-21 1:29am
Does a UAS use the request-URI or To field to determine if a call is for it?
It uses the request URI. A UAS should be prepared to receive calls with the request URI set to values that it has registered (and placed in the Contact header of REGISTER). It should also be prepared to receive calls with the request URI set to the value it placed in the To field of the REGISTER. Its not likely to see such a request URI, unless its receiving a direct client to client call.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Jul-21 11:58am
How are SIP parsers implemented?
Parsers can be implemented either directly from the ABNF or via parser-generator tools. Some tools that have been used include
- http://www.gnu.org/software/flex/flex.html flex for lexical analysis
- bison (http://www.gnu.org/software/bison/bison.html) or lemon (http://www.hwaci.com/sw/lemon/) for parsing.
A somewhat outdated grammar summary can be found at http://www.cs.columbia.edu/~hgs/sip/SIPgrammar.html
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2000-Jul-30 1:35pm
Is it possible to use Hide with Record-Route?
No, only Via can be hidden. Hiding a Record-Route header in the same manner is impossible because it would need to be decrypted by the upstream proxy for subsequent requests from the callee to the caller; however, the secret key would only be known to the server that encrypted the header.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Aug-24 12:50pm
