Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Sep 2007 21:59:28 +0200

Hi Dean,

in ECRIT we assumed that the Request URI contains the service URN. We 
put that stuff into the Phone BCP document (which unfortunately still 
contains an error I just noticed).
That's what we told the 3GPP in the past as well. Hence, they wrote it 
in their specs. See TS 24.229, Section 5.1.6.8.3, bullet (1).

Within the ECRIT group we weren't aware that this issue has not been 
decided and hence we are a bit concerned about the recent change given 
that other SDOs followed our suggestion already.

Do you have an idea what we should do now?

Ciao
Hannes

Dean Willis wrote:
> Hannes Tschofenig wrote:
>> No response received -- resend.
>>
>> Hannes Tschofenig wrote:
>>
>>> Dear SIP WG members,
>>>
>>> during the ECRIT meeting we learned that the SIP working group 
>>> "rejected" the concept described in 
>>> draft-rosenberg-sip-ua-loose-route-01.txt.
>>>
>>> Could someone please give us more information about this decision as 
>>> it impacts the work we do in ECRIT?
>
> I wouldn't say that UA Loose Route was "rejected" so much as "does not 
> yet have consensus".
>
> This is in part influenced by "WG doesn't seem to have a compelling 
> reason to make such a significant change."
>
> Perhaps ECRIT has a compelling reason?
>
> -- 
> Dean

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 09:17:56 +0200

Hi Christer,

Christer Holmberg (JO/LMF) wrote:
> Hi,
>
> In 3GPP, it is true that the UE inserts the service URN into the
> Request-URI.
>
> But, in the current specification the E-CSCF converts the URN into a
> routable PSAP address, i.e. the mechanism in the loose-route draft is
> not used.
>
>   
Why was this done? Do you expect that the call uses a different 
emergency call marking technique went it enters the PSAP operator network?
Do you expect that the call is directly sent from the E-CSCF to the PSAP 
and that there are no other hops in between?

> Regards,
> Christer
Ciao
Hannes

>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]] 
>> Sent: 3. syyskuuta 2007 22:59
>> To: Dean Willis
>> Cc: IETF SIP List; ECRIT
>> Subject: Re: [Ecrit] Re: [Sip] 
>> draft-rosenberg-sip-ua-loose-route-01.txt
>>
>> Hi Dean,
>>
>> in ECRIT we assumed that the Request URI contains the service 
>> URN. We put that stuff into the Phone BCP document (which 
>> unfortunately still contains an error I just noticed).
>> That's what we told the 3GPP in the past as well. Hence, they 
>> wrote it in their specs. See TS 24.229, Section 5.1.6.8.3, bullet (1).
>>
>> Within the ECRIT group we weren't aware that this issue has 
>> not been decided and hence we are a bit concerned about the 
>> recent change given that other SDOs followed our suggestion already.
>>
>>>>> Could someone please give us more information about this 
>>>>>           
>> decision as 
>>     
>>> I wouldn't say that UA Loose Route was "rejected" so much 
>>>       
>> as "does not 
>>     
>>> yet have consensus".
>>>
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments on the application of sip
>>
>>

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Tue, 4 Sep 2007 14:05:57 +0200

Hi Christer, 

Thanks for your quick response. 
Please find a few comments below: 

> -----Ursprüngliche Nachricht-----
> Von: ext Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Gesendet: Dienstag, 4. September 2007 14:00
> An: Hannes Tschofenig
> Cc: IETF SIP List; ECRIT; Dean Willis
> Betreff: RE: [Ecrit] Re: [Sip] 
> >Why was this done?
> I don't have all the details, but one reason was that the same
> procedures were wanted towards a PSAP and an MGCF, and at least in the
> previous 3GPP releases the MGCF does the called party number mapping
> based on the Request-URI value.

You mean that the MGCF wouldn't know what todo with the Request URI. 
This sounds like a backwards compatibility aspect.

> Also, since this was done a while ago,
> the loose-route draft mechanism wasn't even discussed.
That's probably true. 

 Also, since
> neither the PSAP or MGCF registers themselves to the E-CSCF, the
> loose-route draft mechanism wouldn't be used towards those 
> entities even
> if adopted by IMS.

I don't think that the Request URI has anything todo with registrations. 

> 
> >Do you expect that the call uses a different emergency call marking
> technique went it enters the PSAP operator network?
> 
> I think it is up to each operator to decide how the marking is done.

In the 3GPP model with the E-CSCF and the PSAP having a close relationship you could leave this issue open. It would, however, make their life easier. 

> There will always be agreements between the PSAP operators 
> and the other
> ("public") operators using them.

