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

["DRAGE, Keith \(Keith\)" <[e-mail]>]

(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

> -----Original Message-----
> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) 
> [mailto:[e-mail]] 
> Sent: Tuesday, September 04, 2007 1:06 PM
> To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig
> Cc: IETF SIP List; ECRIT; Dean Willis
> Subject: AW: [Ecrit] Re: [Sip] 
> draft-rosenberg-sip-ua-loose-route-01.txt
> 
> Hi Christer, 
> 
> Thanks for your quick response. 
> Please find a few comments below: 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: ext Christer Holmberg (JO/LMF)
> > [mailto:[e-mail]]
> > Gesendet: Dienstag, 4. September 2007 14:00
> > An: Hannes Tschofenig
> > Cc: IETF SIP List; ECRIT; Dean Willis
> > Betreff: RE: [Ecrit] Re: [Sip]
> > draft-rosenberg-sip-ua-loose-route-01.txt
> > 
> > 
> > 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?
> > 
> > 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
> 
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > > >> -----Original Message-----
> > > >> From: Hannes Tschofenig [mailto:[e-mail]]
> > > >> 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.
> > > >>
> > > >> 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 
> > > >> [e-mail] for questions on 
> > current sip Use 
> > > >> [e-mail] for new developments on the application of sip
> > > >>
> > > >>     
> > > 
> > > 
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments on the application of sip
> > 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

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