Show Menu
Cheatography
  1. Home >
  2. Cheat Sheets >

CNA2 Cheat Sheet (DRAFT) by

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Core SIP

WebRTC
A new specif­ication that promises to change commun­ication across the web yet it lacks a signaling protocol.
SIP benefit 1
Services on offers - Offers voicemail, video, call confer­encing, IM, and SMS all for a small cost and sometimes NO cost to user.
SIP benefit 2
Mobility - Presence based services that allow users to control what is seen about them and control over where calls are routed based on their presence status
Why SIP?
Price - drasti­cally reduce LD costs. Calls are carried across the Internet or other networks for most of the journey.
 
Flexib­ility - in adding to or removing trunks as you need them without hardware changes
 
Features - help facilitate multiple forms of commun­ication such as video and IM
What is SIP?
Session Initiation Protocol
 
Signalling protocol used for contro­lling multi-­media sessions
 
Can setup, modify, and tear down sessions
 
Helps establish user presence and locate users when using mobile and desktop
IETF RFC 3261
SIP is an applic­ation layer control protocol
 
Can establish, modify, and terminate multimedia sessions (confe­rences) such as Internet telephony calls
 
Can invite partic­ipants to already existing sessions, such as multicast confer­ences.
 
Media can be added to and removed from an existing session
 
SIP transp­arently supports name mapping and redire­ction services - users can maintain a single externally visible identifier regardless of these network location
RFC
Request for Comments
 
- idea for the Internet
 
- crate a draft doc
IETF
- submit it to Internet Engine­ering Task Force
 
- proposed standard
 
- draft standard
 
- Internet standard
SIP based on HTTP
Is a textual based protocol, written in ASCII format
 
It is based on the client­-server model
Client­-server model
requests from a client device are sent to a server device which then responds to the client
 
This request invokes a method on the server which normally makes something happen
Working group
Are created by the Internet Engine­ering Steering Group to work on limited set of tasks described in its charter and will normally be closed one the work described in its charter is finished.

SIP on the OSI chart

SIP lives at the applic­ation layer above its transport protocol UDP that runs over IP. SIP carries SDP messages in its body to help describe the audio and media components of a session.

RTP (real time protocol) deliver the media after DNS has found out where the destin­ation is

SIP User Agents

A UAC is an applic­ation or device that acts on behalf of a user. The UAC will initiate a call and the UAS will receive the call.

UAC are also UAS so that they can initiate and receive calls.

SIP HEADER - 200 Response

Via headers are inserted by servers into requests to detect loops and to allow responses to find their way back to the client 'VIA' the server.

Simple Call Session Setup

The user dial a destin­ation number, the UAC will send an INVITE message to the destin­ation device. If the destin­ation device answers the call it also returns a '200 OK' message to say that this has happened. The caller will then acknow­ledge this event. Voice, video, or whatever can pass between the two devices.

When one device hangs up, it sends a 'BYE" message which is responded to with a '200 OK' message.

SIP System Archit­ecture

User Agents - SIP VoIP phone, wireless PDA, softphone

SIP Proxy - assist in the Discovery and Setup of the sessions between the UA

SIP Registrar - UA use the Register their current location on a Network

SIP Location Server - contains the registered location info. Usually the Registrar and Location services run on the same server.

SIP gateway - translates Signaling and probably media as well so that SIP devices can commun­icate with legacy devices.

Mini Quizlet

What is the 1st SIP message of Method sent out when a SIP US wants to setup a call with another SIP device?
INVITE

URL / URI

URI/ URL

URI
is a string that identifies some kind of resources
 
 
URI is an identi­fier, an email address but it does not tell you how to move emails to this address
 
General form is User@Host
 
User = name, telephone number
 
Host = Domain name, IP address
Main types of URI
Service, Device, and User
 
- With a Service, the URI could point to a confer­encing unit that SIP users can reference and join
 
- With a Device, the URI represents a single device or app
 
