|
|
That is up to the VSP. In the 3GPP case, they send emergency calls to the
E-CSCF. Others may do it on the first hop outbound (what would be the
P-CSCF). I don't think we care, and I don't think we even discuss it.
Brian
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
> Sent: Sunday, July 15, 2007 9:49 AM
> To: Brian Rosen
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] Phone BCP Draft Comments
>
> Hi Brian,
>
> sure that's fine. But the problem is the following: What proxy should
> add location information other than a proxy in the access network.
> So far, such a proxy does not exist in our emergency services
> architecture. Right?
>
> Ciao
> Hannes
>
> Brian Rosen wrote:
> > Hannes
> >
> > I believe your opinion runs counter to consensus, and I'll bring this up
> for
> > a hum at the meeting. I think most of us think endpoint insertion of
> > location is preferred, but proxy insertion, under the right
> circumstances,
> > is acceptable.
> >
> > Brian
> >
> >
> >> -----Original Message-----
> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
> >> Sent: Sunday, July 15, 2007 4:11 AM
> >> To: Brian Rosen
> >> Cc: 'ECRIT'
> >> Subject: Re: [Ecrit] Phone BCP Draft Comments
> >>
> >> Hi Brian,
> >>
> >> Brian Rosen wrote:
> >>
> >>> The text now says that the phone applies normal outbound processing.
> >>>
> >> That
> >>
> >>> would mean it sends calls to the VSP. That's what we want.
> >>>
> >>> Marc's phone would normally send calls to his house proxy. That is
> what
> >>>
> >> we
> >>
> >>> want.
> >>>
> >>>
> >> Typically, it would be the proxy of Marc's VoIP provider.
> >>
> >>> Let us try my way with the organization and see if it accomplishes
> what
> >>>
> >> you
> >>
> >>> want. If it's a mess, I'll look at doing it your way.
> >>>
> >>> I'll make sure we discuss proxy insertion of location in both -
> framework
> >>>
> >> and
> >>
> >>> -phonebcp. I think it is best to state it is acceptable if the
> >>>
> >> limitations
> >>
> >>> implied (VSP has a relationship with ISP, has a good identifier that
> ISP
> >>>
> >> can
> >>
> >>> use) hold.
> >>>
> >>>
> >> I don't think we have a place in our current architecture for the proxy
> >> insertion for location.
> >> We should first discuss that aspect from an architectural point of
> view.
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >>
> >>> Brian
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
> >>>> Sent: Saturday, July 14, 2007 5:38 PM
> >>>> To: Brian Rosen
> >>>> Cc: 'ECRIT'
> >>>> Subject: Re: [Ecrit] Phone BCP Draft Comments
> >>>>
> >>>> Hi Brian,
> >>>>
> >>>> thanks for the quick response. Please see my comments below:
> >>>>
> >>>> Brian Rosen wrote:
> >>>>
> >>>>
> >>>>> See in line
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
> >>>>>> Sent: Friday, July 13, 2007 5:11 PM
> >>>>>> To: ECRIT
> >>>>>> Subject: [Ecrit] Phone BCP Draft Comments
> >>>>>>
> >>>>>> Hi Brian,
> >>>>>> Hi James,
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I like the document, as I expressed several times in the past.
> >>>>>>
> >>>>>> There are, however, a few issues with it.
> >>>>>>
> >>>>>> Henning and myself have recently written an ECRIT overview
> document.
> >>>>>>
> >>>>>>
> >>>> See
> >>>>
> >>>>
> >>>>>> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-
> >>>>>> overview-00.txt
> >>>>>>
> >>>>>> One thing that was quite important for us to highlight was that the
> >>>>>>
> >>>>>>
> >>>> IETF
> >>>>
> >>>>
> >>>>>> emergency service architecture has a very nice property, namely the
> >>>>>>
> >>>>>>
> >>>> fact
> >>>>
> >>>>
> >>>>>> that different VoIP protocols may be supported between the end host
> >>>>>>
> >> and
> >>
> >>>>>> the VoIP provider. There is no need to implement SIP only.
> >>>>>>
> >>>>>> Now, this document does not give me the impression that this aspect
> >>>>>>
> >> is
> >>
> >>>>>> given enough consideration.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> There are two things that came to mind when I read this. One is
> that
> >>>>>
> >>>>>
> >>>> you
> >>>>
> >>>>
> >>>>> are right, and we can be more clear that any protocol can be used
> >>>>>
> >>>>>
> >>>> between
> >>>>
> >>>>
> >>>>> the endpoint and some kind of gateway that interworks to a protocol
> >>>>>
> >> that
> >>
> >>>> the
> >>>>
> >>>>
> >>>>> PSAP implements.
> >>>>>
> >>>>> The other is that SIP need not be the only protocol the PSAP
> >>>>>
> >> implements.
> >>
> >>>>>
> >>>> That's certainly true. We do, however, have to start somewhere. We
> >>>> cannot describe what Skype protocol features a PSAP has to implement
> >>>>
> >> for
> >>
> >>>> an emergency service scenario.
> >>>>
> >>>> Hence, we focus only on SIP. That's already enough for a PSAP to
> >>>> implement.
> >>>> We do, however, only mandate functionality that is absolutely
> necessary
> >>>> for interoperability.
> >>>>
> >>>>
> >>>>
> >>>>> However. There are some requirements on what the protocol needs to
> do.
> >>>>>
> >>>>>
> >>>> We
> >>>>
> >>>>
> >>>>> should list them, and I think probably that discussion belongs in
> >>>>> -framework. LoST already can return multiple URIs with different
> >>>>>
> >>>>>
> >>>> schemes
> >>>>
> >>>>
> >>>>> corresponding to what it implements.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> It might be a good idea to state what protocols have to support --
> >>>>
> >> there
> >>
> >>>> aren't too many things anyway.
> >>>>
> >>>>
> >>>>
> >>>>>> The IETF emergency service architecture realistically requires that
> >>>>>>
> >> the
> >>
> >>>>>> emergency calls are routed through the VSP in order to get identity
> >>>>>> information attached to an emergency call.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> NO!!!!
> >>>>>
> >>>>> That is NOT true. The PSAPs I work with will take calls that don't
> >>>>>
> >> come
> >>
> >>>>> >from a VSP over the internet.
> >>>>>
> >>>>>
> >>>> I guess you need to describe in more detail what you have seen.
> >>>>
> >>>>
> >>>>
> >>>>> They may well have some suspicion on such
> >>>>> calls due to the lack of a verifiable identity but they will take
> the
> >>>>>
> >>>>>
> >>>> call
> >>>>
> >>>>
> >>>>> anyway. I've had numerous conversations with PSAP people who want
> to
> >>>>>
> >>>>>
> >>>> make
> >>>>
> >>>>
> >>>>> sure I understand the "rules" they have (validated location for
> >>>>>
> >>>>>
> >>>> examples).
> >>>>
> >>>>
> >>>>> When I press them for what they want to do when something goes wrong
> >>>>>
> >> and
> >>
> >>>> it
> >>>>
> >>>>
> >>>>> doesn't happen (like, validation fails, do they want unvalidated
> >>>>>
> >>>>>
> >>>> location or
> >>>>
> >>>>
> >>>>> no location), they ALWAYS want the call, and they want the data you
> >>>>>
> >>>>>
> >>>> have.
> >>>>
> >>>>
> >>>>> They may treat the call with suspiscion. They may go back later and
> >>>>>
> >> try
> >>
> >>>> to
> >>>>
> >>>>
> >>>>> figure out why they didn't get what they wanted but they take the
> call
> >>>>>
> >>>>>
> >>>> and
> >>>>
> >>>>
> >>>>> ask questions later.
> >>>>>
> >>>>> So please don't make that assumption. Ysa, we expect nearly all
> calls
> >>>>>
> >>>>>
> >>>> to go
> >>>>
> >>>>
> >>>>> through a VSP, but the system works if Marc Linsner's proxy in his
> >>>>>
> >> house
> >>
> >>>>> sends the call to the PSAP.
> >>>>>
> >>>>>
> >>>>>
> >>>> That's fine. It is just the question what we write into the document.
> >>>> What is the default behavior?
> >>>> We sent the calls directly to the PSAP or via the VSP?
> >>>>
> >>>> This has impact for the phone BCP document. If you assume that calls
> >>>>
> >> are
> >>
> >>>> routed through the VSP then the protocol run by the end point does
> not
> >>>> matter too much.
> >>>> If you assume that the end host MUST be able to route directly to the
> >>>> PSAP as well then you have to mandate a certain functionality at the
> >>>>
> >> end
> >>
> >>>> point.
> >>>>
> >>>> So, what behavior do we want?
> >>>>
> >>>>
> >>>>
> >>>>>> Having said all that I believe that one important aspect, which is
> >>>>>>
> >> also
> >>
> >>>>>> different to architecturs investigated by other SDOs, is that the
> >>>>>>
> >> PSAP
> >>
> >>>>>> has to support a certain functionality. This functionality is
> >>>>>>
> >> described
> >>
> >>>>>> in the document but might not be too visible to the working group
> or
> >>>>>>
> >> at
> >>
> >>>>>> least hasn't be advertised a lot.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Yes, this is true. We could make that more explicit.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I believe we have to indicate quite close what the different
> entities
> >>>>>> have to support rather than meshing everything together. This
> impacts
> >>>>>> the document structure a bit.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Yes, we have thought about that a lot, and have had some suggestions
> >>>>>
> >> in
> >>
> >>>> that
> >>>>
> >>>>
> >>>>> the direction, the goal being to have all the BCPs for phones in one
> >>>>>
> >>>>>
> >>>> place,
> >>>>
> >>>>
> >>>>> those for the access network in another place, etc.
> >>>>>
> >>>>>
> >>>>>
> >>>> It's OK to have the required functionality listed in one document
> even
> >>>> though they address all the involved parties in the architecture.
> >>>>
> >>>>
> >>>>
> >>>>>> Here is a suggested structure for the document:
> >>>>>>
> >>>>>> * Introduction
> >>>>>>
> >>>>>> Shorten the introduction
> >>>>>>
> >>>>>> It contains a lot of info that is already available in the
> framework.
> >>>>>> This document has to be read in the context of the architecture
> >>>>>>
> >> anyway.
> >>
> >>>>>>
> >>>>> We will do that
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Btw, the introduction must not use RFC 2119 language.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Yes
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> * Terminology
> >>>>>>
> >>>>>> Classical RFC boilerplate and pointers to the requirements
> document.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>> * End Host Profile
> >>>>>>
> >>>>>> This section just describes what is absolutely necessary for an end
> >>>>>> point to support the
> >>>>>>
> >>>>>> This is essentially the location part, the LoST part.
> >>>>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5.
> >>>>>> The LoST stuff can be found in Section 6.3.
> >>>>>>
> >>>>>> * ISP Profile
> >>>>>>
> >>>>>> This is the location part. The server side of Section 4.2.
> >>>>>> Optionally, LoST may be provided by the ISP.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> You see where the problem is? You have the location part in both
> End
> >>>>>
> >>>>>
> >>>> Host
> >>>>
> >>>>
> >>>>> and ISP. Same with LoST.
> >>>>>
> >>>>> This is the problem with this suggestion. It actually makes as much
> >>>>>
> >>>>>
> >>>> sense
> >>>>
> >>>>
> >>>>> to keep all the location information together as it does to keep all
> >>>>>
> >> the
> >>
> >>>> end
> >>>>
> >>>>
> >>>>> host information together.
> >>>>>
> >>>>> My best idea to address this is to leave the structure as is, but to
> >>>>>
> >>>>>
> >>>> make
> >>>>
> >>>>
> >>>>> the BCP elements pulled out and labeled as to whom they apply
> >>>>>
> >> (endpoint,
> >>
> >>>>> VSP, ISP, PSAP). Then, after the functional sections, we can copy
> the
> >>>>>
> >>>>>
> >>>> BCP
> >>>>
> >>>>
> >>>>> elements (only, not the other text) and sort them by who they apply
> >>>>>
> >> to.
> >>
> >>>>>
> >>>>>
> >>>> It's not a big problem to consider location aspects at the ISP and at
> >>>> the end host since the demanded functionality is, to some extend,
> >>>> different.
> >>>> In this particular document we, for example, say that the ISP has to
> >>>> implement one of the location protocols and the client implements all
> >>>>
> >> of
> >>
> >>>> them.
> >>>>
> >>>>
> >>>>
> >>>>>> * VSP Profile
> >>>>>>
> >>>>>> Some parts from Section 5 and Section 6 could go in here. Might
> want
> >>>>>>
> >> to
> >>
> >>>>>> separate this into a separate sub-section to have a way to
> reference
> >>>>>>
> >> it
> >>
> >>>>>> from the "End Host Profile" section to say something like
> >>>>>> "When the end host implements SIP then the VSP might want to use
> the
> >>>>>> same functionality already at the client."
> >>>>>>
> >>>>>> The detailed considerations about SIP location conveyance are not
> >>>>>> necessary since they can already be found in the SIP Location
> >>>>>>
> >>>>>>
> >>>> Conveyance
> >>>>
> >>>>
> >>>>>> document already.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Actually, I think a lot of this text has to stay as it describes how
> >>>>>
> >> you
> >>
> >>>> use
> >>>>
> >>>>
> >>>>> the -conveyance mechanism. We'll take a sharp look at it for
> >>>>>
> >> deletions.
> >>
> >>>>>
> >>>>>
> >>>>>> Section 6.2 does not work with the general IETF emergency
> >>>>>>
> >> architecture,
> >>
> >>>>>> as described in the ECRIT framework document. For example, the
> proxy
> >>>>>> does not obtain location information since it cannot do so in the
> >>>>>> generic case.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> I don't want IETF to be in the position of not supporting proxy
> >>>>>
> >>>>>
> >>>> insertion of
> >>>>
> >>>>
> >>>>> location as, for example, 3GPP does. I think we explicitly allow it
> >>>>>
> >> but
> >>
> >>>>> explain the difficulties.
> >>>>>
> >>>>>
> >>>>>
> >>>> The problem is that it does not work together with the framework
> >>>>
> >> document.
> >>
> >>>> The framework document does not have a case for it.
> >>>>
> >>>> It's fine that the SIP Location Conveyance document has something in
> >>>> there that could potentially be useful for the 3GPP. The interesting
> >>>> case, however, is that the emergency services architecture of the
> 3GPP
> >>>> has the functionality of the P-CSCF and the E-CSCF in the local
> network
> >>>> and hence they don't standardize the interaction with the PSAP,
> unlike
> >>>> we do because the PSAP in the IETF emergency services architecture
> >>>>
> >> might
> >>
> >>>> get the call from an arbitrary entity rather than from the local
> >>>>
> >> network
> >>
> >>>> operator.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>> Section 8 is also relevant.
> >>>>>>
> >>>>>>
> >>>>>> * PSAP Profile
> >>>>>>
> >>>>>> Section 6.5 is relevant but only to the extend where the PSAP
> >>>>>>
> >> operator
> >>
> >>>>>> network faces the outside world. I don't think it is too relevant
> for
> >>>>>> this document to talk about PSAP network interal operator, such as
> >>>>>> transferring a call to another PSAP operator.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Probably right, but the endpoint requirements to support transfer
> must
> >>>>>
> >>>>>
> >>>> stay
> >>>>
> >>>> That's fine
> >>>>
> >>>>
> >>>>
> >>>>>> Section 8 is also relevant.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> * Security Considerations
> >>>>>>
> >>>>>> Don't go too much into the details since we talk about all the
> stuff
> >>>>>>
> >> in
> >>
> >>>>>> other docs.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> If you say so. I'm not sure we can get away with this. Can we ask
> >>>>>
> >> you
> >>
> >>>> to
> >>>>
> >>>>
> >>>>> get a security reviewer assigned sooner rather than later and we can
> >>>>>
> >>>>>
> >>>> work
> >>>>
> >>>>
> >>>>> with him to see what we can accomplish with just references to other
> >>>>>
> >>>>>
> >>>> docs?
> >>>>
> >>>> Good idea. We should do that.
> >>>>
> >>>>
> >>>>
> >>>>>> The testing section is fine.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Albeit it mixes endpoint and PSAP BCP statements.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -- I am not so sure about the location update section.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> There is nothing to reference. It has to be somewhere else, and
> >>>>>
> >>>>>
> >>>> referenced
> >>>>
> >>>>
> >>>>> here, or here. This is a use of presence (and presumably HELD).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> Hmm. I have to re-read that part.
> >>>>
> >>>>
> >>>>
> >>>>>> In any case: Try to make the document as short as possible.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Okay
> >>>>>
> >>>>> Thanks for the suggestions
> >>>>>
> >>>>>
> >>>>>
> >>>> Ciao
> >>>> Hannes
> >>>>
> >>>>
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|