Re: [Sipping] overlap summary

[Michael Hammer <mhammer@cisco.com>]

Jon,

I agree that in an ideal world doing only en-bloc would be great.  But, 
given that overlap is being required, it is best to not have a half-way 
solution.  There are too many caveats in the draft pointing out its own 
short-comings.  While you have done a good job of protecting the interests 
of the SIP network, there is not enough consideration of the impact on the 
PSTN network and impact on the gateways to the PSTN.

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.  If load sharing is used on the GWs then every 
additional digit results in a new PSTN circuit seized in the PSTN to the 
next switch because the GW receiving the INVITE does not know about 
previous INVITEs to other GWs.

The comment about selecting a new route across SIP network as a result of 
receiving another SAM suggests that perhaps the first INVITE was 
premature.  But my real concern is that the arguments about following 
through at the first egress gateway somehow ruining the ability to redirect 
a call to a SIP endpoint is not entirely correct.  If number portability is 
detected at the destination network, it would be possible to redirect the 
call back into the SIP network.  I believe the terms here are crank-back or 
onward routing.  I think this would be just a reuse of other features of 
the PSTN and SIP networks to accomplish that.

The other element of this discussion that I observed was that the behavior 
of the gateway is depending on whether overlap is being used at either the 
ingress or egress PSTN network, which then drives how INVITEs and response 
codes are used, leaving the receiving GWs to have to ASSUME what to do 
next.  It just makes me wonder if a more explicit indication is needed.

I agree with the idea that if you are going to do conversion to en-bloc, 
then do it at the ingress GW.  That will save both CPU cycles at the egress 
GW and wasted messages in the SIP network.

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

Mike H.


At 01:40 PM 6/17/2002 -0500, Peterson, Jon wrote:
>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.
>
>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>http://www.ietf.org/proceedings/01mar/slides/sip-8/index.html
>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 
><mailto:'sip:user@bt.co.uk'>'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.
>
>Jon Peterson
>NeuStar, Inc.


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP