SIP Emulator: Rules to Update Headers

The SIP emulator build the messages to be sent from message templates. The SIP profile includes message templates for most messages sent during call or registration.

Depending on current state and protocol settings, some parts of the message should be automatically updated: start-line, headers, bodies. For example, the Request-URI of the startline depends on the method, the To header, the proxy settings, ...

The user can disable this auto-update feature.

The behavior of the emulator depends on the type of message to build, and on the current state:

1.     REQUEST

1.1     REQUEST  Out of a dialog:

1.1.1     Start line

If update of the Start-Line is allowed, the Request-URI is replaced:

•  removal of the initial Request-URI of the message template

•  insertion of  a Request-URI. The UAC uses the remote target and route set to build the Request-URI of the request:

  • If the route set is empty, the UAC MUST place the remote target URI into the Request-URI.

  • If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI.

  • If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI.

RFC 3261 12.2.1.1

1.1.2     Messages headers

1.1.2.1     Call-ID

If update of the Call-ID is allowed, the Call-ID header is replaced:

•  removal of the initial Call-ID of the message template, if present

• addition of a new Call-ID header with the form "localid@host":

  •  localid: random value

  •  host: host name from TCP/IP sockets parameters

RFC 3261 8.1.1.4 , 20.8

1.1.2.1     Contact

If update of the Contact header field is allowed, the host of the first Contact header is modified:

•  the host part of the first Contact-URI is set to the value of hostname from TCP/IP sockets parameters.

RFC 3261 8.1.1.8 , 20.10

1.1.2.2     Cseq

If update of the CSeq header field is allowed, the CSeq header is replaced:

• removal of the initial CSeq of the message template, if present

• addition of a new CSeq header:

  • INVITE or OPTION: the CSeq method is set to "INVITE" or "OPTION", and the CSeq number is arbitrary initialized to 10

  • REGISTER: the CSeq method is set to "REGISTER", the CSeq number is initialized with current value from registration context, and the value in the context is updated.

RFC 3261 8.1.1.5 ,  20.16

1.1.2.3     From

• If update of the From header field is allowed, the host and tag values of the  From header are modified.

RFC 3261 8.1.1.3 , 20.20

1.1.2.3.1     From URL

The host part of the From-URI is set to the value of hostname from TCP/IP sockets parameters.

1.1.2.3.2     From Tag

The tag is set to a new random value.

1.1.2.4     Routes

If update of the Routes header field is allowed, Record-Route headers are modified by the SIP emulator:

• removal of all Route headers of the message template, if present

• addition a Route header if a Proxy-URI is specified in SIP protocol parameters:

• if  the Proxy-URI has a "lr" parameter, set a Route header field containing the Proxy-URI

• else, set a Route header field containing the URI of the To header

RFC 3261 16.12 , 20.34

1.1.2.5     Via 

If update of the Via header field is allowed, Via header is modified by the SIP emulator:

• removal of initial Via header of the message template, if present

• addition of a new Via header with:

  • transport protocol  and port number according to protocol selected in SIP protocol parameters

  • host set to the value of hostname from TCP/IP sockets parameters

  • branch value set to a new random value starting with the magic cookie "z9hG4bK"

  • rport parameter

RFC 3261 8.1.1.7 , 20.42

1.1.3     Message Body

1.2     REQUEST Within a dialog:

1.2.1     Start line

If update of the Start-Line is allowed, the Request-URI is replaced:

• removal of the initial Request-URI of the message template

• insertion of  a Request-URI. The UAC uses the remote target and route set to build the Request-URI of the request:

  •    If the route set is empty, the UAC MUST place the remote target URI into the Request-URI.

  •    If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI.

  •    If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI.

RFC 3261 12.2.1.1

1.2.2     Messages headers

1.2.2.1     Call-ID

If update of the Call-ID is allowed, the Call-ID header is replaced:

• removal of the initial Call-ID of the message template, if present

• addition of a new Call-ID header:  The Call-ID of the request MUST be set to the Call-ID of the dialog.

RFC 3261 12.2.1.1

1.2.2.2     Cseq

If update of the CSeq header field is allowed, the CSeq header is replaced:

• removal of the initial CSeq of the message template, if present

• addition of a new CSeq header. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled).  The value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. The method field in the CSeq header field value MUST match the method of the request.

