Subject: [Ecrit] call marking

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 14:42:24 -0500

I'm not sure where we left off with this issue, but it needs to be  
resolved.

Previously, I leaned toward the sos URN in the request URI (I believe  
this was Henning's suggestion).  I no longer think this is a good  
idea, because the request URI is actively used in emergency calls  
today, many times containing psuedo-codes relevant to call routing.   
Admittedly, this is an artifact of gatewaying to the PSTN, but  
picking another method that would remain compatible with this  
practice seems to offer easier transition.

For the clueless, why is the Priority header with the "emergency"  
value not useable here?

-andy

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 4 Jan 2007 14:55:48 -0500

Maybe it would be helpful to discuss requirements first and who would  
use the call marking for what.

The first usage is presumably for call routing. This matters only if  
a proxy needs to do something different to route emergency calls,  
such as invoke LoST, and if it sees something other than emergency  
calls. (For example, if we have hierarchical routing, the state proxy  
will simply forward calls to one of the county proxies, but all such  
calls need to be re-mapped. Or, alternatively, the URL identifies  
emergency calls for that destination, without any standardized  
convention, such as sip:[email-masked])

A second usage is that the destination (PSAP) can tell if the call is  
an emergency or "business" call. One could argue that the destination  
URL is the appropriate marker for that, without any standardization.  
In other words, as long as a PSAP doesn't use its business E.164  
number or SIP URL as the service URL in the LoST record, there is no  
problem. Again, no standardization is needed.

Another, orthogonal, usage is to provide some kind of prioritization  
in call handling. This is more closely related to the SIP Resource- 
Priority header.

So, what are the goals and when precisely do we need this?

Henning

On Jan 4, 2007, at 2:42 PM, Andrew Newton wrote:

> Previously, I leaned toward the sos URN in the request URI (I  
> believe this was Henning's suggestion).  I no longer think this is  
> a good idea, because the request URI is actively used in emergency  
> calls today, many times containing psuedo-codes relevant to call  
> routing.  Admittedly, this is an artifact of gatewaying to the  
> PSTN, but picking another method that would remain compatible with  
> this practice seems to offer easier transition.
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 04 Jan 2007 13:57:33 -0600

>practice seems to offer easier transition.

I agree with Andy that this indication needs to be somewhere other than the 
R-URI that may change or be otherwise not obvious (perhaps it is not 
following a certain "emergency" format we haven't come up with yet). I feel 
whatever the indication is, it needs to be obvious what it means.

>For the clueless, why is the Priority header with the "emergency"

The Priority header is for the recipient end user to determine how 
important the message was to the sender, and can get confused with other 
uses (such as a GETS (IEPREP) call, does that call also get marked as an 
emergency call)?

my 2 and a 3rd cents

James

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 Jan 2007 15:02:37 -0500

I think the current proposal is to leave the sos URN in the Request URI and
change the top of the Route stack as the call is routed, in line with
Jonathan's mechanism for a similar problem with GRUUs.

I think your reasoning is specious because you are talking about an upgraded
phone or network, that understands the sos URI, and uses it, and you want to
have backwards compatibility with the existing systems while keeping the new
marking.  That won't work.  

If you take a new (in NENA we would call that an "i3" call) and you want to
put it in the existing ("i2") system, then the sos URI is meaningless within
that system, and like a current i2 call, you don't need or want special
marking.

This would mean that a call enters a proxy with urn:service:sos in the
Request URI, and some meaningful thing in a Route header.  The proxy
determines that the call has to be routed on the i2 network.  It pops the
Route header and replaces the Request URI with what it needs to do to get it
to route in the i2 network.  It would then look just like any other i2 call.
If you attempt to send the call with any marking, the i2 system may well be
unhappy, but even if it was okay (as it really should be), the marking,
however you do it, is meaningless.

Now, I do want to use the RP header, because we really do want resource
priority in the signaling.  Similarly, I'd like to mark the media, because
I'd like some priority there also (but only packet level stuff, so I mean a
DSCP).  The former COULD be implied by whatever marking we end up with, but
I don't like implications.  I'd rather be explicit.

But that doesn't affect the issue of sos in the RequestURI.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 2:42 PM
> To: ECRIT
> Subject: [Ecrit] call marking
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 16:39:53 -0500

On Jan 4, 2007, at 2:55 PM, Henning Schulzrinne wrote:

> Maybe it would be helpful to discuss requirements first and who  
> would use the call marking for what.
>
  [...snip..]
> So, what are the goals and when precisely do we need this?

I agree that we need to understand the requirement.  And I'd prefer  
that the requirement be this: "Marking a call as an emergency call  
without implying anything else."  The arguments, as I understand  
them, against the resource priority header is that it overloading  
another mechanism: I guess some jurisdictions don't think emergency  
calls are worthy of a priority higher than normal.  I'd say the  
argument is also true for using the request URI.  You are overloading  
another mechanism that has another purpose.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 16:42:23 -0500

On Jan 4, 2007, at 2:57 PM, James M. Polk wrote:

> important the message was to the sender, and can get confused with  
> other uses (such as a GETS (IEPREP) call, does that call also get  
> marked as an emergency call)?

Being unfamiliar with GETS, I don't know.  However, I do see a  
distinction between the recipient understanding the call is marked as  
an emergency and other elements in the call path understanding the  
same.  I'm not sure the distinction is relevant, as I cannot think of  
a scenario where it matters.  But I'd welcome such education.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 4 Jan 2007 16:47:45 -0500

But marking for what purpose? Without knowing what this supposed to  
be used for, it's hard to design a mechanism that has the right  
properties. As one obvious issue, if the marking is just  
informational, we wouldn't care if somebody marked calls to the local  
pizza delivery outfit as "emergency" if they are hungry. But in that  
case, I'm somewhat at a loss as to why this would be useful for real  
emergency calls.

Also, in general, I think it's a good design approach to see if  
there's a broader context here. For example, is this a special  
instance of marking types or classes of calls?

On Jan 4, 2007, at 4:39 PM, Andrew Newton wrote:

> argument is also true for using the request URI.  You are  
> overloading another mechanism that has another purpose.
>
> -andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 16:50:13 -0500

> however you do it, is meaningless.

This seems to be a specious argument about i2 being fragile, and that  
it requires the R-URI to be the sos URN.  Is either really true?

I sure hope that everyone understands there will be no flag day  
regarding LoST.  VSPs will have to operate in both worlds, where some  
LoST queries resolve and others do not.  Those that do not will  
require the routing to fall back to the old SIP termination methods.   
When LoST does not produce a result, I'd still like to mark the call  
as an emergency in a universal and standard manner and I'd still like  
to have a GeoLocation header.  Just because the call may not be  
routable via LoST does not mean it won't terminate to an IP end point.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 04 Jan 2007 15:51:33 -0600

At 03:02 PM 1/4/2007 -0500, Brian Rosen wrote:
>DSCP).

In this regard, there is this TSVWG ID that we authors believe can be used 
for 911/112 calling too (plus ETS calling)

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-admitted-realtime-dscp-00.txt

>The former COULD be implied by whatever marking we end up with, but

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 16:54:11 -0500

On Jan 4, 2007, at 4:47 PM, Henning Schulzrinne wrote:

> informational, we wouldn't care if somebody marked calls to the  
> local pizza delivery outfit as "emergency" if they are hungry. But  
> in that case, I'm somewhat at a loss as to why this would be useful  
> for real emergency calls.

The purpose of "implying nothing else" is that you do not overload  
mechanisms that are already in use and may have unknown side affects.

> instance of marking types or classes of calls?

If you want to generalize the mechanism, I'm fine with that within  
the constraints of what I said above.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 4 Jan 2007 16:57:31 -0500

FWIW....wireline 9-1-1 in the U.S. currently has no special
markings/priority except what is achieved by the fact that there is a
dedicated network (at least bearer) from the Class 5 to the Selective
Router/PSAP.

So creating a marking which leads to special treatment may become ugly with
the prospect of spoofing the marking and the possibility of pre-empting a
legit call not marked as emergency with one that is asking directions to
Pizza Hut.

Ugly at best for the IETF....

-Marc-

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Thursday, January 04, 2007 4:48 PM
> To: Andrew Newton
> Cc: ECRIT
> Subject: Re: [Ecrit] call marking
> 
> But marking for what purpose? Without knowing what this 
> supposed to be used for, it's hard to design a mechanism that 
> has the right properties. As one obvious issue, if the 
> marking is just informational, we wouldn't care if somebody 
> marked calls to the local pizza delivery outfit as 
> "emergency" if they are hungry. But in that case, I'm 
> somewhat at a loss as to why this would be useful for real 
> emergency calls.
> 
> Also, in general, I think it's a good design approach to see 
> if there's a broader context here. For example, is this a 
> special instance of marking types or classes of calls?
> 
> > without implying anything else."  The arguments, as I 
> understand them, 
> > against the resource priority header is that it overloading another 
> > mechanism: I guess some jurisdictions don't think emergency 
> calls are 
> > worthy of a priority higher than normal.  I'd say the 
> argument is also 
> > true for using the request URI.  You are overloading 
> another mechanism

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 Jan 2007 19:54:59 -0500

> it requires the R-URI to be the sos URN.  Is either really true?
I hope the systems are not fragile, but they are pretty special purpose and
thus the level of testing for extremes of signaling is not likely all that
great.  I would think the basics of ignoring a header you didn't understand
would be there.

i2 doesn't know anything about the sos URN.  It generally has something
called an ESRN (a "Route Number") in the Request URI, which cause the
network that has gateways connected to the selective routers to route to the
right gateway, and also is used by the gateway to select the right trunk
group.  That pretty much has to be what is in R-URI.  Right now there are
only two networks of such gateways in the U.S.  There are some changes in
the NENA specs coming (which may not matter, as the existing implementations
aren't conformant to the i2 specs) which change the ESRN somewhat.  It's
turning from something that looks like a telephone number to a more general
URI, and has the possibility of a gateway network sensitive translation from
the new "ESRN" (it's got a new name too) to something specific to the
gateway network.
> routable via LoST does not mean it won't terminate to an IP end point.
In the U.S. I think you will not have any case of an IP termination that is
not LoST routed, but I never say never.  I think trying to anticipate all
sorts of transition strategies is fruitless.  The basic idea you describe
above, where you try to see if a LoST route exists, and use it if it does,
falling back to existing mechanisms if it does not, is the likely transition
strategy.  Existing mechanisms don't use sos URNs and they don't need
markings.   They have their own conventions.

Carrying the geolocation header is probably good all the way, again assuming
implementations follow 3261 rules on ignoring headers they don't understand.
I am more than a little worried about multipart in this case however.  If
the existing systems don't implement multipart, they get hosed pretty badly.

I'll see if I can get a "heads up" on that out to the right folks.  Roger
Marshall, are you listening?

Brian

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 20:21:03 -0500

On Jan 4, 2007, at 7:54 PM, Brian Rosen wrote:

>  Existing mechanisms don't use sos URNs and they don't need

Good, then I'd hope you would agree the re-purposing something they  
do use, the request-URI, for call marking is asking for collisions.   
Finding some other mechanism means that the logic is the same  
regardless of the path, which is likely to result in greater  
interoperability and fewer mistakes.

> the existing systems don't implement multipart, they get hosed  

I've always intended to do LbyR here.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 4 Jan 2007 20:23:54 -0500

I don't think my basic question has been answered: what's the purpose  
of marking? Who interprets these markings for what purpose?

Adding random strings to protocols in the hope that they might be  
useful for somebody somewhere for something isn't too useful.

(The URI/routing mechanisms are simply that - routing mechanisms.  
They obviously work just as well for urn:service:pizza as for  
emergency.)

On Jan 4, 2007, at 8:21 PM, Andrew Newton wrote:

> do use, the request-URI, for call marking is asking for  
> collisions.  Finding some other mechanism means that the logic is  
> the same regardless of the path, which is likely to result in  
> greater interoperability and fewer mistakes.
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 20:38:16 -0500

On Jan 4, 2007, at 8:23 PM, Henning Schulzrinne wrote:

> I don't think my basic question has been answered: what's the  
> purpose of marking? Who interprets these markings for what purpose?
>

Ok. I think I understand what you are asking.  And I didn't answer  
it, nor do I think I can answer it... other than to say I thought it  
was a requirement we had to fulfill (in our requirements draft).  I  
could theorize and say that some element might notice that a call is  
an emergency and knowingly assign it higher priority in the network,  
or that routing decisions might be made otherwise.  But I'd really be  
guessing.

So, if the conclusion is that "call marking" isn't really useful  
outside of LoST-based routing, then that seems reasonable to me.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 Jan 2007 20:42:40 -0500

Well, let me cite some reasons for marking:
1. Actual routing; knowing how to route the call, especially if there is
more than one element involved.  I think this is the big one.  We need the
service URN to stay around even after we have done one level of LoST
routing.  This includes things like having the call go to the E-CSCF in the
visited network instead of anything in the home network, for example.
2. Allowing the UAS, and a proxy on the route, to know what service is being
requested
3. Invoking emergency call specific behavior, like adding location
4. Priority handling of signaling and media within the network at all levels
5. Disabling of services like call waiting that are provided by the network
6. Charging issues or lack thereof
7. Processing of the call at all (some systems will allow emergency calls,
but no other forms of call), like a cellphone with no service plan.
8. Assistance in detecting theft of service when fraudulent attempts to get
the above are attempted without a genuine service call

Brian

> Sent: Thursday, January 04, 2007 8:24 PM
> To: Andrew Newton
> Cc: Brian Rosen; 'ECRIT'

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 Jan 2007 20:50:17 -0500

_____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, January 04, 2007 8:21 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] call marking

Good, then I'd hope you would agree the re-purposing something they do use,
the request-URI, for call marking is asking for collisions. Finding some
other mechanism means that the logic is the same regardless of the path,
which is likely to result in greater interoperability and fewer mistakes.

See my list of requirements I just sent Henning.  You need the service URN
all the way to the UAS.  It doesn't have to be in the R-URI though.  I don't
see a practical problem with Henning/Jonathan's proposal, but I'd agree in
general with your observation that not doing something "odd", from an
existing implementation point of view is best.  

Don't get me started.  I think LbyR is a very bad idea for emergency calls
because it requires more relationships and interconnects to work in
situations where they are less likely to work.  I know others don't agree.
It does avoid multipart problems, I'll give you that.  We're not going to
require LbyR, so we must get the existing systems to allow multipart.  If
they do, then there is no advantage of LbyR from that standpoint..

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 4 Jan 2007 21:11:54 -0500

In general, one of the SIP design principles is not to design for  
services, but to have service building blocks. Thus, I think the  
"marking" question has it backwards, as it starts from mechanism and  
syntax, rather than requirements and behaviors. We should, like  
you're starting to do, identify behaviors that we need for emergency  
services and then see how these can be invoked. In many cases,  
similar behaviors will also be needed for other, non-emergency  
services, in various combinations.

Your list is helpful; let's work through it.

> visited network instead of anything in the home network, for example.

We discussed this before. Just for routing, we don't need a generic  
emergency marking. Let's go through this:

(1) Let's assume the UAC recognizes the emergency call (things work  
if it inserts a tel: URI or a sip dial string, it's just one stage  
delayed)

(2) The request URI is urn:service:sos and the call gets proxied to  
the outbound proxy, P-CSCF or some special ES proxy, based on UAC  
policy.

(3) That proxy recognizes the routing, invokes LoST based on the  
service and sends it to sip:something@somewhere. If the service  
matters, each service gets a different (user part) URL.

(4) The call arrives 'somewhere'; since it recognizes the URL as  
requiring special treatment (by normal proxy behavior and local  
rules), it does another LoST lookup.

(5) Repeat (3) and (4) until the call terminates at a PSAP.

> 2. Allowing the UAS, and a proxy on the route, to know what service  

I agree that the destination needs to know whether I want "fire" or  
"police" if these are different PSAPs or call takers or call taker  
protocols, but it is not clear that this requires a single, uniform  
marking. If these should be handled differently, the LoST-invoking  
can easily generate

[email-masked]
[email-masked]

or any other local convention that makes sense. This ensures that  
there is no intra-protocol disagreement, such as

INVITE sip:[email-masked]
Emergency-service: poison

i.e., another error condition. For a variety of reasons (such as the  
SIP history mechanism), adding non-URL/non-Route things that  
influence call routing is dubious.

> 3. Invoking emergency call specific behavior, like adding location

I fully agree that a UAC should be able to ask a proxy to insert  
location; however, it should do this with an explicit protocol  
request "please insert location", since I might want the same  
location-insertion behavior when asking for AAA car-towing service or  
Domino's pizza delivery service.

> 4. Priority handling of signaling and media within the network at  

As you noted, media is its own thing (DSCP) and signaling is  
presumably SIP Resource-Priority. We may want to define an R-P  
namespace.

> 5. Disabling of services like call waiting that are provided by the  

Not a signaling function.

> 6. Charging issues or lack thereof

This is a critical one where the properties matter. We don't want to  
a mechanism that allows

INVITE sip:[email-masked] (my grandmother)
Service: don't-charge-since-its-an-emergency

Thus, for this to be useful, all such calls need to be forced to be  
routed to a PSAP. At the first hop (UAC to first proxy), the service  
URN has the right property: it can disable charging and enforces that  
the call only goes to a PSAP. I suspect that for most practical  
purposes, this is sufficient or we need a more general mechanism that  
relies on inter-provider trust assertions or settlement mechanisms.

> but no other forms of call), like a cellphone with no service plan.