- With a User, the URI can be static. This URI or AOR - address of record will map to as many other SIP URIs as the user wants or needs
URL
is a form of a URI that not only identifies a resource but tells you how to reach the resource
 
 
URL tells you the address of the web server and that a HTTP request should be sent to retrieve a web page
Goal of SIP addressing
To provide all users with a single URI, which when used in conjun­ction with DNS will reveal all the other info relating to user or agent, such as email address, voice, data, video capabi­lities

SIP device start up

When a SIP device starts up it sends its current address and location details to its Registrar server. This server then updates the users location in the location server.

Once the client's details are updated, they can be contacted using their published address which resolves to their current IP address.

Regist­ration

Feature types
When a SIP UA registers it ell the Registrar about its feature capabi­lities. This is useful info for SIP devices wanting to make contact with the UA
RFC 3840
whole list of features

SIP Proxy Server

Proxy Server
forwards requests to the next server after working out which is the next server to talk to
 
It will interpret a request message and if necessary rewrite the message before forwarding it.
 
It can issue both requests and responses so it is in effect a SIP client and a server.
 
It can fork the incoming request to multiple locations if someone has multiple location regist­rations
Stateful Proxy
remembers incoming requests and outgoing requests
 
This keeps 'state' info for the entire duration of a SIP session. This is useful for implem­enting extra services such as call forward on busy or no answer.
Stateless Proxy
forgets all inform­ation once an outgoing request is generated.
 
This keeps a no 'state inform­ations and as soon as it has helped out a UA it forgets everything about the transa­ction.
Why do you need a Proxy Server?
sometimes only by contacting a proxy server SIP signalling actually be allowed to leave a corporate network
 
may also be acting as the corporate firewall
UA proxy details
a UA gets its proxy details either by manual config­uration or via DHCP
Transa­ction stateful
This keeps all state info on all transa­ctions that are pending. Once a session is establ­ished, the proxy forgets the state info.

Mini Quizlet

A 'Stateful Proxy' forgets incoming and outgoing SIP requests once they have been processed
false

DHCP and SIP

DHCP server
can send proxy details in either the DNS or IP address format in DHCP option 120
DHCP option 120
The option is used to provide SIP server IP address or FQDN to SIP client

SIP Proxy - Trapezoid model

100 trying - progress of the call setup
180 ringing - when the destin­ation starts ringing
200 Ok - message is sent on device pick-up which is relayed and followed by an acknow­led­gement.
BYE - when one device hangs up

SIP server in proxy mode

In proxy mode, all SIP messaging goes via the Proxy

SIP server in Proxy Redirect Mode

Once the proxy finds the 'called to' location from the location server, it sends the contact details to the calling device. The INVITE is then reissued with my specific contact details 'directly' to the called softphone.
The proxy is doing less work with this setup.

Mini Quizlet

What is the SIP 'Response code' that signifies 'Ringing'?
180

Location Server

A location server is used by a SIP proxy servor or redirect server to obtain inform­ation about a called party's possible locati­on(s)
Will have a database to hold location info for the SIP UA and this is kept up to date via the Registrar service this is processing Register and Re-Reg­ister messages from clients. The SIP proxy will then use the Location service to help find the current location details of the destin­ation SIP URI in a SIP INVITE mesage

Location Server - components

Location Server - Inform­ation sources

Sources -
Local database provides as part of the location server product
DNS - it will store the location details of other servers in other domains that the location server may need to contact
Microsoft Active directory that uses LDAP protocol

Location Server

Config­uration scenarios

1. Get config via TFTP file on boot up
2. Get config via config server as defined in RFC 6011
3. Manual config­ura­tion.

SIP basic elements that all clients need

SIP regist­ration server hostname /IP
DNS server address if using DNS names for SIP regist­ration
SIP port number
User account / password
SIP proxy hostname or IP address to direct calls

SIP Messages

