2000-Jul-03 7:55pm
How does SIP support multipoint conferences?
SIP has four ways to do multiparty conferencing:
1. Dialup conference bridge: call the bridge just like you call a person. Conference is identified by request URI. Works with rfc2543 - no extensions needed.
2. Distributed multiparty conferencing - no server. Fully distributed. This is what is described in the now-expired draft , and is work in progress (see http://www.softarmor.com/sipwg/teams/callcontrol/index.html for some recent drafts).
3. Multicast conferences - you can run your conference on multicast. Simply INVITE the person to join the multicast session. Works with baseline SIP. In fact, this was the initial purpose of SIP. In this case, there is not a full mesh of SIP signaling.
4. 3-way with local MC/MP function: A and B are talking. A wishes to add C to the call. A can simply call C, but also act as a mixer, so that the media it sends to B contains the A+C media, and the media to C is the A+B media. RTCP CSRC indicate who is in the conference. This also works with baseline SIP. It imposes additional burden on the UA, but otherwise provides this standard feature in a simple way.
There is no preferred way. It depends on the particular application. (Jonathan Rosenberg)
2000-Jul-06 9:16pm mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 9:16pm
How does SIP support text chat and instant messaging?
Text chat can be supported as part of SIP sessions using the RTP text conversation payload format (RFC 2793). Typically, text is sent one character at a time, although almost any number of characters can be packed into a single RTP packet.
Instant messaging (IM) differs from text chat in that:
- messages are sent as a whole and can be in any format, such as HTML;
- messages are independent of a session setup;
- store-and-forward or translation to email are feasible;
SIP can support IM through the use of the proposed MESSAGE method.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2000-Aug-21 11:18am
Does SIP support video or multimedia conferences?
SIP was designed to support multimedia conferences, including video conferences, from the very beginning. It can use any media type, including one or more audio, video, shared application or text chat streams. For multiple participants, SIP can be used for
- dial-in-style conferences with a central "bridge" (MCU) or multicast
- dial-out conferences with a central bridge or multicast
- multicast conferences
- full or partial mesh conferences, where end systems replicate media streams.
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2000-Aug-22 12:13pm
When do I use a proxy server vs. a redirect server?
I believe the difference is fundmentally one of control.
You use a proxy when you want to control processing of the call from the point you receive it, and forward. A proxy can see the provisional and final responses to the request. It can record route so that it sees whats going on during the call. A redirect server, however, hands off control to the device that sent it the INVITE. It will never see the final response to the request, and not be contacted again for the remainder of the call. Its a one-shot deal.
As such, redirect servers are really good for high volume, lookup style transactions. They can almost be considered a form of database query, albeit a SIP specific one. Proxies are generally needed for services and more complex routing problems.
2000-Nov-14 10:50am mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ
2000-Nov-14 10:50am
How do gateways register with a registrar?
In H.323, the entity can register to Gatekeeper as Terminal type or as Gateway type with a prefix. In SIP, the working group decided that registering PSTN prefixes is not the right approach, as it is insufficiently flexible and does not fit into the precise-match registration lookup mechanism. Rather, proxies make routing decisions based on local policy mechanisms, e.g., static tables, TRIP routing information, or SLP (with gateway registration template).
mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2002-Jul-24 11:05am
SIP Protocol Operation
Contains FAQ and clarifications on protocol operation.
Subcategories:
Answers in this category:
[Add a New Answer in "SIP Protocol Operation"]
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ, mailto:jdrosen@dynamicsoft.com?subject=SIP FAQ, mailto:hgs@cs.columbia.edu?subject=SIP FAQ
2002-Mar-07 6:53pm
What does the [H14.17] in RFC 2543 stand for?
This is explained in Section 3 of RFC 2543. It refers to the section number in the HTTP/1.1 specification.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 8:06pm
Do callers need to know the location of the Location Server?
The caller doesn't interact with the location server directly. A redirect or proxy server asks the location server (which may be co-resident with the SIP server or not) for "advice". The location server is just a logical abstraction to indicate where the SIP server gets its information from. The protocol between SIP server and location server is beyond the scope of SIP. Examples of location servers include
finger;
LDAP/X.500;
whois, whois++;
ph and other local directories;
shared file systems with registration on login;
local SQL databases reached through TCP.
Also, callers don't register with the location server.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 8:11pm
What is the difference between a call leg and a call id?
A call leg refers to the one-to-one signaling relationship between two user agents (UAs). The Call-ID is an identifier, carried in the SIP messages, that refers to the call. A call is a collection of call legs. A UAC starts by sending an INVITE; because of forking, it may receive multiple 200 OKs from different UAs. Each corresponds to a different call leg within the same call. Call is thus a grouping of call legs. In the call control spec, additional call legs are created through special mechanisms.
Call legs refer to end-to-end connections between user agents, rather than any relationship with proxies. Within a call leg, there are numerous transactions in both directions.
The request URI is not used in call leg identification.
The To and From field relate to local and remote in the following way. When Alice sends a request on a call leg to Bob, the From field contains the local address (Alice), and the To field the remote address (Bob). When a request is received by Bob, the To field is matched to Bob's local address, and the From field to the remote address (Alice).
The CSeq spaces in the two directions of a call leg are independent. Within a single direction, the sequence number is incremented for each transaction.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 8:19pm
What is the difference between tag and branch-id?
Branch IDs allow proxies to match responses to forked requests. Without them, a proxy wouldn't be able to tell which branch a response corresponds to. Tags, in To headers, are of no help here since they are not known until responses arrive. Tags are used by the UAC to distinguish multiple final responses from different UASs.
A UAS has no reliable way of determining if the request has been forked or not. Thus, to be safe it needs to add a tag. Proxies only insert tags into the final responses they generate themselves; they never insert tags into requests or responses they forward.
Since a request can be forked several times on its way to UAS, a single "tag" (or whatever you like to call it) added to the request by one of the proxies is not sufficient for the next forking proxy along the chain to match responses on its own branches; every proxy that forked the request would need to add its own unique IDs to the branches it created. This is precisely what's being achieved by the branch parameter in the Via header.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 8:23pm
How can one recognize a retransmitted, duplicate or looped request?
header retransmitted duplicate matching response
From same same same
To same same same, but tag may have been added
Call-ID same same same
request URI same same n/a
CSeq same same same
Via - - must be local host; check for branch parameter to identify which branch
Looped request are recognized by one of the following:
The server finds itself in the request's Via list, including any branch parameter. (The server should compute the branch parameter so that it depends on the request URI.) Take a look at sections 6.47.5 and 12.13.1 of RFC2543bis for details on computing and matching branch parameter for loop detection.
The Via header added by the server prior to proxying the request is the same as one of the Via's in the Via list.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 8:57pm
What is the relationship between the From, Contact, Via and Record-Route/Route headers?
All these headers determine how requests and responses are routed in a network of SIP proxy servers. Roughly, the distinction is:
- From:
Used for subsequent requests from the callee to the caller if there is no Contact or Record-Route header. E.g., if Alice makes a call with From: Alice sip:alice@example.org
to Bob, an INVITE request from Bob to Alice would use sip:alice@example.org
as the To header and Request-URI.
- Contact:
Determines the destination placed in the Request-URI for subsequent requests and can be used to bypass proxies _not_ enumerated in a Record-Route header. Also used in responses by redirect servers and in REGISTER requests and responses.
- Record-Route/Route:
The Record-Route header is inserted into requests by proxies that want to be in the path of subsequent requests for the same call-id. It is then used by the user agent to route subsequent requests. The mechanism is similar to a source-route, as the Record-Route information is copied into a set of Route headers. The Request-URI is set to the first Route header.
- Via:
Via headers are inserted by servers into requests to detect loops and to allow responses to find their way back to the client. They have no influence on the routing of future requests (or responses).
Generally, in short, requests should be sent to Route if present, Contact if there is no Route, From if there is no Contact.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-06 1:03am
How are URLs compared?
Two SIP URLs are compared for equality according to the following rules:
- the display name is ignored;
- tags must match;
- user, password, host, port and parameters of the URI must match. If a component is omitted, it matches based on its default value.
- string comparisons are case-sensitive except for the domain part;
- Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396) are equivalent to their ""%" HEX HEX" encoding.
- An IP address that is the result of a DNS lookup on a hostname does not match that hostname.
This is TBD.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:11pm
What's the difference between the request URIs tel:+12125551212 and sip:12125551212@gw.com?
Non-SIP URLs, such as tel:+12125551212 for a telephone number, may be used as request URIs in SIP INVITE requests. This only makes sense if all outbound calls are handled by a proxy server. In the case of a tel: URL, the proxy server would then translate the request URL to a SIP URL of a gateway server, if it is not handling the gateway duty itself. The proxy server might use the Telephony Routing over IP protocol (TRIP) to find the appropriate next-hop SIP server. The To header may always be a tel: URL even if the Request-URI is a SIP URL, although that breaks with the common practice that Request-URI and To start out the same.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:14pm
Do I always need a proxy or redirect server?
No, two SIP user agents can contact each other directly.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:14pm
How does a caller find its local registrar?
The local registrar is either manually configured or, more likely, the SIP client issues a multicast registration request to the sip.mcast.net standard multicast address, which all registrars listen to.
Another possibility is to use SLP through an extensions defined in http://www.cs.columbia.edu/~hgs/sip/drafts/draft-kempf-sip-findsrv-00.txt.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:34pm
How do I ensure registrar reliability?
There are several techniques that can be used to minimize the impact of registrar/proxy server failures for a server in a local area network:
- Run several servers that all respond to the same multicast registration address ("warm standby"). As long as multicast requests are mostly reliable, this ensures a consistent registration picture.
- If a registration server is rebooted and does not have complete knowledge of the local UA population, it could multicast any incoming INVITE requests.
- Use some of the available hardware redundancy solutions.
For servers separated from their client by a wide-area network, use of multicast is not appropriate, so that these servers have to rely on traditional backup techniques to achieve reliability. For example, the designated registrar could multicast registration updates within its local network to keep standby servers synchronized.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:19pm
Are ACK requests retransmitted?
No. An ACK is sent when a response retransmission is received. Reliability is achieved because the response is retransmitted until an ACK arrives, and the ACK is retransmitted on response retransmissions. ACK is only used for INVITE.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:20pm
How are BYE requests routed?
Since a Contact header MUST be present in INVITE and 200, the BYE will go directly to the user agent if there is no Record-Route header. If there is a Record-Route, it will traverse the list of proxies indicated there.
If the caller decides to send a BYE before receiving a 200 from the callee, the BYE is be handled by the proxies just as the corresponding INVITE was handled, i.e., it may be forked.
2000-Jul-03 9:21pm mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:21pm
Can I CANCEL requests other than the first INVITE?
Yes, any request can be cancelled before it has been executed by the UAS. However, it is likely that this will only make sense in practice for the initial INVITE and subsequent re-INVITEs. In the latter case, the call remains, just any changes requests are cancelled.
mailto:islepchin@dynamicsoft.com?subject=SIP FAQ
2000-Jul-03 9:22pm
