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

_______________________________________________
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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 4 Sep 2007 09:06:48 +0200

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.

Regards,

Christer

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

---

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

Hi Christer,

> routable PSAP address, i.e. the mechanism in the loose-route draft is
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?

Ciao
Hannes

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 4 Sep 2007 13:59:54 +0200

Hi, 

Request-URI.
>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. Also, since this was done a while ago,
the loose-route draft mechanism wasn't even discussed. 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.

>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.
There will always be agreements between the PSAP operators and the other
("public") operators using them. 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.

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

Regards,

Christer

> >> 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: "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] 
> 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
> loose-route draft mechanism wouldn't be used towards those 

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

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

> ("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
> normal calls), eventhough I don't think it's currently specified.

I am not sure whether this is a good solution. 

> 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

---

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
> >
> >
> >
> >
> >
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 4 Sep 2007 15:07:05 +0200

Hi, 

>>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
>This sounds like a backwards compatibility aspect.

Correct.

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

The mechanism in the draft is only used towards users that in the
registration have indicated support for it.
 
>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. 
> 

Well, you asked how it works in IMS :)
 
>>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. 

Why not?

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

Yes.

Regards,

Christer

---

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

Hi Christer,

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

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. 
>
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 am not sure whether this is a good solution. 
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: 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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 5 Sep 2007 09:35:20 +0200

Hi Hannes, 

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

Well, that is what the discussion about the draft pretty much is all
about. I think that the P- header approach works. You can use it without
capability discovery (if the receiver does not support it he will simply
discard it) and it does not have the possible backward compability
issues with the other solution. And, the P- header has been part of IMS
for a long time now (since release 5).

There were been some discussions that the P- header is not "standards
track" etc, and that something would have to be done regarding that if
we want to make it more "generic". But, that should not affect existing
deployments/usages of the header.

Regards,

Christer

---

From: [email-masked]
Date: Wed, 5 Sep 2007 16:27:13 -0400

From: Hannes Tschofenig <[email-masked]>

I suspect there is a misunderstanding here:  There was some lengthy
discussion of a generalized "UA loose routing" (using URNs as
request-URIs) mechanism on the SIP mailing list, which discussion did
not result in a consensus.  However, in the course of the discussion,
the use of "loose routing" for emergency calls was mentioned, and I
believe that a consensus in favor of that technique was expressed.

The criticial differentiations between the emergency case and the
general case seem to be (1) a small number (possibly 1) of very
standardized URNs would be used, and (2) the ability of "loose
routing" to prevent fradulient usage of priority service without the
prior exchange of authentication information.

Dale