Basic Call Flow of A SIP Session

The following image shows the basic call flow of a SIP session.
Given below is a step-by-step explanation of the above call flow
An INVITE request that is sent to a proxy server is responsible for initiating a

session.
The proxy server sendsa 100 Trying response immediately to the caller (Alice)
to stop the re-transmissions of the INVITE request.
The proxy server searches the address of Bob in the location server. After
getting the address, it forwards the INVITE request further.
Thereafter, 180 Ringing (Provisional responses) generated by Bob is returned

back to Alice.
A 200 OK response is generated soon after Bob picks the phone up.
Bob receives an ACK from the Alice, once it gets 200 OK.
At the same time, the session gets established and RTP packets (conversations)
start flowing from both ends.
After the conversation, any participant (Alice or Bob) can send a BYErequest to
terminate the session.
BYE reaches directly from Alice to Bob bypassing the proxy server.
Finally, Bob sends a 200 OK response to confirm the BYE and the session is
terminated.
In the above basic call flow, three transactions are (marked as 1, 2, 3)

available.
The complete call (from INVITE to 200 OK) is known as a Dialog.
SIP messages are of two types requests and responses.
The opening line of a request contains a method that defines the request, and a
Request-URI that defines where the request is to be sent.
Similarly, the opening line of a response contains a response code.
Request Methods
SIP requests are the codes used to establish a communication. To
complement them, there are SIP responses that generally indicate
whether a request succeeded or failed.
These SIP requests which are known as METHODS make SIP message
workable.
METHODS can be regarded as SIP requests, since they request a specific action
to be taken by another user agent or server.
METHODS are distinguished into two types

o
Core Methods
Extension Methods
Core Methods
There are six core methods as discussed below.
INVITE
INVITE is used to initiate a session with a user agent. In other words, an
INVITE method is used to establish a media session between the user
agents.
INVITE can contain the media information of the caller in the message body.
A session is considered established if an INVITE has received a success

response(2xx) or an ACK has been sent.
A successful INVITE request establishes a dialog between the two user agents
which continues until a BYE is sent to terminate the session.
An INVITE sent within an established dialog is known as a re-INVITE.
Re-INVITE is used to change the session characteristics or refresh the state of a

dialog.
INVITE Example
The following code shows how INVITE is used.
INVITE sips:Bob@TMC.com SIP/2.0
Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9
Max-Forwards: 70
From: Alice<sips:Alice@TTP.com>;tag = 1234567

To: Bob<sips:Bob@TMC.com>
Call-ID: 12345601@192.168.2.1
CSeq: 1 INVITE
Contact: <sips:Alice@client.ANC.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
v=0
o = Alice 2890844526 2890844526 IN IP4 client.ANC.com
s = Session SDP
c = IN IP4 client.ANC.com
t = 3034423619 0
m = audio 49170 RTP/AVP 0
a = rtpmap:0 PCMU/8000
BYE
BYE is the method used to terminate an established session. This is a SIP
request that can be sent by either the caller or the callee to end a session.
It cannot be sent by a proxy server.
BYE request normally routes end to end, bypassing the proxy server.
BYE cannot be sent to a pending an INVITE or an unestablished session.
REGISTER
REGISTER request performs the registration of a user agent. This request is
sent by a user agent to a registrar server.
The REGISTER request may be forwarded or proxied until it reaches an

authoritative registrar of the specified domain.
It carries the AOR (Address of Record) in the To header of the user that is being
registered.
REGISTER request contains the time period (3600sec).
One user agent can send a REGISTER request on behalf of another user agent.
This is known as third-party registration. Here, the From tag contains the
URI of the party submitting the registration on behalf of the party identified in
the To header.
CANCEL
CANCEL is used to terminate a session which is not established. User agents
use this request to cancel a pending call attempt initiated earlier.
It can be sent either by a user agent or a proxy server.
CANCEL is a hop by hop request, i.e., it goes through the elements between
the user agent and receives the response generated by the next stateful
element.
ACK
ACK is used to acknowledge the final responses to an INVITE method. An
ACK always goes in the direction of INVITE.ACK may contain SDP body
(media characteristics), if it is not available in INVITE.
ACK may not be used to modify the media description that has already been
sent in the initial INVITE.
A stateful proxy receiving an ACK must determine whether or not the ACK
should be forwarded downstream to another proxy or user agent.
For 2xx responses, ACK is end to end, but for all other final responses, it works
on hop by hop basis when stateful proxies are involved.
OPTIONS
OPTIONS method is used to query a user agent or a proxy server about its
capabilities and discover its current availability. The response to a request
lists the capabilities of the user agent or server. A proxy never generates an
OPTIONS request.
Extension Methods
Subscribe
SUBSCRIBE is used by user agents to establish a subscription for the
purpose of getting notification about a particular event.
It contains an Expires header field that indicates the duration of a subscription.
After the time period passes, the subscription will automatically terminate.
Subscription establishes a dialog between the user agents.
You can re-subscription again by sending another SUBSCRIBE within the dialog
before the expiration time.
A 200 OK will be received for a subscription from User.
Users can unsubscribe by sending another SUBSCRIBE method with Expires

value 0(zero).
NOTIFY
NOTIFY is used by user agents to get the occurrence of a particular event.
Usually a NOTIFY will trigger within a dialog when a subscription exists
between the subscriber and the notifier.
Every NOTIFY will get 200 OK response if it is received by notifier.
NOTIFY
contain
an Event header
field
indicating
the
event
and
asubscriptionstate header field indicating the current state of the subscription.
A NOTIFY is always sent at the start and termination of a subscription.
PUBLISH
PUBLISH is used by a user agent to send event state information to a
server.
PUBLISH is mostly useful when there are multiple sources of event information.
A PUBLISH request is similar to a NOTIFY, except that it is not sent in a dialog.
PUBLISH
request
must
contain
an Expires header
field
and
a Min-
Expires header field.
REFER
REFER is used by a user agent to refer another user agent to access a URI
for the dialog.
REFER must contain a Refer-To header. This is a mandatory header for REFER.
REFER can be sent inside or outside a dialog.
A 202 Accepted will trigger a REFER request which indicates that other user
agent has accepted the reference.
INFO
INFO is used by a user agent to send call signalling information to another
user agent with which it has established a media session.
This is an end-to-end request.
A proxy will always forward an INFO request.
UPDATE
UPDATE is used to modify the state of a session if a session is not
established. User could change the codec with UPDATE.
IF a session is established, a re-Invite is used to change/update the

