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:bob@biloxi.com”, where “biloxi.com” is the domain of Bob's SIP service provider. Alice has a SIP URI of “sip:alice@atlanta.com”.

Note than “sip:bob@biloxi.com” and “sip:alice@atlanta.com” 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:bob@biloxi.com 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).

INVITE sip:bob@biloxi.com SIP/2.0

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

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Header’s commentaries:

Request-URI: contains a SIP or SIPS URI (sip:bob@biloxi.com) 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:bob@biloxi.com) towards which the request

was originally directed. From: also contains a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the

originator of the request.

Contact: contains a SIP or SIPS URI (sip:alice@pc33.atlanta.com) 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:bob@biloxi.com) 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:bob@biloxi.com) by applying DHCP/DNS procedures.

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:bob@biloxi.com). It is responsible for “biloxi.com”, so it runs a location service and rewrites the

“Request-URI” (sip:bob@biloxi.com -> sip:bob@term24.biloxi.com) -“P2” forwards the request to the resource indicated in the “Request-URI” (sip:

bob@term24.biloxi.com) by applying DHCP/DNS procedures. M4

INVITE sip:bob@term24.biloxi.com SIP/2.0

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”

(alice@pc33.atlanta.com) 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.

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:bob@biloxi.com>;tag=a6c85cf

Contact: <sip:bob@term24.biloxi.com>

CSeq: 314159 INVITE

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

(sip:bob@term24.biloxi.com). “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

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:bob@term24.biloxi.com). “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(bob@term24.biloxi.com).

ACK sip:bob@term24.biloxi.com SIP/2.0

Max-Forwards: 70

CSeq: 314159 ACK

Request-URI: contains a SIP or SIPS URI (sip:bob@term24.biloxi.com) 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 (alice@pc33.atlanta.com) (see 2.1.4-).

BYE sip:alice@pc33.atlanta.com SIP/2.0

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

Max-Forwards: 70

From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: Alice <sip:alice@atlanta.com>;tag=1928301774

CSeq: 231 BYE

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

structure (alice@pc33.atlanta.com) (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”.

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:bob@biloxi.com”, where “biloxi.com” is the domain of Bob's SIP service

provider. Alice has a SIP URI of “sip:alice@atlanta.com”.

Note than “sip:bob@biloxi.com” and “sip:alice@atlanta.com” 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:bob@biloxi.com 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:bob@biloxi.com) 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:bob@biloxi.com) towards which the request was originally directed.

From: also contains a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the originator of the request.

Contact: contains a SIP or SIPS URI (sip:alice@pc33.atlanta.com) 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:bob@biloxi.com) 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:bob@biloxi.com) 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:bob@biloxi.com -> sip:bob@term24.biloxi.com) -“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” (alice@pc33.atlanta.com).

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” (bob@term24.biloxi.com) 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.

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

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 (bob@term24.biloxi.com) 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 (bob@term24.biloxi.com). 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.

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:bob@term24.biloxi.com) because there are not more “Route” headers, applying DHCP/DNS procedures.

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”(alice@pc33.atlanta.com) (see 2.2.4-). -“B” sends the ACK request by using the first value of “Route Set”.

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

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 (alice@pc33.atlanta.com) (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.

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

(sip:alice@pc33.atlanta.com) because there are not more “Route” headers, applying DHCP/DNS procedures.

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.

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:bob@biloxi.com”, where “biloxi.com” is the domain of Bob's SIP service

provider. Alice has a SIP URI of “sip:alice@atlanta.com”.

Note than “sip:bob@biloxi.com” and “sip:alice@atlanta.com” 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:bob@biloxi.com

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).

Max-Forwards: 70

CSeq: 314159 INVITE

Request-URI: contains a SIP or SIPS URI (sip:bob@biloxi.com) 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:bob@biloxi.com) towards which the request

was originally directed. From: also contains a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the

originator of the request.

Contact: contains a SIP or SIPS URI (sip:alice@pc33.atlanta.com) 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:bob@biloxi.com) 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:bob@biloxi.com) 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:bob@biloxi.com -> sip:bob@term24.biloxi.com) -“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” (alice@pc33.atlanta.com).

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

-“B” uses the “Request-URI” (bob@term24.biloxi.com) 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.

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.

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP

CSeq: 314159 INVITE

(sip:bob@term24.biloxi.com). “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.

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 (bob@term24.biloxi.com) 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).

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 (bob@term24.biloxi.com) (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

(sip:bob@term24.biloxi.com) because there are not more “Route” headers, applying DHCP/DNS procedures.

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”(alice@pc33.atlanta.com) (see 2.3.4-). -“B” sends the ACK request by using the first value of “Route Set”.

(server10.biloxi.com)

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 (alice@pc33.atlanta.com) (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

(sip:alice@pc33.atlanta.com) because there are not more “Route” headers, applying DHCP/DNS procedures.

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.

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

value flows: inter-domain routing over contract links

asymmetric routing and other fortigate layer 2 instalation...

compressible flows 1 - lth · issues related to...

chapter 10 cash flows and other issues in capital budgeting

issues of routing in vanet - diva...

4.2 routing algorithms - rutgers...

location-routing: issues, models and methods -...

routing issues in mobile ip sudarshan vasudevan chun zhang

flows issues

efficient fault recovery two phase routing for voip ... ·...

link and routing issues for internet protocols in space

flood routing 2 review of energy conservation energy grade...

identifying problematic inter-domain routing issues

ernakulam – i cluster · cloud computing concepts...

scaling issues with routing+multihoming

e-flows in indian river basins – methodologies, issues...

remote sensing of complex flows by doppler wind lidar:...

open issues in interdomain routing: a survey

technologies, routing policies and relationships between...

performance issues of mac and routing protocols in