Only in the 3GPP IMS alike architecture. The IETF emergency services architecture is a bit different. 

 I guess it would also be possible to
> put the original service URN into the P-Called-Party-Id header (as for
> normal calls), eventhough I don't think it's currently specified.

I am not sure whether this is a good solution. 

> 
> >Do you expect that the call is directly sent from the E-CSCF to the
> PSAP and that there are no other hops in between?
> 
> I think both cases are applicable.
When you have intermediate entities that need to recognize emergency calls and need to treat the call differently then you might want to define the procedures since otherwise there is a chance that things don't work as expected. 

Ciao
Hannes

> > >> That's what we told the 3GPP in the past as well. Hence, 
> > they wrote 
> > >> it in their specs. See TS 24.229, Section 5.1.6.8.3, bullet (1).
> > >>
> > >> decided and hence we are a bit concerned about the recent change 
> > >> given that other SDOs followed our suggestion already.
> > >>
> > >> This list is for NEW development of the core SIP Protocol Use 
> > >> [email-masked] for questions on 
> current sip Use 
> > >> [email-masked] for new developments on the application of sip
> > >>
> > >>     
> > 
> > 
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Sep 2007 08:50:18 -0400

Just FYI, NENA is likely to require what ecrit decides, assuming that there
does not appear to be a large burden on carriers.

This is one of the areas where it would appear there could be gratuitous
differences between the IETF architecture and the IMS architecture which
need to be addressed.

Brian

> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
> [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2007 8:06 AM
> To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig
> Cc: IETF SIP List; ECRIT
> Subject: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt
> 
> Hi Christer,
> 
> In the 3GPP model with the E-CSCF and the PSAP having a close relationship
> you could leave this issue open. It would, however, make their life
> easier.
> 
> When you have intermediate entities that need to recognize emergency calls
> and need to treat the call differently then you might want to define the
> procedures since otherwise there is a chance that things don't work as
> expected.
> 
> Ciao
> Hannes
> 
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 4 Sep 2007 15:06:37 +0200

(Removing parties from the original list distribution)

The situation in 3GPP is that we have so far failed to agree any marking or other carriage of other information (with a significant number of the objections coming from the organisation Christer works for), not that we have agreed we don't want one.

I believe the appropriate way forward on marking for special handling is actually the Resource-Priority header solution identified by  

http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-01.txt

In terms of special handling, this makes a lot of sense for those SIP entities that already have to implement RFC 4412 for other regulatory reasons.

As already indicated, the 3GPP E-CSCF (the emergency routeing proxy) changes the Request-URI to the PSAP URI, and the original Reuqest-URI is lost. Once we have reached the E-CSCF, is the original Request-URI (the service URN) still important for any issue apart from special handling?

Regards

Keith

> Sent: Tuesday, September 04, 2007 1:06 PM
> Subject: AW: [Ecrit] Re: [Sip] 
> In the 3GPP model with the E-CSCF and the PSAP having a close 
> relationship you could leave this issue open. It would, 
> however, make their life easier. 
> 
> Only in the 3GPP IMS alike architecture. The IETF emergency 
> services architecture is a bit different. 
> 
> When you have intermediate entities that need to recognize 
> emergency calls and need to treat the call differently then 
> you might want to define the procedures since otherwise there 
> is a chance that things don't work as expected. 
> 
> Ciao
> Hannes
> 
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Sep 2007 09:23:58 -0400

> .... Once we have reached the E-CSCF, is the original Request-URI (the
> service URN) still important for any issue apart from special handling?
Yes

You need to know what service was requested, which may or may not be what
PSAP it ended up on.  This is especially true in disasters where regardless
of what you asked for, the call may end up in some temporary call center.

Brian

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Tue, 4 Sep 2007 15:25:58 +0200

Hi Keith, 

> The situation in 3GPP is that we have so far failed to agree 
> any marking or other carriage of other information (with a 
> significant number of the objections coming from the 
> organisation Christer works for), not that we have agreed we 
> don't want one.
> 

Understood. 

> I believe the appropriate way forward on marking for special 
> handling is actually the Resource-Priority header solution 
> identified by  
> 

Good to hear that. 

> In terms of special handling, this makes a lot of sense for 
> those SIP entities that already have to implement RFC 4412 
> for other regulatory reasons.

Aren't these somewhat different entities given that RFC 4412 has it's origin in the MLPP work (if I understood it correctly).

> As already indicated, the 3GPP E-CSCF (the emergency routeing 
> proxy) changes the Request-URI to the PSAP URI, and the 
> original Reuqest-URI is lost. Once we have reached the 
> E-CSCF, is the original Request-URI (the service URN) still 
> important for any issue apart from special handling?

In the 3GPP when the call leaves the E-CSCF towards the PSAP then it might not be that important. (It is yet another issue whether there needs to be call marking in the PSAP operators network itself -- NENA might tell us more about that.) Is there some marking when messages are sent between P-CSCF/E-CSCF and the user's home network?

In the IETF architecture the call might travel through intermediate SIP proxy when it leaves the user's home network. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Tue, 4 Sep 2007 15:27:30 +0200

I forgot that part. You are completely right, Brian. 

Ciao
Hannes

> Von: ext Brian Rosen [mailto:[email-masked]] 
> Gesendet: Dienstag, 4. September 2007 15:24
> An: 'DRAGE, Keith (Keith)'; 'ECRIT'

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 15:37:35 +0200

Hi Christer,

>>> Also, since neither the PSAP or MGCF registers themselves to the
>>>       
> E-CSCF, the
>   
>>> entities even if adopted by IMS.
>>>       
>> I don't think that the Request URI has anything todo with
>>     
> registrations. 
>
> The mechanism in the draft is only used towards users that in the
> registration have indicated support for it.
>   

This seems to be a "capability discovery" approach.
Since the PSAP does not register at the E-CSCF the "capability 
discovery" would not work.

>>> There will always be agreements between the PSAP operators and the
>>>       
> other
>   
>> Only in the 3GPP IMS alike architecture. The IETF emergency services
>>     
> architecture is a bit different. 
>
> Well, you asked how it works in IMS :)
>   
Correct. I asked for the IMS description.