Seems similar to (6).

> the above are attempted without a genuine service call

That's more of a requirement, related to (6).

Thus, I believe that the only real issue are (6) and (7), which need  
to satisfy the "atomicity" that call routing and behavior are  
inextricably tied (only calls routed to an emergency location get  
this behavior). Conveniently, the current SIP routing proposal (Route  
+ request URI) has the right properties to make that happen.

In summary, I think we have the right tools, except for

- something in R-P

- an "insert location please" mechanism, for proxy-provided location

Henning

---

From: Andrew Newton <[email-masked]>
Date: Thu, 4 Jan 2007 21:19:20 -0500

On Jan 4, 2007, at 8:50 PM, Brian Rosen wrote:

> Don’t get me started.

Oh, but I might.

> I think LbyR is a very bad idea for emergency calls because it  
> requires more relationships and interconnects to work in situations  
> where they are less likely to work.  I know others don’t agree.  It  
> does avoid multipart problems, I’ll give you that.  We’re not going  
> to require LbyR, so we must get the existing systems to allow  
> multipart.  If they do, then there is no advantage of LbyR from  
> that standpoint..

I agree with you if LbyR introduces authorization outside the  
reference itself (as, in passwords, certs, etc).  But absent that  
idea (which I think is a really bad idea for ECRIT), LbyR gets us  
around trying to fix the network before we go to deployment.  If we  
have to fix the network first and also force operators to do things  
like TLS where they normally do not, then ECRIT will go nowhere.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 5 Jan 2007 11:42:53 -0500