SIP Messages are normally requests and responses. The request from client to server, the response back to the client from the server.
Request and responses use different headers in the SIP message to describe the detail of the commun­ication between agents
Author­ization and encryption is use to make SIP more secure

Basic SIP Request methods

INVITE
initiates a call by inviting a user to particle in a session. INVITEs can also be used for session modifi­cation
ACK
ACKnow­led­gement is used as a respne to a 200 OK response that was the result of an initial INVITE request. A session should now be in place. ACK is only used with INVITE and reINVITES requests
BYE
is used to indicate termin­ation of a call or session
CANCEL
is used to cancel a pending request
REGISTER
is used to register the user agent by tempor­arily binding the Agent URI to an AOR (address of record) so the SIP server knows the location of the user agent
OPTIONS
is used to find out what a server or UA media capabi­lites are but does not set up a session
INFO
is used for commun­icating mid-se­ssion signaling info
PRACK
is a Provis­ional ACK and is only used in response to a 1XX 'style' response message.
 
IF an initial INVITE had no SDP body, then after a 1xx 'style' response the PRACK can include the relevant SDP detail.
 
Each provisonal response (eg. from a UAS, a 183 session in progress) is given a seq number, carried in the RSeq header field in the response
 
The PRACK message from the UAC contain an RAck header field, which indicates the seq num of the provis­ional response that is being ack.
Session Descri­ption Protocol (SDP)
describes the media of a session. It is important to realize that it doesn’t negotiate the media.
 
SIP deals with establ­ishing, modifying, and tearing down sessions, SDP is solely concerned with the media within those sessions.
 
SDP is used when one party tells the other party, “here are all the media types I can support — pick one and use it.”
SUBSCRIBE
method is used to req notifi­cation of an event or set of events at a later time
 
eg. requesting a notifi­cation when another persons 'IM Presence' details change.
NOTIFY
is used to notify that an event which was requested by an earlier SUBSCRIBE method has occurred.
 
Used by a SIP server to NOTIFY a client of an event. eg. a VM has been left for the client.
REFER
is used to Transfer calls and also to contact external resources
UPDATE
allows a client to update parameters of a session such as set of media streams and their codecs, but has no impact on state of dialog
SERVICE
method can carry a SOAP message as its payload
SOAP
Simple Object Access Protocol is a lightw­eight protocol that defines a framework for encoding request and response message in XML
BENOTIFY
Best Effort NOTIFY
 
is used by MS Lync, LCS, and Skype for Business comm products.
 
Unlike a NOTIFY method, BENOTIFY doesn't require a response as apps may not need a NOTIFY response to a certain request thus reducing SIP signaling traffic, which is important for deploy­ments with large number of clients on server
MESSAGE
method is an ext. to SIP that allows transfer of IM where requests will normally carry the IM content in the request body.

SIP Response Codes

SIP response codes
are made up of 3 digits. The first digit in the code indicates the class of the response and the other two digits are used to represent a reason or 'reason phrase'.
1xx
style response is an inform­ational response. The request was received and is still being processed.
2xx
style response is a sucess respone. The action was received, understood and accepted
3xx
style response is a redire­ction response. Further action needs to be taken in order to complete the request
4xx
style response is a 'client error' response. For some reason, such as bad syntax, the request cannot be fulfilled at this server.
5xx
style response is a 'server error' response. For some reason, the server cannot fulfill a valid request.
6xx
style response is a 'global error' response. The request being made is invalid at any server.

Mini Quizlet

Which 'Method' is an extension to SIP that allows the transfer of Instant Messages?
MESSAGE

SIP Header - INVITE

The header indicates the method type. eg INVITE, the SIP URI of the target UA and SIP version 2.0

Via shows the layer 4 transport protocol to use, eg UDP, IP address, and port where the respnse is to be sent back to. eg. senders gateway 82.36.8­9.7­8:2051

branch - parameter is used to uniquely identify this transa­ction and should not change