But you understand that we would like to use mechanisms in a generic way 
whenever possible regardless whether the call starts in a 3GPP, Wimax, 
DSL, WLAN or enterprise network.

>  
>   
>>> I guess it would also be possible to put the original service URN into
>>>       
> the P-Called-Party-Id 
>   
>>> header (as for normal calls), eventhough I don't think it's currently
>>>       
> specified.
>   
> Why not?
I read through 
http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt 
and I got the impression that Jonathan has encountered a generic problem 
and the description he provided looked reasonable to me to argue for the 
Request URI to remains unchanged end-to-end and not to use other 
solutions. He listed two other solutions and the P- header approach does 
not look generic to me.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 4 Sep 2007 11:47:35 -0400

While this is far from elegant, there is really no practical problem  
with having multiple URIs end up in the same place. In other words,  
each service URN can be mapped to different request URIs  
(fire@overflowpsap, ambulance@overflowpsap, ....) and still be  
answered by the same system or group of call takers. The user part  
has only local significance, after all, and N-to-1 URI mappings are  
quite common for other purposes.

Henning

On Sep 4, 2007, at 9:27 AM, Tschofenig, Hannes (NSN - DE/Germany -

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Sep 2007 12:02:07 -0400

I thought about that.  It gets a lot more complicated, but I imagine we
could make it work.  It would end up using something like:
sip:[email-masked]

A parameter could also be used.  Everyone else would just pass it through
from LoST server to the PSAP.
I'd really rather have an unambiguous marker.
I also think the logic in Jonathan's loose-route draft is pretty good.
Using the same idea in multiple environments is good.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2007 11:48 AM
> To: Tschofenig, Hannes (NSN - DE/Germany - MiniMD)
> Cc: ext Brian Rosen; DRAGE, Keith (Keith); ECRIT
> Subject: Re: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-
> 01.txt
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Sep 2007 11:14:46 -0700

>from LoST server to the PSAP.

Assuming you mean something like

sip:[email-masked]; service-urn=urn:service:sos.fire

I like that better.  If the parameter not present, the PSAP doesn't know what service
was used  to route to it, but that's not really much worse than where we are now. 
It would still reach the right.  I'm less happy about
[email-masked] or even [email-masked],
because I worry that someone may incorrectly construct the left hand side
there and get rejected.  In other words, if someone forget to include

[email-masked]

in the local default maping, it might not get through the routing process, where
[email-masked]; service-urn=urn:service:sos.mountain-rescue
would get through despite the bug. 

Does that make sense?
			Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Sep 2007 14:34:00 -0400

You did interpret what I meant by parameter correct.

All of this works because it is PSAP management that has to specify the
contents of the LoST PSAP URI, so it can put in whatever it needs to "do the
right thing".  I personally like the parameter better than mucking with the
user part of the sip URI.

However, I like loose route better than that.  It seems to do exactly what
is needed, and as far as all systems prior to the PSAP, it follows 3261.
The PSAP could actually pop the route header when it chose the call taker to
get the call.  Or not.

Brian

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2007 2:15 PM
> To: Brian Rosen; 'Henning Schulzrinne'; 'Tschofenig, Hannes (NSN -
> DE/Germany - MiniMD)'
> Cc: 'ECRIT'
> Subject: RE: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-
> 01.txt
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 4 Sep 2007 15:08:30 -0400

