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

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 13 Mar 2003 08:29:15 -0500

Jon said:

>The system is clearly intended
>to increase the chances of call completion, but I think some further
>analysis of the effects of partial ETS coverage is required before we can
>seriously assess the value added by the ETS concept for SIP. 

I agree this is important.  Please consider the following.

Suppose there are Internet Telephony Service Providers (or cable operators
offering telephony services) that are willing to modify gateways to the PSTN
to provide preferential access for authorized users.  The idea would be in
times of gateway congestion, authorized users might have advantage in
obtaining resources.  If the providers run stateful proxies, those proxies
could also favor authorized users.  To receive preferential treatment,
authorized users must be customers of these particular providers.  Isn't
this partial ETS coverage potentially useful?

If some government wanted to create a priority scheme over its own priviate
network (e.g., MLPP/Assured Service over government owned network) then is
that reasonable?

Some people from the NGN PSTN camp are thinking about priviate packet
networks for telephony.  They envision trading traffic with their peers in a
manner mirroring their current methods.  (For example, see 
http://www.msforum.org/techinfo/reports/MSF-TR-QoS-001-FINAL.pdf )
Suppose the majority of ETS locations used a handful of providers and those
providers traded traffic as in the MSF report augmented with ETS support.
Given the assumed architecture, would this partial ETS coverage be
potentially useful?  

Is this the type of analysis you seek for partial ETS coverage?  

Kimberly

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Thu, 13 Mar 2003 08:30:12 -0600

>Some people from the NGN PSTN camp are thinking about 
>priviate packet networks for telephony.

We could actually each of us have our own network and not communicate
with anyone :-)

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of King, Kimberly S.
> Sent: Thursday, March 13, 2003 7:29 AM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: [Sipping] Comments on draft-peterson-sipping-ieprep-00
> 
> 
> Jon said:
> 
> >analysis of the effects of partial ETS coverage is required 
> before we 
> >can seriously assess the value added by the ETS concept for SIP.
> 
> Suppose there are Internet Telephony Service Providers (or 
> cable operators offering telephony services) that are willing 
> to modify gateways to the PSTN to provide preferential access 
> for authorized users.  The idea would be in times of gateway 
> congestion, authorized users might have advantage in 
> obtaining resources.  If the providers run stateful proxies, 
> those proxies could also favor authorized users.  To receive 
> preferential treatment, authorized users must be customers of 
> these particular providers.  Isn't this partial ETS coverage 
> potentially useful?
> 
> If some government wanted to create a priority scheme over 
> its own priviate network (e.g., MLPP/Assured Service over 
> government owned network) then is that reasonable?
> 
> Some people from the NGN PSTN camp are thinking about 
> priviate packet networks for telephony.  They envision 
> trading traffic with their peers in a manner mirroring their 
> current methods.  (For example, see 
> http://www.msforum.org/techinfo/reports/MSF-TR-QoS-001-FINAL.p
> df ) Suppose the majority of ETS locations used a handful of 
> providers and those providers traded traffic as in the MSF 
> report augmented with ETS support. Given the assumed 
> architecture, would this partial ETS coverage be potentially useful?  
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Mar 2003 09:34:05 -0500

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.

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

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

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

(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.)

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

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

Henning

---

From: "Shane McCormack" <[email-masked]>
Date: Thu, 13 Mar 2003 15:57:28 -0000

Hi,
I have been looking at the documents relating to SIP for Emergency services
having the ability to return a users spatial geographical location.
Is their any work been done in this area currently or any documentation
regarding how it applies to a sip service. Is their a provision for an Even
Notification for spatial geographical location?

Regards
ShaneShane McCormack

Research Assistant,
TSSG, Confederation House,
Waterford Business Park, Cork Road,
Waterford, Co. Waterford.

Phone: +353 51 302927     Fax: +353 51 302901
Mobile: +353 87 9955505
http://www.tssg.org <http://www.tssg.org/>
MSN: [email-masked] <mailto:[email-masked]>

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 17 Mar 2003 02:59:49 -0600

Shane asked:
>Is their any work been done in 
> this area currently or any documentation regarding how it 
> applies to a sip service. Is their a provision for an Even 

I believe we're waiting on output from geopriv.

Once this happens, it would seem obvious that one could include geoloc
(perhaps indirectly) in one's presence document, for which we have a
subscription/notficication mechanism fairly well worked out. This is
actually happening in the SIMPLE working group, not SIPPING.

There have also been discussions from time to time of doing an event package
specifically for geoloc transmission, another for informing mobile terminals
of location related information, like "The game is on in the pub across the
street", and several other sorts of things. As far as I know, none of these
have really "set up" yet.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Mar 2003 10:19:37 -0500

> actually happening in the SIMPLE working group, not SIPPING.

It is not clear to me that this is the most robust approach, as you 
would then have to, during an emergency call,
- upload your location
- tell the emergency call center what your presence address is
- get the credentials (and address) for the ECC
- either add them to the access list or explicitly allow access, via the 
usual "Foo wants to subscribe to your presence, click Yes or No" button.
- the ECC then has to subscribe and get the notification

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 17 Mar 2003 10:32:13 -0600

> - the ECC then has to subscribe and get the notification

Admittedly, emergency services are a different question than adding location
to presence. Very different requirements. These requirements weren't clear
to me from Shane's question. Do we have a rigorous statement of the
requirements somewhere?

Presuming that the requirement is something like "Provide location
information within the dialog associated with an emergency call such that
location information is available to the PSAP when the dialog is requested"
or some such, then the answer probably looks more like "Put a geoloc body
into the SIP INVITE request using multipart MIME", which we still can't do
without geopriv and formats. But that is stating the answer before knowing
the problem, I think.

--
dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Mar 2003 12:23:39 -0500

draft-schulzrinne-sipping-emergency-req-01 is one view of the problem 
space (it does cover more than the geographic location issue).