From shows the details of the Caller and Callers SIP URI, it's the callers Caller ID

INVITE

To shows the details of the Called party

Call-Id is a globally unique ID for this particular dialog. It will be the same for all request and response transa­ctions within this dialog.

CSeq is used to indentify and order transa­ctions. eg. sequence 1 and method INVITE. Each of the parties in a call will maintain their own Cseq numbers and these numbers and these numbers increment for every successive command in a call. 70 is the recomm­ended default value.

Max-Fo­rwards field is used to limit the number of proxies or gateways that can forward the request to the next downstream server. eg. 70 will be decrem­ented by each server that forwards the request.

Contact shows the SIP URI that can be used to contact this agent with subsequent requests

User-Agent indicates telephone modem, firmware version, MAC address

If the Accept field is not present the receiving server should assume applic­ati­on/sdp

The Allow field lists the set of methods supported by the UA generating the message.

Allow-­Events details some basic events that the UA supports. eg. Talk, Put on Hold, and Refer (or Transfer) a call or session.

Sessio­n-E­xpires header conveys the session interval for a SIP call. It is placed in an INVITE request and is allowed in any 2xx response to an INVITE eg. 3600 seconds or 60 mins.

Conten­t-Type describes the body content, which is app and the type which is sdp

Content Length is the length of the SDP body in bytes
 

SIP HEADER - 200 Response

Via headers are inserted by servers into requests to detect loops and to allow responses to find their way back to the client VIA the server

Call-info field provides additional info about the called party.

Record­-route details are inserted by the proxy to 'force' future requests in this dialog to be routed through the proxy. eg 217.10.79.23

SIP HEADER

Supported and Require Headers

Supported allows a client to inform a server what features it supports. eg. timer, 100rel

Require - what the server requires the client to support. eg. timer

Session timers

Session timers allows the refreshing of a SIP session period­ically using SIP re-INVITES or UPDATES messages.
'REFRESH' allows user agents and proxies to keep a session alive and also allows the status of the session to be determined and released if not active. This can be useful when a call has been ended but a BYE not been sent. eg. a lost connection
SE - session expires
RFC 4028 defines session timers
Sessio­n-E­xpires is the upper level of time for the session
Min-SE is the minimum a server will actually allow
If a Refresh is not received before the timer expires, the session is ended.
The refresher in charge of sending the updates can be the server or client and is shown in the 200OK that completes the session setup
Refreshes are sent halfway through the session interval
The recomm­ended Sessio­n-E­xpires value in RFC4028 is 1800 seconds or 30 minutes.

100rel

When a SIP device responds to a request the response can be
Final - 200 OK
Decline - 603 - a final result to a transa­ction which is acknow­ledged
Provis­ional - such as 180 Ringing - are not acknow­ledged by default but desirable especially when commun­icating with the PSTN
SIP PRACK method provides reliab­ility and to show support for this feature a SIP device will add the 100rel parameter to the supported header
If the recipient does not support 100rel it must reject with a 420 resonse and state in the header that 100rel is unsupp­orted
PRACK can be used with all 1xx style responsed except 100 trying.
Responses are acknow­ledged to ensure better reliab­ility for a transa­ction

Short form /compact headers

Mini Quiz

What does code 180 mean?
RINGING
A '200' code indicates a successful event
True
What SIP Method will the SIP soft phone need to send to the ITSP in order to be ready to make calls
REGISTER

SDP

SDP stands for Session Descri­ption Protocol and is detailed in the RFC 4566
It is used to handle the session negoti­ation process with a SIP transa­ction
An SDP packet is often carried as the message body of a SIP request
Part of a SIP INVITE request, an SDP offer is made detailing a number of charac­ter­istics that define the proposed media session such as codec type, contact inform­ation, and ports to be used.
The response to this acknow­ledges accept­ance, offers altern­ative session parame­ters, or declines the proposed session with no altern­atives offered.
MIME (multi­purpose internet mail extens­ions) is used to define what is in the body of a SIP message
The entry,Conten­t-Type: applic­ati­on/sdp defines that an agent would need to support the applic­ation layer protocol SDP in order to setup a session.

