Click or drag to resize
SIPIDFactory Class
It generates random identifiers and tags for transactions and dialogs.
Inheritance Hierarchy
SystemObject
  Ozeki.VoIPSIPIDFactory

Namespace: Ozeki.VoIP
Assembly: OzekiSDK (in OzekiSDK.dll) Version: 1.8.12.0 (1.8.12)
Syntax
public class SIPIDFactory : IIDFactory

The SIPIDFactory type exposes the following members.

Constructors
  NameDescription
Public methodSIPIDFactory
Initializes a new instance of the SIPIDFactory class
Top
Methods
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