SIP Header: Difference between revisions
| Line 15: | Line 15: | ||
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'. | 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 | 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. | : 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. | : 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. | ||
Revision as of 09:32, 3 October 2019
Overview
SIP headers 내용 정리
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
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