| The From header field indicates the logical identity of the initiator
of the request, possibly the user's address-of-record. This may be different
from the initiator of the dialog. Requests sent by the callee to the caller
use the callee's address in the From header field.
Like the To header field, it contains a URI and optionally a display name,
encapsulated in a
javax.sip.address.Address . It is used by SIP
elements to determine which processing rules to apply to a request (for
example, automatic call rejection). As such, it is very important that the
From URI not contain IP addresses or the FQDN of the host on which the UA is
running, since these are not logical names.
The From header field allows for a display name. A UAC SHOULD use
the display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
identity of the client is to remain hidden.
Usually, the value that populates the From header field in requests
generated by a particular UA is pre-provisioned by the user or by the
administrators of the user's local domain. If a particular UA is used by
multiple users, it might have switchable profiles that include a URI
corresponding to the identity of the profiled user. Recipients of requests
can authenticate the originator of a request in order to ascertain that
they are who their From header field claims they are.
Two From header fields are equivalent if their URIs match, and their
parameters match. Extension parameters in one header field, not present in
the other are ignored for the purposes of comparison. This means that the
display name and presence or absence of angle brackets do not affect
matching.
- The "Tag" parameter - is used in the To and From header fields of SIP
messages. It serves as a general mechanism to identify a dialog, which is
the combination of the Call-ID along with two tags, one from each
participant in the dialog. When a User Agent sends a request outside of a dialog,
it contains a From tag only, providing "half" of the dialog ID. The dialog
is completed from the response(s), each of which contributes the second half
in the To header field. When a tag is generated by a User Agent for insertion into
a request or response, it MUST be globally unique and cryptographically
random with at least 32 bits of randomness. Besides the requirement for
global uniqueness, the algorithm for generating a tag is implementation
specific. Tags are helpful in fault tolerant systems, where a dialog is to
be recovered on an alternate server after a failure. A UAS can select the
tag in such a way that a backup can recognize a request as part of a dialog
on the failed server, and therefore determine that it should attempt to
recover the dialog and any other state associated with it.
For Example:
From: "Bob" sips:bob@biloxi.com ;tag=a48s
From: sip:+12125551212@phone2net.com;tag=887s
From: Anonymous sip:c8oqz84zk7z@privacy.org;tag=hyh8
author:
BEA Systems, NIST
version:
1.2 |