session.
PRACK
PRACK is used to acknowledge the receipt of a reliable transfer of
provisional response (1XX).
Generally PRACK is generated by a client when it receive a provisional response

containing an RSeq reliable sequence number and asupported:100rel header.
PRACK contains (RSeq + CSeq) value in the rack header.
The PRACK method applies to all provisional responses except the 100 Trying
response, which is never reliably transported.
A PRACK may contain a message body; it may be used for offer/answer

exchange.
MESSAGE
It is used to send an instant message using SIP. An IM usually consists of
short messages exchanged in real time by participants engaged in text
conversation.
MESSAGE can be sent within a dialog or outside a dialog.
The
contents
of
MESSAGE
are
carried
in
the
message
body
as
a MIMEattachment.
A 200 OK response is normally received to indicate that the message has been
delivered at its destination.
SIP traces provide key information in troubleshooting SIP Trunks, SIP

endpoints and other SIP related issues. Even though these traces are in clear
text, these texts can be gibberish unless you understand fully what they
mean.
This document attempts to break down each component of the SIP
interaction using a practical approach. We will look at various logs, the SIP
messages, headers, SDP information and try to figure out what is going on in
a sip voice call transaction.
In as much as I will try to define the under lying layer of the SIP messaging,
this document will not go into in-depth analysis of the SIP protocol, so it is
advisable to understand SIP protocol technology to be able to understand sip
traces.
One key element of troubleshooting is this: To fix a problem, you need to
understand the issue, how it works before you can restore it to order.
One popular debug used in troubleshooting a sip solution on a cisco IOS
router is
Debug ccsip messages.
To understand The output generated by this debug..We need to understand

the Key/fundamental sip messages exchanged during a sip voice call..
1. Invite
2. Trying
3. Ringing
4. ACK
5. OK
We will look at these messages as we try to understand the debugs. These

messages are key in knowing whats going on. They help us to understand
the language been spoken so we are not lost like a non French speaking man
in Paris!
Ok enough of grammars, lets dive in! Ready?
INVITE:
An Invite is a SIP requests called methods. There are Six SIP methods
described in the SIP specification document RFC 3261 [1].
The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the
original six methods
in SIP.
The INVITE method is used to establish media sessions between user agents.
In
telephony, it is similar to a Setup message in ISDN
An INVITE usually has a message body containing the media information

of the caller. The message body can also contain other session information,
such
as a resource list in the case of an early offer. If an INVITE does not contain
media information, the ACK contains the media information of the UAC.
To identify the caller, the called number, the media information and
resources advertised in the Invite, SIP invites use headers. Headers are key
parameters within the SIP invite and we shall look at them so as to gain full
clarity of whats going on.
Lets look at a sample SIP trace from CUCM. Note this is very similar to what
a debug ccsip messages will produce on a CUBE gateway.
Here is the call setup for this trace
CUCM----------sip trunk------>CUBE---------SIP Trunk--------------->ITSP
(10.105.80.114)
(10.105.80.174)
INVITE with SDP.
INVITE sip:14107154522807@10.105.80.174:5060 SIP/2.0
Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6

From: "Solihull" <sip:01214248526@10.105.80.114>;tag=25526~ffa809265fac-4dd6-b405-2dbbc56ae9a2-551664735
To: <sip:14107584528207@10.105.80.174>
Date: Mon, 02 Apr 2012 18:12:31 GMT
Call-ID: 68781700-f791ec0f-2d26-e28690a@10.105.80.114
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:10.105.80.114:5060>;method="NOTIFY;Event=telephoneevent;Duration=500"
Cisco-Guid: 1752700672-0000065536-0000007823-0237529354
Session-Expires: 84600
Contact: <sip:01214248526@10.105.80.114:5060>
Max-Forwards: 70
Content-Length: 0
Content-Length: 238
v=0
o=CiscoSystemsCCM-SIP 811669 1 IN IP4 10.105.40.14
s=SIP Call
c=IN IP4 10.133.92.102
t=0 0
m=audio 25268 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Now lets break it up or dissect this piece of information.
As we can see there are lots of headers in this invite
Via
To
From
Call-ID
CSeq
Contact
Max-Forwards
Expires
The INVITE header
INVITE sip:14107584528207@10.105.80.174:5060 SIP/2.0

This is the first part of the trace usually refrred to as the Request-URI This
shows four key things
1. The called number
2. The device responsible for the called number or the device through which
the called number will be routed
3. SIP Port number
4. Sip Version..
So here we see the called number is: 14107584528207
The gateway responsible for routing to this number is 10.105.80.174
SIP port is 5060 and the Sip version is 2.0
The Via Header:
Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6
The required Via header field is used to record the SIP route taken by a
request
and is used to route a response back to the originator. A UA generating a
request
records its own address in a Via header field.
Here we see that CUCM is the UA generating this invite and it stamps it IP on
the call. This helps identify the origin of the call.
Via header fields contain protocol name, version number, and transport
(SIP/2.0/UDP, SIP/2.0/TCP, etc)
The Via header contains what is called the sent-by field. The image below shows the sent by
field and this is where the required response will be sent to.
via.png
In SIP responses follow the via header except for future requests like ACK and BYE where
responses are sent to the contact header
The To and From Headers