RFC 3261 8.1.1.5 ,  12.2.1.1

1.2.2.3     From

If update of the From header field is allowed, the From header is replaced:

• removal of the initial From of the message template, if present

• addition of a new From header. The From URI of the request MUST be set to the local URI from the dialog state.  The tag in the From header field of the request MUST be set to the local tag of the dialog ID.  If the value of the remote or local tags is null, the tag parameter MUST be omitted from the To or From header fields, respectively.

RFC 3261 8.1.1.3 , 12.2.1.1

1.2.2.4     Routes

If update of the Routes header field is allowed, Record-Route headers are replaced by the SIP emulator:

• removal of all Route headers of the message template, if present

• addition of new Route headers.:

•  If the route set is empty, the UAC MUST NOT add a Route header field to the request.

• If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST include a Route header field containing the route set values in order, including all parameters.

•  If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST add a Route header field containing the route set values in order except first URI, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value.

RFC 3261 12.2.1.1

1.2.2.5     To

If update of the To header field is allowed, the To header is replaced:

• removal of the initial To of the message template, if present

• addition of a new To header. The To URI of the request MUST be set to the remote URI from the dialog state.  The tag in the To header field of the request MUST be set to the remote tag of the dialog ID.  If the value of the remote or local tags is null, the tag parameter MUST be omitted from the To or From header fields, respectively.

RFC 3261 12.2.1.1

1.2.2.6     Via

If update of the Via header field is allowed, Via header is modified by the SIP emulator:

• removal of initial Via header of the message template, if present

• addition of a new Via header with:

  • transport protocol  and port number according to protocol selected in SIP protocol parameters

  • host set to the value of hostname from TCP/IP sockets parameters

  • branch value set to a new random value starting with the magic cookie "z9hG4bK"

  • rport parameter

RGFC 3261 8.1.1.7 , 20.42

1.2.3     Message Body

1.3     CANCEL

1.3.1     Start line

If update of the Start-Line is allowed, the Request-URI is replaced:

• removal of the initial method and Request-URI of the message template

• insertion of  CANCEL method and Request-URI.  The Request-URI in the CANCEL request MUST be the same as in the request being cancelled.

RFC 3261 9.1

1.3.2     Messages headers

1.3.2.1     Call-ID

If update of the Call-ID is allowed, the Call-ID header is replaced:

• removal of the initial Call-ID of the message template, if present

• addition of a new Call-ID header.  The Call-ID header fields in the CANCEL request MUST be the same as in the request being cancelled.

RFC 3261 9.1

1.3.2.2     Cseq

If update of the CSeq header field is allowed, the CSeq header is replaced:

• removal of the initial CSeq of the message template, if present

• addition of a new CSeq header. addition of a new Call-ID header.  The numeric part of CSeq fields in the CANCEL request MUST be the same as in the request being cancelled. The method part of the CSeq header field MUST have a value of CANCEL

RFC 3261 9.1

1.3.2.3     From

If update of the From header field is allowed, the From header is replaced:

• removal of the initial From of the message template, if present

• addition of a new From header. addition of a new Call-ID header.  The From header fields in the CANCEL request MUST be the same as in the request being cancelled, including tags.

RFC 3261 9.1

1.3.2.4     Routes

If update of the Routes header field is allowed, Record-Route headers are replaced by the SIP emulator:

• removal of all Route headers of the message template, if present

• addition of new Route headers. If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values. If the route set is empty, the UAC MUST NOT add a Route header field to the request.

RFC 3261 9.1

1.3.2.5     To

If update of the To header field is allowed, the To header is replaced:

• removal of the initial To of the message template, if present

• addition of a new To header. The To header fields in the CANCEL request MUST be the same as in the request being cancelled, including tags.

RFC 3261 9.1

1.3.2.6     Via

If update of the Via header field is allowed, Via header is modified by the SIP emulator:

• removal of initial Via header of the message template, if present

• addition of a new Via header. A CANCEL constructed by a client MUST have only a single Via header field value matching the  top Via value in the request being cancelled.

RGFC 3261 9.1

1.3.3     Message Body

1.4     REQUEST With Authentication

When a 401 or 407 response is received and if proper authentication information is available in the protocol parameters, the SIP emulator creates a new transaction to send the original request with additional authentication headers. To build the new request, the initial request is cloned and is used as a template for the new one.

