It generates random identifiers and tags for transactions and dialogs.
Inheritance Hierarchy
Namespace: Ozeki.VoIPAssembly: OzekiSDK (in OzekiSDK.dll) Version: 1.8.12.0 (1.8.12)
Syntax public class SIPIDFactory : IIDFactory
Public Class SIPIDFactory
Implements IIDFactory
public ref class SIPIDFactory : IIDFactory
type SIPIDFactory =
class
interface IIDFactory
end
The SIPIDFactory type exposes the following members.
Constructors
| Name | Description |
---|
| SIPIDFactory | Initializes a new instance of the SIPIDFactory class |
TopMethods Remarks
19.3 Tags
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 UA 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. The forking of
SIP requests means that multiple dialogs can be established from a
single request. This also explains the need for the two-sided dialog
identifier; without a contribution from the recipients, the
originator could not disambiguate the multiple dialogs established
from a single request.
When a tag is generated by a UA for insertion into a request or
response, it MUST be globally unique and cryptographically random
with at least 32 bits of randomness. A property of this selection
requirement is that a UA will place a different tag into the From
header of an INVITE than it would place into the To header of the
response to the same INVITE. This is needed in order for a UA to
invite itself to a session, a common case for "hairpinning" of calls
in PSTN gateways. Similarly, two INVITEs for different calls will
have different From tags, and two responses for different calls will
have different To tags.
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.
See Also