Call dialogs

E.g. IF Lynda answers her mobile and desk phone, you will have 1 conversion or call and 2 call legs.

A call leg in RFC 2543 refers to the signaling relati­onship between two user agents (UAs) but this is now referred to as a 'dialog' in the replac­ement of RFC 3261.

In a SIP INVITE, a dialog is identified by a call identi­fier, local tag, and remote tag.

In an initial call setup, the From field has a tag at the end of the field. The To field only contains the SIP URI, no tag as yet.

Trace example

The 200 OK contains, the unique caller id, CSeq value, and tag on called to and the unique tag on calling number.

SIP mobility

branch ID
Introduced in RFC 3261 and are used by servers ans systems to help them differ­entiate all of the dialogs that they may be involved in.
 
All branch IDs start with z9hG4bk

Mini Quizlet

The Contact field is found in the SDP body of a SIP message.
False

Call forward to voicemail

The proxy knows about the call forward setting, sends a message to the calling device to notify it of the call forwarding setting.

The proxy rewrites the INVITE and sends it to the voicemail server. This server then responds and a media path is establ­ished so the caller can leave a message.

When the called hangs up the VM sends a NOTIFY sip message that will make the MWI indication on the phone light up.

SIP Call forward - No answer

Proxy sends an INVITE to a device which rings and responds back to the proxy. After a config­urable timer has expired on the proxy, the proxy sends a cancel to the device that responds and then the proxy sends an INVITE to the call forward number the proxy has for the user.

Replaces header

Replaces header

Replaces is used for attended call transfer, call park. RFC3891.
1. Operator calls the call center
2. Get a 182 response. Operator transfer customer to the call center using REFER method.
3. Customer issue an INVITE with the replaces header to take the operators place in the queue. From entry changes to the customer with his own unique tag. The Replaces header shows the replaced call ID and the tags used in the transa­ction between the operator and the call center.
4. The call center then sends the 182 message to the customer.

Diversion headers

In this scenario, call is forwarded on no answer and the new Diversion header will contain the detail of where the call has been diverted from along with a reason.

Stateless proxy

Extending SDP

Stateful proxy

The proxy can receive all respond from possible destin­ations and send back only the approp­riate 200 response without mainta­ining state an agent would have sent 3 invites and maybe received the errors before the live agent could respond, resulting in call setup failure.

Proxy

Transa­ctional
Super Stateful

VIA and Record­-route

Via and Record­-route entries can help prevent 'loops' and can govern the path a SIP message takes.

VIA Details

VIA records are added to a SIP message as follows

VIA Details

VIA headers are used by proxies to see if any looping of the message has occurred. If they receive a message that includes their own IP address in a VIA record a 482 (Loop detected) response is returned to the sender

SIP call forking - parallel

With call forking in 'parallel mode', the SIP proxy receiving the INVITE will discover via the location server that you have two current locations. It will send an INVITE to both locations at the same time

Both locations will ring and the proxy will notify the caller of this. In this example, the desk phone answers and sends a 200 OK message to the proxy. The proxy forwards the 200 OK to the caller and send a cancel message to the softphone to stop ringing.

SIP call forking - sequential

Sequential call forking is when the Proxy tries to contact the SIP devices registered for a user in order, one at a time. eg. the 1st device returns a 302 moved response that will then allow the proxy to move on and try the next device on it's list. In reality, the Proxy will probably be commun­icating with a destin­ation proxy that will respond saying that the device user has moved not the end device.

SDP component in a SIP message

SIP header generally describes who is making the call and where the destin­ation agent is.

The SDP section lists all the detail required in order to setup a successful media connection such as a voice or video media stream.

