VoIP in-depth: An Introduction to the SIP protocol, Part 1-2

Document directory

• Registering multiple user devices
• The via header, forking, loop prevention
• An example using proxies

User location

Let's step out of the SIP layers and see what we have so far: using the layers, we can now create and receive sip transactions.

One basic requirement in SIP is for phone devices to be able to register their location with a registrar. using this registration information, we can send a request to a server and this request wocould reach the intended recipient. let's go back to the previous example:

REGISTER sip:arstechnica.com SIP/2.0
Via: SIP/2.0/UDP home.mynetwork.org;branch=z9hG4bKmq0Tgb
To: sip:me@arstechnica.com
From: sip:me@arstechnica.com;tag=m25caI4
Call-ID: n35nzlsdjfb3@home.mynetwork.org
CSeq: 153 REGISTER
Contact: sip:me@home.mynetwork.org
Max-Forwards: 70


We already covered the first two lines, so let's now look at the rest.

• TheContactHeader tells the Registrar the actual address of the device; times you'll see an IP rather than a domain name in this field.
• TheToHeader tells the Registrar the address of record (usually referred as the AOR). AOR is the public sip address, the same as my email address.
• TheFromHeader usually has the same value asTo. (IT wocould be different in case someone is registering on behalf of someone else, but this case is rare .)
• Call-IDIs an identifier that groups together a series of messages. Two different registrations shold have differentCall-IDValues, but re-registrations shoshould have the sameCall-IDValues. to differentiate the re-registrations, the client wocould increment the CSeq value.
• We'll leaveMax-forwardsExplanation for the last section.

The client may also add an expiration value to the registration, either by adding a newExpiresHeader or by addingExpiresParameter to the contact header. this is a recommended value to the server, because the server is the party that chooses the expiration time and sends it in the successful response. the expiration time may not be higher than the client-requested value, and if the value is below the minimum acceptable value then the Registrar shold reject the request.

Registering multiple user devices

A user is not bound to register with only one device, since it's possible that the user owns several sip-capable devices and wants to be able to use the same sip address simultaneously. A simple example involves two phones, one a desk phone and the other a cell phone. when someone CILS the public sip address, both phones wocould ring. to accomplish this, both devices register with the same AOR but different contact values. the Registrar grouping ing these registrations maintains both associations. requests arriving to the user AOR wocould fork to both devices. in some cases, it may make sense that both devices wocould create a session, but most of the time, this wocould be a call and thus the first device that answers wocould establish the call. anyone who has a cell phone and a car phone with the same phone number is quite familiar with this scenario.

The fact that sip lets several devices register originally worked out well, but then more complex scenarios started to come up. suppose a user with two devices is in a conversation, and the person on the other end transfers the call to a third party. in sip, it wocould mean the third party wocould send a request to the first user, but if it were to use the AOR, the request wocould fork to both devices. a device that is not active in the call wocould not be able to transfer a non-existent call. in this case, you might suggest using the device IP value, but several times, this will be a non-routable IP address, and the only way to reach it is via a server that has access to this private network.

For such scenarios, an extension called gruu (globally routable User Agent URI) was introduced, defined in RFC 5627. when a user registers with a device that supports this extension, a header parameter named "+ sip. instance "with a unique identifier is added to the contact header. the Registrar creates two gruus for that instance: A Public gruu with the identifiable AOR, and a temporary gruu to be used in case the user wants to make an anonymous call. both these gruus are SIP addresses with a "GR" parameter. now when there's a call with one of the devices, the contact address wowould have the gruu sip address. A transfer request wocould use this value, and because the server has a mapping between this gruu and the actual device instance, the request reaches a single device participant ipating in the call rather than the other devices.

Locating servers

A sip client that wishes to register to sip: arstechnica.com needs to resolve this address. SIP uses DNS to do that, but simply resolving the address to an IP is not enough. therefore, SIP uses DNS to discover everything it needs to send the request. all the procedures I describe in this section are detailed in RFC 3263.

First, the client needs to discover the preferred transport type. for example, a client that supports UDP, TCP and sctp performs a naptr query (defined in RFC 3403) for arstechnica.com. A response for such query may be:

   ;          order pref flags service      regexp  replacement      IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.arstechnica.com.      IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.arstechnica.com.      IN NAPTR 80   50  "s"  "SIP+D2S"      ""  _sip._sctp.arstechnica.com.      IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.arstechnica.com.

That means the server supports TLS, TCP, sctp and UDP in this order.ServiceValue determines the transport type. A client that does not support TLS will choose the second option, "sip + d2t" which means "sip over TCP. "To use TCP, the client now needs to resolve _ sip. _ tcp.arstechnica.com.

We have the transport type, but now the port is unknown. it is true that the default port is 5060, but this port will only be used if we cannot resolve a different port. to resolve the port, the client performs an SRV query (this type is defined in RFC 2782) for _ sip. _ tcp.arstechnica.com. A possible response to this query may be:

   ;;          Priority Weight Port   Target       IN SRV  0        1      5060   server1.arstechnica.com       IN SRV  0        2      5070   server2.arstechnica.com

Now it's finally time to resolve the IP address. the client tries to send the request to server1.arstechnica.com, port 5060 via TCP. to find the correct IP address, the client performs an query on IPv4 or AAAA query on IPv6. if the transaction times out, then the client shocould not stop at this point. it shoshould try to send a new request to server2.arstechnica.com, port 5070 and transport TCP. if this also fails, then the client stops because it's the last SRV record. so, SRV records are not just for resolving the port, but are also useful for server redundancy and load balancing.

Naturally, this elaborate process of doing different DNS queries takes time, and will significantly increase latency if you want to send messages to SIP messages. hence, the assumption is that the client caches these DNS results. this is a reasonable assumption, since HTTP clients also cache DNS to improve performance. there are other possibilities for overriding these queries. the first is to use a numeric IP address, but this is not recommended for obvious reasons. the other option is to specify the values in the sip uri itself. one can specify its address as: SIP: arstechnica.com: 5060; Transport = TCP. this is also not recommended, since changing the values requires changing the URI. furthermore, the server redundancy supported by the SRV records wocould not be available.

Proxies

Now let's look at sip proxies to see how the different pieces fall together. you rarely send signaling messages directly between phone devices. usually, there's at least one, if not several, proxies along the signaling path, and these proxies are designed to be aware of transactions, not CILS. (such a design is more scalable .)

Proxies act as both UAC and UAS. an incoming request goes to the proxy UAS side, and the proxy then creates a new transaction as a UAC. responses reach the UAC, and the proxy generates responses as a UAS. therefore, for an incoming transaction and a corresponding outgoing transaction, the transaction layer maintains two state-machines, and it's the proxy's job to manage the interaction of these two transactions.

Some proxies work in conjunction with a registrar and have access to a shared database. it's such a proxy's job to retrieve a user's public AOR and to resolve its registered contact address. other proxies simply route the messages. I shoshould note at this point that this section focuses on stateful proxies. the standard also defines stateless proxies, so some of the text here wocould not apply to those server types.

The via header, forking, loop prevention

When we went through the transport layer, I added a vague description of the top via header. Now it's time to address this header in more detail.

A sip message may contain in more than a single via header. when a proxy constructs a request for a new transaction, it takes the existing message and adds an additional via header abve the existing, topmost via header. this via header has a new "branch" parameter value, thus signifying that this is a new transaction and that its address is the proxy's UAC-Side address. the UAS processing ing this request wocould send the response based on the top via header, thereby ensuring that the response goes back to the proxy. if the proxy sends back the response, it sends it without its own via header, because the original transaction is a different one and has a different top via header with a different "branch" value. proxies use a similar mechanic with route and record-route headers, but this subject is covered in the next part of the article.

 

 

I mentioned previusly that a single user can register with multiple devices. in order to send a request to multiple targets, the proxy forks a request. an incoming request may result in several outgoing requests to different targets, each containing a different branch value. proxies will not forward every failed final response to the UAC because the first final response wocould cause the UAC to close the transaction. therefore, the proxy collects the error responses, and if all the outgoing transactions fail, it chooses the most appropriate failed response. A successful response is sent back to the UAC immediately. this is why we saw that an ACK request is part of the transaction for a failed response. for invite transactions, the proxy sends out an ACK for failed responses and does not wait until the other responses arrive. on the other hand, the proxy cannot ack a successful 2XX response to invite since this means a new call was created, but the caller is not aware of this yet.

To prevent loops, proxies useMax-forwardsHeader. this is the last of the mandatory headers that I skipped in earlier sections. the initial request is sent out with a value, most commonly 70, and every proxy that forwards this request deducts 1 from the value in the request that it sends out. if the value ofMax-forwardsReaches 0 before it reaches the final destination, the UAS sends back a 483 (too handle hops) response. it shoshould be noted that a possible amplification vulnerability was later discovered for forking proxies. this was addressed by RFC 5393, which changed some loop detection mechanisms and introduced a new header calledMax-breadthThat means CES the number of possible forks a message goes through.

Finally, proxies send out a 100 (trying) provisional response when they receive a request whose response takes more than 200 ms. this prevents the UAC from retransmitting the request, and it also prevents a time-out event. 100 is a response that is generated by the proxy. if we have more than one proxy, the proxy that exceeds es the 100 message will not forward it. this is because it shoshould have sent its own 100 message prior to keep ing it.

An example using proxies

Let's look at an example to wrap up this discussion (non-essential details elided, including the SIP version in the first line of the request and some headers that will be discussed when we cover CILS ):

This message is sent from ARS technica's network and reaches the arstechnica.com sip proxy. the proxy sends out the message to the voxisoft.com sip proxy and returns a 100 response. voxisoft's proxy has two registrations and forks the request to two devices (while also sending out a 100 response ). notice that all new requests have a new via header with a new branch parameter. also, note that the second message is using TCP as a transport. this is a valid scenario, as we previusly discussed, since both transactions have different state machine and one of them may discover a different transport when Ming a naptr query.

At this point, one device might answer with, for example, 486 (busy), but the proxy does not forward it because it has another forked message pending; so it just sends an ACK. the ack has the same branch value since it's the same transaction. ack is sent only for the invite case; if this were a different method then ack wouldn't be used. the second device sends a 200 OK and this message is sent all the way back to the initiating client. the following validation shows this process in action:

Finally, the client on the left side sends out an ACK for the 200 OK. this Ack is a new transaction and therefore has a new branch value. the proxies forward the request to the destination, again adding a via header for each hop. this time ack does not fork; we will see this mechanic in the next article.

Summary

In this article, we 've covered the foundation layers of SIP, including its message structure, transport layer and Transaction layer. we 've also covered the way sip registrars and proxies work based on these layers. the discussion so far shoshould give you a good foundation for understanding this protocol. in the next part of this series of articles, we'll complete this discussion by going through the definitions of SIP calland additional services.