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 sequence of figures illustrates the creation of a dialog, the
processing of requests during this dialog, and the termination of the dialog.
This example shows two proxies that 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.
Note: 100 Trying provisional responses are not shown.
|
|
|
|
|
|
|
|
| U1: |
| - |
generates the INVITE request;
|
| - |
in this example, U1 is configured with a Route set containing
a single URI,
that of the outbound proxy (<sip:p1.atlanta.com;lr>);
it applies DNS procedures to this URI for determining where to send the request.
|
|
|
| P1: |
| - |
inspects the Request-URI (sip:bob@biloxi.com) and does not change it because it is not responsible
for the resource indicated in this URI;
|
| - |
sees that it is the first value in the Route header field
so it removes that value;
|
| - |
adds a Record-Route header field value;
|
| - |
forwards the request to the resource indicated in the Request-URI
(the route set is now empty)
by applying DNS procedures.
|
|
|
| P2: |
| - |
inspects the Request-URI: it is responsible
for "biloxi.com" so it runs a location service and rewrites the Request-URI (sip:bob@u2.biloxi.com);
|
| - |
adds a Record-Route header field value;
|
| - |
forwards the request to the resource indicated in the
Request-URI (the route set is empty)
by applying DNS procedures.
|
|
|
|
|
|
|
|
|
|
|
| U2: |
| - |
creates an 'early' dialog by answering with a provisional response with
a To tag;
|
| - |
copies all Record-Route headers from the request
into the response;
|
| - |
adds a Contact header field to the response;
|
| - |
constructs the state of the dialog:
|
|
| - |
the Route set is set to the list of URIs
in the Record-Route header fields from the request,
taken in order and preserving all URI parameters;
|
| - |
the remote target is set to the URI
from the Contact header field of the request;
|
| - |
the remote sequence number is set to the value of the sequence
number in the CSeq header field of the request;
|
| - |
the local sequence number is empty;
|
| - |
the call identifier component of the dialog ID
is set to the value of the Call-ID field in the request;
|
| - |
the local tag component of the dialog ID is set to the tag in the
To field
in the response to the request;
|
| - |
the remote tag component of the dialog ID is set to the tag from the
From field in the request;
|
| - |
the remote URI is set to the URI in the
From field;
|
| - |
the local URI is set to the URI in the
To field.
|
|
| - |
sends the 180 response by using the Via header fields
(not shown).
|
|
|
| P2: |
| - |
forwards the 180 response by using the Via header fields
(not shown).
|
|
|
| P1: |
| - |
forwards the 180 response by using the Via header fields
(not shown).
|
|
|
| U1: |
| - |
establishes an 'early' dialog when receiving the provisional response with
a To tag;
|
| - |
constructs the state of the dialog:
|
|
| - |
the Route set is set to the list of URIs
in the Record-Route header fields from the response,
taken in reverse order and preserving all URI parameters;
|
| - |
the remote target is set to the URI
from the Contact header field of the response;
|
| - |
the local sequence number is set to the value of the sequence
number in the CSeq header field of the request;
|
| - |
the remote sequence number is empty;
|
| - |
the call identifier component of the dialog ID
is set to the value of the Call-ID field in the request;
|
| - |
the local tag component of the dialog ID is set to the tag in the
From field
in the request;
|
| - |
the remote tag component of the dialog ID is set to the tag in the
To field of the response;
|
| - |
the remote URI is set to the URI in the
To field;
|
| - |
the local URI is set to the URI in the
From field.
|
|
|
|
|
|
|
|
|
|
|
|
| U2: |
| - |
confirms the dialog by sending a final response to the INVITE request;
|
| - |
sends the 200 response by using the Via header fields
(not shown).
|
|
|
| P2: |
| - |
forwards the 200 response by using the Via header fields
(not shown).
|
|
|
| P1: |
| - |
forwards the 200 response by using the Via header fields
(not shown).
|
|
|
| U1: |
| - |
passes its dialog state to 'confirmed' when receiving the final response
to its INVITE request.
|
|
|
|
|
|
|
|
|
|
|
| U1: |
| - |
generates the ACK request by using many of the
components of the state stored as part of the dialog:
|
|
| - |
the URI in the To field of the request
is set to the remote URI from the dialog state;
|
| - |
the tag in the To header field of the request
is set to the remote tag of the dialog ID;
|
| - |
the From URI of the
request is set to the local URI from the dialog state;
|
| - |
the tag in the From header field of the request
is set to the local tag of the dialog ID;
|
| - |
the Call-ID of the request is set to the Call-ID
of the dialog;
|
|
| - |
uses the remote target and route set to build the Request-URI
and Route header field of the request:
|
|
| - |
the route set is not empty, and the first URI in the route set
contains the lr (loose routing) parameter: the UAC places
the remote target URI into the Request-URI
and includes a Route
header field containing the route set values in order, including all
parameters;
|
| - |
note: if the route set was empty, the UAC would place the remote target URI
into the Request-URI and would not add a Route header field to
the request;
|
|
|
|
| P1: |
| - |
inspects the Request-URI (sip:bob@u2.biloxi.com) and
does not change it because it is not responsible
for the resource indicated in this URI;
|
| - |
sees that it is the first value in the Route header field
so it removes that value;
|
| - |
forwards the request to the resource indicated in the topmost
Route header field
by applying DNS procedures.
|
|
|
| P2: |
| - |
inspects the Request-URI: it is not responsible
for "u2.biloxi.com" (it is responsible for "biloxi.com", not "u2.biloxi.com")
so it does not change it;
|
| - |
sees that it is the first value in the Route header field
so it removes that value;
|
| - |
forwards the request to the resource indicated in the
Request-URI (the route set now is empty)
by applying DNS procedures.
|
|
|
|
|
|
|
|
|
|
|
| U2: |
| - |
generates the BYE request by using many of the
components of the state stored as part of the dialog:
|
|
| - |
the URI in the To field of the request
is set to the remote URI from the dialog state;
|
| - |
the tag in the To header field of the request
is set to the remote tag of the dialog ID;
|
| - |
the From URI of the
request is set to the local URI from the dialog state;
|
| - |
the tag in the From header field of the request
is set to the local tag of the dialog ID;
|
| - |
the Call-ID of the request is set to the Call-ID
of the dialog;
|
|
| - |
uses the remote target and route set to build the Request-URI
and Route header field of the request:
|
|
| - |
the route set is not empty, and the first URI in the route set
contains the lr (loose routing) parameter: the UAC places
the remote target URI into the Request-URI
and includes a Route
header field containing the route set values in order, including all
parameters;
|
| - |
note: if the route set was empty, the UAC would place the remote target URI
into the Request-URI and would not add a Route header field to
the request;
|
|
|
|
| P2: |
| - |
inspects the Request-URI (sip:alice@u1.atlanta.com) and
does not change it because it is not responsible
for the resource indicated in this URI;
|
| - |
sees that it is the first value in the Route header field
so it removes that value;
|
| - |
forwards the request to the resource indicated in the topmost
Route header field
by applying DNS procedures.
|
|
|
| P1: |
| - |
inspects the Request-URI: it is not responsible
for "u1.atlanta.com" (it is responsible for "atlanta.com", not "u1.atlanta.com")
so it does not change it;
|
| - |
sees that it is the first value in the Route header field
so it removes that value;
|
| - |
forwards the request to the resource indicated in the
Request-URI (the route set now is empty)
by applying DNS procedures.
|
|
|
|
|
|
|
|
|
|
|
| U1: |
| - |
sends the 200 response by using the Via header fields
(not shown).
|
|
|
| P1: |
| - |
forwards the 200 response by using the Via header fields
(not shown).
|
|
|
| P2: |
| - |
forwards the 200 response by using the Via header fields
(not shown).
|
|
|
|
|
|
|
|