The Called agent can decide to accept or reject the session. To reject the session, the called agent responds with a port setting of 0, to accept it responds with it's own SDP details in a SIP 200 Response. After this media can be exchanged.

SDP Detail

SDP Detail

Sip INVITE version number of 0
o or origin entry, displays the username of 'root' and session identi­fiers along with the IP v4 IP address
s or session name field allows for a call descri­ption
c is connection inform­ation for calling party to return all messages to.
t Timer values (start and stop) are usually set at 0 and 0 allowing the calls to have no timer bounda­ries.
m for media shows the media type, eg AUDIO.
Port 60106 - the port the UA can receive audio on
RTP/AVP - the Real-time protocol / Audio Video profile codecs that this UA is offering the destin­ation device to choose to use.
One of these is Codecs, 18, is G729 **a=rt­pmap:18 g729/8000

SDP Detail - reply

SDP Detail - reply

v=0
reply shows the same version of 0
"­o" owner
An owner 'username' of root, the sessions IDs along with the source IP address
s=
descri­ption of 'SIP Call'
e=
optional piece of info of the contact email addres of agent
a=
E.164 number of this agent, the contact details, time values and the media type that this device has chosen from the list offered by the caller, eg 18 -- G729

Multiple 'm' lines

multiple 'm' lines - The SDP INVITE element shows the m=auio element for the voice including port info and the m=video element details the port and other requir­ements for the video. When the calling received the 200 OK to both elements the voice and video channels are set up.

Changing session parameters

A session can be modified after it is started by changing the session parameters through SDP with methods such as re-INVITE or UPDATE
Adding a new stream such as video to a voice conver­sation
Removing a stream
Changing codecs from uncomp­ressed G.711 to compressed G.729
Changing address info
Putting a call on hold
Set up a call conference

SDP Example - Put a call on Hold

The re-invite message includes the hold command

SDP - Call hold trace

To put a call on hold, the holding device sends connection details of an IP address of 0.0.0. and an audio setting of sendonly which the receiving device responds back with recvonly. Press hold to re-est­ablish the media stream resends the approp­riate connection IP address along with the sendrecv attribute. The receiving device responds with sendrecv and two way audion is reesta­bli­shed.

Call hold - old and new methods

RFC 2543
placing a user on hold is accomp­lished by setting the connection address to c=0.0.0.0
RFC 3264
discou­rages the use of c=0.0.0.0. Extends options available with the following attibutes.
RFC 3264 attributes
*
sendrecv
used to establish a 2-way media stream
recvonly
the SIP endpoint would only receive (listen mode) and not send media
sendonly
The SIP endpoint would only send and not receive media
inactive
The SIP endpoint would neither send nor receive media.

INVITE and reINVITE

INVITE and reINVITE

Resent /Retra­nsm­itted INVITE
contains the same Call-ID and CSeq value as a previous INVITE and is normally sent to the proxy if a '100 trying' has not been received
reINVITE
A re-INVITE is used to change the session parameters of an existing or pending call. It uses the same Call=ID, but the CSeq value is increm­ented because it is new request

SIP mobility

SIP mobility allows freedom to have calls redirected to the location you are currently at and to the device you want to receive calls on.
  

Module Quiz