Brian,
You said
"I am more than a little worried about multipart in this case however.
If
the existing systems don't implement multipart, they get hosed pretty
badly."

Forgive my ignorance --
Can you expand on what this means? My understanding of SDP and MIME
types and such is only surface deep, and this comment flew straight over
my head.

I would have just emailed you, and not copied ecrit. But experience has
taught me I'm usually not alone in my ignorance, and I don't remember
having seen this mentioned or discussed in any previous threads.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Beyer, Loraine" <[email-masked]>
Date: Fri, 5 Jan 2007 10:50:46 -0600

Thanks for bringing that up.  Where can I go to get a 15-min summary of
ecrit? 

-----Original Message-----
From: Stark, Barbara 
Sent: Friday, January 05, 2007 10:43 AM
To: Brian Rosen
Cc: ECRIT
Subject: [Ecrit] multipart

Brian,
You said

Forgive my ignorance --

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA623

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 5 Jan 2007 12:03:38 -0500

Okay, in a SIP message, there is a "body".  The body is MIME encoded.
Simple MIME has a type like "application/SDP", and that would be what you
find in an INVITE with an offer.

When you send the geolocation header and you include location by value, the
value goes in the body of the message, with "application/pidf+xml".

So now you get to ask, what mime type do you use if you have BOTH a hunk of
SDP and a location value.

