Avaya Support Website Help

(index? Subscribe (index? (index? Printable version (index? (JavaScript:OpenEmailArticleWindow('index?

page=subscribe_toggle&return=content&type=CONTENT&id=ADMN102092&viewlocale=null) page=subscribe_toggle&return=content&type=CONTENT&id=ADMN102092&viewlocale=null) page=content&id=ADMN102092&pmv=print&impressions=false) page=content&id=ADMN102092&pmv=print&impressions=false) page=mailpage&sendcontent=mail_url&id=ADMN102092');)

4600 Series IP Phones: Information on SIP Call Flows Between two

SIP Phones
(#rate) Rate this Page (#rate)

Doc ID: ADMN102092

Version: 2.0
Status: Published
Published date: 06 Aug 2008
Updated: 22 Apr 2015
Author: Content Migrator

Body
SIP 2.0 RFC 3261
Session Initiation Protocol (SIP): is a protocol in which a user locates another user, determines the willingness of that user to participate in a session, determines the
parameters, and media that will be used for that session, and tears down the created session between the two users. More on SIP can be found in the Request For
Comment (RFC) 3261. The RFC 3261 for SIP is referenced through this article many times along with Session Description Protocol (SDP) RFC 4566 and RTP RFC
3551.
The following chart is an example of Simple SIP call flows between two users initiated from user 1 (x200) and being received by user 2l(x202). The same example is
used later in explaining the call flows associated with this scenario. This example is used to describe the process taken by SIP to establish and break down an
Realtime Transport Protocol (RTP) Media Path.

User 1(x200) User 2l(x202)

SIP Phone SIP Phone
ß ----------------------------------------à
|-----------------INVITE-----------------à |
|ß -------------100 Trying-----------------|
|ß ------------180 Ringing-----------------|
|ß ---------------200 OK-------------------|
|------------------ACK-------------------à |
ß ============RTP MEDIA PATH==============à
|ß -----------------BYE--------------------|
|-----------------200 OK-----------------à |
ß ----------------------------------------à

1. The user 1 (x200) sends an INVITE (or request) to user 2 (x202) for a media session
2. X202 responds with a 100 Trying to signify that SIP is trying to establish the connection with x202
3. X202 then replies with a 180 Ringing to let x200 know that x202 is alerting user 2 to pick up.
4. When user 2 picks up his QE phone x202 sends a 200 OK back to x200 to let it know that both user 2 and x202 accept the request for a session
5. Then x200 will tell x202 that it acknowledges (ACK) the session acceptance.
6. At this point a RTP Media Path is established and user 1 (x200) and user 2 (x202) the two SIP phones begin communication
7. When user 2 hangs up his phone x202 sends a BYE to x200
8. X200 replies back with a 200 OK to acknowledge the teardown of the RTP Media Path thereby ending the SIP session

Reading and Understanding SIP (Session Initiation Protocol) Call Flows.

The following call flow is a session between two Avaya One-X Quick Edition (QE) phones extensions 200(Josh) and 202(Russell).

The Call Flows:

Note: All user 1 (x200) IP address has been changed to 135.9.XX.user1 and all user 2 (x202) IP Address has been changed to
135.9.XX.user2 for security reasons
INVITE
First we have the INVITE. An Invite is a request for a media session.
INVITE sip:dn202@135.9.XX.user2 SIP/2.0_____________________________
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
Max-Forwards: 70
Content-Length: 324
To:"user 2"
From:"user 1"
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 2130599698 INVITE
P-Asserted-Identity:"user1"
Allow: INVITE
Allow: CANCEL
Allow: OPTIONS
Allow: BYE
Allow: REFER
Allow: INFO
Allow: UPDATE
Content-Type: application/sdp
Contact:"user1"
Supported: replaces
User-Agent: NeuralX MxSF/v3.2.6.26________________________________
v=0
o=dn200 1136169767 1136169768 IN IP4 135.9.XX.user1
s=-
c=IN IP4 135.9.XX.user1
t=0 0
a=sendrecv
m=audio 20004 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:18 annexb=no
a=fmtp:101 0-15
a=ptime:20
a=rtcp:20005 IN IP4 135.9.XX.user1
The first section is called the start line. The Start Line is broken down into three sections.
INVITE sip:dn202@135.9.XX.user2 SIP/2.0
1. INVITEis called the Request Method.
2. sip:dn202@135.9.XX.user2is the Request URI or the destination address.
 3. SIP/2.0is the version of SIP.
The second section is called the Message Header.
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
Max-Forwards: 70
Content-Length: 324
To:"user 2"
From:"user 1"
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 2130599698 INVITE
P-Asserted-Identity:"user1"
Allow: INVITE
Allow: CANCEL
Allow: OPTIONS
Allow: BYE
Allow: REFER
Allow: INFO
Allow: UPDATE
Content-Type: application/sdp
Contact:"user1"
Supported: replaces
User-Agent: NeuralX MxSF/v3.2.6.26
The first line Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
1. SIP/2.0/UDPContains the version of SIP and the transport protocol used to send the message.
2. 135.9.XX.user1the path that was taken so far and should thus in routing responses. The clients host name or network address.
3. branch=z9hG4bKfa2b6c8f8the first part of the branch parameter z9hG4bKidentifies the branch parameter as being generated by a “magic cookie”
compliant with SIP the RFC 3261 –SIP.
4. branch=z9hG4bKfa2b6c8f8the second part of the branch parameter fa2b6c8f8identifies the transaction and is incremented with each new transaction.
Max-Forwards: 70
1. The limit to the number of proxies or gateways allowed to forward the request.
Content-Length: 324
1. The message body length (in octets) – indicates the length of the message body. If there is no message body, the content length should be set to
0. The length of the message body does not include the CRLF that separates header fields and the body.
To: "user 2"
1. Person or device receiving the request (call). In this case it is user 2(x202) and his SIP address is SIP:dn202@135.9.XX.user2
From: "user 1"
1. Person or device making or initiating the request (call). In this case it is user 1 (x200) and his SIP address is SIP:dn200@135.9.XX.user1
2. tag=3235d8254db5d18uniquely identifies the dialogue.
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
1. Uniquely identifies a particular invitation or all registrations of a particular client. Usually@ the string must be a globally unique value.
CSeq: 2130599698 INVITE
1. Command sequence number – this number is incremented for each new request within a dialogue.
2. INVITE– Request method.
P-Asserted-Identity:"user1"
1. Agent identifies itself to a registrar as a device at which the user is located (RFC 3261).
Allow: INVITE
Allow: CANCEL
Allow: OPTIONS
Allow: BYE
Allow: REFER
Allow: INFO
Allow: UPDATE
1. Lists the methods supported by the user agent generating the request. However just because one isn’t listed doesn’t mean it isn’t supported.
Content-Type: application/sdp
1. Defines the media type of the message body. Content-type must be present if there is anything in the body.
Contact: "user1"
1. URI where all future requests should be sent.
Supported: replaces
1. Enumerates all the extensions supported by the user agent.
User-Agent: NeuralX MxSF/v3.2.6.26
1. Contains information about the user agent originating the request.
2. Revealing the software version can cause vulnerability to attacks so this field should be configurable.
The third section is called the Message Body. The values are based on the Content-Type media type which in this case was sdp. The values are found
in the SDP (RFC 4566).
v=0
o=dn200 1136169767 1136169768 IN IP4 135.9.XX.user1
s=-
c=IN IP4 135.9.XX.user1
t=0 0
a=sendrecv
m=audio 20004 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:18 annexb=no
a=fmtp:101 0-15
a=ptime:20
a=rtcp:20005 IN IP4 135.9.XX.user1
v=0
1. The version number.
o=dn200 1136169767 1136169768 IN IP4 135.9.XX.user1
Originator - represented as o=

1. Username – Originating host. (-) indicates no value being supplied.

2. SessionID – Session identifier. (Possibly NTP timestamp).
3. Version – Version number of announcement. Must increase as session is modified. NTP recommended.
4. Network Type – Type of network. (INternet defined only).
5. Address Type – IP4 and IP6 are the options here.
6. Address – address of the initiating machine that created the session.
s=-
1. Session name – again (-) indicates no value being supplied.
c=IN IP4 135.9.XXuser1
Connection Data – represented as c=
All representations same as those in the originator.

t=0 0
Time – represented as t=
1. Start time – Start time of the session in NTP – 0=session is permanent.
2. Stop time - Stop time of the session in NTP – 0=session is not bounded.
a=sendrecv
1. The Attributes
2. sendrecv, sendonly, recvonly, and inactive. Sendrecv is the default if not set.
m=audio 20004 RTP/AVP 0 8 18 101
Media – represented as m=
1. Format – the media format
2. Port – RTP or UDP port.
3. Transport – RTP/AVP or UDP
 4. Media Payload Types – RFC 3551
a. 0 = PCMU
b. 8 = PCMA
c. 18 = G729
d. 101 = dynamic
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
Attribute represented as a=:.
1. rtpmap:Values are RTP media payload types from RFC 3551. Represented as
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=ptime:20
a=rtcp:20005 IN IP4 135.9.XX.user1
Represented a=
100 Trying
Next we have the 100 Trying – Trying indicates that the request has been received by the
next-hop server and that some unspecified action is being taken on behalf of this call.
SIP/2.0 100 Trying
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 2130599698 INVITE
From:"user 1"
To:"user 2"
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
Content-Length: 0
User-Agent: NeuralX MxSF/v3.2.6.26
This section only contains a Message Header and most of it is interpreted the same as INVITE.
SIP/2.0 100 Trying
SIP/2.0 is the version of SIP and 100 trying is the Method Request.
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 2130599698 INVITE
These two fields retain their same meaning however if you remember the CSeq Number is supposed to increment with each new
request. It has not incremented because the request as you see on the CSeq is still INVITE because it is only responding to the invite
and has therefore not changed it’s request dialogue.
From:"user1"
To: "user2sell"
These two fields also retain their meanings however if you notice “user 2” now carries a tag as well. This is because x202 has now sent
something and it is being tagged to uniquely identify the dialogue. Another thing to notice is that even though user1(x200) is the
recipient of this message it still shows that it is from user1(x202). The reason for this is also because of the CSeq is still showing it in
the INVITE method. Until the receiver makes a new request it will remain this way.
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
Notice how the branch parameter was supposed to increment but hasn’t. Again this is because the INVITE method has not changed.
Content-Length: 0
The content-length is now zero because if there is no message body, the content length should be set to 0.
User-Agent: NeuralX MxSF/v3.2.6.26
This one remains the same as well.
180 Ringing
Next we have the 180 Ringing – Ringing is the user agent receiving the INVITE is trying to alert the user. This response MAY be used
to initiate local ringback.
SIP/2.0 180 Ringing
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 2130599698 INVITE
From:"user 1"
To:"user 2"
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
Content-Length: 0
Contact:"user 2"
User-Agent: NeuralX MxSF/v3.2.6.26
CSeq: 2130599698 INVITE
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
Again notice the CSeq and the Branch parameter have still not incremented. This is because the request as you see on the CSeq is still
INVITE and has therefore not changed its request dialogue.
From:"user1"
To:"user2"
The To and From fields are still in their original order because it is still in the original Method request.
All the other fields remain the same as they were in the 100 Trying.
200 OK
Now we have the 200 OK When user2(x202) picks up the handset, his SIP phone sends a 200 (OK) which is a response to indicate
that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that the
recipient is willing to establish with the initiator. As a result, there is a two-phase exchange of SDP messages: user 1(x200) sent a
request to user 2 (x202), and now user 2 (x202) is sending one back to user 1 (x200). This two-phase exchange provides basic
negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If user 2 (x202) did not wish to answer the call
or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media
session being established.
SIP/2.0 200 OK_______________________________________________
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 2130599698 INVITE
From:"user 1"
To:"user 1"
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bKfa2b6c8f8
Content-Length: 253
P-Asserted-Identity:"user2"
Allow: INVITE
Allow: CANCEL
Allow: OPTIONS
Allow: BYE
Allow: REFER
Allow: INFO
Allow: UPDATE
Content-Type: application/sdp
Supported: replaces
Contact:"user 2"
User-Agent: NeuralX MxSF/v3.2.6.26___________________________
v=0
o=dn202 1136169766 1136169767 IN IP4 135.9.XX.user2
s=-
c=IN IP4 135.9.XX.user2
t=0 0
a=sendrecv
m=audio 20002 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=rtcp:20003 IN IP4 135.9.XX.user2
This 200 OK is also broken down into three sections the Start Line, Message Header and Message Body. As mentioned earlier the
message body is sent this time to establish the SDP media session that the recipient is willing to establish with the initiator.
1. The Start LineSIP/2.0 200 OKis the same concept as the others its fields are . Again the SIP version is 2.0 and the Request Method is 200 OK.
2. The Message Header is again the same concept described earlier however notice that the CSeq number parameters and Via Branch
parameters still haven’t changed for the same reason that they are still based on the original request method. Also the “to” and “from”
parameters haven’t changed because they are still based on the original request as well. Notice however thatP-Asserted-Identity:"user 2"has changed to
“user 2” and now gives his SIP address, this is because of the origin of the message is now user 2(x202). Last notice that the contact has
changed to “user 2” the URI where all future requests should be sent.
 3. The message body also follows the same concept as the INVITE message body, that it is still SDP and so the values fields have the same
meanings. Some of the parameters, values, and attributes however may have changed but all of these parameters can be found in the SDP’s
RFC 4566 and RTP media payload types from RFC 3551. Notice the changes in IP Addresses as origins change regarding user 1 (x200) and
user 2(x202).
ACK
Coming back from user 1(x200) the initiator of the request we get an acknowledgment ACK that the OK was received. The ACK request
constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that is equal to the values of those
header fields in the request passed to the transport by the original request. The To header field in the ACK MUST equal the To header
field in the response being acknowledged.
ACK sip:dn202@135.9.XX.user2 SIP/2.0
Via: SIP/2.0/UDP 135.9.XX.user1;branch=z9hG4bK1d51cbec5
Max-Forwards: 70
Content-Length: 0
To:"user 2"
From:"user 1"
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 2130599698 ACK
Contact:"user 1"
User-Agent: NeuralX MxSF/v3.2.6.26
Most of the fields here are the same concept as well; however there are a few differences.
1. First notice the Start line has a different format it is now demonstrated as .
2. Second notice the branch parameter has changed. This is because of the new request method being sent by the initiator.
However the first part “z9hG4bK” has not changed because this is what verifies to the server that this is a genuine SIP request.
3. Third notice that the contact is back to “ user1” the URI where all future requests should be sent.
4. Last notice the CSeq number hasn’t changed. This will not change until someone other than the initiator makes a request which
we will see happen in the BYE request. But the CSeq request method has changed to ACK being the next new request from the
initiator.
ß-----------------RTP Media Path-------------------à
Now that all the verification and setup has been completed we have a media path by which we can communicate.
BYE
The BYE becomes a unique request method in that there is now a new initiator. This whole time the initiator has been user 1(x200),
now it is user 2(x202). When user 2 hangs up his phone x202 sends a request method BYE to close the session.
BYE sip:dn200@135.9.XX.user1 SIP/2.0
Via: SIP/2.0/UDP 135.9.XX.user2;branch=z9hG4bKe1465323b
Max-Forwards: 70
Content-Length: 0
To:"user 1"
From:"user 2"
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 519504377 BYE
Supported: replaces
User-Agent: NeuralX MxSF/v3.2.6.26
The Start line has a different format as well, but same as the ACK it is now demonstrated as . Notice how the recipient is now user1
(x200).
The branch parameter has also incremented again because a new request has been made by a new initiator. Notice the path being
taken is now from 135.9.XX.user2 this is the address of user 2(x202). This is demonstrating that x202 made this request and it is the
new path and it should stay this thus in routing responses.
The “to” and “from” field parameters have also changed, now they point to user 1 (x200) from user 2 (x202).
The CSeq number has incremented because a request was made by a new initiator and because a new request method was made this
parameter was also changed to BYE.
BYE brought about new changes we haven’t seen yet because of the new initiator and change of recipient.
200 OK
We have another 200 OK only this time the original recipient is making it in regards to the new request (BYE) being made by the new
initiator. This OK will close out the RTP Media Path, while the first assisted in its construction.
SIP/2.0 200 OK
Call-ID: 34e98c82840d57045c078350dd2ea039@135.9.XX.user1
CSeq: 519504377 BYE
From:"user 2"
To:"user 1"
Via: SIP/2.0/UDP 135.9.XX.user2;branch=z9hG4bKe1465323b
Content-Length: 0
Supported: replaces
User-Agent: NeuralX MxSF/v3.2.6.26
None of the fields here have changed. Although totally different from the original request they are quite similar to the BYE request
method because it is a response to the BYE request. The CSeq has remained the same for this reason and so have the “to” and “from”
fields. The branch parameter in the Via field has not been altered either because it is also referencing the same request method.
One thing that did change with this 200 OK verses the last one is the absence of a message body. The reason for this is because it
does not need to say whether it supports the BYE request or not it only acknowledges that user 2 (x202) is going to disconnect and it
will do the same.
The SIP session has officially been torn down, the communication has been dropped, and the RTP Media Path is gone.
This gives you a simple basic understanding of reading a simple SIP call flow between two Avaya One-X Quick Edition (QE) phones.
Legacy ID
KB01012723

Please rate this article

RATE CONTENT

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy

• About Avaya • Contacts • Careers • Site Map Hurricane or• Weather Event
Terms of Use • Privacy Support
Statement
• © 2018 Avaya Inc.
Avaya Services is ready to help clients impacted by a Hurricane or Weather Event.
For emergency preparation, business continuity, and disaster recovery information, please click here.

Opening a case on the Avaya Support Website is the fastest way to get support. Alternately, for
International Support Numbers please click here. For the US, call +1-800-242-2121 for support.

If you need to report a Service outage and are unable to do so via the web, please click here for the
regional phone contact numbers.