From: <sip:01214248526@10.105.80.114>;tag=25526~ffa80926-5fac-4dd6b405-2dbbc56ae9a2-551664735
To: sip:14107584528207@10.105.80.174
The next header fields are the To and From header fields, which show the
originator and destination of the SIP request.
Note that the To and From header fields are not reversed in the response
message as one might expect them to be. This is because the To and From
header fields in SIP are defi ned to indicate the direction of the request, not
the direction of the message. Since <sip:01214248526@10.105.80.114
initiated this request, all responses to this INVITE will read
To: sip:14107584528207@10.105.80.174
From: <sip:01214248526@10.105.80.114.
Date Header:
A key component of the sip message. Its tells us the time of the sip request.
Call ID:
Call-ID: 68781700-f791ec0f-2d26-e28690a@10.105.80.114
The Call-ID header field is an identifier used to keep track of a particular SIP
session. The originator of the request creates a locally unique string. Some
older implementations also add an @ and its host name to the string. The
initiator of the session that generates the establishing INVITE generates the
unique Call-ID and From tag.
The Call ID is one of the key components used in troubleshooting. Each UA

generates its own Call ID. Sowhen a call originates from CUCM, CUCM
generates its own call id and when a call origate from the CUBE, CUBE
generate its own call ID.
Cseq Header:
CSeq: 101 INVITE
The command sequence CSeq header field is a required header field in every
request. The CSeq header field contains a decimal number that increases for
each request. Usually, it increases by 1 for each new request, with the
exception of CANCEL and ACK requests, which use the CSeq number of the
INVITE request to which it refers. The CSeq count is used by UASs to
determine out-of-sequence requests or to differentiate between a new
request (different CSeq) or a retransmission (same CSeq). The CSeq header fi
eld is used by UACs to match a response to the request it references
User Agent Header:
User-Agent: Cisco-CUCM8.6
This header identifies the UA that is originating this request/response. In this

trace we can see that the UA above is CUCM version 8.6.The user agent
header helps identify the originator of the request/response.
SDP Extensions and Attributes
The SDP extensions used in the application/SDP header lists the media
capabilities the calling party is willing to receive or negotiate or support for
the session. The table below shows the SDP attributes in this test call and
the meaning of each attribute/extension. Please note that The RFC 3264[17]
specifies that the attributes containing a=rtpmap should be used for each
media field
SDP Parameter Parameter

Name
v=0
o=CiscoSystemsCCM-SIP 811669 1
IN IP4 10.105.40.14
Version Number
Origin
s=SIP Call
c=IN IP4 10.133.92.102
Call Subject
Connection/IP address for RTP
stream
time
Media
Attributes-media
Attributes-Packetization
Dtmf attributes
t=0 0
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephoneevent/8000
a=fmtp:101 0-15
Dtmf tones
Lets look at media attributes below
m=audio 25268 RTP/AVP 18 0 8 101
This line defines the media attribtes that will be used for the call.
Audio:
means that this is an Audio call, we can also have
m=video in case of a Video call
25268:
Is the dynamic RTP port used for the call
RTP/AVP:
Represents the RTP/AVP profile number for each of the
profiles listed. The profile numbers are explained below
18=G729
0=PCMU
8=PCMA
101=rtp-nte payload
DISSECTING A SIP TRACE
Now we have looked at the basics of sip headers and messages, lets use this
to understand the following sip trace
The call flow for this call is as shown:
PSTN-------->ITSP------->CUBE--------------->CUCM---------------->IP PHONE
ITSP: 10.10.33.132
CUBE:10.100.0.74
CUCM:10.100.0.14
1. An inbound call is received on the CUBE from the ITSP. This invite was sent
with SDP. NB that this inbound leg of this call will have a unique call ID that
shows the origin of the call, highlighted below.
Received:
INVITE sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-
1338998848384To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267841 INVITE
Contact: <sip:07455900064@10.10.33.24:5070;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: multipart/mixed,application/media_control+xml,application/sdp
Supported:
Max-Forwards: 69
Content-Length: 207
v=0
o=BroadWorks 161384582 1 IN IP4 10.10.33.132
s=c=IN IP4 10.10.33.132
t=0 0
m=audio 11164 RTP/AVP 18 0 8 101
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
+++From our understanding of the traces, we see that the call originates
from a device called Broadworks, which advertises G711a, G711u, G729 and
uses rtp-nte for DTMF. We also see the IP address for the CUBE to stream its
RTP to.+++++
2. A new Invite Sent to CUCM.

After the CUBE receives the invite, it sends an invite to cucm based on the
dial-peers configured.
NB: that this new invite is sent with a new CALL-ID. This is very important in
understanding the order of thigs especially when troubleshooting issues. We
can also see that the CUBE advertises all its SDP attributes, codec, dtmf
supported, fax etc.
002791: Jun 6 16:07:28.394: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:901926653485@10.100.0.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859

Remote-Party-ID: <sip:07455900064@10.100.0.74>;party=calling;screen=no;privacy=off
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2352544350-2938638817-2514718541-1568562753
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1338998848
Contact: <sip:07455900064@10.100.0.74:5060;transport=tcp>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 68
Content-Disposition: session;handling=required
Content-Length: 355
v=0
o=CiscoSystemsSIP-GW-UserAgent 8773 2764 IN IP4 10.100.0.74
s=SIP Call
c=IN IP4 10.100.0.74
t=0 0
m=audio 19264 RTP/AVP 18 0 8 100 101
c=IN IP4 10.100.0.74
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=fmtp:101 0-15
3. Next the CUBE sends a trying to ITSP. Trying simply means: I am looking
for the number you have requested.

Sent:
SIP/2.0 100 Trying

