Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)
Extracted elements (20)
Multiple INVITEs (one per SAM) were chosen over a single-transaction approach because each new INVITE represents a new SIP transaction that can be independently routed to take advantage of SIP services, whereas requests within an early dialog are bound to the same path. The trade-off is added complexity in managing concurrent INVITE transactions and the risk of reaching multiple egress gateways when routing is not controlled.
The approach of sending an INVITE with initial digits and then sending subsequent digits via INFO within an early dialog was rejected because it requires the remote UA to send a non-100 provisional response immediately, which would cause ingress gateways to generate early ACMs and confuse the PSTN state machine. Additionally, requests within an early dialog follow the same path and cannot be re-routed for SIP services.
The preferred solution for a gateway handling PSTN overlap signalling and SIP is to convert PSTN overlap signalling into SIP en-bloc signalling using number analysis and timers, waiting until all digits arrive before generating an INVITE. Overlap-to-en-bloc conversion in SIP is preferred because SIP itself is an en-bloc protocol; the Request-URI of an INVITE always contains the whole address of the callee.
If the gateway encapsulates ISUP messages as SIP bodies, the new INVITE sent for each SAM should include the original IAM and all SAMs received so far. This ensures that an egress gateway reconstructing the ISUP call has full context from a single SIP message.
This document extends RFC 3398 (ISUP-to-SIP mapping), which only covers en-bloc signalling. Implementations must apply the procedures in RFC 3398 for building INVITEs and computing REL cause values; the present document adds overlap-specific rules layered on top of those procedures.
A gateway SHOULD only generate SIP overlap signalling (multiple INVITEs) if the SIP routing infrastructure ensures that INVITEs will only reach one gateway; when the routing infrastructure is not under the administrator's control, the en-bloc conversion procedures of Section 2 must be used instead.
A media stream corresponding to a response to an INVITE with a greater number of digits should be given more priority than media streams from responses with fewer digits, as the more-digit response is more likely to be semantically relevant to the caller.
A new INVITE sent in overlap signalling mode must not contain a To tag nor a Route header field derived from earlier responses, so that the new INVITE can be routed dynamically by the network for services.
If 4xx, 5xx, or 6xx final responses arrive for pending INVITE transactions before T10 expires, the gateway should not send a REL. A REL is sent only if no more SAMs arrive, T10 expires, and all INVITEs sent have been answered with a final response other than 200 OK.
If the IAM contains less than the minimum amount of digits to route a call, the gateway starts T35 (15-20 seconds per Q.764) and waits for the minimum number of digits or a stop digit. If T35 expires before that threshold is reached, a REL with cause value 28 must be sent to the ISUP side.
In SIP-to-ISUP overlap signalling, upon reception of a subsequent INVITE (same Call-ID, same From tag, updated Request-URI), the gateway should generate a SAM and answer the previously received INVITE with 484 Address Incomplete. If the gateway is attached to an en-bloc PSTN area, a REL for the prior IAM and a new IAM should instead be generated.
Once a 200 OK response is received for any of the overlap INVITEs, the gateway should CANCEL all other pending INVITE transactions. A gateway may implement a brief timer before sending these CANCELs to allow prior transactions to terminate smoothly and reduce signalling traffic.
Once the minimum digits are received and the gateway cannot determine completeness, it should collect digits until timer T10 expires or a stop digit is entered; T10 is refreshed on each new digit. When T10 expires, an INVITE with the digits collected so far is sent to the SIP side, and any subsequent SAMs are ignored.
SIP overlap signalling should not be used when attempting to reach parts of the PSTN where a telephone number and a shorter prefix of that number could both be valid addresses of different terminals, as this could result in contacting the wrong destination.
The best status code among all responses received for all INVITEs generated during overlap signalling is used to compute the cause value of the REL sent to ISUP, computed in the same manner as a forking proxy selects its best response; this is not necessarily the response to the INVITE with the most digits.
The CSeq of each new INVITE in an overlap signalling sequence is recommended to be higher than any previous CSeq generated for the same Call-ID across all dialogs, to avoid confusion at destination when the original INVITE has forked and established multiple early dialogs with distinct CSeq spaces.
When sending a new INVITE with additional digits, the gateway should not CANCEL the previous INVITE transaction, because the CANCEL could arrive at an egress gateway before the new INVITE and trigger a premature REL. Pending INVITE transactions are typically terminated by 4xx responses.
In the SIP-to-ISUP direction, when a gateway receives a subsequent INVITE with the same Call-ID and From tag as the previous one and an updated Request-URI, it should generate a SAM (Subsequent Address Message) rather than a new IAM, and answer the previously received INVITE with 484 Address Incomplete.
When generating multiple INVITEs for overlap signalling, each subsequent INVITE carries the same Call-ID and From header field (including tag) as the first INVITE, but has an updated Request-URI and To header field containing all digits received so far; the To header field must have no tag, and no Route header field from prior responses should be included.
An attacker may send multiple INVITEs with incomplete addresses to the same gateway to exhaust available ports and deny service to legitimate callers; since these calls never complete, the sender may not be billed. Gateway operators are recommended to authenticate INVITE senders and track a threshold of hanging overlap calls, rejecting further calls from the same source once the limit is exceeded.