Traditional SIP headers for Call setup are INVITE, ACK and teardown are CANCEL or BYE However with more adoption newer methods specific to services were added such as MESSAGE Methods for Instant Message based services SUBSCRIBE, NOTIFY standardised by Event notification extension RFC 3856 PUBLISH to push presence information to the network
Outlining the SIP Requests and Responses in tables below,
1. Request Message
A Client use this message to register an address with a SIP server
A User or Service use this message to let another user/service participate in a session. The body of this message would include a description of the session to which the callee is being invited.
This is used only for INVITE indicating that the client has received a final response to an INVITE request
This is used to cancel a pending request
A User Agent Client use this message to terminate the call
This is used to query a server about its capabilities
2. Response Message
The request has been received and processing is continuing
An ACK, to indicate that the action was successfully received, understood, and accepted.
Further action is required to process this request
The request contains bad syntax and cannot be fulfilled at this server
The server failed to fulfill an apparently valid request
The request cannot be fulfilled at any server
, based on RFC 3261
SIP headers :
From originators sipuri
CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.
Contact – SIP URI that represents a direct route to the originator usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. The Contact header field tells other elements where to send future requests.
Max-Forwards -to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.
Content-Type – description of the message body. ex : application/h.323
Content-Length – an octet (byte) count of the message body.
Accept – acceptable formats like application/sdp or currency/dollars
Authorization – encryption info
Call-Id uniquely identify a session
contact – sip url alternative for direct routing
Expires – when msg content is no longer valid
Mandatory SIP headers
Via: SIP/2.0/UDP host.domain.com:5060
From: Bob <sip:email@example.com>
To: Altanai <sip:firstname.lastname@example.org>
CSeq: 1 INVITE
session description in SDP
SDP /Session Description Protocol
standard for protocol definition for exchange of media ( RFC 4566)
SDP is encapsulated inside of SIP packet
TYPICAL SIP INVITE :
Via: SIP/2.0/UDP x.x.x.x:5060branch=z9hG4bK400fc6e6
From: "123456789" ltsip:email@example.com=as42e2ecf6
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
o=root 14040 14040 IN IP4 x.x.x.x
c=IN IP4 x.x.x.x
m=audio 26784 RTP/AVP 0 8 18 101
a=fmtp:18nbspannexb=no - - - -
c=* (connection information - optional if included at session-level)
b=* (bandwidth information)
a=* (zero or more media attribute lines)
response that tells to its recipient that the associated request was received but result of the processing is not known yet which could be if the processing hasnt finished immediately. The sender must stop retransmitting the request upon reception of a provisional response.
100 Trying 180 Ringing 181 Call is Being Forwarded 182 Queued 183 Session in Progress199 Early Dialog Terminated
final responses express result of the processing of the associated request and they terminate the transactions.
200 OK 202 Accepted 204 No Notification
redirection response gives information about the user’s new location or an alternative service that the caller should try for the call. Used for cases when the server cant satisfy the call and wants the caller to try elsewhere . After this the caller is suppose to resend the request to the new location.
300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 305 Use Proxy 380 Alternative Service
4xx—Client Failure Responses
negative final responses indicating that the request couldn’t be processed due to callers fault , for reasons such as t contains bad syntax or cannot be fulfilled at that server.
400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required 412 Conditional Request Failed 413 Request Entity Too Large 414 Request-URI Too Long 415 Unsupported Media Type 416 Unsupported URI Scheme 417 Unknown Resource-Priority 420 Bad Extension 421 Extension Required 422 Session Interval Too Small 423 Interval Too Brief 424 Bad Location Information 428 Use Identity Header 429 Provide Referrer Identity 430 Flow Failed 433 Anonymity Disallowed 436 Bad Identity-Info 437 Unsupported Certificate 438 Invalid Identity Header 439 First Hop Lacks Outbound Support 470 Consent Needed 480 Temporarily Unavailable 481 Call/Transaction Does Not Exist 482 Loop Detected. 483 Too Many Hops 484 Address Incomplete 485 Ambiguous 486 Busy Here 487 Request Terminated 488 Not Acceptable Here 489 Bad Event 491 Request Pending 493 Undecipherable 494 Security Agreement Required
5xx—Server Failure Responses
negative responses but indicating that fault is at server’s side for cases such as server cant or doesnt want to respond the the request.
500 Server Internal Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Server Time-out 505 Version Not Supported 513 Message Too Large 580 Precondition Failure
6xx—Global Failure Responses
request cannot be fulfilled at any server with definitive information
600 Busy Everywhere 603 Decline 604 Does Not Exist Anywhere 606 Not Acceptable
Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)
An INVITE request sent within an existing dialog is known as a re-INVITE.
A re-Invite has an offer-answer exchange and can be used to
change the session and/or dialog params
change the port to which media should be sent.
change the connection address or media type.
Hold/Release and SUSPEND/RESUME rtp streams (connection address is zero).
FAX (T.38 and Bypass).
Re-INVITE with SDP useCases
UAS rejects all changes in params in re-INVITE
Situtaion where UAC establishes audio only call
SDP1: m=audio 30000 RTP/AVP 0
but later wants to upgrade to video as well
SDP:m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31
UAS configured to reject video streams, can reject this with a 4XX error and get ACK .
No changes to session are made
UAS receives re-INVITE for param but wants to accept few and reject others, it sends back SDP with acceptable changes with 200 OK
For instance UAC moves to high bandwidth access point and wants to update IP of media stream . It also wanst to add video stream
UAS receives re-INVITE but wants for user intervention
UAS receives re-INVITE to add video , but instead of rejecting , it prompts user to permit.
So UAS provides a null IPaddress instead of setting the stream to ‘inactive’ because inactive streams still need to exchange RTP Control Protocol (RTCP) traffic
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
Later if user rejects the addition of the video stream. Consequently, the UAS sends an UPDATE request (6) setting the port of the video stream to zero in its offer.
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0