SIP is a widely adopted application layer protocol used in VoIP calls and confernecing applciations and in IMS architeture or pure packet switched networks .
More on SIP , its packet structure , transaction and dialogs , loose and strict record routing , location service , near and far end nating , and commonly used SIP Call flows like Redirection , forking , click to Dial – https://telecom.altanai.com/2013/07/13/sip-session-initiaion-protocol/(opens in a new tab)
SIP Request and Repsosnes
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,
Request Message
| Request Message | Description |
| REGISTER | A Client use this message to register an address with a SIP server |
| INVITE | 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. |
| ACK | This is used only for INVITE indicating that the client has received a final response to an INVITE request |
| CANCEL | This is used to cancel a pending request |
| BYE | A User Agent Client use this message to terminate the call |
| OPTIONS | This is used to query a server about its capabilities |
Response Message
| Code | Category | Description |
| 1xx | Provisional | The request has been received and processing is continuing |
| 2xx | Success | An ACK, to indicate that the action was successfully received, understood, and accepted. |
| 3xx | Redirection | Further action is required to process this request |
| 4xx | Client Error | The request contains bad syntax and cannot be fulfilled at this server |
| 5xx | Server Error | The server failed to fulfill an apparently valid request |
| 6xx | Global Failure | The request cannot be fulfilled at any server |
SIP headers
Display names
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) , also 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
Content-Type – description of the message body.
Content-Type: application/h.323
Content-Type: message/sip
Content-Type: application/sdp
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content Encoding
Content-Encoding: text/plain
Content Language
Content-Language: en
Content-Length – an octet (byte) count of the message body.
Content-Disposition
describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. It extends the MIME Content-Type
Disposition Types :
- “session” – body part describes a session, for either calls or early (pre-call) media
- “render” – body part should be displayed or otherwise rendered to the user.
- “icon” – body part contains an image suitable as an iconic representation of the caller or callee
- “alert” – body part contains information, such as an audio clip
Accept
Accept – acceptable formats like application/sdp or currency/dollars
Header field where proxy ACK BYE CAN INV OPT REG
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
An empty Accept header field means that no formats are acceptable.
Accept-Encoding
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language : languages for reason phrases, session descriptions, or status responses carried as message bodies in the response.
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c
Tag globally unique and cryptographically random with at least 32 bits of randomness. identify a dialog, which is the combination of the Call-ID along with two tags ( from To and FROM headers )
Call-Id uniquely identify a session
contact – sip url alternative for direct routing
Encryption
Expires – when msg content is no longer valid
Mandatory SIP headers
INVITE sip:altanai@domain.comSIP/2.0 Via: SIP/2.0/UDP host.domain.com:5060 From: Bob To: Altanai Call-ID: 163784@host.domain.com CSeq: 1 INVITE
Informational headers
Call-Info additional information for example, through a web page. The “card” parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA
Call-Info: http://wwww.example.com/alice/photo.jpg ;purpose=icon,http://www.example.com/alice/ ;purpose=info
Contact
Contact: “Mr. Watson” ;q=0.7; expires=3600,
“Mr. Watson” watson@bell-telephone.com ;q=0.1 m: ;expires=60
Priority indicates the urgency of the request as perceived by the client.
can have the values “non-urgent”, “normal”, “urgent”, and “emergency”, but additional values can be defined elsewhere
Subject: A tornado is heading our way!
Priority: emergency
or
Subject: Weekend plans
Priority: non-urgent
Subject summary or indicates the nature of call
Subject: Need more boxes
s: Tech Support
Supported enumerates all the extensions supported. can contain list of option tags, described
Supported: 100rel
k: 100rel
Unsupported features not supported
Unsupported: foo
User-Agent information about the UAC originating the request.
User-Agent: Softphone Beta1.5
Organization conveys the name of the organization to which the SIP element issuing the request or response belongs.
Organization: AltanaiTelecom Co.
Warning additional information about the status of a response.
List of warn-code
- 300 Incompatible network protocol:
- 301 Incompatible network address formats:
- 302 Incompatible transport protocol:
- 303 Incompatible bandwidth units:
- 304 Media type not available:
- 305 Incompatible media format:
- 306 Attribute not understood:
- 307 Session description parameter not understood:
- 330 Multicast not available:
- 331 Unicast not available:
- 370 Insufficient bandwidth:
- 399 Miscellaneous warning:
- 1xx and 2xx have been taken by HTTP/1.1.
Warning: 307 isi.edu “Session parameter ‘foo’ not understood”
Warning: 301 isi.edu “Incompatible network address type ‘E.164′”
Authetication and Authorization related headers
Authentication-Info mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field.
Authentication-Info: nextnonce=”47364c23432d2e131a5fb210812c”
Authorization authentication credentials of a UA
Authorization: Digest username=”Alice”, realm=”atlanta.com”, nonce=”84a4cc6f3082121f32b42a2187831a9e”, response=”7587245234b3434cc3412213e5f113a5432″
Proxy-Authenticate contains an authentication challenge.
Proxy-Authenticate: Digest realm=”atlanta.com”,domain=”sip:ss1.carrier.com”, qop=”auth”,
nonce=”f84f1cec41e6cbe5aea9c8e88d359″,opaque=””, stale=FALSE, algorithm=MD5
Timers
exponential back-off on re-transmissions
Session Expire Header Feild
limit the time period over which a stateful proxy must maintain state information.
options
- User agents must tear down the call after the expiration of the timer , or
- aller can send re-INVITEs to refresh the timer, enabling a “keep alive” mechanism for SIP.
SDP (Session Description Protocol)
SIP can bear many kinds of MIME attachments , one such is SDP. It is a standard for protocol definition for exchange of media , metadata and other transport realted attributes between the particpants before establishing a VoIP call.
SDP session description is entirely textual using the ISO 10646 character set in UTF-8 encoding and described by application/SDP media type.
It should be noted that SDP itself does not incorporate a transport protocol and can be used with difference protocls like Session announcement proctols (SAP) , SIP , HTTP , Electronic MAIl MIME extension, RTSP etc.
In case of SIP SDP is encapsulated inside of SIP packet and use offer/answer model to convey information about media stream in multimedia session.
SDP body contains 2 parts : session based section starting with v= line and media bsesction starting with m= line
Media and Transport Information can contain type of media like video, audio , transport protocol like RTP/UDP/IP, H.320 and format of the media such as H.261 video, MPEG video, etc.
Session Description in SDP
protocol version ( v= ) protocol version mostly version 0
originator and session identifier ( o= )
o= < username > <session-id> <session-version> <net-type> <addr-type> <unicast address> o=- 6476888576284874344 2 IN IP4 127.0.0.1
session name ( s=) and session information ( i= ) session name is textual and can contain empty space or even s=- but must not be empty. Session infomration is optional textual information about the session
URI of description ( u = )
Email Address and Phone Number (“e=” and “p=”)
Both are optional free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding
Nothe that if given the Phone numbers SHOULD follow international public telecommunication number specification ( ITU-T Recommendation E.164) and be preceded by a “+”. Spaces and hyphens may be used to split up a phone field to aid readability if desired.
e=Jane Doe j.doe@example.com
p=+1 617 555-6011
Connection Data ( c= ) connection information — not required if included in all media in which media specific connecion data override overall session connection data
c= <net-type> <addr-type> <connection-address>
c=IN IP4 172.31.90.251
If the session is multicast, the connection address will be an IP multicast group address . TTL shoudl be present in IPv4 multicast address .
If connection is unicast the address contains the unicast IP address of the expected data source or data relay or data sink .
Bandwidth ( b= ) interpreted as kilobits per second by default
b= <bwtype> : <bandwidth>
Encryption Keys ( k= ) Only is SDP is exchanged in secure and trusted channel, keys va be excahnged on this SDP field . Although this process is not recomended,
k= clear:< encryption key >
k= base64:< encoded encryption key >
k= uri:< URI to obtain key >
k= prompt
Attributes ( a= )
extends the SDP with values like flags
a=inactive , a=sendonly , a=sendrecv , a=recvonly
Mapping the Encoder Spec from
a=rtpmap: < payload type > < encoding name >/ < clock rate > [/ ]
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/48000
a=rtpmap:97 telephone-event/8000
Conferenec Type like “broadcast”, “meeting”, “moderated”, “test”,
a=type: < conf type>
Orientation portrait or landscape for whiteboard session
a=orient: <orientation>
ICE candidates
a=ice-pwd:86701d63e2d96ec42268679a a=ice-ufrag:948a1316 a=rtcp-12133xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
Frame per second for video
a=framerate:
Quality between 0 – 10 ( 10 best still image , 5 default , 0 wrst )
a= quality: < quality >
Format specific Parameters
a=fmtp: <format> <parameters>
a=rtpmap:114 AMR-WB/16000/1 a=fmtp:114 mode-change-capability=2;max-red=220 a=rtpmap:113 AMR-WB/16000/1 a=fmtp:113 octet-align=1;mode-change-capability=2;max-red=220 a=rtpmap:102 AMR/8000/1 a=fmtp:102 mode-change-capability=2;max-red=220 a=rtpmap:115 AMR/8000/1 a=fmtp:115 octet-align=1;mode-change-capability=2;max-red=220 a=rtpmap:105 telephone-event/16000 a=fmtp:105 0-15 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
Time Description in SDP
Timing (t =)
time the session is active)
t=<start-time> <stop-time>
If the <stop-time> is set to zero, then the session is not bounded, though it will not become active until after the < start -time>.
If the <start-time> is also zero, the session is regarded as permanent.
t=0 0
Repeat Times ( r= )
zero or more repeat times for scheduling a session
r= <repeat interval> <active duration> <offsets from start-time>
time zone adjustments ( z = )
z= <adjustment time> <offset> <adjustment time> <offset> ….
useful for scejduling session during transation to daylightv saving to standard time and vice versa
Media Description in SDP
For RTP, the default is that only the even-numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session
m= <media> <port> <proto> <fmt> …
m=audio 20098 RTP/AVP 0 101
will stream RTP on 20098 and RTCP on 20099
For multiple transport ports pairs of RTP , RTCP stream are specified
m= <media> <port>/ <number of ports> <proto> <fmt> …
m=audio 20098/2 RTP/AVP 0 101
will stream one pair on RTP 20098 , RTCP 20099 and RTP 20100 , RTCP 20101
If non-contiguous ports are required, they must be signalled using a separate attribute like example, “a=rtcp:”
Additioan SDP features : In addition to normal unicast sessions , SDP can also convery multicast group address for media on IP multicast session. Private (encryption of SDP ) or public session are not treated differently by SDP and they are entorely a function of implementing mechanism like SIP or SAP. Optiopnal SDP params include URI , Categorisation “a=cat:” , Internationalisation etc
Example 1 : Typical Audio call SIP INVITE showing SIP headers in blue and SDP in green below
INVITEnbspsip:01150259917040@x.x.x.x SIP/2.0 Via: SIP/2.0/UDP x.x.x.x:5060branch=z9hG4bK400fc6e6 From: "123456789" ltsip:123456789@x.x.x.xgttag=as42e2ecf6 To: ltsip:01150259917040@x.x.x.x.4gt Contact: ltsip:123456789@x.x.x.x4gt Call-ID: 2485823e63b290b47c042f20764d990a@x.x.x.x.x CSeq: 102 INVITE User-Agent:nbspMatrixSwitch Date: Thu, 22 Dec 2005 18:38:28 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Content-Type: application/sdp Content-Length: 268 v=0 o=root 14040 14040 IN IP4 x.x.x.x s=session c=IN IP4 x.x.x.x t=0 0 m=audio 26784 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=fmtp:18nbspannexb=no - - - - c=* (connection information - optional if included at session-level) b=* (bandwidth information) a=* (zero or more media attribute lines)
The above SDP shows 4 supported media codecs on audio stream which are 0 PCMU , 8 PCMA , 18 G729 and finally 101 used for telephone events . It also shows RTP/AVP as RTP profile and does not contain any m=cideo line which shows that this endpoint does not want a video call , only an audio one.
Example 2 : Video Vall SIP invite from Linphone
SIP URI Params
Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry defines URI params that can be sued along with SIP scheme
sip:user:password@host:port;uri-parameters?headers
comp param
signalling compression of SIP messages
sip:alice@atlanta.com;comp=sigcomp
Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
The aobve exmaple indicates that the request has to be compressed using SigComp
transport-param
SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768), TCP (RFC 761), and SCTP (RFC 2960).
For a SIPS URI, the transport parameter MUST indicate a reliable transport.
“transport=” ( “udp” / “tcp” / “sctp” / “tls” / “ws” / other-transport )
sip:alice:secretword@atlanta.com;transport=tcp
maddr paarm
The server address ( detsiantion address , port , transport ) to be contacted for this user, overriding any address derived from the host field.
Although discouraged , maddr URI param has been used as a simple form of loose source routing. It allows a URI to specify a proxy that must be traversed en-route to the destination.
user-param
“user=” ( “phone” “ip” “dialstring” other-user )
sip:1-212-555-1212:1234@gateway.com;user=phone
sip:123;phone-context=atlanta.example.com@example.com;user=dialstring
method-param
“method=” Method
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
annc-parameters (announcement)
ANNC-URL
sip‑ind annc‑ind “@” hostport annc‑parameters uri‑parameters
sip:annc@ms.example.net; \
; play=file://fs.example.net//clips/my-intro.dvi; \
; content-type=video/mpeg%3bencode%d3314M-25/625-50
sip-ind - “sip:” / “sips:”
annc-ind - “annc”
annc-parameters
“;” play‑param
[ “;” delay‑param ]
[ “;” duration‑param ]
[ “;” repeat‑param ]
[ “;” locale‑param ]
[ “;” variable‑params ]
[ “;” extension‑params ]
play-param – “play=” prompt‑url
prompt-url – “/provisioned/” announcement‑id
announcement-id = 1*( ALPHA / DIGIT )
content-param “content‑type=” MIME‑type
VoiceXML Media Services
dialog-param
“voicexml=” vxml-url ; vxml-url follows the URI syntax
method-param – “method=” ( “get” / “post” )
postbody-param- “postbody=” token
ccxml-param – “ccxml=” json‑value
aai-param- “aai=” json‑value
json-value – false / null / true / object / array / number / string
sip:dialog@mediaserver.example.com; \
voicexml=http://appserver.example.com/promptcollect.vxml; \
maxage=3600;maxstale=0
dialog-params (prompt and collect)
DIALOG-URL = sip-ind dialog-ind “@” hostport dialog‑parameters
ttl-param (time-to-live)
ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP.
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
cause param
“cause” EQUAL Status-Code
; 404 Unknown/Not available
; 486 User busy
; 408 No reply
; 302 Unconditional
; 487 Deflection during alerting
; 480 Deflection immediate response
; 503 Mobile subscriber not reachable
; 380 Service number translation RFC 8119 – Section 2
sip:voicemail@example.com;target=bob%40example.com;cause=486
SIP Responses
1xx—Provisional Responses
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 : Triigers a local ringing at callers device
181 Call is Being Forwarded : Used before tranefering to another UA such as during forking or tranfer to voice mail Server
182 Queued
183 Session in Progress : conveys information . Headers field or SDP body has mor details about the call. Used in announcements and IVR + DTMF too by being followed by “Early media”.
199 Early Dialog Terminated
2xx—Successful Responses
final responses express result of the processing of the associated request and they terminate the transactions.
200 OK
202 Accepted
204 No Notification
3xx—Redirection Responses
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
Mandatory SIP headers in SIP respone
SIP/2.0 200 OK Via: SIP/2.0/UDP host.domain.com:5060 From: Bob<sip:bob@domain.com> To: Altanai<sip:altanai@domain.com> Call-ID: 163784@host.domain.com CSeq: 1 INVITE
Via, From, To, Call-ID , and CSeq are copied exactly from request
Re-INVITE and Target-Refresh Request Handling
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 do the following
- 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
1.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
2. 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
initial SDP
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
new SDP in reINVITE
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
UAS returns a 200 (OK) response to accept IP but sets the port of the video stream to zero in its SDP to show rejected of video stream.
m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 m=video 0 RTP/AVP 31
another example is when UAC wwants to add another audio codec and also add video stream to session
orignal SDP
m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.1
re-invite SDP
m=audio 30000 RTP/AVP 0 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
again the UAS will optionally accept the some param canges like audio code but set video to null IP address
m=audio 31000 RTP/AVP 0 3 c=IN IP4 192.0.2.5 m=video 31002 RTP/AVP 31 c=IN IP4 0.0.0.0
3. UAS receives re-INVITE but waits 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
References:
- RFC 3261 SIP
- RFC 4566 SDP https://tools.ietf.org/html/rfc4566
- RFC 6141 Updates the RFC 3261 with respect to re-INVITE and UAS behaviour https://tools.ietf.org/html/rfc6141
- Techinvote : https://www.tech-invite.com/fo-abnf/tinv-fo-abnf-sipuriup.html
Telecom R & D 