As for Brian, my preferred solution is the loose-route proposal.

If we want an explicit marking, I think an explicit header would be  
clearest, as in

Service: urn:service:sos.fire

(I don't want this to be conflated with the service discussion in  
SIP; this has nothing to do with what's been discussed there. I don't  
care about the header label.)

Resource priority is, in my opinion, not appropriate for marking the  
service requested since such calls may not actually get resource  
priority and since it is unlikely that fire calls will get a  
different priority from police calls. Conversely, the RPH header is  
dangerous outside carefully controlled environments, since it can be  
a DOS tool. In particular, RPH requires strong client authentication,  
which is generally not available in emergency calls. Within the  
(trusted) ESN, this isn't a major problem, but letting end users or  
VSPs set that header field is asking for trouble unless other  
entities can verify that the call is indeed an emergency call. If  
they can do that, then you don't need the header.

Overloading headers just because they are available doesn't strike me  
as architecturally appropriate.

Henning

On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote:

> The situation in 3GPP is that we have so far failed to agree any  
> marking or other carriage of other information (with a significant  
> number of the objections coming from the organisation Christer  
> works for), not that we have agreed we don't want one.
>
> In terms of special handling, this makes a lot of sense for those  
> SIP entities that already have to implement RFC 4412 for other  
> regulatory reasons.
>
> proxy) changes the Request-URI to the PSAP URI, and the original  
> Reuqest-URI is lost. Once we have reached the E-CSCF, is the  
> original Request-URI (the service URN) still important for any  
> issue apart from special handling?
>
> Regards
>
> Keith
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 4 Sep 2007 14:13:21 -0500

On Sep 3, 2007, at 2:59 PM, Hannes Tschofenig wrote:

> Hi Dean,
>
> in ECRIT we assumed that the Request URI contains the service URN.  
> We put that stuff into the Phone BCP document (which unfortunately  
> still contains an error I just noticed).
> That's what we told the 3GPP in the past as well. Hence, they wrote  
> Within the ECRIT group we weren't aware that this issue has not  
> been decided and hence we are a bit concerned about the recent  
> change given that other SDOs followed our suggestion already.
>

Tell them not to translate the emergency service URN into something  
that doesn't preserve the requisite information?

In IMS that should be easy, even if the CSCF is translating into a  
routable PSAP entry.

In the broader IETF case, I suspect it means "NEVER retarget a  
request URI that contains a service URN unless you're the terminating  
PSAP's proxy, and then do so very carefully."

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Sep 2007 15:21:28 -0400

Agree

We may end up trying to use RPH within a public network, but I don't think
it can do a whole lot for the reasons Henning gives.  It's more likely to be
of value in the emergency services IP networks.

I look at RPH exactly as its name suggests: a RESOURCE priority header; it
specifies how the individual entities treat the call with respect to
resources they manage.  It's analogous, to me, with a DiffServ code point,
which specifies how routers treat the underlying packet streams with respect
to the resources they manage.

The Service URN specifies the service that was requested, independent of any
resources that may be needed.

I'm particularly concerned that the endpoint not have yet one more mechanism
it has to implement.  We're asking they implement the Service URN.  I'd
rather not MUST them into RPH.

Brian

> Sent: Tuesday, September 04, 2007 3:09 PM
> To: DRAGE, Keith ((Keith))
> Cc: ECRIT
> Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Sep 2007 01:29:27 -0500

I believe I agree that the RPH shouldn't be relied upon as the (or 
the only) enduring indication a call is an emergency call.

I think the sos RPH namespace should be used within emergency 
networks for resource treatment. 
draft-polk-ecrit-local-emergency-rph-namespace-01.txt talks about this.

I also think it should be up to the arrangements between the 
emergency network to and a service provider, say one with an IMS 
architecture, to establish trust to a particular server, perhaps each 
E-CSCF within that provider's network, to appropriate PSAPs.  In this 
scenario, which should be possible, but not necessarily pushed at 
this time, the *-CSCF can add the sos RPH to an emergency SIP 
request.  The SP would be taking on the charge of making sure the RPH 
wouldn't cause harm within their network to the emergency services network.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 5 Sep 2007 09:46:21 +0100

