d basic flows-routing-issues-vt00r00

ROUTING ISSUES IN BASIC CALL FLOWS DES

DES Page :1/40

ROUTING ISSUES IN BASIC

CALL FLOWS

By: Daniel Esteban Soroko - 2011


DES Page :2/40

Contents

1 GENERAL INTRODUCTION: .................................................3

1.1 PURPOSE: .......................................................................................... 3

1.2 SCOPE:.............................................................................................. 3

1.3 ABBREVIATIONS AND TERMINOLOGY:.................................................... 3

1.4 REQUIRED INFORMATION: ................................................................... 3

1.5 RELATED DOCUMENTATION:................................................................. 3

2 OVERVIEW: ........................................................................4

2.1 EXAMPLE Nº1 (SIP TRAPEZOID WITHOUT USING RECORD-ROUTE AND

ROUTE): ..................................................................................................... 4

2.2 EXAMPLE Nº2 (SIP TRAPEZOID USING RECORD-ROUTE AND ROUTE): ...... 12

2.3 EXAMPLE Nº3 (SIP TRAPEZOID USING RECORD-ROUTE AND ROUTE - VARIANT): ................................................................................................ 27

3 UA DIALOG STRUCTURES: ................................................39

3.1 FIELDS DESCRIPTION:....................................................................... 39


DES Page :3/40

1 GENERAL INTRODUCTION:

1.1 Purpose:

This document gives a brief detail of the mechanisms used to route SIP messages and an approach about routing related header fields.

1.2 Scope:

This description depicts the routing mechanisms used in SIP messages.

1.3 Abbreviations and Terminology:

-.

1.4 Required information:

call_flow_woRR_v00.pdf: signalling flow example.

call_flow_w1RR_v00.pdf: signalling flow example. call_flow_w2RR_v00.pdf: signalling flow example.

1.5 Related documentation:

RFC 3261: SIP: Session Initiation Protocol. RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers.

RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples. RFC 3666: Session Initiation Protocol (SIP) Public Switched Telephone

Network (PSTN) Call Flows. RFC 5411: A Hitchhiker's Guide to the Session Initiation Protocol (SIP).

RFC 5627: Obtaining and Using Globally Routable User Agent URIs (GRUUs)

in the Session Initiation Protocol (SIP) RFC 5630: The Use of the SIPS URI Scheme in the Session Initiation Protocol

(SIP).


DES Page :4/40

2 OVERVIEW:

In the next sections we will deal with SIP dialogs and routing of requests. A Dialog is a peer-to-peer relationship between two user agents. It

represents a context that facilitates the sequencing of messages between the user agents and proper routing of requests between both of them. The following

examples, illustrates the creation of a dialog, the processing of requests during this dialog, and the termination of the dialog.

2.1 Example Nº1 (SIP trapezoid without using Record-Route and

Route):

A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |-----------------M12(ACK)--------------->| |<----------------M13(BYE)----------------| |-----------------M14(200)--------------->|

This example shows two proxies in the routing path and neither of them

request to be maintained in the signalling path by inserting Record-Route header

fields. Only the header fields relevant to the dialog and the routing of requests are shown in the SIP messages.

You can see the flow graph in “call_flow_woRR_v00.pdf” document. Next we will describe each one of the flow’s messages and its relevant headers (“100

Trying” provisional response are ignored).

Note that we used the “blue” colour to denote FQDN identities, and the “red” colour to denote NFQDN identities.

In this example “A” calls “B” using his SIP identity, a type of Uniform

Resource Identifier (URI) called a SIP URI. This SIP URI has a similar form to an email address, typically containing a username and a host name. In this case, it is

“sip:[email protected]”, where “biloxi.com” is the domain of Bob's SIP service provider. Alice has a SIP URI of “sip:[email protected]”.

Note than “sip:[email protected]” and “sip:[email protected]” are

logical identities that define the users, and “pc33.atlanta.com” and

“term24.biloxi.com”, are the physical identities (machines) where these users reside. In the same way “bigbox3.site3.atlanta.com” and

“server10.biloxi.com”, are the proxies’ physical identities.

Note than “Request-URI” is part of the “Request-Line = Method SP

