SIP Header

Overview

SIP headers 내용 정리

Basic

SIP and SIPS URIs

SIP URIs are used in a number of places including the To, From, and Contact headers, as well as in the Request-URI, which indicates the destination. SIP URIs are similar to the mailto URL and can be used in hyperlinks on Web page, for example. They can also include telephone numbers. The information in a SIP URL incidates the way in which the resource (user) should be contacted using SIP.

An example SIP URI contains the scheme sip a :, then a username@host or IPv4 or IPv6 address followed by an optional :, then port number, or a list of ; separated URI parameters.

sip:pchero.sungtae@pchero21.com:5060;transport=udp;user=ip;method=INVITE;ttl=1;maddr=240.101.102.103?Subject=FFT

Note that URIs may not contain spaces or line breaks, so this example would be on a single line. Some SIP URIs, such as REGISTER Request-URI do not have a username, but begin with the host or IP address. In this example, the port number is shown as 5060, the well-known port number for SIP. For a SIP number 5061 is assumed. The transport parameter indicates UDP is to be used, which is the default. TCP, TLS, and SCTP are alternative transport parameters.

The user parameter is used by parsers to determine if a telephone number is present in the username portion of the URI. The assumed default is that it is not, indicated by the value ip. If a telephone. number is present, it is indicated by the value phone. This parameter must not used to guess at the characteristics or capabilities of the user agent. For example, the presence of a user=phone parameter must not be interpreted that the user agent is a SIP telephone(which may have limited display and processing capabilties). In a telephone environment, IP telephones and IP/PSTN gateways may in fact use the reverse assumption, interpreting any digits in a username as digits regardless of the presence of user=phone.

CSeq

The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values.

CSeq: 4711 INVITE

CSeq 는 메시지의 순서를 파악하는데 사용된다. 각각의 request 메시지마다 1씩 증가하게 되며, 이를 통해서 메시지의 순서를 확인할 수 있다. 만약 이전에 처리한 CSeq 보다 낮은 숫자의 Request 가 오게된다면 500 response 를 보내야 한다. 하지만 CSeq 는 종종 한번에 1 이상씩 증가할 수도 있다. 하지만 이는 에러가 아니며, 메시지는 정상적으로 처리되게 된다.

UAC behavior =

The Call-ID of the request MUST be set to the Call-ID of the dialog. 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 canceled). Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines.

UAS behavior

If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than remote sequence number, the request is out of order and MUST be rejected with a 500 (Server internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence umber by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request.

If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition.

When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in the request, if present.

Max-Forwards

The Max-Forwards header field is used to indicate the maximum number of hops that a SIP request may take. The value of the header field is decremented by each proxy that forwards the request. A proxy receiving the header field with a value of zero discards the message and sends a 403 Too Many Hops response back to the originator.

Max-Forwards is a mandatory header field in requests generated by an RFC 3261 compliant UA. However, an RFC 2543 UA generally will not include the header field. The suggested initial value is 70 hops.

Max-Forwards: 70

P-Asserted-Identity

P-Asserted-Identity is a special type of UA identity implying "This is the proven ID for me within this trusted network".

Usually, UA ID is set in 'From' header, but the From header does not necessarily contain the actual identity. Actually, you can put any kind of string for 'From' header. Therefore, once the authentication is complete for a UA, a proxy can add P-Asserted-Identity to inform other proxies saying 'Hey, this is a proven ID. So you can trust'.

From the RFC 3325, 9.1 The P-Asserted-Identity header:

The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries)to carry the identity of the user sending a SIP message as it was verified by authentication.

A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) add and remove this header field.

P-Asserted-Identity: tel:+123456789
P-Asserted-Identity: "sungtae kim" <sip:pchero@pchero21.com>

• https://i3forum.org/wp-content/uploads/2019/06/i3f_CLI_management_guidelines_rev-1.pdf

Record-Route

The Record-Route header field is used to force routing through a proxy for all subsequent requests in a session(dialog) between two UAs. Normally, the presence of a Contact header field allows UAs to send messages directly bypassing the proxy chain used in the initial request (which probably involved database lookups to locate the called party). A proxy inserting its address into a Record-Route header field overrides this and forces future requests to include a Route header field containing the address of the proxy that forces this proxy to be included.