The answer is you use mime/multipart, as in the following snippet:
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...SDP here

   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: [email-masked]

   <?xml version="1.0" encoding="UTF-8"?>
.....

The problem is that many SIP implementations have neglected to include
support for multipart.  If a UA was upgraded to support geolocation, it
would have to be upgraded to support multipart.  Proxies don't normally look
at bodies, so that's probably not much of a problem.  The concern would be
things like SBCs and other B2BUAs, as well as the specific concern here of
the gateways in the i2 systems.

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Friday, January 05, 2007 11:43 AM
> To: Brian Rosen
> Cc: ECRIT
> Subject: multipart
> 
> Brian,
> You said

---

From: Andrew Newton <[email-masked]>
Date: Fri, 5 Jan 2007 12:55:31 -0500

> Thanks for bringing that up.  Where can I go to get a 15-min  

You might be able to sweet talk Henning into providing you a sneak  
peak at a really good paper he just submitted to NetCri on this subject.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 05 Jan 2007 12:42:06 -0600

Barbara

It is not specified in RFC3261 (the base SIP spec) that "mulitpart" (i.e. 
multiple message body parts) be able to be included in any one SIP message; 
though this has been talked about at IETF meetings from years to remedy - 
someone always sways the WG not to consider it "now".

Unfortunately, there are several of these little tweeks to SIP the WG has 
been talking about for the same set of years (i.e. like removing UDP as an 
appropriate transport because of fragmentation problems with large messages 
- instead using TCP or SCTP).

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 5 Jan 2007 14:17:58 -0500

