Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
Extracted elements (24)
A new 'trunk-context' parameter was created rather than reusing tel URI's 'phone-context' because 'phone-context' is semantically applicable only to local telephone numbers, while trunk groups may appear in both local and global telephone numbers.
The originating trunk group is placed in the Contact header rather than the From URI because a trunk group binding is valid only for the duration of the session, whereas the From URI is an abstract long-term identifier. The Contact URI has exactly the right session-scoped semantics.
Trunk group parameters are defined as an extension to the tel URI rather than only the sip URI because trunks are intimately associated with the PSTN, and defining them on the tel URI allows reuse by non-SIP VoIP protocols (MGCP, Megaco, H.323). SIP procedures in RFC 3261 Section 19.1.6 can then derive an equivalent sip URI from the tel URI.
For URI equivalency, two URIs containing trunk group parameters are compared according to the base comparison rules of their URI type: Section 4 of RFC 3966 for tel URIs and Section 19.1.4 of RFC 3261 for sip URIs.
In inter-domain call flows, a receiving domain that is not authoritative for the 'trunk-context' value does not interpret the trunk group parameters; it simply passes the Contact header (including trunk group parameters) as-is for use as the R-URI in subsequent requests back toward the originating domain.
A proxy SHOULD NOT change destination trunk group parameters already present in the R-URI unless it has more authoritative information about the routing topology than the upstream client that originally inserted them.
A proxy SHOULD NOT change trunk group parameters in the Contact header as the request traverses through it, since the UAC populated them based on authoritative knowledge the proxy may not have.
A UAC initiating a call that supports this specification MUST include trunk group parameters in the Contact header URI (as a SIP translation of the tel URI). The Contact URI MUST be a sip or sips URI.
Both 'tgrp' and 'trunk-context' parameters MUST be present in a tel URI to identify a trunk group. All conforming implementations MUST generate both parameters when using trunk groups.
If a gateway receives an incoming call where the calling party number is not available, it MUST create a tel URI containing a locally generated token (e.g., gateway line or port number) with local significance, then convert it to a sip URI for the Contact header.
If a node receives a call signaling request from an upstream node it does not trust, it SHOULD remove the trunk group parameters, as they are only applicable within mutually trusted network nodes.
If a UAS supports trunk groups but is not configured with the particular trunk group identified in the R-URI, it SHOULD NOT use any other trunk group. It MAY reject the request with a 404, or if it processes the request, it MUST disregard the 'trunk-context' and 'tgrp' values.
If an implementation receives a tel URI with only one of 'tgrp' or 'trunk-context', it MUST act as if no trunk group parameters are present at all. If it chooses to process such a URI, it MUST disregard the values in both parameters.
If the receiver of a SIP request is not authoritatively responsible for the value in 'trunk-context', it MUST treat the 'tgrp' parameter as if it were not there, and MUST disregard both trunk group parameters if it processes the request.
SIPS URI scheme and TLS SHOULD be used to provide integrity protection against malicious modification of trunk group parameters in R-URIs and Contact headers.
The originating (ingress) trunk group MUST appear in the Contact header of a SIP request. Trunk group parameters in the Contact header URI signify the trunk group over which the call arrived.
The terminating (egress) trunk group parameters MUST be specified in the Request-URI (R-URI), signaling to the next downstream entity which egress trunk group to use.
The 'trunk-context' parameter can contain four value types: (1) a specific host/gateway, (2) a subdomain identifying a subset of gateways, (3) a service provider domain identifying all gateways in that domain, or (4) a global number or leading digits for provider-wide scoping.
Trunk groups are identified by two tel URI parameters: 'tgrp' (the trunk group label) and 'trunk-context' (the namespace/scope). Both parameters together constitute the 'trunk group parameters' and must appear together to identify a trunk group.
The tel URI parameters 'tgrp' and 'trunk-context' introduced in this document are registered with IANA through the tel URI parameter registry. This specification itself does not create a new registry.
In the intra-domain case, proxies should accept trunk group parameters only via the SIPS URI scheme and use HTTP Digest to authenticate senders. In the inter-domain case, a receiving proxy should use the sender proxy's X.509 certificate to authorize insertion of trunk group parameters.
Malicious modification of trunk group parameters in an R-URI could cause a gateway to prefer one trunk over another, enabling attacks such as receiving free service via toll-free trunks or disrupting traffic flow. Modification of Contact header trunk groups could cause routing intermediaries to incorrectly associate a call with a different source.
Trunk group parameters may reveal sensitive carrier information: how a carrier performs least-cost routing and peering, and network topology details. Carriers should use discretionary judgment about including trunk group parameters, and TLS SHOULD be used for confidentiality protection.
The ABNF for trunk group identifiers extends the 'par' production of the tel URI: 'trunk-group = ";tgrp=" trunk-group-label' and 'trunk-context = ";trunk-context=" descriptor'. The trunk-group-label allows unreserved, escaped, and trunk-group-unreserved characters ('/', '&', '+', '$').