As for other REQUEST, some header fields are optionally updated.

1.4.1.1     CSeq

If update of the CSeq header field is allowed, the CSeq header is updated. The value of the local sequence number is incremented by one, and this value is placed into the CSeq header field

RFC 3261 8.1.1.5 ,  12.2.1.1

1.4.1.2     Via

If update of the Via header field is allowed, Via header is modified by the SIP emulator:

• removal of initial Via header of the message template, if present

• addition of a new Via header with:

  • transport protocol  and port number according to protocol selected in SIP protocol parameters

  • host set to the value of hostname from TCP/IP sockets parameters

  • branch value set to a new random value starting with the magic cookie "z9hG4bK"

  • rport parameter

RGFC 3261 8.1.1.7 , 20.42

1.4.1.3     Authorization

If update of the Authorization header field is allowed, the Authorization header is added by the SIP emulator if a valid WWW-Authenticate header is present in the 401 response. The Authorization field value consists of credentials containing the authentication information of the user agent.

RFC 3261 20.7

1.4.1.4     Proxy-Authorization 

If update of the Proxy-Authorization header field is allowed, the Proxy-Authorization header is added by the SIP emulator if a valid Proxy-Authenticate header is present in the 407 response. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.

RFC 3261 20.28

 2.     RESPONSE:

2.1     Response common  process

2.1.1     Call-ID 

If update of the Call-ID is allowed, the Call-ID header is replaced:

• removal of the initial Call-ID of the message template, if present

• addition of a new Call-ID header:  The Call-ID of the response is set to the value of the Call-ID of the request.

RFC 3261

2.1.2     CSeq

If update of the CSeq header field is allowed, the CSeq header is replaced:

• removal of the initial CSeq of the message template, if present

• addition of a new CSeq header.  The CSeq of the response is set to the value of the CSeq of the request.

RFC 3261

2.1.3     Contact

If update of the Contact header field is allowed, the host of the first Contact header is modified:

• the host part of the first Contact-URI is set to the value of hostname from TCP/IP sockets parameters.

RFC 3261

2.1.4     From

2.1.5     To

2.1.6   Via

2.2     Response which establish a dialog

2.2.1     Record-Route

2.3     Response to INVITE

2.4     Response to OPTION

• 1.    REQUEST

• 1.1    REQUEST  Out of a dialog:

• 1.1.1   Start line

• 1.1.2   Messages headers

• 1.1.2.1   Call-ID

• 1.1.2.2   Contact

• 1.1.2.3   Cseq   

• 1.1.2.4   From

• 1.1.2.4.1 From URL   

• 1.1.2.4.2 From Tag   

• 1.1.2.5   Routes

• 1.1.2.6   Via 

• 1.1.3   Message Body

• 1.2    REQUEST Within a dialog:

• 1.2.1   Start line

• 1.2.2   Messages headers

• 1.2.2.1   Call-ID 10

• 1.2.2.2   Cseq    10

• 1.2.2.3   From  10

• 1.2.2.4   Routes 11

• 1.2.2.5   To      11

• 1.2.2.6   Via      12

• 1.2.3   Message Body    13

• 1.3    CANCEL 14

• 1.3.1   Start line 14

• 1.3.2   Messages headers 15

• 1.3.2.1   Call-ID 15

• 1.3.2.2   Cseq    15

• 1.3.2.3   From  15

• 1.3.2.4   Routes 16

• 1.3.2.5   To      16

• 1.3.2.6   Via      16

• 1.3.3   Message Body    17

• 1.4    REQUEST With Authentication  18

• 1.4.1.1   CSeq   18

• 1.4.1.2   Via      18

• 1.4.1.3           Authorization          19

• 1.4.1.4   Proxy-Authorization    19

• 2.    RESPONSE:        20

• 2.1    Response common  process 20

• 2.1.1   Call-ID  20

• 2.1.2   CSeq      20

• 2.1.3   Contact 20

• 2.1.4   From     20

• 2.1.5   To         20

• 2.1.6   Via        20

• 2.2    Response which establish a dialog 20

• 2.2.1   Record-Route   20

• 2.3    Response to INVITE             20

• 2.4    Response to OPTION           20

home     Quick start     Specifications     Connections     Features     How to?     Notes     Search     Site Map

updated:  27-Feb-04