Subject: RE: [Sipping] Comments on draft-peterson-sipping-ieprep-00

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Mar 2003 05:48:29 -0500

inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 6:34 AM
> To: King, Kimberly S.
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [Sipping] Comments on draft-peterson-sipping-ieprep-00
> 
> 
> Since partial coverage seems to be the crux of the matter, let me try to 
> add a few words. We should probably be careful to distinguish three 
> types of 'partial coverage', as their likely effect on ETS will differ.
> 

I think this is the sort of analysis that's required, yes. I've added some
notes inline, but basically just expanding on what you have below.

> (1) UAS as PSTN gateways
> 
> First, we can have partial coverage in PSTN gateways. Clearly, if all my 
> calls are routed to a non-ETS gateway, then all the indications in the 
> world, however done, are pointless. Until all or almost all gateways 
> support ETS, deployments may need to force call routing and avoid the 
> use of default gateway discovery (i.e., tel URIs.). Since I can discover 
> gateway support, a smart end system could try default routing first and 
> if that fails, use source routing to reach a known entry point.
> 

Let me make sure I understand. So UACs would either throw out a tel URL, and
let proxies (presumably the default outbound) route it as they will, or UACs
would form some sort of sip:tel@gateway URI (if that's what you mean by
'source routing') or perhaps the URI of a particular proxy that fronts for a
farm of such ETS-compliant gateways. The latter addresses the possibility
that the UAC's local proxy will not be ETS-capable (and hence this is an
important partial coverage case). To mitigate that, users are informed of
one or more known-capable URI which can be called when the proxy
infrastructure doesn't support ETS. That seems reasonable, though somewhat
intensive on the user's memory. Not really more intensive, I suppose, than
carrying around GETS numbers.

Presumably, the discovery capability (in REQ-14) can let the UAC know if the
proxy supported ETS, rather than just determining if the gateway supported
ETS. There's also some question of whether or not the UAC needs to place a
call to learn if the proxy supports ETS (I suppose something like OPTIONS
Proxy-Require would be in order). In any event, it would definitely be
better to detect this condition at the proxy in these partial deployment
cases, and it would be best if the UAC didn't have to place a call to do so.

Another important aspect of gateway priority management seems to be the
'context' in which prioritization is asserted. Even if we assume that all
gateways support ETS, it isn't that case that all gateways would respect all
contexts (i.e. that an Iraqi general would receive priority in the United
States). The concept is certainly noted by the requirements (REQ-14), but it
seems like another potential cause of partial coverage for any given call.

> This offers a transition mechanism that improves as deployment improves. 
> (This is somewhat similar to the need to dial 1010xxx to reach a 
> 710-aware carrier in the GETS system.)
> 

A system which has no effect on congestion in the LEC, but is better than
nothing.

> (2) UAS as SIP devices, but not gateways
> 
> Some people have pointed out that it would be useful to have SIP 
> endpoints, such as IP phones or ACD systems, handle ETS calls 
> differently, from flashing an orange light to bypassing the call queue. 
> Again, while universal coverage is nice, the alternative of not 
> indicating ETS is no better. After all, existing ETS systems also have 
> the problem that phone end systems may not know that the call is an ETS 
> call and are still useful.
> 

Agreed, I'm not particularly concerned about prioritized calls to SIP UAs
that don't support ETS. It is hard for me to see, though, how much benefit
these mechanisms really provide in the SIP-to-SIP cases. There is virtually
no behavior required of the UAC, proxy, or UAS in this case - while it may
be no worse than unprioritized SIP calls, it's hard to see how it's better.

I think it is also worth considering the case in which the UAC is a SIP
device that does not support ETS. In that case, while it is no doubt
possible to place calls to proxies and gateways that support ETS, the UAC
would presumably be unable to discover whether or not the priority mechanism
is supported. Depending on the authentication methods accepted by the proxy
(and the nature of the mechanism, I suppose), a user agent could also prove
that it requires prioritization and rely on the proxy to add some sort of
prioritization indicator on the UA's behalf (though I'm still unsure how to
read REQ-4 on this subject - it seems to suggest that ETS UAs should support
some special authentication methods).