It is the SIP user agent server (UAS) that initiates a SIP call
False
SIP
Session Initiation Protocol
At what TCP/IP layer would you find the SIP protocol
applic­ation
SIP proxy sever will always relay media as well as SIP messages on behalf of a SIP UAC
False
Valid URI addresses
Can contain +,-,na­me,­starts wit sip:
After a successful REGIST­RATION
A 200 code is sent
Main charac­ter­istics of a SIP location server
1. The LOCATION service usually coexists on the same server as the REGISTRAR service2. It can utilize external databases such as DNS
SIP Request methods
REGISTER, UPDATE, CANCEL, INVITE
SIP Response code types
Response code - moved tempor­arily
302
VIA element of a SIP message can be found in the SDP body
False
SIP response, elements from the initial SIP message ar copied exactly
Via, From, To, Call-ID, and CSeq are copied exactly from Request. To and From are NOT swapped
A SIP device needs to send SDP element in order to negotiate the codec to use with the 'called' SIP device
True
Sequential SIP 'Call Forking' implies a proxy will 'call' you SIP registered devices one after the other until one is answered
True
A SIP UAS will try to use the location details in a certain preferred order to get a Request to a SIP UA as part of a dialog
Route, Contact, From
Call Flow
B2BUA
Back to Back User Agent
If you move your SIP device and it does not reregister with the REGISTRAR server it will be able to locate the SIP device using DNS
False

The Call process

B2BUA benefits and features

Centri­alized management of all calls
PBX call managment features such as call transfer, forwarding and automatic call discon­nection to warn a user that credit is low.
Billing functi­onality
Call confer­encing facilities
The ability to 'hide' the network such as private IP address schemes and the underlying network topo from scanning attempts
The ability to connect two different types of signalling networks such as SIP and H323 for coexis­tence during a migration to a fully SIP based network
Implement and enforce policies such as class of service and restri­ction

B2BUA

Back-2­-Back user agent is a 4th type of server. Others are proxy, registrar, and redirect. Can act as standalone proxy

The B@BUA maintains the complete call state and continues to send requests and responses for sessions in which it is involved.

SIP code and PSTN mapping

SIP to PSTN call flow

PSTN
public switched telephone network
ISUP
Integrated services digital network user part
IAM
Initial address message
NPI
numbering plan indicator
PRACK 183
provis­ional acknow­led­gement
180
ringing
The gateway convert the RTP media to TDM media for the PSTN.

SIP to PSTN call flow

Multiple MIME parts

A SIP message can actually contain multiple MIME parts, but there needed to be a set boundary defined to separate each of these parts. Boundary 1 separates the usual info in the SDP body and then following the next boundary marker is a gif image.

MIME

MIME
multip­urpose Internet Mail extensions
MIME
was defined to provide a way of attaching different document/ file types to email messages. SIP takes advantage of this existing standart by using it to inform a UR what content is present in a SIP message
Conten­t-type: applic­ation/ SDP
tells us that the MIME content of the SIP message is the applic­ation layer protocl SDP. The UA, if support SDP, can interpret the SDP info in the message to find out details such as codecs supported in the inviting agent and prot numbers for responses.
Content is described as
Conten­t-type: <ty­pe>­/<s­ubt­ype>

Routing

ACK message needed to end up at the SIP gateway. The Reques­t-URI is the sip URI of the called number + the IP address of the gateway of the SIP provider
The messag is sent to the top of the Route list, the IP address of the SIP server
When the SIP server checks to see if the Request URI is something it is resonsible for or owns compares its IP address with the first route record, rewrites the ACK message which is then sent to the Billing server
Billing server does its own checks and removes the route record and tthen forwards the ACK based on the info in the request URI, the gateway
Loose routing - The way SIP servers leave the Request URI alone and use the route records to route, RFC 2543

Routing

Routing example

200 OK response have VIA records that were included in the INVITE removed. Only the VIA record for the UA A phone is included.

There are also 2 record­-route records that were added to the INVITE message by the SIP and Billing servers on the ways out. Record - Route records are never deleted.

Contact element changed to represent the SIP provider gateway and will be used in the ACK to be sent

Routing

1. 192.16­8.1­00.31 calls 084574­45445 which generates a SIP INVITE
2. The domain name of UA A service provider is appended to create the Request URI
3. VIA Header is added to by UA A along with its local LAN contact details
4. Contact field is populated with the Live contact deails, eg UA A phone number + the IP addres­s/port combo of the outside edge of my network.
4. To, who UA A is calling
5. From, UA A phone details

Routing

Record­-route defined

