The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
Extracted elements (29)
Only the generic 'TN' network type is defined rather than specific types like 'ISDN' or 'GSM', and transports are named 'voice', 'fax', 'pager' rather than referencing specific protocols. This deliberately hides underlying telephone network complexity and allows the GSTN to choose implementation details.
The SDP origin-field (global-session-id) rather than the SIP Call-ID is used as the canonical identifier for monitoring sessions, because a SUBSCRIBE from a third party (not the original requestor) constitutes a new SIP call leg and would not share the original Call-ID.
The SUBSCRIBE/NOTIFY/UNSUBSCRIBE mechanism was added because a PINT client is not necessarily a party to the resulting telephone call and therefore has no out-of-band way to learn whether the service succeeded. The design mirrors INVITE/BYE semantics to keep the model consistent with existing SIP.
PINT clients sending included data objects (multipart MIME) SHOULD use TCP to avoid fragmentation and ensure reliable delivery. If the PINT gateway location is unknown and the request is likely to span multiple IP datagrams, it is RECOMMENDED to use a URI reference rather than inline data.
PINT is specified as a strict superset of SIP 2.0 and SDP; the extensions are not intended to alter the behaviour of baseline SIP or SDP. Standard SIP proxy, redirect, and location servers can forward PINT requests without modification.
A PINT server MUST support the SIP 'Warning:' header so that it can signal lack of support for individual PINT features. SIP servers that do not understand PINT extensions at all are strongly encouraged to implement Warning: headers to indicate this.
A SUBSCRIBE request MUST NOT include any sub-parts other than the session description, even if sub-parts were present in the original INVITE. A server MUST ignore whatever sub-parts are included within a SUBSCRIBE request, with the sole exception of the enclosed session description.
For each element of the Fmt sub-field in a PINT media line, there MUST be a following fmtp attribute. The fmtp attribute describes the sources (uri-ref, opaque-ref, or sub-part-ref) used with a given Fmt entry.
If a PINT server does not recognize an attribute listed in the 'require' attribute, it MUST return an error status code (such as 420 or 400) and SHOULD return Warning: lines or an Unsupported: header. If it recognizes but cannot fulfill the attribute, the request MUST be rejected with 606 Not Acceptable.
If the telephone network cannot terminate a call in response to a BYE request, the server MUST return a '606 Not Acceptable' response along with a session description indicating the telephone network session causing the problem.
Of all PINT SDP extensions, only the TN network type (with its RFC2543 address type) and the 'require' attribute MUST be supported by PINT 1.0 clients and servers. All other constructs are optional unless the client/server wishes to enable the associated function.
PINT clients SHOULD include a SUBSCRIBE request before a service session terminates if they know they will want status information after termination, because a PINT gateway is only required to keep state about a call for as long as indicated by its Expires: header.
Private SDP address types used with network type TN MUST begin with 'X-' and SHOULD contain a domain name after the X- prefix (e.g., 'X-mytype.mydomain.com'). New address types SHOULD only be used for formats that cannot be expressed as local-phone-numbers within address type RFC2543.
The receiving user agent server MUST acknowledge a NOTIFY request by returning a final response (normally a '200 OK'). If the response code class is above 2xx, the Gateway may treat it as a failure of the monitoring session.
When included data is carried within a PINT service request, the Content Type entity header of the enclosing SIP message MUST be set to 'multipart'. The first MIME part MUST contain an SDP session description.
PINT requests reveal to the server the identity of parties to a telephone call and the content being transmitted. The 'clir' attribute provides a mechanism for callers to request suppression of calling line identity, but PINT itself does not mandate that Executive Systems honor it in all jurisdictions.
The 'clir' SDP attribute controls Calling Line Identity Restriction: 'a=clir:<true|false>'. A value of 'true' requests the Executive System to suppress the calling line identity; 'false' permits its presentation.
The 'phone-context' SDP attribute enables remote local dialling by specifying the network prefix context within which a local phone number should be interpreted. It takes the form 'a=phone-context: <intl-network-prefix | local-network-prefix | private-prefix>'.
The 'require' SDP attribute forces a server to decline a request if it does not understand listed attributes: 'a=require:<attribute-list>'. Two Require: header tags are defined: 'org.ietf.sip.subscribe' and 'org.ietf.sdp.require'.
Three ITU-T Q.763-mapped SDP attributes are defined for telephone address qualification: 'a=Q763-nature:' (nature of address indicator, 0-127), 'a=Q763-plan:' (numbering plan, 0-7), and 'a=Q763-INN:' (routing to internal network number allowed/disallowed).
Three new SIP methods are introduced: SUBSCRIBE (open a monitoring session to receive disposition notifications), NOTIFY (server sends status indications during a monitoring session), and UNSUBSCRIBE (close the monitoring session). Their state machine mirrors INVITE/BYE.
Appendix B specifies IANA considerations for PINT: registration of new SIP methods (SUBSCRIBE, UNSUBSCRIBE, NOTIFY), SDP network type 'TN', SDP address type 'RFC2543', SDP transport protocols 'voice', 'fax', 'pager', SDP attribute names (phone-context, clir, Q763-nature, Q763-plan, Q763-INN, require), and URL parameters (tsp).
PINT service requests invoke real telephone calls at cost to the service provider; any entity able to send a PINT request can cause calls to be made. The protocol relies on the underlying SIP security mechanisms (authentication, encryption) to establish authority and prevent unauthorized invocation.
SUBSCRIBE/NOTIFY monitoring sessions expose call status to subscribers. A PINT gateway must verify that a subscriber is authorized to receive status on a given session, as an unauthorized party learning call disposition or timing constitutes a privacy violation.
The SUBSCRIBE/UNSUBSCRIBE/NOTIFY monitoring session state machine mirrors INVITE/BYE/in-session: SUBSCRIBE opens the monitoring session, NOTIFY carries status updates during it, and UNSUBSCRIBE closes it. Either client or gateway may initiate UNSUBSCRIBE; only the client initiates SUBSCRIBE.
PINT extends SDP transport protocol sub-field with three values for use with TN address type: 'voice' (GSTN voice call), 'fax' (GSTN fax transmission), and 'pager' (pager message). The Fmt sub-field lists MIME sub-types; '-' means default/unspecified.
PINT URLs use the SIP URL user portion to encode service type: 'R2C' (Request-to-Call), 'R2F' (Request-to-Fax), 'R2HC' (Request-to-Hear-Content). A new URL parameter 'tsp' (telephone service provider) identifies the telephone network provider. Example: 'sip:[email protected];tsp=telco.com'.
The fmtp attribute in PINT uses three resolution reference forms: 'uri:<URI-reference>' for IP-network data objects, 'opr:<uric*>' for GSTN-held opaque references, and 'spr:<Content-ID>' for sub-parts included inline in the SIP multipart MIME body.
The SDP network type 'TN' (Telephone Network) is introduced with address type 'RFC2543', followed by a telephone-subscriber string (global-phone-number with '+' prefix for E.164, or local-phone-number). Example: 'c= TN RFC2543 +1-201-406-4090'.