From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=15264387271338998848384To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID:
BW1807283840606121067600210@212.136.178.216

Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
4. Next the CUBE receives a trying from CUCM. The call-ID help us to know
where these responses are coming from.
Received:
SIP/2.0 100 Trying
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>
Date: Wed, 06 Jun 2012 16:07:28 GMT
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
5. Next the CUBE receives ringing from CUCM This informs the CUBE that the
called endpoint is ringing
Received:
SIP/2.0 180 Ringing
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2477917854
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID:
8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
CSeq: 101 INVITE

SUBSCRIBE, NOTIFY
Allow-Events: presence
Content-Length: 0
6. The CUBE relays this message to the calling party

Sent:
SIP/2.0 180 Ringing
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=15264387271338998848384To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>;tag=4C85763E-1CF8
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID:
BW1807283840606121067600210@212.136.178.216

Remote-Party-ID: <sip:901926653485@10.100.0.74>;party=called;screen=no;privacy=off
Contact: <sip:901127653485@10.100.0.74:5060>
Content-Length: 0
7. Now the CUBE receives a 200 ok from CUCM. Please note that some
elements of the SDP has changed
c=IN IP4 10.100.20.10------------------------IP address to send RTP stream to
t=0 0 -------------------------------------------Duration of the call
m=audio 16730 RTP/AVP 18 101---------Codec to use for call and DTMF type
to use
a=rtpmap:18 G729/8000-------------------Codec = G729

Received:
SIP/2.0 200 OK
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
CSeq: 101 INVITE
SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Session-Expires: 84600;refresher=uas
Require: timer
Content-Length: 237
v=0
o=CiscoSystemsCCM-SIP 811674 1 IN IP4 10.100.0.14
s=SIP Call
c=IN IP4 10.100.20.10
t=0 0
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=fmtp:101 0-15
8. CUBE sends an ACK to CUCM to acknowledge the last 200 Ok message

Sent:
ACK sip:901127653485@10.105.40.14:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953DC95
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
Max-Forwards: 70
CSeq: 101 ACK
Content-Length: 0
9. CUBE then sends a 200 OK to ITSP with the SDP attributes to use for the
Call based on what it received from CUCM.
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.100.0.14:5060;branch=z9hG4bK198a0b7ee5d33c
From: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b4052dbbc56ae9a2-477917854
To: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
CSeq: 101 SUBSCRIBE
Content-Length: 0
Expires: 7200
Sent:
SIP/2.0 200 OK
Date: Wed, 06 Jun 2012 16:07:28 GMT

Call-ID: BW1807283840606121067600210@212.136.178.216
Remote-Party-ID: <sip:901926653485@10.100.0.74>;party=called;screen=no;privacy=off
Contact: <sip:441127653485@10.100.0.74:5060>
Supported: replaces
Supported: sdp-anat
Supported: timer
Content-Disposition: session;handling=required
Content-Length: 270
v=0
o=CiscoSystemsSIP-GW-UserAgent 7413 6169 IN IP4 10.100.0.74
s=SIP Call
c=IN IP4 10.100.0.74
t=0 0
c=IN IP4 10.100.0.74
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=ptime:20
10. CUBE then receives an ACK

002803: Jun 6 16:07:28.594: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0.1
Call-ID:
BW1807283840606121067600210@212.136.178.216
CSeq: 558267841 ACK

Contact: <sip:07455900064@10.10.33.24:5070;transport=udp>
Max-Forwards: 69
Content-Length: 0
11. Finally the call is ended. Now when troubleshooting the direction of call
termination is important. In this case we can see that the CUBE receives a
BYE, which is the sip method for call termination. However who sent the BYE,
is it CUCM or ITSPThe answer is in the Call-ID. As we call can see the CALLID is for the leg from the ITSP. So we see that the call was terminated from
the ITSP side.
Next important thing is the cause code. The reason why the call was
terminated.
CSeq: 558267842 BYE
Reason: Q.850;cause=16
Here we see as normal call clearing Cause=16.
Received:
BYE sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267842 BYE
Max-Forwards: 69
Content-Length: 0
002809: Jun 6 16:07:34.470: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1
Date: Wed, 06 Jun 2012 16:07:34 GMT
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267842 BYE
P-RTP-Stat: PS=295,OS=5900,PR=292,OR=5840,PL=0,JI=0,LA=0,DU=5
Content-Length: 0

Sent:
BYE sip:901127653485@10.100.0.14:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1338998854
CSeq: 103 BYE
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:34 GMT
CSeq: 103 BYE
Content-Length: 0
Below are a few of the Threads that we have used the indepth understanding
of sip trcaes to help resolve thier issues. Please take a look as this will help
you to understand better sip traces and how they play a key part in
troubleshooitng issues
https://supportforums.cisco.com/message/3646952#3646952
Support
...
Troubleshoot and Alerts
Configuration Example and TechNotes
Understanding H.323
Gatekeepers
Download
Print
Download Options
PDF (178.0 KB)
View with Adobe Reader on a variety of devices
Updated:Sep 25, 2014
Document ID:5244
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Gatekeeper Definition
Gatekeeper Zones and Subnets
Gatekeeper Functionality
Mandatory Gatekeeper Functions
Optional Gatekeeper Functions
H.323 Protocol Suite
H.225 RAS Signaling
H.225 Call Control (Setup) Signaling
H.245 Media Control and Transport
H.323 Protocol Suite Overview
H.225 RAS Signaling: Gatekeepers and Gateways
RAS Gatekeeper Discovery
RAS Registration and Unregistration
RAS Admissions
RAS Endpoint Location
RAS Status Information
RAS Bandwidth Control
Gatekeeper-Routed Call Signaling vs Direct Endpoint Signaling
Gatekeeper to Gateways Call Flow

Intra-Zone Call Setup
Inter-Zone Call Setup
Inter-Zone Call Setup with a Directory Gatekeeper
Proxy-Assisted Call Setup
Call Disconnect
H.323 Network Scaling with Gatekeepers
H.225 RAS Protocol Elements Table
Related Information
Introduction
The ITU-T H.323 standard specifies four components:
gateway
gatekeeper
terminal
multipoint control unit (MCU)

