Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling

From: "Roger Marshall" <[email-masked]>
Date: Fri, 27 Oct 2006 09:16:11 -0700

>First Proxy
>INVITE sip:urn:service:sos
>To: 
>sip:911;phone-context=[email-masked];user=dialstring
>
>Second Proxy
>INVITE sip:[email-masked]
>To: 
>sip:911;phone-context=[email-masked];user=dialstring

This doesn't make sense to me.  How does the First Proxy know to get to
the Second Proxy?  Are you showing that the service identifier,
urn:service:sos, is "hard-coded" within the 1st Proxy
("911"-->"urn:service:sos"==IP_addr_Proxy2)?

I don't think this would work too well. 

>I would say that the presence of a service URN is not a 
>request for resource priority, but is only used for route 
>determination. 

What happened to using the service identifier for emergency marking?
Emergency marking doesn't have to do with route determination, (unless
it is inappropriately used to hard-coded a route).  Route determination
is equated to a LoST query. 

Roger Marshall.

>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Friday, October 27, 2006 8:33 AM
>To: 'Henning Schulzrinne'
>Cc: [email-masked]
>Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT 
>type calling
>
>> Just so that we don't talk past each other: We wouldn't be 
>using Route 
>> to indicate an emergency call; that's indicated by the request URI 
>> and/or To header.
>Well, there is Jonathan's proposal, but even if there wasn't, 
>I thought the service URN has to go in Route because after 
>LoST mapping it wouldn't be in Request URI.
>
>Take the case of the proxy doing dialstring interpretation, 
>and just for fun, make it not the one that does LoST.
>
>UA:
>INVITE 
>sip:911;phone-context=[email-masked];user=dialstring
>To: 
>sip:911;phone-context=[email-masked];user=dialstring
>
>First Proxy
>INVITE sip:urn:service:sos
>To: 
>sip:911;phone-context=[email-masked];user=dialstring
>
>Second Proxy
>INVITE sip:[email-masked]
>To: 
>sip:911;phone-context=[email-masked];user=dialstring
>
>No service URN.  I had thought the messages were:
>First Proxy
>INVITE sip:urn:service:sos
>To: 
>sip:911;phone-context=[email-masked];user=dialstring
>Route: sip:urn:service:sos;lr
>
>Second Proxy
>INVITE sip:[email-masked]
>To: 
>sip:911;phone-context=[email-masked];user=dialstring
>Route: sip:urn:service:sos;lr
>
>
>> 
>> If all citizen-to-authority emergency calls should get 
>priority, we're 
>> essentially saying the same thing twice, which means we now have to 
>> decide what happens for calls that
>> 
>> - only indicate that this is an emergency call
>> - only indicate some kind of RP
>> - do both, but use the "wrong" RP value (e.g., use the 
>> authority-authority code)
>> 
>> Three new cases, no net gain.
>I would say that the presence of a service URN is not a 
>request for resource priority, but is only used for route 
>determination. 
>
>As I said, I'm not sure there is a need for an ordered 
>priority in this namespace, but if there is, the same problems 
>you would have with use of RPH
>in any circumstances apply.   No new problems
>
>> 
>> Also, you haven't addressed my main concern, namely that a RP 
>> indication without a strong tie to PSAP routing is a rather 
>large security hole.
>RPH in general has that issue. 
>
>Of course, the same is true of using the service URN.  
>Ignoring for a moment, my argument above:
>
>UA:
>INVITE sip:[email-masked]
>To: sip:urn:service:sos
>
>Is exactly the problem you are describing, right?  What 
>defenses do we have against this?  I think the only thing you 
>could do is to verify that for the location in the Geolocation 
>header, the RequestURI was the LoST response.
>
>Brian
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 12:42:05 -0400

The first proxy has a hard coded route to the second proxy.  The first proxy
is the P-CSCF, the second proxy is the E-CSCF in IMS terms.  All emergency
calls are routed to the second proxy and it does all the work.  That's a
pretty reasonable mechanism; it's what the Packet Cable 2.0 spec says, for
instance.  It's not unlike how a lot of systems work for gateways,  the
first hop outbound proxy determines if it needs to route to a gateway, but
all gateway calls are passed to another proxy whose job is to pick the right
gateway to get the call.  It's a pretty simple mechanism, albeit it needs a
provisioning step.

Of course, you can combine the two proxies into one proxy, and the result
would have the problem I showed: without a Route header containing the
service urn, the message would no longer have a marking.

Actually, I do think the marking is all about routing.  It tells you that
this call is routed as an emergency call.  When in a Route header, it's
exactly right: your destination is the UA handling the urn:service:sos URI,
Although there may be a number of intermediaries in the path (ESRPs for
example).

Brian

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 12:16 PM
> To: Brian Rosen; Henning Schulzrinne
> Cc: [email-masked]
> Subject: RE: [Ecrit] New ID for SIP RPH namespace for ECRIT type calling
> 
> 
> >First Proxy
> The information contained in this message may be privileged and/or
> confidential. If you are not the intended recipient, or responsible for
> delivering this message to the intended recipient, any review, forwarding,
> dissemination, distribution or copying of this communication or any
> attachment(s) is strictly prohibited. If you have received this message in
> error, please so notify the sender immediately, and delete it and all
> attachments from your computer and network.