A proxy wishing to implement this inserts the header field containing its own URI, or adds it URI to an already present Record-Route header field. The URI is constructed so that the URI resolves back to the proxy server. The UAS copies the Record-Route header field into the 200 OK response to the request. The header field is forwarded unchanged by proxies back to the UAC. The UAC then stores the Record-Route proxy list plus a Contact header field if present in the 200 OK for use in a Route header field in all subsequent requests. Because Record-Route is bidirectional, messages in the reverse direction will also traverse the same set of proxies.

The 'lr' parameter is new to RFC 3261 and indicates that the proxy server supports "loose routing".

Older RFC 2543 compliant proxy servers create Record-Route URIs that instead of the lr parameter often contain the maddr parameter with an address or host that resolves to that proxy server.

Record-Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>
Record-Route: <sip:192.168.0.237;transport=tcp;lr;r2=on>

Record-Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>,<sip:192.168.0.237;transport=tcp;lr;r2=on>

Request line URI

The Request line URI includes the destination of the call. It contains the same information as the To field, omitting the display name.

Route

The Route header field is used to provide routing information for requests. RFC 3261 introduces two types of routing: strict and loose routing, which have a similar meaning as the IP routing modes of the same name. In strict routing, a proxy must use the first URI in the Route header field to rewrite the Request-URI, which is then forwarded. In loose routing, a proxy does not rewrite the Request-URI, but either forwards the request to the first URI in the Route header field or to another loose routing element.

In loose routing, the request must route through every server in the Route list(but may also route through other servers) before it may be routed based on the Request-URI.

In strict routing, the request must only route through the set of server in the Route header field with the Request-URI being rewritten at each hop.

A proxy or UAC can tell if the next element in the route set supports loose routing by the presence of an 'lr' parameter.

Route: <sip:192.168.0.237;transport=tcp;lr;r2=on>
Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>

Route: <sip:192.168.0.237;transport=tcp;lr;r2=on>, Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>

Session-Expires

The Session-Expires header field is used to specify the expiration time of the session. To extend the session, either UA can send a re-INVITE or UPDATE with a new Session-Expires header field.

At the expiration of the interval in the Session-Expires, either UA may send a BYE and call-stateful proxies may destroy any state information. A proxy may shorten the expiration time by reducing the interval in the header field as it proxies the request.

A UAS confirms the session timer by including the Session-Expires header field in the response to the request. A UAS may also shorten the interval by reducing the interval.

Session-Expires: 1800

Btw, the UA can expire the session before the session expiration. The RFC-4028 recommends 32-secs for early expiration. Here is a detailed description. In this case, the UA should send the BYE.

https://www.rfc-editor.org/rfc/rfc4028.html#section-10

   Similarly, if the side not performing refreshes does not receive a
   session refresh request before the session expiration, it SHOULD send
   a BYE to terminate the session, slightly before the session
   expiration.  The minimum of 32 seconds and one third of the session
   interval is RECOMMENDED.

And the Asterisk(PJSIP) follows this 32-sec recommendation.

https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_timer.c#L518

    } else {
        /* Send BYE if no refresh received until this timer fired, delay
         * is the minimum of 32 seconds and one third of the session interval
         * before session expiration.
         */
        delay.sec = timer->setting.sess_expires - 
                    timer->setting.sess_expires/3;
        delay.sec = PJ_MAX((long)timer->setting.sess_expires-32, delay.sec);
    }

To

The To header field is required header field in every SIP message used to indicate the recipient of the request. Any responses generated by a UA will contain this header field with the addition of a tag. (Note tha t an RFC 2543 client will typically only generate a tag if more than one Via header field is present in the request.) Any response generated by a proxy must have a tag added to the To header field. A tag added to the header field in a 200 OK response is used throughout the call and incorporated into the dialog. The To header field URI is never used for routing - the request-URI is used for this purpose. An optional display name can be present in the header field, in which case the SIP URI is enclosed in < >. If the URI contains any parameters or username parameters, the URI must be enclosed in < > even if no display name is present. The compact form of the header fields is t.

Via

Every proxy in the request path adds to top of the "Via" the address and port on which it received the message, than forwards it onwards. When processing responses, each proxy in the return path process the contents of the "Via" field in reverse order, removing its address from the top.

See also

• https://www.3cx.com/blog/voip-howto/sip-invite-header-fields - The main SIP INVITE Header Fields explained