The paper has just been accepted at NetCri 07 (http://www.cs.umd.edu/ 
~sharno/NetCri07/). A preliminary version can be found at

http://www.cs.columbia.edu/~hgs/papers/Schu07_LoST.pdf

The published version will look a bit different. This is joint work  
with Hannes, Andy and Ted.

Naturally, comments from the ECRIT WG would be most welcome as we  
prepare the final version.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 5 Jan 2007 15:58:25 -0500

Inline

> the outbound proxy, P-CSCF or some special ES proxy, based on UAC
How?  Specifically, you are hoping that the routing up to the LoST stage
doesn't need any changes to the R-URI.  I'm not sure that always works.  It
may work to force anything that needs something specific to use a Route
header.

> matters, each service gets a different (user part) URL.
Haven't you now done something we try not to do: imply service meaning in a
general SIP URI?  We have the service URN for that purpose :)  We've been
down that road more than once, with not so great results.

> rules), it does another LoST lookup.
Ah, but you've skipped a step.  You are assuming there is no proxy between
the one from step 3 and "somewhere".  Take, for example, an exit proxy on a
domain.  It can't tell this is an emergency call, and it may wish to do
something different for routing such a call.

I also object, although I agree it works, to do something that amounts to
hiding the service name in a SIP uri, then recreating the service uri using
string hacking on the made up sip URI for the purpose of doing the next pass
of routing.
> influence call routing is dubious.
Well, agree that non-RequestURI/non-Route things that influence routing are
dubious.  

