Hi,
>>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.
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.
>
>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.
>>>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.
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?
>>>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.
Yes.
Regards,
Christer
> > > >> -----Original Message-----
> > > >> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED]
> > > >> 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
> > > >> [EMAIL PROTECTED] for questions on
> > current sip Use
> > > >> [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
> > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
