[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] PhoneBCP
Please be careful.
What you mean is that 3GPP has chosen to go a different direction. The
phonebcp procedures would work fine in IMS systems if operators chose to
implement them. There is no inherent disconnect.
At the moment, it would seem that IMS operators will have to provide all the
tools to allow devices and services on their underlying packet network to be
phonebcp compliant. The mobile WiFi to wireless network bridge plus any
standard phonebcp compliant client for example. The services that the
operators provide directly may use different procedures, given the current
3GPP standards direction.
Brian
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
> Of DRAGE, Keith (Keith)
> Sent: Thursday, May 14, 2009 9:52 AM
> To: Ted Hardie; Marc Linsner; ecrit at ietf.org
> Subject: Re: [Ecrit] PhoneBCP
>
> In general, I have trouble thinking of any SIP RFC that cannot be
> applied, or attempted to be applied somehow in the IMS environment. Not
> all operators may deploy all capabilities, but that applies to all of
> SIP. Even something like RFC 4474 can be applied across the top of IMS
> if one so wished, asssuming someone had not stuck an SBC in the way.
>
> Those considerations do not apply for Phone BCP, where if attached in
> an IMS environment, in order to make an emergency call, the sequence
> followed is somewhat different, and the IETF procedures just will not
> work.
>
> regards
>
> Keith
>
> > -----Original Message-----
> > From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> > On Behalf Of Ted Hardie
> > Sent: Thursday, April 30, 2009 8:55 PM
> > To: Marc Linsner; ecrit at ietf.org
> > Subject: Re: [Ecrit] PhoneBCP
> >
> > At 12:52 PM -0700 4/30/09, Marc Linsner wrote:
> > >Ted,
> > >
> > >I searched a small amount for comparison type language in
> > other IETF drafts.
> > >I'm struggling with the notion that anyone who would read
> > IETF drafts
> > >would get confused as to their solution/applicability space.
> > >
> > >Since my search was small and cycles are short, are you
> > aware if there
> > >is any such language in any of the ream of SIP drafts that point out
> > >the solution space and explicitly exclude IMS?
> > >
> > >-Marc-
> >
> > Besides the long-running argument over SBCs? I am not sure;
> > possibly Keith would be able to point to comparison text.
> >
> > Ted
> >
> >
> >
> > >
> > >On 4/30/09 1:40 PM, "Ted Hardie" <hardie at qualcomm.com> wrote:
> > >
> > >> At 9:48 AM -0700 4/30/09, Dawson, Martin wrote:
> > >>> Understanding ECRIT means understanding that broadband Internet
> > >>> access is broadband Internet access is broadband Internet access.
> > >>
> > >> To put it mildy, this is far from true. There is a whole class of
> > >> offerings that is voice-as-a-service (the IMS/NGN group) which
> > >> absolutely do not act like
> > >> voice-as-an-application. The solution we've defined is for
> > >> voice-as-an-application,
> > >> which has the natural result that the end user device has
> > the primary role.
> > >>
> > >> The root of the problem we're facing is that there is a difference
> > >> between using IP and using the Internet model. IMS uses
> > IP, but uses
> > >> a different model entirely (Whatever you think of that
> > model, I don't
> > >> think anyone who looked at how it works could argue that it is the
> > >> same as the Internet
> > >> model.)
> > >>
> > >> The documents we're dealing with contrast the offering
> > with PSTN, but
> > >> don't really see any differentiation among
> > "packet-switched networks".
> > >> Take this early text from the Framework document:
> > >>
> > >>> It is beyond the scope of this document to enumerate and
> > discuss all
> > >>> the differences between traditional (Public Switched Telephone
> > >>> Network) and IP-based telephony, but calling on the Internet is
> > >>> characterized by:
> > >>> o the interleaving over the same infrastructure of a
> > wider variety
> > >>> of services;
> > >>> o the separation of the access provider from the application
> > >>> provider;
> > >>> o media other than voice (e.g. video and text in
> > several forms);
> > >>> o the potential mobility of all end systems, including
> > endpoints
> > >>> nominally thought of as fixed systems and not just
> > those using
> > >>> radio access technology. For example, consider a wired
> phone
> > >>> connected to a router using a mobile data network
> > such as EV-DO as
> > >>> an uplink.
> > >>>
> > >>> This document focuses on how devices using the Internet
> > can place
> > >>> emergency calls and how PSAPs can handle Internet multimedia
> > >>> emergency calls natively, rather than describing how
> > circuit-switched
> > >>> PSAPs can handle VoIP calls. In many cases, PSAPs making the
> > >>> transition from circuit-switched interfaces to packet-switched
> > >>> interfaces may be able to use some of the mechanisms
> > described here,
> > >>> in combination with gateways that translate
> > packet-switched calls
> > >>> into legacy interfaces, e.g., to continue to be able to
> > use existing
> > >>> call taker equipment. There are many legacy telephone
> > networks that
> > >>> will persist long after most systems have been upgraded to IP
> > >>> origination and termination of emergency calls. Many
> > of these legacy
> > >>> systems route calls based on telephone numbers. Gateways and
> > >>> conversions between existing systems and newer systems
> > defined by
> > >>> this document will be required. Since existing systems
> > are governed
> > >>> primarily by local government regulations and national
> > standards, the
> > >>> gateway and conversion details will be governed by
> > national standards
> > >>> and thus are out of scope for this document.
> > >>
> > >> The real contrast being made is between circuit-switched
> > and Internet
> > >> model, but the terms used mix "packet-switched", "IP-based", and
> > >> "Internet"; there is even an explicit mention of EV-DO,
> > but in a mode
> > >> that treats it as a pure IP bearer (which is not what is
> > being sold
> > >> in most markets
> > > > today). The reality on the ground today is that there
> > are at least
> > >> circuit-switched,
> > >> Internet model IP, and IP with operator services out there in the
> > >> real world. This document set doesn't acknowledge that, and it
> > >> treats all packet-switched services/IP-based services as
> > if they were Internet model.
> > >> That's simply not true.
> > >>
> > >> The argument that Steven and others have made is that the document
> > >> set needs to have an explicit acknowledgement of the other
> > model, so
> > >> that there is a realization by those reading them that
> > just because they have
> > >> IP, doesn't mean they are dealing with the Internet model.
> > You could
> > >> argue that everyone knows that, but the document itself muddies it
> > >> far enough that it is far from evident.
> > >>
> > >> Do I, personally believe the Internet model version is
> > better? Yep.
> > >> Do I, personally believe that it will eventually subsume other
> > >> versions? Maybe, and I think it would be nice. But I
> > also recognize
> > >> that it is not the case now, and we're trying to define a
> > system that
> > >> will actually work to deliver emergency calls in the real world.
> > >> Explicit acknowledgement seems to me valuable in that case. The
> > >> other option is to re-write the documents to clarify that not any
> > >> packet-switched network nor any network using IP fits this set of
> > >> assumptions; that seems to me likely to take longer and
> > not add much.
> > >>
> > >> You've already had Keith note that he would object to the
> > documents
> > >> if they did not contain language like that which was in
> > -09. If it
> > >> is taken out, I believe the documents will need a major
> > editing pass
> > >> to accomplish the clarification without the explicit text.
> > This text
> > >> is a compromise already, and the issue it deals with is
> > important.
> > >> Unless we are going to pretend that the IMS model simply doesn't
> > >> exist and won't be used to deliver a substantial fraction of
> > >> emergency calls for a good long time to come, we need it.
> > If we are
> > >> going to pretend that, I think we are being very foolish indeed.
> > >>
> > >> Ted
> > >>
> > >>
> > >>
> > >>> Having to change the way the device initiates an
> > emergency call when
> > >>> something as prosaic as the access technology changes is akin to
> > >>> having to change your web browser just because the access
> > technology
> > >>> has changed. It's neither helpful nor harmless to have
> > such a restriction.
> > >>>
> > >>> A helpful statement to put in the BCP might be "Other
> > architectures,
> > >>> such as IMS Emergency calling defined by 3GPP and 3GPP2,
> > which are
> > >>> not based on the ECRIT framework are likely to not be compatible
> > >>> with devices and emergency networks which assume this framework -
> > >>> e.g. such as is defined by NENA as i3."
> > >>>
> > >>> I don't endorse the inclusion of such a statement; it's
> > commentary -
> > >>> as is the proposed "applicability statement" and
> > commentary is unnecessary.
> > >>> Nevertheless, I think it's a more accurate characterization. That
> > >>> is, it's more the case that the 3GPP IMS emergency architecture
> > >>> doesn't fit ECRIT than it is that ECRIT doesn't fit a
> > 3GPP access network.
> > >>>
> > >>> Cheers,
> > >>> Martin
> > >>>
> > >>>
> > >>> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On
> > >>> Behalf Of Edge, Stephen
> > >>> Sent: Friday, 1 May 2009 2:29 AM
> > >>> To: Bernard Aboba; Thomson, Martin; ecrit at ietf.org
> > >>> Subject: Re: [Ecrit] PhoneBCP
> > >>>
> > >>> Bernard and others
> > >>>
> > >>> This is an interesting view - an admission that the Ecrit
> > solution
> > >>> will probably not be universally applied and when it is may be
> > >>> subject to modification. On the 3GPP/3GPP2 sides, solutions are
> > >>> defined with a specific and explicit scope and are
> > expected to be -
> > >>> and nearly always actually are - supported exactly as
> > defined in the
> > >>> appropriate spec.s for all scenarios covered by the scope. A
> > >>> solution whose deployment is unpredictable will be less useful
> > >>> because of the implied interworking problems between incompatible
> > >>> implementations. That is a main reason why I and others initially
> > >>> tried to include a more precise applicability/scope
> > statement than
> > >>> the one we are now discussing. Specifically, the Ecrit
> > solution will
> > >>> probably not be deployed by
> > >>> 3GPP/3GPP2 operators for cellular terminals because they have
> > >>> defined a
> > > >> somewhat different solution more suitable for cellular
> > operation.
> > > >> That means
> > >>> that a terminal supporting only the Ecrit solution (based on an
> > >>> assertion of universal ap
> > >> plicability) will encounter problems when its user attempts an
> > >> emergency call on a 3GPP/3GPP2 network. If I can extend your
> > >> analogies, this would be like not including a precise menu
> > >> description for a meal containing meat and/or fish in a
> > restaurant catering to both vegetarians and non-vegetarians.
> > >>>
> > >>> Kind Regards
> > >>>
> > >>> Stephen
> > >>>
> > >>> From: Bernard Aboba [mailto:bernard_aboba at hotmail.com]
> > >>> Sent: Thursday, April 30, 2009 1:13 AM
> > >>> To: Edge, Stephen; martin.thomson at andrew.com; ecrit at ietf.org
> > >>> Subject: RE: [Ecrit] PhoneBCP
> > >>>
> > >>>> Your interpretation of applicability is certainly
> > extreme (yes or
> > >>>> qualified yes to all questions) - removing any dependence on
> > >>>> suitability or feasibility (which are the more normal
> > benchmarks)
> > >>>> and simply making a legalistic blanket assertion. (I can
> > now more
> > >>>> understand incidentally why the fictitious protocol
> > police are so
> > >>>> often invoked on matters of
> > >>>> conformance.)
> > >>>>
> > >>>> But do others have any views on this?
> > >>>
> > >>> Here is my 2 pence. As noted in the Introduction, the
> > Phone BCP document
> > >>> and framework documents are closely related documents
> > that need to
> > >>> be read (and understood) together. In looking at Phone
> > BCP, there
> > >>> have been many situations in which I wondered what the
> > >>> justification was for a requirement, only to find the (usually
> > >>> persuasive) explanation in the corresponding section of
> > the framework document.
> > >>>
> > >>> IMHO, the separation of the two documents is somewhat unnatural.
> > >>> It's a bit like taking a meal, freeze drying it, and then
> > presenting
> > >>> the diner with a cup of powder and a cup of water and
> > wondering why
> > >>> they are left with a quizical look on their faces. Including
> > >>> cooking instructions along with the two cups is not a
> > fully satisfactory answer.
> > >>>
> > >>> Given this reality, if there is a need for text explaining the
> > >>> fundamental assumptions of the architecture, the place
> > for that text
> > >>> is not in the BCP document, but in the framework
> > document. As has
> > >>> been noted by others, the entire BCP document is an applicability
> > >>> statement, and when viewed in that way, the proposed text is not
> > >>> only unnecessary, but somewhat confusing since required
> > context for
> > >>> the BCP document belongs in the framework document. If anything
> > >>> more is necesary, it would probably be some additional
> > instructions for the reader delving into the document set
> > for the first time.
> > >>>
> > >>> Like any IETF effort, the framework and BCP documents will be
> > >>> evaluated on their own merits. Athough this is an area with a
> > >>> considerable regulatory component, I see little evidence that the
> > >>> world at large is so in awe of the IETF that every word will be
> > >>> taken as immutable truth. No doubt other SDOs will take
> > issue with
> > >>> these documents in whole or in part and will explain the basis of
> > >>> their assessments and where necessary, their alternatives. As a
> > >>> result, some portions of the architecture may be adopted, some
> > >>> portions may be ignored, and others will be revised in an
> > effort to address the issues encountered and improve their
> > chances for deployment.
> > >>>
> > >>> With respect to this process, the addition of cautionary
> > text is a
> > >>> bit like the warning labels that we find on consumer products.
> > >>> While it may be necessary in some legalistic sense, given the
> > >>> expertise of the individuals assessing these documents,
> > one wonders what the practical effect will be.
> > >>> Typically these are individuals who already understand
> > that it is a
> > >>> good idea to double-cup hot coffee.
> > >>>
> > >>>
> > >>>
> > >>>
> > --------------------------------------------------------------------
> > >>> ---------
> > >>> -------------------
> > >>> This message is for the designated recipient only and may contain
> > >>> privileged, proprietary, or otherwise private information.
> > >>> If you have received it in error, please notify the sender
> > >>> immediately and delete the original. Any unauthorized
> > use of this
> > >>> email is prohibited.
> > >>>
> > --------------------------------------------------------------------
> > >>> ---------
> > > >> -------------------
> > >>> [mf2]
> > >>>
> > >>> Content-Type: text/plain; name="ATT00001.txt"
> > >>> Content-Description: ATT00001.txt
> > >>> Content-Disposition: attachment; filename="ATT00001.txt";
> > size=194;
> > >>> creation-date="Thu, 30 Apr 2009 09:49:15 GMT";
> > >>> modification-date="Thu, 30 Apr 2009 09:49:15 GMT"
> > >>>
> > >>> Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt)
> > >>> (0040366B)
> > >>
> > >> _______________________________________________
> > >> Ecrit mailing list
> > >> Ecrit at ietf.org
> > >> https://www.ietf.org/mailman/listinfo/ecrit
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit at ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit