RFC 3665: (SIP) Basic Call Flow Examples
The assignment is to select a RFC from sipping-charter. In this course I am, for the first time, introduced to SIP. I wanted to learn the call flow using the protocol and simple and generic examples were what I was looking for. RFC 3665 serves to that end. I especially liked what it states at the very beginning, “It is the hope of the authors that this document will be useful for SIP implementers, designers, and protocol researchers alike and will help further the goal of a standard implementation of RFC 3261”.
As with other RFCs, it starts by pointing out the key words. I wanted to know the difference of ‘May’ and ‘Optional’. As suggested, I looked into RFC 2119 [2] that states, “Truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation, which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)”
It uses a nonce based (challenge and response) authentication, more specifically, HTTP Digest Access Authentication using TLS transport. The first message is nothing but to ask the server to get a nonce (number used once) and following this, server sends the authenticate message (a challenge awaiting a valid response) with standard realm, qop, nonce and opaque stuffs. Now Bob will resend the same thing but with an additional encrypted response code (standard MD5 hash with his credentials). Server checks the credential and sends OK or Unauthorized. This is similar for HTTP 1.0 authentication process [3].
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 401 Unauthorized F2 |
|<------------------------------|
| REGISTER F3 |
|------------------------------>|
| 200 OK F4 |
|<------------------------------|
| |
Note: Each 401 Unauthorized message comes with a new nonce.
Later to update the contact list Bob can use the same server nonce to make response code in his new request but he will also add his own nonce (cnonce) this time.
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 200 OK F2 |
|<------------------------------|
| |
To know the current contact list the response message will not include any contact header.
This is what the RFC has to say about it, “The request has an expiration period of 0 and applies to all existing contact locations.” Seeing it the server clears user’s contact list.
There are different scenarios that the RFC shows but generally these are the things that happen, “The successful calls show the initial signaling, the exchange of media information in the form of SDP payloads, the establishment of the media session, then finally the termination of the call” [1].
Alice (calling party) calls Bob (called party) with a call id (this is actually the session id). Each message has TO header as Bob’s address and FROM header as Alice’s address. Alice starts by sending INVITE message. Bob’s phone starts ringing and sends RINGING. Bob picks up and says OK. Alice ACK the fact. At this point media stream is setup between Bob and Alice. At the end Bob says BYE and Alice acknowledges by sending OK.
Alice Bob
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |
| BYE F5 |
|<-----------------------|
| 200 OK F6 |
|----------------------->|
| |
The proxies are there to relay messages that Alice sends to Bob or that Bob responses to Alice. But in first part, Alice goes through the authorization phase with the Proxy 1.
Alice adds Proxy 1 in its Route header. Both the proxies add Record-Route header in the message so that they are available in all the following message exchanges. Here is what they add in Route and Record-Route headers.
Alice:
Route: <sip:ss1.atlanta.example.com;lr>
Proxy 1:
Record-Route: <sip:ss1.atlanta.example.com;lr>
Proxy 2:
Record-Route: <sip: ss2.biloxi.example.com;lr>, <sip:ss1.atlanta.example.com;lr>
(This process of relay by Proxies is like what we see in a relay attack where they act as rouge verifier and prover.)
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| 407 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | | |
|--------------->| INVITE F5 | |
| 100 F6 |--------------->| INVITE F7 |
|<---------------| 100 F8 |--------------->|
| |<---------------| |
| | | 180 F9 |
| | 180 F10 |<---------------|
| 180 F11 |<---------------| |
|<---------------| | 200 F12 |
| | 200 F13 |<---------------|
| 200 F14 |<---------------| |
|<---------------| | |
| ACK F15 | | |
|--------------->| ACK F16 | |
| |--------------->| ACK F17 |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F18 |
| | BYE F19 |<---------------|
| BYE F20 |<---------------| |
|<---------------| | |
| 200 F21 | | |
|--------------->| 200 F22 | |
| |--------------->| 200 F23 |
| | |--------------->|
| | | |
There are also occasions when Alice will have to be authenticated by both the proxies. Another scenario depicts where Alice has a primary and a secondary proxy server configuration. If one of them fails and Alice has tried to use that line many times, Alice will give up and use secondary proxy to connect to Bob. The RFC also shows the use of Application Layer Gateway(ALG).
References
[1] http://rfc.net/rfc3665.html.
[2] http://rfc.net/rfc2119.html.
[3] HTTP Authentication: Basic and Digest Access Authentication: RFC 2617, http://tools.ietf.org/html/rfc2617 .