And then we finally get to NGN signaling protocols: SIP and SDP. The picture below was extracted from RFC 3261 and gives a fairly good example of a SIP dialog between two users, Alice and Bob.
The entities involved in the call setup are called User Agents (UA). UAs which request services are called User Agent Clients (UAC), and those which fulfill requests are called User Agent Servers (UAS). Although the basic operating mode is end-to-end, the model supports the use of intermediate proxy servers, which work as back-to-back User Agents (B2BUA) relaying requests from one user to the other. In the picture Alice’s softphone and Bob’s SIP phone are the end-to-end user agents, while there’s two proxy servers: atlanta.com and biloxi.com. Linking this with what we already know about IMS, we can identify the P-CSCF as a SIP proxy server, while the communicating UEs are the end-to-end UAs.
Quoting RFC 3261:
“SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a ‘caller ID’ service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services.”
SIP primitives are:
- REGISTER: indicate an UA current IP address and the Uniform Resource Identifiers (URI) for which it would like to receive calls;
- INVITE: used to establish a media session between UAs;
- ACK: confirms message exchanges with reliable responses (see below);
- PRACK (Provisional ACK): confirms message exchanges with provisional responses (see below). This was added by RFC 3262;
- OPTIONS: requests information about the capabilities of a SIP proxy server or UA, without setting up a call;
- CANCEL: terminates a pending request;
- BYE: terminates a session between two UAs.
Typically a SIP message have to have a response. Like HTTP, SIP responses are identified with three-digit numbers. The leftmost digit says to which category the response belongs:
- Provisional (1xx): request received and being processed;
- Success (2xx): request was successfully received, understood, and accepted;
- Redirection (3xx): further action needs to be taken by sender to complete the request;
- Client Error (4xx): request contains bad syntax or cannot be fulfilled at the server/UA of destiny;
- Server Error (5xx): The server/UA of destiny failed to fulfill an apparently valid request;
- Global Failure (6xx): The request cannot be fulfilled at any server/UA.
Session Description Protocol (SDP) is described at RFC 4566 (warning: IETF mmusic working group is preparing an Internet Draft which eventually will supersede RFC 4566).
Matter of fact, it should be called Session Description Format, since it’s not a protocol as we use to know. SDP data can be carried over a number of protocols, and SIP is one of them (although RFC 3261 says that all SIP UAs and proxy server must support SDP for session parameter characterization).
Quoting RFC 4566:
An SDP session description consists of a number of lines of text of the form:
=
where MUST be exactly one case-significant character and is structured text whose format depends on . In general, is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace MUST NOT be used on either side of the ‘=’ sign.
An SDP session description consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a “v=” line and continues to the first media-level section. Each media-level section starts with an “m=” line and continues to the next media-level section or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. Some lines in each description are REQUIRED and some are OPTIONAL, but all MUST appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). OPTIONAL items are marked with a “*”.
Here’s an example of an actual SDP session description:
Very well. I think that’s enough to you understand how NGN signaling works. Now it’s time to get one step down on the TCP/IP protocol stack, so on our next article we’ll be starting to talk about transport protocols, and will understand how the socket API is used to create separate sessions over the transport protocols service
Au revoir, mes amis .