3.6.3 Initialization

The SIP proxy SHOULD create one or more tables to maintain the information that spans the lifetime of the dialog and then store an index to this type of table in the Record-Route header field that it inserts into the dialog-creating messages. Specifically, the SIP proxy SHOULD create a table of endpoints that user agents communicating with the proxy represent.

Consequently, the SIP proxy SHOULD add an index to an entry in the endpoint table as a value of the ms-opaque parameter in the Record-Route header field URI which this proxy inserts into the messages, as described in [RFC3261] section 16. When the Record-Route header field URI is then stored in the dialog route set, and later copied to the Route header field of the mid-dialog request, the value of the ms-opaque parameter represents the identity of the UAS endpoint.<17>

Furthermore, the SIP proxy SHOULD add an index to an entry in the endpoint table as a value of the ms-identity parameter of the Record-Route header field URI which this SIP proxy inserts into the messages, as described in [RFC3261] section 16. When the Record-Route header field URI is then stored in the dialog route set and later copied to the Route header field of the mid-dialog request, the value of the ms-identity parameter can represent the identity of the UAC endpoint.<18>

The SIP proxy can add ms-role-rs-to or ms-role-rs-from parameters to the Record-Route header field URI so that when the Record-Route header field URI is stored in the dialog route set, and later copied to the Route header field of the mid-dialog request, the ms-role-rs-to parameter indicates that this SIP proxy is an authorized proxy for the UAS endpoint domain while the ms-role-rs-from parameter indicates that the SIP proxy is an authorized proxy for the domain of the UAC endpoint.<19>

If the SIP server is a member of a set of multiple redundant proxies that appear to share the same FQDN with some or all other SIP elements that communicate with them, the SIP server can add its specific unique FQDN as the value of the ms-fe parameter of the Record-Route or Contact header field URI so that when the Record-Route or Contact header field URI is stored in the dialog route set, and later copied to the Request-URI field or Route header field of the mid-dialog request, the ms-fe parameter contains the unique FQDN of the server.

The SIP proxy can add an ms-ent-dest parameter to the Record-Route header field URI so that when the Record-Route header field URI is stored in the dialog route set, and later copied to the Route header field of the mid-dialog request, the ms-ent-dest parameter indicates that if the SIP proxy is an authorized proxy for the domain of the UAC endpoint, the UAS endpoint belongs to the same domain.<20>

The SIP proxy can combine all state information that it maintains for the endpoints in the dialog that spans the lifetime of the dialog, encode it using a method that produces output that satisfies the SIP URI parameter syntax, such as the method defined in [RFC3548] section 4, and add it as a value of an opaque parameter to the Record-Route header field URI that this SIP proxy inserts into messages, as described in [RFC3261] section 16.<21> When the Record-Route header field URI is then stored in the dialog route set, and later copied to the Route header field of the mid-dialog request, the opaque parameter value can be decoded and all of the information that the proxy previously stored can be made available to it.<22>