> Domino's pizza delivery service.
Yeah, I don't think this is emergency specific.  It may well be service
specific.

I think this does need some care in design, because it could be a way to
trick you into revealing location if not carefully specified.

> presumably SIP Resource-Priority. We may want to define an R-P
Yes, I think these are orthogonal, and I don't want them commingled with
something that affects routing.

> Not a signaling function.
I don't know what you are getting at here.  I'll kind of agree that is is
more state (you are in an emergency call) then a message parameter of some
sort, but the reality, rightly or wrongly, is that in many systems the
network implements services (using things like 3PCC) and some of those
services have to be disabled in an emergency call

> relies on inter-provider trust assertions or settlement mechanisms.
Well if the endpoint does the LoST route, which you and I advocate, then the
downstream proxies don't know this is an emergency call, and thus would
assume you can charge.  I do think this case has the problem that if you
were to do:

INVITE urn:service:sos
Route: sip:[email-masked]

Then you create the problem we're talking about.  The way I think you can
mitigate it is to allow the carrier to re-run the LoST query, if it wants
to, to figure out that the right thing is happening.  In most cases, it will
be able to cache domains that it knows are PSAPs, so the incidence of actual
LoST query just to validate charging issues should be rare.  Doing that
implies it can get the location, and that pushes the authorization hot
button again, but if emergency calls are allowed to dereference without
authorization, it works.  Note that in most cases, this can be a
non-real-time check.  You can progress the call and worry about the charging
later.