Route and Record­-Route header fields have a slightly different purpose >-- they are used to route _requests_
User agent A with IP address 1.2.3.4 sends an INVITE request to the proxy which forwards the request to user agent B. UA A adds the Contact header field in the request. The Contact header field tells UA B that it can reach UA A on IP 1.2.3.4. UA B adds a Contact header field to 200 OK reply, telling UA A that it can reach B on IP address 5.6.7.8. This way both user agents exchange their IP addresses and they do not need the proxy anymore. They can easily send all further SIP messages directly to each other, because they remember the IP address of the remote party from Contact header field. This way all further requests would bypass the proxy server.
There are many cases where the proxy server needs to see _all_ future SIP messages exchanged between the user agent, such as for accoun­ting. In this case the proxy server needs tell the user agents that they should not exchange future SIP messages direct­ly,but they should relay them through the proxy again.
The proxy server can do this by inserting Record­-Route header field in the INVITE message. The Record­-Route header field contains the IP address of the proxy and once the INVITE message reaches UA B, it extracts the IP address of the proxy server from Record­-Route header field and store it in memory along with the IP address of the remote party (UA A). So UA B knows the IP address of UA A and it also knows that it should send all future requests to UA A through the proxy server.
UA A should also send all future SIP requests to UA B through the proxy server, but it does not know it yet, because the proxy server added Record­-Route header field to the INVITE message which will only reach UA B. UA B has to tell UA A that all future SIP requests should be sent through the proxy, and it does so by copying all Record­-Route header fields from the INVITE message to 200 OK which is sent from UA B to UA A. UA A will then extract Record­-Route header fields along with Contact from 200 OK and store it in memory. At this point both user agents know the IP address of the remote party and that they should relay all SIP messages through the proxy.
When UA A wants to send an ACK to UA B. It will lookup the IP address of the remote party (Contact from 200 OK) from memory and put it in the Reques­t-URI of ACK. The reason why ACK does not have the same Reques­t-URI as the original INVITE is that the ACK should be sent to the user agent instance that generated 200 OK -- the Reques­t-URI from the INVITE would fork if user B had several user agents and this is not desirable for ACKs.
The URI based on Contact header field never forks, it is delivered only to the UA instance that generated 200 OK. UA A will also find the URI from the Record­-Route header field in memory (stored along with the contact of the remote party). It will create a Route header field, put the URI in it and append it to the ACK.

Record­-route / VIA defined

Endpoint A sends a request say INVITE to proxy1, proxy1 forwards it to proxy2 and proxy2 gives that INVITE to endpoint B. Each proxy adds its Record­-route at the start of the record­-route header, when called party gets request, last proxies record­-route token is the at the start of record route header. Unlike Via, the record route is not deleted by respective proxies in return path. At calling party, whole record route is received.
When the request is arrived at UAS, the route set is prepared from record­-route header taken in order. If record­-route is absent, route set is set to NULL.
When the response received at UAS, route set is prepared at UAS by taking RR in reverse order.
In next transa­ctions because of Route set request URI may be affected. If route set is empty, the UAC must place remote target URI into the Reques­t-URI.
If first route URI in route set contains lr parameter (loose routing), then reques­t-URI is not affected.. However if first route URI does not contain lr parameter, then UA should put the first route to reques­t-URI, then put the route set in order, and finally adds remote target to Route header at the end.
VIA is used by UAS to to determine target to send immediate response. All proxies in path adds corres­ponding Via at the start of Via header. Say there are N proxies. So Via at called party looks at proxy(­n).v­ia­;pr­oxy­(n-­1).v­ia.... Callin­g-p­hon­e-via
So when UAS responds back, it sends all Via without any modifi­cation. Now each proxy deletes its corres­ponding via, finally when response is received at endpoint , endpoint sees its own via only.

Record­-route defined

When sending a Request message, which is used?
Route
Contact (if there is no route)
From (if there is no contact)