Re: [Sipping] overlap summary

[Mpierce1@aol.com]

Good summary, but some comments inline:

In a message dated 6/17/02 2:41:55 PM Eastern Daylight Time, jon.peterson@neustar.biz writes:


> I can see that overlap dialing remains a contentious and difficult issue - but then again, that is why we split it out from the main SIP-ISUP mapping draft in the first place.
>  
> 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.


[MAP] Therefore, let's keep the overlap operation as simple as possible.

 
> 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):
> http://www.ietf.org/proceedings/01mar/slides/sip-8/index.html


[MAP] That presentation and many comments since have claimed that overlap is required since otherwise there would be "unaccaptable establishment delay". Many years ago the US telephone industry decided not to support overlap, so they must have felt that it was not a problem. Since that time, the causes of delay (slow signaling systems at the destination and non-uniform length numbers which require timeouts) have been reduced significantly world-wide. They continue to disappear. It's hard to understand why some service providers insist on continued support for overlap, but, as you realize, traditional telephony service providers are prone to insist that they "require" something they've had in the past simply out of uncertainty about its real need. So SIP, as with previous designs, continues to include things that should have disappeared. (Is SIP handling dial pulse?)


> 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.
>
> [MAP] It is this fact - that the mechanism "treats each SAM as a new INVITE" - that causes most of the problem. Since we agree that overlap should not be used, there is no reason ot go out of the way to provide extra functionality for those who insist on using it, such as to expect INVITEs with more digits to be routed differently. The proposal I made is to presume that the number of digits required for routing is received first before the first INVITE is sent and to not treat SAMs as new INVITEs. That is, model the mechanism in SIP on what ISUP does. The first INVITE needs to explicitly indicate whether the ingress gateway thinks it includes a complete number or not and the following INVITEs need to explicitly indicate that they are really "SAMs".
>
>  
> > 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.
>
>
> [MAP] The thought of number portability, with some in the IP world and some in the PSTN world, really makes my head hurt when I try to think of it at the same time as overlap. I believe that number portability is one of the big reasons for insisting on conversion to en-bloc at the ingress. In fact, what you called "prefix-based routing" (or what I would call a "hierarchical numbering plan") worked okay with overlap. "Query-based", such as for number portability does not, and the whole world is going to query-based routing where the full number (or at least some minimum number of digits) is required before any meaningful routing decision can be made. "Route refinement" is necessary only if a preliminary call was sent anyplace, so I say don't send it, then "route refinement" isn't necessary.
>
>  
> > 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.
>
>
> [MAP] I'm not sure what the "hung IAM" behavior is, but it doesn't sound good. It's easy to say how service providers should design their numbering/routing plans, but they are not going to change them just because SIP comes along.
>
>  
> > 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 go!
> >  ing to convert overlap to enbloc, the closer it is to the ingress, the better).
> >  
>
> [MAP] I am not aware of what "prefix consumption" means in regards to national numbering plans or how it affects this subject. A "prefix" generally only pertains to the local dialing scheme, like how you reach an international number, so they do not impact calls from other countries. I don't see how this could be "virtually impossible for an ingress gateway", since it is what switches in the US have been doing for calls to every place in the world for many years. Am I missing some new functionality that is beyond what we have been doing for a long time?
>
> It would take very little data to allow the ingress gateway to know the minimum number of digits for most destinations, and it can use a simple default for those it does not know. I believe the absolute minimum worldwide is 7. (A data base for this would be a great project.)
>
>
> A
> > rguments 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.
>
>
> [MAP] Absolutely correct, the orginating entity should not behave differently based on the capabilities of the destination, especially when such behavior could affect which destination is selected (chicken and egg problem).
>
>  
> > Jon Peterson
> > NeuStar, Inc.