> > but no other forms of call), like a cellphone with no service plan.
Well, it may be similar but it may need different mechanisms.  If you use
the service urn in the R-URI and the PSAP URI in the Route header, the same
mechanism is sufficient.

> + request URI) has the right properties to make that happen.
Hmmm, did I miss something?  I think service URN in the R-URI and PSAP URI
in Route is a good mark for routing.  The last proposal I heard from you was
replace R-URI with PSAP URI.  What are you advocating?

> - an "insert location please" mechanism, for proxy-provided location
I agree with this, although I'd add a DSCP for media

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 5 Jan 2007 21:05:47 -0500

> may work to force anything that needs something specific to use a  

See below.

> down that road more than once, with not so great results.

This is local only, between consenting proxies.

> something different for routing such a call.

If a proxy gets a call, there are four cases:

(1) it's a local URL and handled via its registration database (not  
applicable here)

(2) route it to a fixed place (if the URL is not recognized at all)

(3) route it to the destination domain specified in the URL (not  
applicable here)

(4) recognize a service or tel URI and map it to something routable

For your case, you're assuming it's not (4) since it is not  
recognizing the emergency call, so it doesn't matter what it is and  
case (2) applies.

> string hacking on the made up sip URI for the purpose of doing the  

It's not re-creating the service URN. It's just mapping a string to a  
service URN, no different than mapping

sip:[email-masked] to a service. Again, this is a somewhat  
pointless discussion with the R-URI/Route mechanism currently  
proposed. I'm just trying to show that this can work.

> trick you into revealing location if not carefully specified.

Indeed, but that illustrates that having a single marking is probably  
a bad idea, as some markings are dangerous to the UAC if inserted by  
third parties (such as this one) and others are dangerous to the PSAP  
or the carrier (such as anything that bypasses charging). Thus, the  
necessary trust relationships are different.

For this particular kind of request, I'm not that tying this to  
routing is helpful, but it might be as long as routing is done by the  
same entity that inserts the location information.

(If Trudy modifies a request to obtain location information, she can  
only get it routed to a PSAP, not a location of her choosing, where  
she can inspect the result.)

> services have to be disabled in an emergency call

I suspect we'd have to talk more concretely about specific services.  
Again, I'd rather have something that turns off a particular service  
explicitly, rather than implying this indirectly. Also, not all  
emergency calls will be routed via the home proxy, so this is not  
likely to be too helpful.

> non-real-time check.  You can progress the call and worry about the  

I mostly agree. However, if the call is unauthenticated, "charging  
later" is not likely to be an option. For different reasons, I think  
that encouraging unauthenticated emergency calls is a bad idea. (As  
discussed elsewhere, having an emergency call authenticator does not  
imply having a monthly subscription with the phone company. "Get code  
at DMV" will do, as will other mechanisms.)

> replace R-URI with PSAP URI.  What are you advocating?

I think either will work. I'm still of the opinion that Route +  
service R-URI is the best solution, but we can probably make things  
work even without it, i.e., the traditional "replace R-URI" approach.

> I agree with this, although I'd add a DSCP for media

Sure, although I'm somewhat doubtful that DSCP is likely to be  
implemented or useful across the Internet, as it is much harder to  
secure than signaling priority.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 8 Jan 2007 00:42:20 +0800

Hi, James,

Just so I don't misquote you...

> multiple message body parts) be able to be included in any one SIP 
> message; though this has been talked about at IETF meetings from years to 
> remedy - someone always sways the WG not to consider it "now".

Are you saying that since it's not explicitly specified, that some 
implementations support it while others don't?

Thanks,

Spencer

---

From: Andrew Newton <[email-masked]>
Date: Sun, 7 Jan 2007 12:49:22 -0500

> implementations support it while others don't?

I don't know what the cause and effect are, but it is true that many  
implementations do not support it.