This document provides a comprehensive introduction to the functionality and operation of
the gatekeeper in H.323 Voice over IP (VoIP) networks.
Refer to the H.323 Tutorial
for more information on H.323.
Prerequisites
Requirements
Ensure that you use the H.323 Gatekeeper functionality feature, which is denoted as x- on
the Downloads(registered customers only) . For example, a valid Cisco IOS for the Cisco
2600 to act as a gatekeeper is c2600-ix-mz.122-11.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
Refer to the Cisco Technical Tips Conventions for more information on document
conventions.
Gatekeeper Definition
A gatekeeper is an H.323 entity on the network that provides services such as address
translation and network access control for H.323 terminals, gateways, and MCUs. Also, they
can provide other services such as bandwidth management, accounting, and dial plans that
you can centralize in order to provide salability.
Gatekeepers are logically separated from H.323 endpoints such as terminals and gateways.
They are optional in an H.323 network. But if a gatekeeper is present, endpoints must use
the services provided.
Gatekeeper Zones and Subnets

A zone is the collection of H.323 nodes such as gateways, terminals, and MCUs registered
with the gatekeeper. There can only be one active gatekeeper per zone. These zones can
overlay subnets and one gatekeeper can manage gateways in one or more of these subnets.
Gatekeeper Functionality
The H.323 standard defines mandatory and optional gatekeeper functions:
Mandatory Gatekeeper Functions
Address TranslationTranslates H.323 IDs (such as gwy1@domain.com) and E.164

numbers (standard telephone numbers) to endpoint IP addresses.
Admission ControlControls endpoint admission into the H.323 network. In order

to achieve this, the gatekeeper uses these:
H.225 Registration, Admission, and Status (RAS) messages

See the H.225 RAS Signaling: Gatekeepers and Gateways section for more information
about RAS Signaling.
Admission Request (ARQ)
Admission Confirm (ACF)
Admission Reject (ARJ)
Bandwidth ControlConsists of the management of endpoint bandwidth

requirements. In order to achieve this, the gatekeeper uses these H.225 RAS messages:
Bandwidth Request (BRQ)
Bandwidth Confirm (BCF)
Bandwidth Reject (BRJ)

Zone ManagementThe gatekeeper provides zone management for all registered
endpoints in the zone, for example, the control of the endpoint registration process.
Optional Gatekeeper Functions
Call AuthorizationWith this option, the gatekeeper can restrict access to certain
terminals or gateways and/or have time-of-day policies restrict access.
Call ManagementWith this option, the gatekeeper maintains active call

information and uses it to indicate busy endpoints or redirect calls.
Bandwidth ManagementWith this option, the gatekeeper can reject admission

when the required bandwidth is not available.
Call Control SignalingWith this option, the gatekeeper can route call-signaling
messages between H.323 endpoints with the use of the Gatekeeper-Routed Call Signaling
(GKRCS) model. Alternatively, it allows endpoints to send H.225 call-signaling messages
directly to each other.
Note: Cisco IOS gatekeepers are Direct Endpoint Signaling based. They do not support
GKRCS. See theGatekeeper-Routed Call Signaling vs Direct Endpoint Signaling section of this
document.
H.323 Protocol Suite

The H.323 protocol suite is split into three main areas of control:
RAS (H.225) signaling
Call Control/Call Setup (H.225)
Media Control and Transport (H.245) signaling
H.225 RAS Signaling

RAS is the signaling protocol used between gateways and gatekeepers. The RAS channel is
opened before any other channel and is independent of the call setup and media transport
channels.
RAS uses User Datagram Protocol (UDP) ports 1719 (H.225 RAS messages) and 1718
(multicast gatekeeper discovery).
See the H.225 RAS Signaling: Gatekeepers and Gateways section of this document for more
detailed information.
H.225 Call Control (Setup) Signaling

H.225 call control signaling is used to setup connections between H.323 endpoints. The ITU
H.225 recommendation specifies the use and support of Q.931 signaling messages.
A reliable (TCP) call control channel is created across an IP network on TCP port 1720. This
port initiates the Q.931 call control messages for the purpose of the connection,
maintenance, and disconnection of calls.
When a gatekeeper is present in the network zone, H.225 call setup messages are
exchanged either via Direct Call Signaling or GKRCS. See the Gatekeeper-Routed Call
Signaling vs Direct Endpoint Signaling section of this document for more information. The
method chosen is decided by the gatekeeper during the RAS admission message exchange.
If no gatekeeper is present, H.225 messages are exchanged directly between the endpoints.
H.245 Media Control and Transport

H.245 handles end-to-end control messages between H.323 entities. H.245 procedures
establish logical channels for transmission of audio, video, data, and control channel
information. It is used to negotiate channel usage and capabilities such as:
flow control
capabilities exchange messages

A detailed explanation of H.245 is beyond the scope of this document.
H.323 Protocol Suite Overview
H.225 RAS Signaling: Gatekeepers and Gateways