Request-URI SP SIP-Version CRLF”. Example: INVITE sip:[email protected] SIP/2.0


DES Page :5/40

2.1.1- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |-----------------M12(ACK)--------------->| |<----------------M13(BYE)----------------| |-----------------M14(200)--------------->|

-“A” generates the INVITE request (Since the “A” softphone does not know the location of Bob or the SIP server in the “biloxi.com” domain, the softphone sends

the INVITE to the SIP server that serves Alice's domain, “atlanta.com”. The address of the “atlanta.com” SIP server could have been configured in Alice's softphone (as

an outbound proxy), or it could have been discovered by DHCP/DNS, for example).

M1

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Header’s commentaries:

Request-URI: contains a SIP or SIPS URI (sip:[email protected]) that indicates the

user or service to which this request is being addressed. Via: contains the address (pc33.atlanta.com) at which “A” is expecting to receive

responses to this request. To: contains a SIP or SIPS URI (sip:[email protected]) towards which the request

was originally directed. From: also contains a SIP or SIPS URI (sip:[email protected]) that indicate the

originator of the request.

Contact: contains a SIP or SIPS URI (sip:[email protected]) that represents a direct route to contact Alice, usually composed of a username at a fully qualified

domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header

field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.


DES Page :6/40


-“P1” inspects the received “Request-URI” in M1 message (sip:[email protected]) and

does not change it because it is not responsible for the resource indicated in this URI.

-“P1” forwards the request to the resource indicated in the “Request-URI” (sip:[email protected]) by applying DHCP/DNS procedures.

M2


Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1

Max-Forwards: 69




CSeq: 314159 INVITE



Via: P1 adds its own via header in the routing path (bigbox3.site3.atlanta.com), for

its use in the response messages.


-“P2” inspects the received “Request-URI” in M2 message (sip:[email protected]). It is responsible for “biloxi.com”, so it runs a location service and rewrites the

“Request-URI” (sip:[email protected] -> sip:[email protected]) -“P2” forwards the request to the resource indicated in the “Request-URI” (sip:

[email protected]) by applying DHCP/DNS procedures. M4


Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1

Via: SIP/2.0/UDP

bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2


Max-Forwards: 68




CSeq: 314159 INVITE



DES Page :7/40


Via: P2 adds its own via header in the routing path (server10.biloxi.com), for its use in the response messages.


-“B” inspects the received message (M4). Then it stores the “A” “Contact header”

([email protected]) in its UA “dialog data structure” as “Remote Target”. It uses the “Request-URI” of M4 to fill its own “Contact” header.

-“B” creates the 180 response message. -“B” sends the 180 response message by using the “Via” headers.

M6

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1;received=192.0.2.3

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;

branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2


To: Bob <sip:[email protected]>;tag=a6c85cf




CSeq: 314159 INVITE


Contact: “B” adds a Contact header field to the response, with its direct route

(sip:[email protected]). “B” obtain this value from the Request-URI of the incoming request (M4).

To: “B” adds its local tag, to “To” header.


DES Page :8/40


-“P2” forwards the 180 response message by using the “Via” headers. M7

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP







CSeq: 314159 INVITE


Via: P2 delete its own via header in the routing path (server10.biloxi.com).



SIP/2.0 180 Ringing






CSeq: 314159 INVITE


Via: P1 delete its own via header in the routing path (bigbox3.site3.atlanta.com).


DES Page :9/40



M9

SIP/2.0 200 OK


Via: SIP/2.0/UDP






CSeq: 314159 INVITE



Contact: “B” adds a Contact header field to the response, with its direct route (sip:[email protected]). “B” obtains this value from the Request-URI of the

incoming request (M4).

To: “B” adds its local tag, to “To” header.



SIP/2.0 200 OK

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;

received=192.0.2.2





CSeq: 314159 INVITE



Via: P2 delete its own via header in the routing path (server10.biloxi.com).


DES Page :10/40



SIP/2.0 200 OK





CSeq: 314159 INVITE



Via: P1 delete its own via header in the routing path (bigbox3.site3.atlanta.com).

2.1.10- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |-----------------M12(ACK)--------------->| |<----------------M13(BYE)----------------| |-----------------M14(200)--------------->| -“A” inspects the received message (M11). Then it stores the “B” “Contact header”

