Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)

A Framework for Application Interaction in the Session Initiation Protocol (SIP)

“…For interface components that are presentation capable, the application sends a REFER [7] request to the user agent. The Refer-To header field contains an HTTP URI that points to the markup for the user interface, and the REFER contains a Target-Dialog header field [10] which identifies the dialog associated with the user interface component. For user interface components that are presentation free (such as those defined by KPML), the application sends a SUBSCRIBE request to the user agent.…”

“…If the Allow header field indicates support for the SIP REFER method, and the Supported header field indicates support for the TargetDialog header field [10], and the Contact header field contains UA capabilities [6] that indicate support for the HTTP URI scheme, it means that the UA supports presentation-capable user interface components. In this case, the application can push presentationcapable user interface components to the client according to the rules of Section 8.1.2.…”

Multiple Dialog Usages in the Session Initiation Protocol

“…The Target-Dialog header field [10] was created to address problems 2 and 3. This header field allows a request to indicate the dialog identifiers of some other dialog, providing association with the other dialog that can be used in an authorization decision.…”

The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular

“…However, there is no guarantee that the media will be received by the final recipient that was indicated in the Refer-To header in the original SIP REFER request. The dialog could be related either because the SIP REFER request was sent on the same dialog or because the SIP REFER request contained a Target-Dialog header, as defined in [16], that identified the dialog.…”

“…Also, it MAY buffer any media it receives until the UAC part of its back-to-back UA receives a "Confirmed Response" from the final destination UA or until its buffer is full. The dialog could be related either because the SIP REFER request was sent on the same dialog or because the SIP REFER request contained a Target-Dialog header, as defined in [16], that identified the dialog.…”