RAS Gatekeeper Discovery
Thisis the processes by which H.323 terminals/gateways discover their zone
gatekeepers Automatic Gatekeeper Discovery:
If an H.323 endpoint does not know its gatekeeper, then it can send a Gatekeeper
Request (GRQ). This is a UDP datagram addressed to the well-known destination port 1718
and transmitted in the form of an IP multicast with the multicast group address
224.0.1.41.
One or several gatekeepers can answer the request with either a positive Gatekeeper
Confirmation (GCF) message or a negative Gatekeeper Reject (GRJ) message. A reject
message contains the reason for the rejection and can optionally return information about
alternative gatekeepers. Auto discovery enables an endpoint to discover its gatekeeper
through a multicast Gatekeeper Request (GRQ) message. Because endpoints do not have
to be statically configured for gatekeepers, this method has less administrative overhead.
A gatekeeper replies with a GCF or GRJ message. A gatekeeper can be configured to
respond only to certain subnets.
Note: A Cisco IOS gatekeeper always replies to a GRQ with a GCF/GRJ message. It never
remains silent.
If a gatekeeper is not available, the gateway periodically attempts to rediscover a
gatekeeper. If a gateway discovers the gatekeeper has gone off-line, it ceases to accept new
calls and attempts to rediscover a gatekeeper. Active calls are not affected.
This table defines the RAS gatekeeper discovery messages:
Gatekeeper Discovery
GRQ (Gatekeeper_Request)
GCF (Gatekeeper_Confirm)
A message sent
by endpoint to
gatekeeper.
A reply from
gatekeeper to
endpoint which
indicates the
transport address
of the gatekeeper
RAS channel.
GRJ (Gatekeeper_Reject)
A reply from
gatekeeper to
endpoint that
rejects the
endpoint's
request for
registration.
Usually due to
gateway or
gatekeeper
configuration
error.
RAS Registration and Unregistration

Registration is the process by which gateways, terminals, and/or MCUs join a zone and
inform the gatekeeper of their IP and alias addresses. Registration occurs after the discovery
process. Every gateway can register with only one active gatekeeper. There is only one
active gatekeeper per zone.
The H.323 gateway registers with an H.323 ID (email ID) or an E.164 address. For example:
EmailID (H.323 ID): gwy-01@domain.com
E.164 Address: 5125551212
This table defines the RAS gatekeeper registration and unregistration messages:
Gatekeeper Discovery
RRQ (Registration_Request)
Sent from an
endpoint to a
gatekeeper RAS
channel address.
RCF (Registration_Confirm)
A reply from the

gatekeeper that
confirms endpoint
registration.
RRJ (Registration_Reject)
A reply from the

gatekeeper that
rejects endpoint
registration.
URQ (Unregister_Request)
Sent from
endpoint or
gatekeeper to
cancel
registration.
UCF (Unregister_Confirm)
Sent from
endpoint or
gatekeeper to
confirm an
unregistration.
URJ (Unregister_Reject)
Indicates that the

endpoint was not
preregistered with
the gatekeeper.
RAS Admissions
Admission messages between endpoints and gatekeepers provide the basis for call
admissions and bandwidth control. Gatekeepers authorize access to H.323 networks with the
confirmation of or rejection of an admission request.
This table defines the RAS admission messages:
Admission Messages
ARQ (Admission_Request)
An attempt by an
endpoint to
initiate a call.
ACF (Admission_Confirm)
An authorization
by the
gatekeeper to
admit the call.
This message
contains the IP
address of the
terminating
gateway or
gatekeeper and
enables the
original gateway
to initiate call
control signaling
procedures.
ARJ (Admission_Reject)
Denies the
request of the
endpoint to gain
access to the
network for this
particular call.
See the Gatekeeper to Gateways Call Flow section of this document for more information.
RAS Endpoint Location

Location Request messages are commonly used between inter-zone gatekeepers in order to
get the IP addresses of different zone endpoints. This table defines the RAS location request
messages:
Location Request
LRQ (Location_Request)
LCF (Location_Confirm)
Sent to request
the gatekeeper
contact
information for
one or more
E.164 addresses.
Sent by the
gatekeeper and
contains the call
signaling channel
or RAS channel
address of itself
or the requested
endpoint. LCF
uses its own
address when
GKRCS is used.
LCF uses the
requested
endpoint address
when Directed
Endpoint Call
Signaling is used.
LRJ (Location_Reject)
Sent by
gatekeepers that
received an LRQ
for which the
requested
endpoint is not
registered or has
unavailable
resources.
See the Gatekeeper to Gateways Call Flow section for more information.
RAS Status Information

The gatekeeper can use the RAS channel in order to obtain status information from
endpoints. You can use the RAS in order to monitor whether the endpoint is online or off-line.
This table defines the RAS status information messages:
Status Information
IRQ (Information_Request)
IRR
(Information_Request_Response)
A status
request
sent from
gatekeepe
r to
endpoint.
Sent from
endpoint
to
gatekeepe
r in
response
to IRQ.
This
message is
also sent
from
endpoint
to
gatekeepe
r if the
gatekeepe
r requests
periodic
status
updates.
The IRR is
used by
gateways
to inform
the
gatekeepe
r about the
active
calls.
IACK (Info_Request_Acknowledge)
Used by
the
gatekeepe
r in order
to respond
to IRR
messages.
INACK
(Info_Request_Neg_Acknowledge)
Used by
the
gatekeepe
r in order
to respond
to IRR
messages.
RAS Bandwidth Control

Bandwidth control is initially managed through the Admission Messages (ARQ/ACF/ARJ)
sequence. However, bandwidth can change during the call. This table defines the RAS
bandwidth control messages:
Bandwidth Control
BRQ (Bandwidth_Request)
A request for an
increase/decrease in
call bandwidth sent
by the endpoint to
the gatekeeper.
BCF (Bandwidth_Confirm)
Sent by the
gatekeeper and
confirms the
acceptance of the
bandwidth change
request.
BRJ (Bandwith_Reject)
Sent by the
gatekeeper and
rejects the
bandwidth change
request.
RAI (Resource Availability

Indicator)
This is used by
gateways to inform
the gatekeeper
whether resources
are available in the
gateway to take on
additional calls.
RAC (Resource Availability

Confirm)
Notification from the

gatekeeper to the
gateway that
acknowledges the
reception of the RAI
message.
Refer to Understanding, Configuring, and Troubleshooting Resource Allocation Indication for

more information about RAI.
Gatekeeper-Routed Call Signaling vs Direct Endpoint Signaling

There are two types of gatekeeper call signaling methods:
Direct Endpoint SignalingThis method directs call setup messages to the