in its UA “dialog data structure” as “Remote Target”. -“A” creates the ACK request.

-“A” sends the ACK request by using the Contact header received in M11([email protected]).

M12

ACK sip:[email protected] SIP/2.0


Max-Forwards: 70




CSeq: 314159 ACK


Request-URI: contains a SIP or SIPS URI (sip:[email protected]) that

indicates the user or service to which this request is being addressed.”A” fills it value, with the received “Contact” header of M11 message.


DES Page :11/40


-“B” creates a BYE message.

-“B” sends the BYE request by using the “Remote Target” of UA dialog data structure ([email protected]) (see 2.1.4-).

M13

BYE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP term24.biloxi.com;branch=z9hG4bKnashds10

Max-Forwards: 70

From: Bob <sip:[email protected]>;tag=a6c85cf

To: Alice <sip:[email protected]>;tag=1928301774


CSeq: 231 BYE



Request-URI: “B” fills the Request-URI value, “Remote Target” of UA dialog data

structure ([email protected]) (see 2.1.4-).


-“A” creates a 200 OK response to respond to the BYE message.

-“A” sends the 200 response by using the “Via headers”.

M14

SIP/2.0 200 OK





CSeq: 231 BYE


DES Page :12/40

2.2 Example Nº2 (SIP trapezoid using Record-Route and Route):

A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---M12(ACK)->|---M13(ACK)->|---M14(ACK)->| |<--M17(BYE)--|<--M16(BYE)--|<--M15(BYE)--| |---M18(200)->|---M19(200)->|---M20(200)->|

This example shows two proxies in the routing path and both of them

request to be maintained in the signalling path by inserting Record-Route header fields. Only the header fields relevant to the dialog and the routing of requests are

shown in the SIP messages. You can see the flow graph in “call_flow_w2RR_v00.pdf” document. Next we

will describe each one of the flow’s messages and its relevant headers (“100 Trying” provisional response are ignored).

Note that we used the “blue” colour to denote FQDN identities, and the “red” colour to denote NFQDN identities.

In this example “A” calls “B” using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. This SIP URI has a similar form to an

email address, typically containing a username and a host name. In this case, it is “sip:[email protected]”, where “biloxi.com” is the domain of Bob's SIP service

provider. Alice has a SIP URI of “sip:[email protected]”.

Note than “sip:[email protected]” and “sip:[email protected]” are

logical identities that define the users, and “pc33.atlanta.com” and “term24.biloxi.com”, are the physical identities (machines) where these

users reside. In the same way “bigbox3.site3.atlanta.com” and “server10.biloxi.com”, are the proxies’ physical identities.

Note than “Request-URI” is part of the “Request-Line = Method SP

Request-URI SP SIP-Version CRLF”. Example: INVITE sip:[email protected] SIP/2.0


DES Page :13/40

2.2.1- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---M12(ACK)->|---M13(ACK)->|---M14(ACK)->| |<--M17(BYE)--|<--M16(BYE)--|<--M15(BYE)--| |---M18(200)->|---M19(200)->|---M20(200)->|

-“A” generates the INVITE request (Since the “A” softphone does not know the location of Bob or the SIP server in the “biloxi.com” domain, the softphone sends

the INVITE to the SIP server that serves Alice's domain, “atlanta.com”. The address of the “atlanta.com” SIP server could have been configured in Alice's softphone (as

an outbound proxy), or it could have been discovered by DHCP/DNS, for example). M1



Max-Forwards: 70




CSeq: 314159 INVITE



Request-URI: contains a SIP or SIPS URI (sip:[email protected]) that indicates the user or service to which this request is being addressed.

Via: contains the address (pc33.atlanta.com) at which “A” is expecting to receive responses to this request.

To: contains a SIP or SIPS URI (sip:[email protected]) towards which the request was originally directed.

From: also contains a SIP or SIPS URI (sip:[email protected]) that indicate the originator of the request.

Contact: contains a SIP or SIPS URI (sip:[email protected]) that represents a

direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have

registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header

field tells other elements where to send future requests.


DES Page :14/40


