SIP Header

From 탱이의 잡동사니
Jump to navigation Jump to search

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.

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>

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.

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

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

Retrieved from "http://wiki.pchero21.com/index.php?title=SIP_Header&oldid=3870"