How does a proxy handle a method other than the standard INVITE, ACK, BYE, etc.?
See SIP RFC, section 4.2. Proxies always forward requests, regardless of method. A UAS returns 501 (Not Implemented) if it does not support a particular request method.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2000-Sep-13 2:28pm
Why does a proxy server doing TCP need to be stateful?
The situation comes up in a proxy which is TCP on the upstream side and UDP in the downstream side (see diagram below).
TCP UDP
UA1 -------- Proxy --------- UA2
Lets assume that this proxy is stateless, meaning that it holds the TCP connection state but otherwise does not store transaction state. According to the specification, requests are not retransmitted over TCP. So, the UA1 sends its request, say an INVITE, just once over the TCP connection. The proxy receives this, and forwards it to UA2. Its lost. UA1 will not retransmit (since its TCP), and neither will the proxy, since its stateless, thus, the message is lost.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ, mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Oct-27 3:18pm
In computing the Content-Length, does the newline in a body count as one byte or two (CR vs. CR-LF)?
The Content-Length is always the number of BYTES in the body. If the body is text and has newlines, a CR-LF would be counted as two bytes, while just a CR is one byte.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Nov-03 2:59am
Can a proxy fork a non-INVITE request? If yes, what happens if it gets multiple responses?
Yes, a proxy can fork a non-INVITE request. However, it must forward only a single response upstream, 200 or otherwise. Thus, only a single 200 is ever forwarded upstream. This is in contrast to INVITE, where all 200's received are forwarded upstream. Why is that? The reliability mechanism of non-INVITE requests dictates that. Response retransmissions are triggered on request retransmissions. Thus, the client retransmits its request until it gets *a* response. So, upon receiving the first final response, the client would cease retransmitting the request, and then there would be no way to reliably send the other final responses.
As a result of this, forking of non-INVITE requests is only useful when the method has semantics that meet certain criteria. Specifically, (1) the client doesn't care which server gets the request, (2) the client doesn't care which server sent the response, or even if multiple servers sent a response, (3) the service provided by each server is identical. In essence, forking of non-INVITE requests is useful only for an anycast type of service.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Nov-19 5:18pm
Should responses be sent to the host specified in Via? Is From ever used for sending responses?
The rules for forwarding responses are explained in section 6.47.5 of 2543bis.
Note that if you are a UAS, you are the entity responsible for adding "received" parameter to the top Via so you may want to interpret the last two rules in the section as requiring to send the response to the source address of the request.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Dec-07 11:37am
Once a SIP registrar gets a REGISTER request, how does it update the Location Server with the contact information?
This depends on whether the location server is co-located with the SIP registrar or not. If it is, a functional interface (API) suffices to save the location information and any registration payload. If it is not, any protocol or middleware like CORBA, LDAP, RPC, or a database access protocol (e.g., SQL over TCP), can be used. The details are implementation-dependent and outside the scope of the protocol. (Vijay Gurbani)
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2001-Jan-16 7:58pm
Is a SIP URI without a user name valid?
SIP request URIs such as sip:phone123.example.com are valid if the device being addressed does not have a notion of a 'user'. Generally, it would not be sent to a proxy, but a proxy may translate, for example, sip:joe@example.com into the request URI sip:phone123.example.com, if that phone has registered with that Contact address.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2001-Mar-14 4:53pm
Is there a specific order for header fields?
Header fields can appear in any order, except within a header field type (a list of headers separated by a comma or several fields with the same name). For example, Route, Record-Route and Via need to be kept in order. Responses can re-order header fields found in the request.
HTTP/1.1 says:
"The order in which header fields with differing field names are received is not significant."
"The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded."
If a set of fields is authenticated, proxies must not re-order or otherwise modify these field, as this would break the authentication.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2001-Mar-14 5:11pm
When is a CANCEL used?
- A proxy has forked an INVITE request, and it receives a 200 or 600 response on one of the branches, the proxy CANCELs unanswered branches;
- The time described in the Expires header of the request has elapsed;
- No response, including provisional, was ever received from downstream nodes;
- Internal logic determines its time to end the transaction (a CPL or sip-cgi script, for example).
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2001-Mar-21 11:55pm
What do I need to do to use SRV records?
Any bind implementation after 4.9.5 supports SRV records, as does Windows 2000.
_sip._tcp SRV 0 0 5060 sip-server.cs.columbia.edu.
SRV 1 0 5060 backup.ip-provider.net.
_sip._udp SRV 0 0 5060 sip-server.cs.columbia.edu.
SRV 1 0 5060 backup.ip-provider.net.
DNS SRV records are supported by BIND 4.9.6 and newer, generally installed as named. Configuring named for Linux is discussed in a HOWTO at http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html
Currently registered SRV records:
sip.tcp.cs.columbia.edu SRV 0 0 5060 erlang.cs.columbia.edu
sip.udp.sip-happens.com SRV 0 0 5060 sip.sip-happens.com
Use, for example,
host -v -t srv sip.tcp.cs.columbia.edu
host -v -t srv sip.udp.cs.columbia.edu
host -v -t srv _sip._udp.cs.columbia.edu
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2001-Mar-22 12:03am
Why does SIP/SDP allow for multiple codecs to be used for the same media stream?
In the call setup procedures of SIP/SDP, the caller offers their list of codecs for a stream, and the called party responds with those amongst the set which can be supported. The result is that both sides agree on a set of codecs which can be used for that stream. Any of those codecs can be used at any time. The codec used for a packet is indicated in the payload type of the RTP packet.
Why does SIP do that? Why doesn't it restrict it to a single codec, and then do something like an H.323 open logical channel to change codecs mid call?
The answer is twofold. First, it supports application adaptation. Network conditions will vary. To adapt to those conditions, the sender needs the ability to vary the encoding rate and type. It will need to change codecs rapidly. Therefore, SIP allows for multiple codecs to be in use for a single stream.
The second reason is that different codecs might be used depending on the content of the encoded media. For example, rfc2833 defines an encoding of DTMF. It is very useful for the caller to use g.723.1 to send speech, and then, when a number on the dialpad is pressed, to transmit the tone in SIP using rfc2833 instead of g.723.1. This requires the sender to quickly change codecs mid-stream. Similarly, during a silence period, a comfort noise codec might be used instead of the main codec. This too, will require the sender to change codecs on the fly.
There are scenarios where a participant can indeed support multiple codecs, but cannot change them on the fly. Work is underway in the mmusic group in IETF to add some basic capability negotiation to SDP for this purpose.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2001-Apr-27 5:05am
What are spirals? Why does a proxy care?
Sprials are defined in bis-03. They are requests that loop back to the same proxy, but for which the request URI has changed.
Classic example:
joe@example.com calls bob@bigcompany.com. Goes to the bigcompany.com proxy. It proxies it to bob@marketing.bigcompany.com. The marketing.bigcompany.com proxy invokes a CPL. The CPL has bob forwarding all his calls to jane@bigcompany.com. This request is then proxied to the bigcompany.com proxy. Now, this is a "loop", in the sense that the request has hit the same server, but its a valid one. Its valid because the request URI the second time around (sip:jane@bigcompany.com) is not the same as the first time around (sip:bob@bigcompany.com). So, the proxy should accept this and process it. This case is called a "spiral". Its called that since you can think of a proxy network in two dimensions; one dimension is the set of elements, and the other is the r-uri. The request returns to the same point in the first axis, but a different point in the second. Much like a spiral in 3D space, which returns to the same point in the X,Y axis, but a different one in the Z.
Now, how does the proxy know this was a spiral, and not a loop? Using the branch-ID. The branch-ID is supposed to contain a hash of the R-URI. So, when the request arrives again at the proxy, it finds its previous Via entry (because of the host name), and it matches. THen, it computes the hash of the R-URI in the incoming request, and compares it to the hash in the branch ID. If they are not the same, its a spiral. If they're the same, its a loop.
mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2001-Jun-12 1:23pm
What's the difference between loose and strict source routing?
Both loose and strict routing use the Route header.
Strict routing (with more than zero intermediaries) attempts to carry information about the request target and the next hop to be reached in the Request-URI.
Loose routing leaves the request target in the Request-URI and the next hop in the Route header. Loose routing is identified by a ;lr parameter in the Route URI.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2002-Mar-07 6:55pm
Relationship to Other Protocols
Answers commonly asked questions about relationship between SIP and other protocols.
Subcategories:
Answers in this category:
[Add a New Answer in "Relationship to Other Protocols"]
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ, mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ, mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2001-Jul-26 3:26pm
What is the relationship between MGCP and SIP?
The details of combining the two in a system are still being fleshed out. MGCP is a device control protocol, where a slave (gateway (MG)) is controlled by a master (media gateway controller (MGC), call agent). SIP may be used between controllers, in a peer-to-peer relationship. Note that to the SIP side, the MGC looks like a node with a large number of connections, but otherwise the same as a "native" SIP device. Similarly, the MG is completely unaware that the call between MGCs is established via SIP. Only the MGC needs to understand both protocols.
Additional details provided by Tom Taylor:
The basic architecture assumed by the Megaco Working Group postulates two functional entities: a Media Gateway Controller (MGC), which owns the call model and is responsible for call signalling, and a Media Gateway (MG), responsible for manipulating (directing, transforming) media flows under the control of the MG.
MGCP and Megaco/H.GCP are both protocols used between the MGC and MG when they are realized in separate physical elements. MGCP (Media Gateway Control Protocol) was a major source of the ideas in the current Megaco/H.GCP protocol draft, and is being deployed in a number of products being announced over the next few months. It is best suited for IP telephony gateway applications. The Megaco protocol is also called H.GCP because it is being developed cooperatively between the Megaco WG and ITU-T Study Group 16.
H.323 is a complete system specification, including call signalling protocols which would run between an MGC and another MGC or other H.323 entities (Gatekeepers, endpoints). SIP can also be used as a call signalling protocol, and can therefore be viewed as a competitor to H.323. Both protocols are capable of supporting multipoint multimedia conferences. H.323 was first standardized in 1996 and has been improved since then; current standardization is focusing on networking aspects such as translations data exchange and interworking with legacy telephony signalling. SIP just reached Proposed Standard status, but has attracted wide interest which may speed its maturing stages. The Megaco/H.GCP protocol will complement both protocols by also providing support for multipoint, multimedia calls at the media level.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 11:10pm
What is SIP+ and how does it relate to SIP
SIP+ was a proposal by Level3 on how to extend SIP to interconnect two MGCs. This functionality is now being provided by various orthogonal SIP extensions, including the carriage of multipart MIME types, the INFO method and others. These are being documented in a BCP draft. The name SIP+ is obsolete and should not be used to avoid confusion.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-04 10:51pm
How does SIP compare to H.323?
See SIP vs. H.323 comparison at http://www.cs.columbia.edu/~hgs/sip/h323-comparison.html.
The brief answer: The main advantage of SIP is its full integration with other Internet protocols and functions, such as email, web and instant messaging. For example, it is very easy to "forward" calls to web pages or email; web pages can be included in responses to call attempts. SIP is also codec-neutral and has been used to set up anything from audio and video to Doom distributed games and screen sharing. There a number of open-standard programming interfaces, SIP servlets, sip-cgi and CPL, that are particularly suited to SIP-based devices. These programming interfaces make creating SIP-based services very similar to writing web scripts or web pages.
It also supports a number of services, such as ACD and follow-me, that are much harder to implement in H.323.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ, mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2000-Dec-15 10:28pm
Can H.323 and SIP be used together?
Yes. SIP can locate the called party and determine its capabilities, including H.323. H.323 is then used to connect the two parties.
Unfortunately, there is currently no standard on translating between the two. Conversion is made more difficult by the multiple versions of H.323 (v1, v2, v3). However, there is at least one product (Lucent PacketStar IP) that allows SIP and H.323 terminals to call each other.
There is an ongoing effort within SIP Working Group to define SIP-H.323 interoperation standard. Some details on the effort are available at http://www.softarmor.com/sipwg/teams/sip-h323/index.html. The group has produced an internet dratf that can be found at http://www.cs.columbia.edu/~hgs/sip/drafts/draft-singh-sip-h323-00.txt.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-04 11:00pm
How do I interconnect Q.931 (ISDN signaling) and SIP?
A gateway that initiates an ISDN call based on a SIP call or vice versa is reasonably straightforward, as sketched here:
Some additional information and links to related Internet Drafts can be found at http://www.softarmor.com/sipwg/teams/sipt/index.html.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-04 11:09pm
How do I interconnect ISUP (SS7 signaling) and SIP?
SIP can be used either between SS7 nodes or to trigger a phone call in an SS7 network. While all the details have not been worked out, the basic call flow is similar to the ISDN case:
Some additional information and links to related Internet Drafts can be found at http://www.softarmor.com/sipwg/teams/sipt/index.html.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-04 11:08pm
Where do I find description of SDP?
SDP (Session Description Protocol) specification can be found in RFC2327. SIP uses SDP to describe media capabilities of call participants and to negotiate the common media set media for a call. Appendix B of RFC2543 describes the usage of SDP in SIP messages.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 10:45pm
Can SIP be used for Internet telephony gateways (ITGs)?
Yes, in two ways. First, it can indicate to the Internet-based caller that the callee is reachable via an ITG, via the Contact header. Secondly, two ITGs connecting parties on the PSTN can signal new calls to each other, with the destination phone number contained in the request URL.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-04 11:16pm
What is sip-cgi and how does it relate to CPL?
Both are viewed as different approaches for creating VoIP services. Both are written offline, and both are executed when messages arrive in order to execute features.
CPL is an XML-based language, while sip-cgi is a mechanism for invoking scripts or programs written in any language. sip-cgi is very similar to web cgi scripts.
In its current version, CPL is only invoked when INVITE requests and responses arrive, while sip-cgi can intercept any request.
sip-cgi is designed to be used by SIP, while CPL can probably be used by a number of signaling protocols such as Q.931 or H.323.
CPL and sip-cgi differ in their applicability. CPL is designed for end user service creation. It is intentionally limited in capabilities and is not a general purpose programming language. Its execution on a server is generally very fast. CGI is more powerful - you can do nearly anything. It is programming language independent. It incurs a process-spawning overhead, so its less efficient than CPL. (CPL is usually executed in the same process as the server). As a service provider, I would not want to execute CGI scripts sent to me by end users. However, I would prefer to use CGI to develop my own services.
Note that CGI may be used as the execution environment for a CPL script. (Jonathan Rosenberg)
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-04 11:18pm