> (3) Partial coverage in proxies
> 
> This matters in two ways, depending on how proxies use the RP 
> indication. If it's used for routing, the need depends on issue (1). You 
> could either have lots of RP-aware proxies and relatively few 
> specialized gateways or the converse. (If all gateways are RP-aware, 
> proxy routing isn't all that important.)
> 

Like gateway support, I assume proxy support of ETS is also specific to a
particular context, with the same ramifications for partial coverage.

If the only prioritization function that proxies provide is ETS gateway
discovery, then it is worth noting that proxy support for ETS is useless
unless the proxy knows of an appropriate gateway.

Another proxy case that's worth examining is one in which the UAC must go
through some local outbound proxy that doesn't support ETS, and the effects
of that. Does the source-routing requirement extend to this case? I suppose
pre-loaded Route headers could be used to traverse proxies that might
otherwise route a call for a tel URL to a local gateway (perhaps especially
for emergency numbers). I gather that REQ-3 is partly intended to cover
something like this case.

> Proxies could use RP for prioritized call handling to deal with 
> signaling overload.
> 

This idea does concern me a little. If you've gone through the processing of
the message to the point that you're extracting an RP header (to take that
one mechanism as an example), then you've already expended a significant
amount of the energy that a proxy puts into the processing of an entire
request. But moreover, it seems to be this sort of grey area - neither in
scope nor out of scope of the requirements.

> I think in all cases, the issue is increased *probability* of call 
> completion. I can't see how partial deployment could be worse than no 
> deployment, particularly if the most-likely-to-be-scarce resources are 
> enabled first. My guess is that those scarce resources are the 
> gateways/PSTN circuits, where we have a reasonable chance of making this 
> work. 

Agreed that partial deployment of ETS will be no worse than no deployment
(provided that security issues are all handled well - if the system is
exploitable, it could be quite a bit worse). I also agree that the scarcity
of gateway resources is one of the paramount concerns.

> This would not require international cooperation - indeed, as long 
> as the Internet side stays up, this may make calls from abroad into a 
> national ETS system far more likely to work. I think that type of 
> international usage is the more likely one (officials traveling abroad, 
> etc.).
> 
> Clearly, the access links from the SIP endpoint to the gateway could be 
> congested, but the experts in IEPREP tell us that the Internet never 
> gets congested, so this is nothing to be concerned about. (In any event, 
> it's not the concern of the mechanism under discussion here.)
> 

Well, I was just citing the access links as one example - the partial
coverage cases described above are just as important, and seem more like
they should be in the scope of this work.

> Henning
_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Sat, 15 Mar 2003 16:52:49 -0500

> carrying around GETS numbers.

If the UA is owned by the ETS-person, the UA can presumably do this all 
automatically, without the need for the user to remember anything. For 
the official-in-hotelroom scenario, clearly some manual typing is required.

> Proxy-Require would be in order). In any event, it would definitely be

Yes.

> cases, and it would be best if the UAC didn't have to place a call to do so.

That's why we propose to use OPTIONS, with an optional *Require.

> seems like another potential cause of partial coverage for any given call.

If the Iraqui general wants to call in for unconditional surrender, I'm 
sure that an ETS code could be arranged :-)

While in theory the number of ETS schemes is unbounded, in practice the 
number is likely to be rather small, at least for each country.

After all, after half a century of this in the telecom field (MLPP, GETS 
and such), we still have only a few variants of this. The bigger issue 
is authorization - even if somebody uses the right ETS scheme, they may 
not be recognized as a suitable person to use it. That's probably ok in 
practice since I see little practical need for "roaming" arrangements 
where official-from-country-A needs to place a call for termination 
within country B while country B is having an emergency.

> A system which has no effect on congestion in the LEC, but is better than

You solve the problems you can solve...

> be no worse than unprioritized SIP calls, it's hard to see how it's better.

The scenarios may be a bit far-fetched, but I can picture ACDs fronting 
emergency coordination centers and similar resources making good use of 
this. You want citizens to be able to call these, but if an official 
needs to get through to an operator, it's helpful if they can.

> some special authentication methods).

Yes, proxies could add this indication, although this is a bit dicey 
since the identity of a caller does not imply that the call deserves 
special treatment.

Do you mean SEC-4?

> particular context, with the same ramifications for partial coverage.

Sure.

> unless the proxy knows of an appropriate gateway.

Again, it's no worse than having no indication.

> something like this case.

Do you mean REQ-3 'invisible to IP layer'?

> scope nor out of scope of the requirements.

This is a local choice, depending on how much post-parsing processing 
you do. If you have lots of scripts running, AAA, logging and such, 
having two queues (RP, rest) can help. At least from our implementation 
experience, parsing is a small fraction of the resources expended on a 
request.

> of gateway resources is one of the paramount concerns.

Any such system needs to limit the high-priority set-aside to some safe 
number so that even compromise does not significantly degrade the system 
below the non-enabled state. After all, the volume of ETS calls is 
usually only a tiny fraction of the total system capacity, so if you set 
aside, say, 10% of the capacity for ETS, you can limit the worst-case 
exposure.

I think we all agree on the security issues; the requirements documents 
is not shy about those...

> they should be in the scope of this work.

The goal of this work is modest; it tries to do the things that are 
likely to be implementable and known to be required (based on 
operational experience). Things like non-gw UAS or proxy behavior 
modification are gravy.