Subject: Re: [Sipping] overlap summary

From: [email-masked]
Date: Tue, 18 Jun 2002 10:15:01 EDT

Good summary, but some comments inline:

In a message dated 6/17/02 2:41:55 PM Eastern Daylight Time, 
[email-masked] 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 
> 

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

[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 <A HREF="mailto:'sip:[email-masked]'">'sip:[email-masked]'</A>). 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 
> 

[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 
> 

[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 
> going 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 
> 

[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.

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jun 2002 11:38:43 -0400

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
>
> I think the main issue is the effect this design will have on the 
> Answer-Seizure Ratio.  Customers measure the quality of the GWs and 
> switches on this and demand better.  I believe this is what 
> you refer to as 
> the hung-IAM problem. 

You picked up on the term Jon was using, but seem to have completely
missed the point he was making with that term.

A distillation of what he said is: using the mechanism we have defined,
you can architect a network that causes hung IAMs, and you can architect
a network that does *not* cause hung IAMs. It's the service provider's
choice.

If the Answer-Seizure ratio is a critical measure for service providers
who insist on using overlap dialling, they will choose to give up some
routing flexibility in exchange for fewer or no wasted IAMs. If they
decide that they are willing to waste a few IAMs in exchange for more
flexible routing, they can do so. It's their choice, and we see no reason
to place restrictions on the protocol that artificially limit what is
fundimentally a business and engineering decision that carriers certainly
have the competence to make themselves.

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jun 2002 11:53:21 -0400

> Hopefully, this draft can be improved to where we have 
> overlapped digits 
> within a single session, rather than overlapped sessions.

<sarcasm>Thanks for your helpful comment. It is not at all
obvious, and certainly makes a concrete proposal that we
can move forward with.</sarcasm>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 18 Jun 2002 12:01:01 -0400

Adam,

If by "architect a network" you mean ignore what appears to be the 
over-riding design goal in the overlap draft, then I agree.  But, the 
problem is the relationship between this feature and other capabilities 
that the GW must support.  You are saying that these other capabilities 
must be sacrificed to do overlap.

I don't see the issue here as being a limitation on the protocol, but 
defining the behavior at the GW using the existing protocol such that 
interoperability is supported.

Mike

---

From: [email-masked]
Date: Tue, 18 Jun 2002 14:06:36 EDT

> a network that does *not* cause hung IAMs. It's the service provider's

[MAP] And I think you have skipped an important point - the network is 
already "architected", that is, its numbering plan exists, so the service 
provider can't be expected to change it to accomodate SIP. We need to 
consider the existing "architecture" and not make it work badly.

> have the competence to make themselves.
[MAP] Yes, the answer-seizure ratio is important, whether they choose to use 
overlap or not. Remember, the argument given for using overlap is to reduce 
setup time, which is due to the slow signaling systems and non-uniform 
dialing plans at the destination, not necessarily at the service provider who 
choses to do overlap to help tolerate those old techniques. Also, in the 
PSTN, using overlap did not have a significant impact on the answer-seizure 
ratio, since it didn't cause false routes to be tried and then released when 
additional digits were dialed.

Note in your comment above, the "service provider" who may choose to do 
"flexible routing" may not be the same one who is impacted by the extraneous 
IAMs.

Mike Pierce
Artel