As to the spec being the cause... well, the spec says MUST for TLS  
and there are still a good many implementations that do not support  
this.

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 7 Jan 2007 15:59:38 -0600

Isn’t the cause a combination of a SHOULD and the fact that it has been easy to avoid needing multipart up until now?

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, 8 January 2007 4:49 AM
To: Spencer Dawkins
Cc: 'ECRIT'
Subject: Re: [Ecrit] RE: multipart

Are you saying that since it's not explicitly specified, that some implementations support it while others don't?

I don't know what the cause and effect are, but it is true that many implementations do not support it.

As to the spec being the cause... well, the spec says MUST for TLS and there are still a good many implementations that do not support this.

-andy

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 7 Jan 2007 16:04:15 -0600

The fact that there any implementations that do not support multi-part,
make setting up a voice call AND including a location value perilous.

It seems that location by reference may be the only sure bet.. *8)

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Monday, 8 January 2007 9:00 AM
To: Andrew Newton; Spencer Dawkins
Cc: ECRIT
Subject: RE: [Ecrit] RE: multipart

Isn't the cause a combination of a SHOULD and the fact that it has been
easy to avoid needing multipart up until now?

 

As to the spec being the cause... well, the spec says MUST for TLS and
there are still a good many implementations that do not support this.

-andy

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 10 Jan 2007 08:33:43 -0500

The fact that there any implementations that do not support multi-part, make
setting up a voice call AND including a location value perilous.

 

Absolutely!  All those proxies that don't support multipart are certain to
support the yet-to-be-defined location conveyance headers!

-Marc-

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Wed, 10 Jan 2007 15:41:51 +0100

As far as location-conveyance is concerned, the situation is exactly the
same as for bodies as for headers.

The default handling rules at a proxy are to pass on, unchanged, headers
and bodies that are not understood.

I assume that any proxies that need to provide functionality based on
location, e.g. special routeing or dereferencing of a location by
reference, would be required to support location-conveyance
functionality.

With regard to the support of multipart, I think that is well understood
in the SIP WG that needs to be a mandatory part of SIP and we need to
address some text somewhere to cover it. We can not of course cover
those implementations that refuse to conform to the specifications (for
example those that do not implement TCP or TLS).

Regards

Keith

	From: Marc Linsner [mailto:[email-masked]] 
	Sent: 10 January 2007 13:34
	To: 'Winterbottom, James'
	Cc: 'ECRIT'
	Subject: RE: [Ecrit] RE: multipart

		The fact that there any implementations that do not
support multi-part, make setting up a voice call AND including a
location value perilous.

		It seems that location by reference may be the only sure
bet.. *8)

	Absolutely!  All those proxies that don't support multipart are
certain to support the yet-to-be-defined location conveyance headers!

	-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 10 Jan 2007 10:14:13 -0500

Keith,

I agree with everything you said.

-Marc- 

> From: Drage, Keith (Keith) [mailto:[email-masked]] 
> Sent: Wednesday, January 10, 2007 9:42 AM
> To: Marc Linsner; Winterbottom, James
> Cc: ECRIT
> As far as location-conveyance is concerned, the situation is 
> exactly the same as for bodies as for headers.
> 
> The default handling rules at a proxy are to pass on, 
> unchanged, headers and bodies that are not understood.
> 
> I assume that any proxies that need to provide functionality 
> based on location, e.g. special routeing or dereferencing of 
> a location by reference, would be required to support 
> location-conveyance functionality.
> 
> With regard to the support of multipart, I think that is well 
> understood in the SIP WG that needs to be a mandatory part of 
> SIP and we need to address some text somewhere to cover it. 
> We can not of course cover those implementations that refuse 
> to conform to the specifications (for example those that do 
> not implement TCP or TLS).
> 
> Regards
> 
> Keith
> 
> 
> 		The fact that there any implementations that do 
> not support multi-part, make setting up a voice call AND 
> including a location value perilous.
> 
> 	Absolutely!  All those proxies that don't support 
> multipart are certain to support the yet-to-be-defined 
> location conveyance headers!
> 
> 	 
> 
> 	-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 10 Jan 2007 10:20:48 -0500

Just for completeness, you need multipart to support S/MIME, also a
mandatory to implement part of sip.  

Brian