Figure 2.14 SIP Redirection
{ 2.2.2.3 SIP messages
Communication using SIP (often called signalling) is comprised of a series of messages. Messages can be transported independently by the network. Usually they are each transported in a separate UDP datagram. Each message consists of a ‘first line’, a message header and a message body.The first line identifies type of the message.There are two types of messages: requests and responses.
Requests are usually used to initiate some action or inform the recipient of the request of something. Replies are used to confirm that a request was received and processed and contain the status of the processing.
A typical SIP request looks like this:
INVITE sip:7170@iptel.org SIP/2.0
Via: SIP/2.0/UDP 195.37.77.100:5040;rport
Max-Forwards: 10
From: “jiri” <sip:jiri@iptel.org>;tag=76ff7a07-c091-4192-84a0-d56e91fe104f
To: <sip:jiri@bat.iptel.org>
Call-ID: d10815e0-bf17-4afa-8412-d9130a793d96@213.20.128.35
CSeq: 2 INVITE
Contact: <sip:213.20.128.35:9315>
User-Agent: Windows RTC/1.0
Proxy-Authorisation: Digest username="jiri", realm="iptel.org", algorithm="MD5", uri="sip:jiri@bat.iptel.org", nonce="3cef753900000001771328f5ae1b8b7f0d742da1feb5753c", response="53fe98db10e1074
b03b3e06438bda70f"
Content-Type: application/sdp
Content-Length: 451
v=0
o=jku2 0 0 IN IP4 213.20.128.35
s=session
P.36
[IP Telephony Cookbook] / Technological Background
c=IN IP4 213.20.128.35
b=CT:1000
t=0 0
m=audio 54742 RTP/AVP 97 111 112 6 0 8 4 5 3 101
a=rtpmap:97 red/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:6 DVI4/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap: 3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
The first line tells us that this is an INVITE message which is used to establish a session.The URI on the first line, sip:7170@iptel.org is called Request URI and contains the URI of the next hop of the message. In this case, it will be host iptel.org.
A SIP request can contain one or more Via header fields which are used to record path of the request.They are later used to route SIP responses exactly the same way.The INVITE message contains just one Via header field which was created by the user agent that sent the request. From the Via field we can tell that the user agent is running on host 195.37.77.100 and port 5060.
The From and To header fields identify initiator (calling party) and recipient (called party) of the invitation (just like in SMTP where they identify sender and recipient of a message).
The From header field contains a tag parameter which serves as a dialogue identifier and will be described in Section 2.2.2.5.
The Call-ID header field is a dialogue identifier and its purpose is to identify messages belonging to the same call. Such messages have the same Call-ID identifier. CSeq is used to maintain order of requests. Because requests can be sent over an unreliable transport that can re-order messages, sequence numbers must be present in the messages so that recipient can identify re-transmissions and out-of-order requests.
The Contact header field contains the IP address and port on which the sender is awaiting further requests sent by called party. Other header fields are not important and will be not described here.
The Message header is delimited from message body by an empty line.The Message body of the INVITE request contains a description of the media type accepted by the sender and encoded in SDP.
2.2.2.3.1. SIP requests
An INVITE request has been described.The request is used to invite a called party to a session.
Other important requests are:
P.37
[IP Telephony Cookbook] / Technological Background
- ACK
This message acknowledges receipt of a final response to INVITE. Establishing of a session utilises 3-way hand-shaking due to asymmetric nature of the invitation. It may take a while before the called party accepts or declines the call so the called party's user agent periodically re-transmits a positive final response until it receives an ACK (which indicates that the calling party is still there and ready to communicate);
- BYE
BYE messages are used to tear down multimedia sessions. A party wishing to tear down a session sends a BYE to the other party;
- CANCEL
CANCEL is used to cancel a not yet fully-established session. It is used when the called party has not replied with a final response yet but the calling party wants to abort the call (typically when a called party does not respond for some time);
- REGISTER
The purpose of REGISTER is to let the registrar know of current user's location. Information about the current IP address and port on which a user can be reached is carried in REGISTER
messages. Registrar extracts this information and puts it into a location database.The database can be later used by SIP Proxy Servers to route calls to the user. Registrations are time-limited and need to be periodically refreshed.
The listed requests usually have no message body because it is not needed in most situations (but can have one). In addition, many other request-types have been defined but their descriptions are out of the scope of this document.
2.2.2.3.2 SIP responses
When a user agent or proxy server receives a request, it sends a reply. Each request must be replied to except ACK requests which trigger no replies.
A typical reply looks like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68
From: sip:sip2@iptel.org
To: sip:sip2@iptel.org;tag=794fe65c16edfdf45da4fc39a5d2867c.b713
Call-ID: 2443936363@192.168.1.30
CSeq: 63629 REGISTER
Contact: <sip:sip2@66.87.48.68:5060;transport=udp>;q=0.00;expires=120
Server: Sip EXpress router (0.8.11pre21xrc (i386/linux))
Content-Length: 0
Warning: 392 195.37.77.101:5060 "Noisy feedback tells:
pid=5110 req_src_ip=66.87.48.68 req_src_port=5060
in_uri=sip:iptel.org
out_uri=sip:iptel.org via_cnt==1"
Responses are very similar to the requests, except for the first line.The first line of response contains a protocol version (SIP/2.0) reply code and reason phrase.The reply code is an integer number from 100 to 699 and indicates type of the response.There are 6 classes of responses: P.38
[IP Telephony Cookbook] / Technological Background
1xx are provisional responses. A provisional response is a response that tells to its recipient that the associated request was received but the result of the processing is not known yet. Provisional responses are sent only when the processing does not finish immediately.The sender must stop re-transmitting the request upon reception of a provisional response.
Typically, proxy servers send responses with code 100 when they start processing an INVITE and user agents send responses with code 180 (Ringing) which means that the called party's phone is ringing.
2xx responses are positive final responses. A final response is the ultimate response that the originator of the request will ever receive.Therefore, final responses express the result of the processing of the associated request. Final responses also terminate transactions. Responses with code from 200 to 299 are positive responses.That means that the request was processed successfully and accepted. For instance, a 200 OK response is sent when a user accepts the invitation to a session (INVITE request).
A UAC may receive several 200 messages to a single INVITE request.This is because a forking proxy (described later) can fork the request so it will reach several UAS and each of them will accept the invitation. In this case, each response is distinguished by the tag parameter in the To header field. Each response represents a distinct dialogue with an unambiguous dialogue identifier:
- 3xx responses are used to redirect a calling party. A redirection response gives information about the user's new location or an alternative service that the calling party might use to satisfy the call. Redirection responses are usually sent by proxy servers.When a proxy receives a request and does not want or can't process it for any reason, it will send a redirection response to the calling party and put another location into the response which the calling party might want to try. It can be the location of another proxy or the current location of the called party (from the location database created by a registrar).The calling party is then supposed to re-send the request to the new location. 3xx responses are final;
- 4xx are negative final responses. A 4xx response means that the problem is on the sender's side.
The request could not be processed because it contains bad syntax or cannot be fulfilled at that server.
- 5xx means that the problem is on server's side.The request is apparently valid but the server failed to fulfil it. Clients should usually retry the request later;
- 6xx reply code means that the request cannot be fulfilled at any server.This response is usually sent by a server that has definitive information about a particular user. User agents usually send a 603 Decline response when the user does not want to participate in the session.
In addition to the response class, the first line also contains the reason phrase.The code number is intended to be processed by machines. It is not very human-friendly but it is very easy to parse and understand by machines.The reason phrase usually contains a human-readable message describing the result of the processing. A user agent should render the reason phrase to the user.
The request to which a particular response belongs is identified using the CSeq header field. In addition to the sequence number, this header field also contains the method of corresponding request. In our example it was a REGISTER request.
P.39
[IP Telephony Cookbook] / Technological Background
{ 2.2.2.4. SIP transactions
Although we said that SIP messages are sent independently over the network, they are usually arranged into transactions by user agents and certain types of proxy servers.Therefore SIP is said to be a transactional protocol.
A transaction is a sequence of SIP messages exchanged between SIP network elements. A transaction consists of one request and all responses to that request.That includes zero or more provisional responses and one or more final responses (remember that an INVITE might be answered by more than one final response when a proxy server forks the request).
If a transaction was initiated by an INVITE request, then the same transaction also includes ACK, but only if the final response was not a 2xx response. If the final response was a 2xx response, then the ACK is not considered part of the transaction.
As we can see, this is quite asymmetric behaviour, ACK is part of transactions with a negative final response but is not part of transactions with positive final responses.The reason for this separation is the importance of delivery of all 200 OK messages. Not only do they establish a session, but also 200 OK can be generated by multiple entities when a proxy server forks the request and all of them must be delivered to the calling user agent.Therefore, user agents take responsibility in this case and retransmit 200 OK responses until they receive an ACK. Also note that only responses to INVITE are retransmitted.
SIP entities that have a notion of transactions are called stateful. Such entities usually create a state associated with a transaction that is kept in the memory for the duration of the transaction.When a request or response comes, a stateful entity tries to associate the request (or response) to existing transactions.To be able to do this, it must extract a unique transaction identifier from the message and compare it to identifiers of all existing transactions. If such a transaction exists, then its state gets updated from the message.
In the previous SIP RFC2543, the transaction identifier was calculated as hash of all important message header fields (that included To, From, Request-URI and CSeq).This proved to be very slow and complex. During interoperability tests, such transaction identifiers were a common source of problems.
In the new RFC3261, the way of calculating transaction identifiers was completely changed.
Instead of the complicated hashing of important header fields, a SIP message now includes the identifier directly.The branch parameter of Via header fields directly contains the transaction identifier.This is a significant simplification, but there still exist old implementations that do not support the new way of calculating of the transaction identifier, so even new implementations have to support the old way.They must be backwards-compatible.
Figure 2.15 shows what messages belong to what transactions during a conversation of two user agents.
P.40
[IP Telephony Cookbook] / Technological Background
Calling party
Called party
INVITE
100 Trying
Transaction #1
180 Ringing
200 OK
ACK
BYE
200 OK