in2EPS
IETF ›  RFC index  ~~  Areas/Groups  ~~  Stats  ~~  SIP  ~~  SEC  ~~  QoS
3GPP ›  TS/TR series  ~~  Glossaries  ~~  RELxx  ~~  EPC  ~~  IMS  ~~  subsData  ~~  UICC
ETSI ›  SCP  ~~  M2M  ~~  LI
OMA
 
 
 
›  Search

SIP – Session Initiation Protocol

RFC 3261 example SIP Protocol structure SIP Dialogs & Routing SIP Service examples RFC 3665-6 examples
### ABNF for SIP:  ### ABNF for SDP:  ### other ABNFs:
Messages   › URIs   › Response Codes   › Common Rules Session Description Fields ABNF Notation   › MSRP
Headers (A to G)   › Headers (H to R)   › Headers (S to Z)   › P-Headers Payload Types & Addressing Generic URI   › IMF

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 that 100 Trying provisional responses are not shown.
SIP Dialogs and Routing of Requests
Top Prev Next   1) INVITE  2) 180 Ringing  3) 200 OK  4) ACK  5) BYE  6) 200 OK 

Route and Record-Route in SIP INVITE request

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.
SIP Dialogs and Routing of Requests
Top Prev Next   1) INVITE  2) 180 Ringing  3) 200 OK  4) ACK  5) BYE  6) 200 OK 

SIP early Dialog state with SIP 180 Ringing  response

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.
SIP Dialogs and Routing of Requests
Top Prev Next   1) INVITE  2) 180 Ringing  3) 200 OK  4) ACK  5) BYE  6) 200 OK 

SIP confirmed Dialog state with SIP 200 OK  response

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.
SIP Dialogs and Routing of Requests
Top Prev Next   1) INVITE  2) 180 Ringing  3) 200 OK  4) ACK  5) BYE  6) 200 OK 

SIP ACK request during SIP Dialog establishment

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.
SIP Dialogs and Routing of Requests
Top Prev Next   1) INVITE  2) 180 Ringing  3) 200 OK  4) ACK  5) BYE  6) 200 OK 

SIP BYE request

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.
SIP Dialogs and Routing of Requests
Top Prev Next   1) INVITE  2) 180 Ringing  3) 200 OK  4) ACK  5) BYE  6) 200 OK 

SIP 200 OK response to SIP BYE request

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