terminating gateway or endpoint.
Gatekeeper-Routed Call Signaling (GKRCS)This method directs the call setup

messages through the gatekeeper.
Note: Cisco IOS gatekeepers are Direct Endpoint signaling based and do not support GKRCS.
These diagrams illustrate the differences between these two methods:
Gatekeeper to Gateways Call Flow

These sections only present Directed Call Signaling call flow scenarios. Also, assume the
gateways have already completed discovery and registration with their gatekeepers.
Intra-Zone Call Setup
Inter-Zone Call Setup
Inter-Zone Call Setup with a Directory Gatekeeper

A major functionality of gatekeepers is to keep track of other H.323 zones and forward calls
appropriately. When many H.323 zones are present, gatekeeper configurations can become
administratively intensive. In such large VoIP installations it is possible to configure a
centralized directory gatekeeper that contains a registry of all the different zones and
coordinates LRQ-forwarding processes. No full mesh is needed between inter-zone
gatekeepers with directory gatekeepers.
Note: A directory gatekeeper is not an industry standard, but is a Cisco implementation.
See the H.323 Network Scaling with Gatekeepers section for more information .
Proxy-Assisted Call Setup
Call Disconnect
H.323 Network Scaling with Gatekeepers
This diagram illustrates the concept of VoIP Network scaling with gatekeepers and directory
gatekeepers:
H.225 RAS Protocol Elements Table
Note: Refer to Understanding Cisco IOS Gatekeeper Call Routing for more information on
gatekeeper sample configurations.
CUCM Subscribe CSS

Figure 14-4 describes how the subscribe CSS controls presence watchers.
Figure 14-4 CUCM Subscribe CSS

CUCM provides the capability to set policy for users who request presence status:
Configure a CSS to route SIP SUBSCRIBE messages for presence status.
Configure presence groups with which watchers can be associated, that specify rules for viewing the
presence status of presence entities that are associated with another group.
The first aspect of presence policies for CUCM is the subscribe CSS. CUCM uses the subscribe CSS to determine
how to route presence requests. Presence requests are SUBSCRIBE messages with the Event field set to Presence.
These messages are sent from the watcher, which can be a phone or a trunk. The subscribe CSS is associated with
the watcher and lists the partitions that the watcher is allowed to see. This mechanism provides an additional level of
granularity for the presence SUBSCRIBE requests to be routed independently from the normal call-processing CSS.
With the subscribe CSS set to <None>, BLF speed dial and call list presence status does not work (if no directory
number or route pattern is associated with the <None> partition) and the subscription message is rejected as user
unknown. When a valid subscribe CSS is specified, the indicators work and the SUBSCRIBE messages are
accepted and routed properly.
Translation patterns are used for modifying the calling/called party number based on the
dialed number. This is done before a destination is selected, meaning calls route through
translation patterns to modify the calling/called number before reaching a route pattern which
points to a gateway or an end device such as a phone. Transformation patterns are modifying
the calling/called party number once an endpoint or destination has been selected.
Transformation patterns are used to change the calling/called party number right before
a call is sent out of a gateway or trunk, or can be used to change the displayed number on a
phone when a call is received.
Translation used for digit manipulation before (pre-routing decision made) a destination(GW,
Trunk ) is chosen.
Transformation used for digit manipulation after routing decision made like GW trunk is chosen.
so its pre-routing for translation and post-routing for transformation which i can say.
Adding to my previous response in simple words Translation Pattern has the ability to change
the destination of a call whereas Transformation Pattern can only change the display i.e., how
Calling and Called number will show up as on the phone.
1. Translation Patter applies on DNIS - You mean to say incoming call to CUCM only or is it
managed with CSS for outbound as well.
2. Translation is kind of a rule where transformation is kind of a change on a number mask. Am I
correct? Correct me If I am wrong.
Below is a example which I would like to understand.
Phone ---> CUCM---->Gateway---->ISDN PRI.

1. Phone Internal Extension is 5544.
2. Dials a LD number as 91.7458563514
3. We have a RP with 91.[2-9]xxxxxxxxx
4. Matches and goes to SIP trunk.
5. Sip Trunk to GW and to PSTN.
So here how are these applied. Do you require any more information. Let me know. Thanks.
Sanjay.
1. You can apply TP to both inbound and outbound calls. Moreover to internal calls as well.
Beauty of TP is it doens't select the trunk/gateway and you always have a choice where to take
this call further. And in either case, whether to apply or not can be controlled through CSS.
2. Not exactly. If you see the manipulation parameters under TP (with respect to called party
number) and Called Party Transformation, all manipulation parameters are same. Difference is
at which part of call flow, you apply the same.
In your example, let see how we can apply either translation pattern or called party
transformation to strip prefix viz 91.
1. If we use translation pattern, instead of creating RP like 91.[2-9]xxxxxxxxx, create TP as 91.
[2-9]xxxxxxxxx. Now under translation pattern, strip predot. This will change the number to [29]xxxxxxxxx
Since TP can't decide the gateway/trunk, you need a RP like [2-9]xxxxxxxxx. This RP will get
match as the output of translated number.
So here is the flow;
Phone -> TP (apply manipulation here) -> RP -> RL -> RG -> Trunk/Gateway
Basically here you've used TP for digit manipulation during outbound call.
2. If we use called party transformation, lets have RP like 91.[2-9]xxxxxxxxx. You also need to
create Called Party Transformation Pattern which can match the configured RP.
Called Party Transformation can look similar to 91.[2-9]xxxxxxxxx. Now you will strip the pre-dot
here under called party transformation which will translate the number to [2-9]xxxxxxxxx. This
transformation pattern is then assigned to trunk/gateway with the help of CSS.
So here is the flow;
Phone -> RP -> RL -> RG -> Trunk/Gateway (apply manipulation here)
- Vivek
See correct answer in context
Correct Answer by Deepak Rawat about 10 months 4 weeks ago
Sanjay,
1) Translation Pattern in simple words change the destination of a call. This is usually used for
incoming calls. However, it can be used for outgoing calls as well but that really does not make
much sense to do since it is actually the Route Pattern that is taking the calls out using
Trunks/Gateways. In your example, you already have a RP created that matches as soon as
agent dials the number 91.7458563514 and call goes out. Now you can simplify this using TP
wherein you can create a TP for lets say 1200 and then you can transform this to
91.7458563514 under Called Party Transform Mask. What it does is that, user does not actually
need to dial the complete long distance number and will just dial 1200 that in turn will change
the called number to 91.7458563514 and will then hit the RP and call will go out. Hence, it is
actually changing the destination.
2)Transformation Pattern simply changes the number mask, your understanding is correct in
that
It does not change the destination, only the display i.e., how ANI and DNIS will looks like once
the transformation had been applied.
> 1.What is prack?