> of what you asked for, the call may end up in some temporary call center.

Furthermore, no matter whether or not everything else handles it correctly,
it strikes me as a really bad idea to throw away information like this.
Even if the original Request-URI ends up in a Original-Emergency-Request-URI
header that we have to invent, let's not throw away data that could be
a matter of life and death (literally).

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 21 Sep 2007 16:22:11 +0200

I think this is a case of horses for courses. People have said we should
not overload headers, and we seem to have two separate functions - the
routing function and the processing treatment function where emergency
calls need to be recognised for special handling.

Where emergency calls in the network require special processing
treatment, then I also consider the RPH header is appropriate. Note that
this is not a case of treating emergency calls first, more a matter of
making sure that they are not precluded by other heavy traffic.

I (now) understand the need to retain the service URN once a candidate
PSAP address has been identified. This is a routeing function.

I think we need two separate solutions covering each problem. Each
solution is inappropriate to cover the other problem.

Regards

Keith

> From: James M. Polk [mailto:[email-masked]] 
> Sent: Wednesday, September 05, 2007 7:29 AM
> To: Henning Schulzrinne; DRAGE, Keith (Keith)
> Cc: ECRIT
> I believe I agree that the RPH shouldn't be relied upon as 
> the (or the only) enduring indication a call is an emergency call.
> 
> emergency network to and a service provider, say one with an 
> IMS architecture, to establish trust to a particular server, 
> perhaps each E-CSCF within that provider's network, to 
> appropriate PSAPs.  In this scenario, which should be 
> possible, but not necessarily pushed at this time, the *-CSCF 
> can add the sos RPH to an emergency SIP request.  The SP 
> would be taking on the charge of making sure the RPH wouldn't 
> cause harm within their network to the emergency services network.
> 
> >(I don't want this to be conflated with the service 
> discussion in SIP; 
> >this has nothing to do with what's been discussed there. I 
> don't care 
> >about the header label.)
> >
> different 
> >priority from police calls. Conversely, the RPH header is dangerous 
> >outside carefully controlled environments, since it can be a 
> DOS tool. 
> >In particular, RPH requires strong client authentication, which is 
> >generally not available in emergency calls. Within the
> >VSPs set that header field is asking for trouble unless 
> other entities 
> >can verify that the call is indeed an emergency call. If they can do 
> >that, then you don't need the header.
> >
> >>number of the objections coming from the organisation 
> Christer works 
> >>for), not that we have agreed we don't want one.
> >>
> >>I believe the appropriate way forward on marking for 
> special handling 
> >>is actually the Resource-Priority header solution identified by
> >>
> those SIP 
> >>entities that already have to implement RFC 4412 for other 
> regulatory 
> >>reasons.
> >>
> >>Reuqest-URI is lost. Once we have reached the E-CSCF, is 
> the original 
> >>Request-URI (the service URN) still important for any issue 
> apart from 
> >>special handling?
> >>
> >>Regards
> >>
> >>Keith
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 16:34:02 +0200

Hi Keith,

I think in ECRIT we essentially came to the conclusion that we want to 
use the procedure described in
http://www1.ietf.org/mail-archive/web/ecrit/current/msg04297.html

I believe Brian has added the description already to the most recently 
submitted Phone BCP draft, see
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt

For dealing with emergency call marking within a PSAP operator network 
the RPH header may be fine.
I was asked by James whether 
draft-polk-ecrit-local-emergency-rph-namespace-01.txt can become a 
working group item of ECRIT and after interacting with our ADs they 
suggested to postpone such a question to the group after we finished our 
current items. That's fine with me as well given that our progress

Ciao
Hannes

DRAGE, Keith (Keith) wrote:
>>> Overloading headers just because they are available doesn't 
>>>       
>> strike me 
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Sep 2007 10:36:38 -0400

Keith

I am a little worried about policing RPH.

If a proxy puts the RPH on, and it stays in one domain until it's given to
the PSAP domain (the ESRP in most cases), then it might work.

However, if the endpoint asserts it, then we really have a problem with
fraud, especially if you take it at face value and say that you have a
priority on resources in the network.  I'm not really thinking about the
monetary value, but the ability to gain priority just by claiming to be an
emergency call.

It did occur to me that the solution offered by Richard Barnes for
validation of a PSAP URI in the presence of location hiding would work here,
but I suspect that the damage would be done by the time it was discovered
(which is at the exit point from the origination domain).  The other ideas
we had wouldn't work at all.

Brian

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Friday, September 21, 2007 10:22 AM
> To: James M. Polk; Henning Schulzrinne
> Cc: ECRIT
> Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt
>