[Sipping] overlap summary

There has been a lot of traffic in the past couple of weeks about this draft, threads that started both from the QSIG document and the WGLC announcement for overlap. Although I've heard a few comments that sound like good specific proposals for enhancing the mechanism, I've also heard a lot of confusion and rehashing of familiar ideas. So I want to briefly summarize the position of the authors of the overlap draft in light of the last call comments that have been made.

First off, just to be absolutely clear, the position of the authors is that en bloc dialing should always be used in SIP signaling - timers or similar mechanisms should convert overlap dialing to en bloc at the edges of SIP networks. We were initially content to leave the matter at this, but public demand eventually convinced us that we need to create a mechanism that, while it is not recommended, could be used by those that had no alternative to overlap. I think our discomfort with overlap dialing is amply substantiated within the draft.

For general background to these issues, those who weren't there at the time might want to check out this presentation from the IETF in March 2001 (though note that some of the problems discussed in the later slides about load-balancing and SRV have been fixed within SIP):

The main point of controversy about this draft is, as always, the fact that the overlap mechanism treats each SAM as a new INVITE that is handled by SIP more or less independently of prior INVITEs for the same call. On the plus side, this means that as the overlap process discovers more digits, you can refine your route selection if it turns out there is a better destination for the call. On the minus side, this means that it is possible that an IAM will be sent to the PSTN from a gateway that will not eventually complete the call (although the IAM will be released shortly) - a 'hung IAM'. The authors have argued that temporarily occupying a TCIC for a call that will never complete is not a high cost to pay for the features that you potentially gain in route refinement.

The mechanism currently in the draft was motivated primarily by network designs in which service providers would indeed want to choose a different route, sometimes, when further digits of an address are revealed. This is most appropriate to networks that mix prefix-based routing with other routing systems (for example, networks that rely on some query-based routing, such as routing based on local number portability or ENUM, that requires a complete address to make a routing decision). For example, a network might have a gateway that is an appropriate destination for all calls to country code +44. However, it may also have a different route for numbers in the range +44 (0)20 9999 XXX, that are managed by a particular IP PBX, and then finally ENUM might provide a translation fo the specific number r +44 (0)20 9999 0001 (maybe to 'sip:user@bt.co.uk'). If, once all the digits are discovered, it turns out that the call must terminate on an IP endpoint (one discovered by ENUM, say), then no preliminary call to the PSTN could ever successfully complete (the fact that the target of an overlap dialing call might be an IP phone also ultimately ruled out any SAM-over-INFO strategies). Route refinement is in this case necessary if a preliminary call has been sent to the +44 gateway.

Note, however, that the overlap mechanism specified in our draft can only exhibit 'hung IAM' behavior when a service provider elects to structure their routing logic this way. If service providers use pure non-hierarchical prefix-based routing, the same overlap mechanism will never hang IAMs. I think that our mechanism empowers service providers to choose their poison - I don't think we want to make this trade-off decision for them. We have already gone on the books recommending that they not use overlap, anyway.

Mike Pierce suggested some text like: "The ingress GW MUST NOT send the first INVITE until it has collected enough digits to ensure that this INVITE can be routed to the appropriate destination egress GW or proxy and until the number of digits equals the minimum number needed by that destination." Of course, as was pointed out, in many national numbering plans (ones based on prefix-consumption) this would be virtually impossible for an ingress gateway to discover - and unfortunately, it is in these very nationalities that overlap dialing is actually unavoidable for precisely this reason. Effectively, I think this solution amounts to "don't use overlap" - the choice of whether the ingress GW, proxy, or egress GW is ultimately responsible for converting overlap to en bloc in a given architecture doesn't make much difference (though we agree that if you're going to convert overlap to enbloc, the closer it is to the ingress, the better).

Arguments have also been made in this thread that gateways need to somehow advertise support for overlap dialing in the region(s) of the PSTN to which they are connected, as well as informing one another when addresses are incomplete as they are passed in requests. How these capabilities would benefit any of the participants in overlap dialing call setup has been obscure to me throughout this discussion, though (especially in a way that would be compatible with non-gateway participants in calls). Aside from the standard use of the existing 484 response code, I don't think any entities are likely to behave any differently with this information, and assessments of the completeness of addresses are problematic. I do think adding some further text about the judicious use of the 484 code, however, is warranted.