>
> PRACK stands for Provisonal
Response Acknowledgement
The PRACK method is used to acknowledge receipt of reliably transported

provisional responses (1xx). The reliability of 2xx, 3xx, 4xx, 5xx, and
6xx responses to INVITEs is achieved using the ACK method. However, in
cases where a provisional response, such as 180 Ringing, is critical in
determining
the call state, it may be necessary for the receipt of a provisional
response
to be confirmed. The PRACK method applies to all provisional responses
except
the 100 Trying response, which is never reliably transported.
.why is prack used?

>
As per RFC 3262
Provisional responses provide information on the
progress of the request processing, but are not sent reliably in RFC
3261.
It was later observed that reliability was important in several
cases, including interoperability scenarios with the PSTN.
Therefore, an optional capability was needed to support reliable
transmission of provisional responses. That capability is provided
n this specification.i.e With PRACK
> 3.What are the reasons for using prack?
>
Same as :Answer 2
>
> 4.What is the difference between prack , ack and 200 OK?
>
PRACK:Prack, is received that indicates reception of
the 1xx by the UAC .
ACK:ACK, is received that indicates reception of
the 2xx by the UAC .
The ACK method is used to acknowledge final responses to INVITE requests.
Final responses
are defined as 2xx, 3xx, 4xx, 5xx, or 6xx class responses. The CSeq
number is never incremented for an ACK, but the CSeq method is
changed to ACK.
ACK will be used for Sending SDP if the initial INVITE is send without SDP
offer.
200 Ok: Has two properties
When used to accept a session invitation,
it will contain a message body containing the media properties of the
UAS (called party).
When used in response to other requests, it indicates successful
completion or receipt of the request. The response stops further
retransmissions
of the request.

Basic Call Flow of A SIP Session

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Basic Call Flow of A SIP Session

Загружено:

Авторское право:

Доступные форматы

The following image shows the basic call flow of a SIP session.

Given below is a step-by-step explanation of the above call flow

An INVITE request that is sent to a proxy server is responsible for initiating a

Thereafter, 180 Ringing (Provisional responses) generated by Bob is returned

In the above basic call flow, three transactions are (marked as 1, 2, 3)

The complete call (from INVITE to 200 OK) is known as a Dialog.

SIP messages are of two types requests and responses.

Similarly, the opening line of a response contains a response code.

METHODS are distinguished into two types

A session is considered established if an INVITE has received a success

An INVITE sent within an established dialog is known as a re-INVITE.

Re-INVITE is used to change the session characteristics or refresh the state of a

From: Alice<sips:Alice@TTP.com>;tag = 1234567

It cannot be sent by a proxy server.

BYE cannot be sent to a pending an INVITE or an unestablished session.

The REGISTER request may be forwarded or proxied until it reaches an

REGISTER request contains the time period (3600sec).

It can be sent either by a user agent or a proxy server.

It contains an Expires header field that indicates the duration of a subscription.

Subscription establishes a dialog between the user agents.

A 200 OK will be received for a subscription from User.

Users can unsubscribe by sending another SUBSCRIBE method with Expires

Every NOTIFY will get 200 OK response if it is received by notifier.

asubscriptionstate header field indicating the current state of the subscription.

A NOTIFY is always sent at the start and termination of a subscription.

A PUBLISH request is similar to a NOTIFY, except that it is not sent in a dialog.

Expires header field.

REFER can be sent inside or outside a dialog.

This is an end-to-end request.

A proxy will always forward an INFO request.

IF a session is established, a re-Invite is used to change/update the

Generally PRACK is generated by a client when it receive a provisional response

PRACK contains (RSeq + CSeq) value in the rack header.

A PRACK may contain a message body; it may be used for offer/answer

MESSAGE can be sent within a dialog or outside a dialog.

SIP traces provide key information in troubleshooting SIP Trunks, SIP

Debug ccsip messages.

To understand The output generated by this debug..We need to understand

We will look at these messages as we try to understand the debugs. These

An INVITE usually has a message body containing the media information

INVITE sip:14107154522807@10.105.80.174:5060 SIP/2.0

Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6

The INVITE header

INVITE sip:14107584528207@10.105.80.174:5060 SIP/2.0

The To and From Headers

The Call ID is one of the key components used in troubleshooting. Each UA

User Agent Header:

This header identifies the UA that is originating this request/response. In this

SDP Parameter Parameter

Lets look at media attributes below

m=audio 25268 RTP/AVP 18 0 8 101

Is the dynamic RTP port used for the call

DISSECTING A SIP TRACE

2. A new Invite Sent to CUCM.

Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859

002792: Jun 6 16:07:28.394: //260862/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

SIP/2.0 100 Trying

CSeq: 558267841 INVITE

CSeq: 101 INVITE

6. The CUBE relays this message to the calling party

CSeq: 558267841 INVITE

002796: Jun 6 16:07:28.556: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

8. CUBE sends an ACK to CUCM to acknowledge the last 200 Ok message