-“P1” inspects the received “Request-URI” in M1 message (sip:[email protected]) and does not change it because it is not responsible for the resource indicated in this

URI. -“P1” adds a Record-Route header with its own address

(bigbox3.site3.atlanta.com). (The next requests must traverse this address). -“P1” forwards the request to the resource indicated in the “Request-URI”

(sip:[email protected]) by applying DHCP/DNS procedures. M2




Max-Forwards: 69




CSeq: 314159 INVITE


Record-Route: sip:bigbox3.site3.atlanta.com;lr>


Via: “P1” adds its own “Via” header in the routing path (bigbox3.site3.atlanta.com), for its use in the response messages.

Record-Route: “P1” adds a “Record-Route” header with its own address(bigbox3.site3.atlanta.com). (The next requests must traverse this

address).


DES Page :15/40



“Request-URI” (sip:[email protected] -> sip:[email protected]) -“P2” adds a Record-Route header with its own address (server10.biloxi.com). (The

next requests must traverse this address). -“P2” forwards the request to the resource indicated in the “Request-URI” (sip:




Via: SIP/2.0/UDP



Max-Forwards: 68




CSeq: 314159 INVITE


Record-Route: sip:server10.biloxi.com;lr>



Via: P2 adds its own “Via” header in the routing path (server10.biloxi.com), for its use in the response messages.

Record-Route: “P2” adds a “Record-Route” header with its own address

(server10.biloxi.com). (The next requests must traverse this address).


DES Page :16/40


-“B” inspects the received message (M4). Then it stores: The “A” “Contact” header in its UA “dialog data structure” as “Remote

Target” ([email protected]).

The “Record-Route” headers in its UA “dialog data structure” as “Route Set”. (server10.biloxi.com; bigbox3.site3.atlanta.com)

-“B” uses the “Request-URI” ([email protected]) of M4 to fill its own “Contact” header.

-“B” creates the 180 response message.

-“B” copies all the Record-Route headers to the 180 response message. -“B” sends the 180 response message by using the “Via” headers.

M6

SIP/2.0 180 Ringing


Via: SIP/2.0/UDP bigbox3.site3.atlanta.com; branch=z9hG4bK77ef4c2312983.1

;received=192.0.2.2






CSeq: 314159 INVITE




Contact: “B” adds a “Contact” header field to the response, with its direct route


To: “B” adds its local tag, to “To” header. Record-Route: “B” copies the received “Record-Route” headers into the response

message.


DES Page :17/40



SIP/2.0 180 Ringing


;received=192.0.2.2






CSeq: 314159 INVITE




Via: P2 delete its own “Via” header in the routing path (server10.biloxi.com).



SIP/2.0 180 Ringing






CSeq: 314159 INVITE




Via: P1 delete its own “Via” header in the routing path (bigbox3.site3.atlanta.com).


DES Page :18/40



M9

SIP/2.0 200 OK


Via: SIP/2.0/UDP






CSeq: 314159 INVITE








message.



SIP/2.0 200 OK

Via: SIP/2.0/UDP






CSeq: 314159 INVITE





DES Page :19/40





SIP/2.0 200 OK





CSeq: 314159 INVITE





Via: P1 delete its own via “Via” header in the routing path (bigbox3.site3.atlanta.com).


DES Page :20/40


-“A” inspects the received message (M11). Then it stores : The “B” “Contact” header ([email protected]) in its UA “dialog data

structure” as “Remote Target”. The “Record-Route” headers in its UA “dialog data structure” as “Route Set”

(bigbox3.site3.atlanta.com ; server10.biloxi.com). -“A” creates the ACK request.

-“A” adds the “Route” headers using the stored “Route Set” (bigbox3.site3.atlanta.com ; server10.biloxi.com).

-“A” sends the ACK request by using the first value of “Route Set”.

(bigbox3.site3.atlanta.com ; server10.biloxi.com) M12



Max-Forwards: 70




CSeq: 314159 ACK

Route:sip:bigbox3.site3.atlanta.com

Route:sip:server10.biloxi.com


Request-URI: “A” fills the Request-URI value, with “Remote Target” value of UA

dialog data structure ([email protected]). Route: contains the addresses that they will used to route the message. (Its value

was the previously recorded “Route Set”) (bigbox3.site3.atlanta.com ; server10.biloxi.com).


DES Page :21/40


-“P1” inspects the Request-URI of the received message (M12), and does not change it because is not responsible for the resource indicated in this URI.

-“P1” sees that it is the first value in the “Route” header field so it removes that value (sip:bigbox3.site3.atlanta.com).

-“P1” forwards the request to the resource indicated in the topmost “Route” header (sip:server10.biloxi.com) field applying DHCP/DNS procedures.

M13




Max-Forwards: 69




CSeq: 314159 ACK



Via: P1 adds its own “Via” header in the routing path (bigbox3.site3.atlanta.com). Route: P1 delete its own “Route” header in the routing path

(bigbox3.site3.atlanta.com).


DES Page :22/40


-“P2” inspects the Request-URI of the received message (M13), and does not change it because is not responsible for the resource indicated in this URI (it is

responsible for “biloxi.com”, not “term24.biloxi.com”). -“P2” sees that it is the first value in the “Route” header field so it removes that

value (sip: server10.biloxi.com). -“P2” forwards the request to the resourse indicated in the Request-URI

(sip:[email protected]) because there are not more “Route” headers, applying DHCP/DNS procedures.

M14





Max-Forwards: 68




CSeq: 314159 ACK


Via: P2 adds its own “Via” header in the routing path (server10.biloxi.com). Route: P2 delete its own “Route” header in the routing path (server10.biloxi.com).


DES Page :23/40


-“B” creates a BYE message. -“B” adds “Route” headers using the data stored at “Route Set”

(server10.biloxi.com; bigbox3.site3.atlanta.com) (see 2.2.4-). -“B” sets “Request-URI” header using the data stored at “Remote

Target”([email protected]) (see 2.2.4-). -“B” sends the ACK request by using the first value of “Route Set”.

(server10.biloxi.com ; bigbox3.site3.atlanta.com)

M15



Max-Forwards: 70




CSeq: 231 BYE


Route: sip:server10.biloxi.com

Route: sip:bigbox3.site3.atlanta.com


Request-URI: “B” fills the Request-URI value, with “Remote Target” value of UA dialog data structure ([email protected]) (see 4-).

Route: contains the addresses that they will used to route the message. (Its value was the previously recorded “Route Set”) (server10.biloxi.com ;

bigbox3.site3.atlanta.com).


DES Page :24/40

2.2.14- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---M12(ACK)->|---M13(ACK)->|---M14(ACK)->| |<--M17(BYE)--|<--M16(BYE)--|<--M15(BYE)--| |---M18(200)->|---M19(200)->|---M20(200)->| -“P2” inspects the Request-URI of the received message (M15), and does not

change it because is not responsible for the resource indicated in this URI.. -“P2” sees that it is the first value in the “Route” header field so it removes that

value (sip: server10.biloxi.com). -“P2” forwards the request to the resource indicated in the topmost “Route” header

(sip: bigbox3.site3.atlanta.com) field applying DHCP/DNS procedures.

M16




Max-Forwards: 69




CSeq: 231 BYE


Route: sip:bigbox3.site3.atlanta.com


Via: P2 adds its own “Via” header in the routing path (server10.biloxi.com). Route: P2 delete its own “Route” header in the routing path

(server10.biloxi.com).


DES Page :25/40


-“P1” inspects the Request-URI of the received message (M16), and does not change it because is not responsible for the resource indicated in this URI URI (it is

responsible for “atlanta.com”, not “pc33.atlanta.com”). -“P1” sees that it is the first value in the “Route” header field so it removes that

value (sip: bigbox3.site3.atlanta.com). -“P1” forwards the request to the resourse indicated in the Request-URI


M17


Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;

branch=z9hG4bK77ef4c2312983.1



Max-Forwards: 68




CSeq: 231 BYE



Via: P1 adds its own “Via” header in the routing path

(bigbox3.site3.atlanta.com). Route: P1 delete its own “Route” header in the routing path


2.2.16- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---M12(ACK)->|---M13(ACK)->|---M14(ACK)->| |<--M17(BYE)--|<--M16(BYE)--|<--M15(BYE)--| |---M18(200)->|---M19(200)->|---M20(200)->| -“A” creates a 200 OK response to respond to the BYE message.


M18

SIP/2.0 200 OK







CSeq: 231 BYE


DES Page :26/40


-“P1” forwards the 200 response by using the “Via” header field. M19

SIP/2.0 200 OK






CSeq: 231 BYE

Header’s commentaries: Via: P1 deletes its own “Via” header in the routing path

(server10.biloxi.com).



SIP/2.0 200 OK





CSeq: 231 BYE


Via: P1 deletes its own “Via” header in the routing path (bigbox3.site3.atlanta.com).


DES Page :27/40

2.3 Example Nº3 (SIP trapezoid using Record-Route and Route -

Variant):

A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->|

This example shows two proxies in the routing path and neither of them

request to be maintained in the signalling path by inserting Record-Route header fields. Only the header fields relevant to the dialog and the routing of requests are

shown in the SIP messages. You can see the flow graph in “call_flow_w1RR_v00.pdf” document. Next we

will describe each one of the flow’s messages and its relevant headers (“100

Trying” provisional response are ignored).

Note that we used the “blue” colour to denote FQDN identities, and

the “red” colour to denote NFQDN identities.

In this example “A” calls “B” using his SIP identity, a type of Uniform

Resource Identifier (URI) called a SIP URI. This SIP URI has a similar form to an

email address, typically containing a username and a host name. In this case, it is “sip:[email protected]”, where “biloxi.com” is the domain of Bob's SIP service

provider. Alice has a SIP URI of “sip:[email protected]”.

Note than “sip:[email protected]” and “sip:[email protected]” are logical identities that define the users, and “pc33.atlanta.com” and

“term24.biloxi.com”, are the physical identities (machines) where these users reside. In the same way “bigbox3.site3.atlanta.com” and

“server10.biloxi.com”, are the proxies’ physical identities.

Note than “Request-URI” is part of the “Request-Line = Method SP Request-URI SP SIP-Version CRLF”. Example: INVITE sip:[email protected]

SIP/2.0


DES Page :28/40

2.3.1- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->| -“A” generates the INVITE request (Since the “A” softphone does not know the

location of Bob or the SIP server in the “biloxi.com” domain, the softphone sends the INVITE to the SIP server that serves Alice's domain, “atlanta.com”. The address

of the “atlanta.com” SIP server could have been configured in Alice's softphone (as an outbound proxy), or it could have been discovered by DHCP/DNS, for example).

M1



Max-Forwards: 70




CSeq: 314159 INVITE



Request-URI: contains a SIP or SIPS URI (sip:[email protected]) that indicates the

user or service to which this request is being addressed. Via: contains the address (pc33.atlanta.com) at which “A” is expecting to receive

responses to this request. To: contains a SIP or SIPS URI (sip:[email protected]) towards which the request

was originally directed. From: also contains a SIP or SIPS URI (sip:[email protected]) that indicate the

originator of the request.

Contact: contains a SIP or SIPS URI (sip:[email protected]) that represents a direct route to contact Alice, usually composed of a username at a fully qualified

domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header

field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.


DES Page :29/40

2.3.2- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->|

-“P1” inspects the received “Request-URI” in M1 message (sip:[email protected]) and does not change it because it is not responsible for the resource indicated in this

URI. -“P1” forwards the request to the resource indicated in the “Request-URI”

(sip:[email protected]) by applying DHCP/DNS procedures. M2




Max-Forwards: 69




CSeq: 314159 INVITE



Via: “P1” adds its own “Via” header in the routing path (bigbox3.site3.atlanta.com), for its use in the response messages.


DES Page :30/40



“Request-URI” (sip:[email protected] -> sip:[email protected]) -“P2” adds a Record-Route header with its own address (server10.biloxi.com). (The

next requests must traverse this address). -“P2” forwards the request to the resource indicated in the “Request-URI” (sip:




Via: SIP/2.0/UDP



Max-Forwards: 68




CSeq: 314159 INVITE




Via: P2 adds its own “Via” header in the routing path (server10.biloxi.com), for its use in the response messages.

Record-Route: “P2” adds a “Record-Route” header with its own address (server10.biloxi.com). (The next requests must traverse this address).


DES Page :31/40

2.3.4- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->| -“B” inspects the received message (M4). Then it stores:

The “A” “Contact” header in its UA “dialog data structure” as “Remote Target” ([email protected]).

The “Record-Route” headers in its UA “dialog data structure” as “Route Set”. (server10.biloxi.com)

-“B” uses the “Request-URI” ([email protected]) of M4 to fill its own “Contact” header.

-“B” creates the 180 response message.

-“B” copies all the Record-Route headers to the 180 response message. -“B” sends the 180 response message by using the “Via” headers.

M6

SIP/2.0 180 Ringing


Via: SIP/2.0/UDP bigbox3.site3.atlanta.com; branch=z9hG4bK77ef4c2312983.1

;received=192.0.2.2






CSeq: 314159 INVITE



Contact: “B” adds a “Contact” header field to the response, with its direct route



message.


DES Page :32/40



SIP/2.0 180 Ringing


;received=192.0.2.2






CSeq: 314159 INVITE




2.3.6- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->| -“P1” forwards the 180 response message by using the “Via” headers.

M8

SIP/2.0 180 Ringing






CSeq: 314159 INVITE



Via: P1 delete its own “Via” header in the routing path (bigbox3.site3.atlanta.com).


DES Page :33/40



M9

SIP/2.0 200 OK


Via: SIP/2.0/UDP






CSeq: 314159 INVITE





(sip:[email protected]). “B” obtains this value from the Request-URI of the incoming request (M4).


message.

2.3.8- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->| -“P2” forwards the 200 response message by using the “Via” headers.

M10

SIP/2.0 200 OK

Via: SIP/2.0/UDP






CSeq: 314159 INVITE






DES Page :34/40



SIP/2.0 200 OK





CSeq: 314159 INVITE




Via: P1 delete its own via “Via” header in the routing path



-“A” inspects the received message (M11). Then it stores : The “B” “Contact” header ([email protected]) in its UA “dialog data

structure” as “Remote Target”. The “Record-Route” headers in its UA “dialog data structure” as “Route Set”

(bigbox3.site3.atlanta.com ; server10.biloxi.com).

-“A” creates the ACK request. -“A” adds the “Route” headers using the stored “Route Set” (server10.biloxi.com).

-“A” sends the ACK request by using the unique value of “Route Set” (server10.biloxi.com).

M12



Max-Forwards: 70




CSeq: 314159 ACK



DES Page :35/40


Request-URI: “A” fills the Request-URI value, with “Remote Target” value of UA

dialog data structure ([email protected]) (see 2.3.4-). Route: contains the addresses that they will used to route the message. (Its value

was the previously recorded “Route Set”) (server10.biloxi.com) (see 2.3.4-).


-“P2” inspects the Request-URI of the received message (M12), and does not change it because is not responsible for the resource indicated in this URI (it is

responsible for “biloxi.com”, not “term24.biloxi.com”). -“P2” sees that it is the first value in the “Route” header field so it removes that



M13





Max-Forwards: 69




CSeq: 314159 ACK


Via: P2 adds its own “Via” header in the routing path (server10.biloxi.com). Route: P2 delete its own “Route” header in the routing path (server10.biloxi.com).


DES Page :36/40


-“B” creates a BYE message. -“B” adds “Route” headers using the data stored at “Route Set”

(server10.biloxi.com) (see 2.3.4-). -“B” sets “Request-URI” header using the data stored at “Remote

Target”([email protected]) (see 2.3.4-). -“B” sends the ACK request by using the first value of “Route Set”.

(server10.biloxi.com)

M14



Max-Forwards: 70




CSeq: 231 BYE


Route: sip:server10.biloxi.com


Request-URI: “B” fills the Request-URI value, with “Remote Target” value of UA dialog data structure ([email protected]) (see 2.3.4-).

Route: contains the addresses that they will used to route the message. (Its value was the previously recorded “Route Set”) (server10.biloxi.com).


DES Page :37/40

2.2.13- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->| -“P2” inspects the Request-URI of the received message (M15), and does not

change it because is not responsible for the resource indicated in this URI.. -“P2” sees that it is the first value in the “Route” header field so it removes that



M15




Max-Forwards: 69




CSeq: 231 BYE



Via: P2 adds its own “Via” header in the routing path (server10.biloxi.com).

Route: P2 delete its own “Route” header in the routing path (server10.biloxi.com).

2.3.14- A P1 P2 B |---M1(INV)-->|---M2(INV)-->|---M4(INV)-->| |<--M8(180)---|<--M7(180)---|<--M6(180)---| |<--M11(200)--|<--M10(200)--|<--M9(200)---| |---------M12(ACK)--------->|---M13(ACK)->| |<--------M15(BYE)----------|<--M14(BYE)--| |---------M16(200)--------->|---M17(200)->| -“A” creates a 200 OK response to respond to the BYE message.


M16

SIP/2.0 200 OK






CSeq: 231 BYE


DES Page :38/40



SIP/2.0 200 OK





CSeq: 231 BYE


Via: P2 deletes its own “Via” header in the routing path (server10.biloxi.com).


DES Page :39/40

3 UA DIALOG STRUCTURES:

In the UA there are data structures that are used to store dialogues’ states

and necessary parameters for the interchange of messages. In the previous sections, we mentioned some of these parameters. In this section we will

enumerate these parameters. This data structures are not standarised, but through its use on “best

practices” they became in a defacto design standard.

Figure Nº1: UA dialog structure

Note than exists a field named “Other parameters”, in this field I grouped

some existing fields, that I will mention briefly.

3.1 Fields description:

Each UA can behave like UAS or UAC for different dialogues. One UA will behave like UAC if it sends requests in a certain dialog and one UA will behave like

UAS if it sends responses in a certain dialog. Some of the fields of the UA dialog structure take its value in different form if the UA acts as an UAC or an UAS.

Figure Nº2: UAC-UAS scheme.

In the following lines I will give a description of the structure’s fields. Between square brackets will be added the related SIP header in each case.

Call-Id [Call-Id]: This field stores de Call-ID of the call. A generated Call-Id for UAC (see 2.1.1) or a received Call-ID for UAS (see 2.1.4).

Local Tag [From(UAC);To(UAS)]: This field stores the generated local tag used in the “From” header in the UAC (see 2.1.1) or the generated local tag for the “To”

header in the UAS (see 2.1.4).


DES Page :40/40

Remote Tag [To(UAC);From(UAS)]: This field stores the received tag in the “From”

header in the UAC (see 2.1.6 - “A” node) or the received tag in the “To” header in

the UAS (see 2.1.4).

Local seqnum[Cseq(UAC)]: This field stores the generated Cseq for UAC (see 2.1.1).

Remote seqnum[Cseq(UAS)]: This field stores the received Cseq for UAS (see

2.1.4).

Local URI [From(UAC);To(UAS)]: This field stores the local URI used in the “From” header in the UAC (see 2.1.1) or in the “To” header in the UAS (see 2.1.4).

Remote URI [To(UAC); From(UAS); Request-URI(UAC*)]: This field stores the remote URI used in the “To” header in the UAC (see 2.1.1) or in the “To” header in

the UAS (see 2.1.4). Under certain conditions this value is used on “Request-URI” by UAC (see 2.1.1 [Condition: In the first INVITE of an outgoing call]).

Local target [Contact]: This field stores the value for “Contact” header. This value is

generated on UAC (see 2.1.1) or obtained from “Request-URI” in UAS(see 2.1.4)/UAC only under certain conditions.

Remote target [Request-URI]: This field stores the value for “Request-URI” header. This value is obtained from “Contact” header in UAS(see 2.1.4)/UAC(see 2.1.6 node

“A”) or generated in UAC under certain conditions.

Route Set[Record-Route, Route]: This field stores the values obtained from “Record-Route” headers and used in “Route” headers.(see 2.2.6 node “A” , see

2.2.4).

Secure flag: This field stores when the UA uses TLS for signalling or SRTP for audio

streams. Other parameters: “display” part, “P-Preferred-Identity”,”A-Asserted-Identity”,”Privacy”. The mentioned headers are related to the “local tag” identification through public networks. The values that they can take depend on the

country network “id” parameters and interconnection terms.

d basic flows-routing-issues-vt00r00

Engineering