Subject: Re: [Enum] Horizontal vs Vertical

From: "Stastny Richard" <[email-masked]>
Date: Fri, 08 Jul 2005 18:01:53 -0400

Thanks,
 
Also PSTN providers move already to peering, but they still charge their subscribers
in most cases. They also move to free "on-net" calls.
 
The choice the subscriber has in future at his mobile device is:
does he use the charged (or partially charged) of the IMS provider;
or does he use the "free" VoIP service on the Internet, but
gets charged for the access to the Internet.
 
With a dual-mode device the user may choose to use VoIP
if connected via WiFi,
but he may use the mobile operator voice service if connected
via 3G (UMTS), because although VoIP (or Skype) works, but
the data charges are prohitive, especially when roaming.
In this case you are tunnelled via the visited network to the
home network
 
-richard

________________________________

Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com]
Gesendet: Fr 08.07.2005 23:50
An: Stastny Richard; Patrik Faltstrom (pfaltstr)
Cc: enum at ietf.org; Richard Shockey
Betreff: RE: [Enum] Horizontal vs Vertical

Good summary.  Carriers can provide useful services to their customers, but must keep in mind that the first most useful feature is that anyone in the world can reach them.

I'm not sure how the termination charges carriers like to charge each other will work out, but if the calls are symmetric with each carrier terminating one half of the call, that should even out and each can bill their respective customers and keep the money.  If it is asymmetric, well that may be another story.

Mike

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On
> Behalf Of Stastny Richard
> Sent: Friday, July 08, 2005 5:26 PM
> To: Patrik Faltstrom (pfaltstr)
> Cc: enum at ietf.org; Richard Shockey
> Subject: [Enum] Horizontal vs Vertical
>
> >I know you (and myself) reject some of the proposals and
> thinking that
> >have been passed around on this list. To be able to *REALLY* reject
> >those, I want to know the requirements that are behind the proposals.
>
> >I.e. enough so that the requirements can be attacked instead of the
> >solutions that claim to respond to all of them.
>
> Yes and no, I think the current discussion on which Carrier
> ENUM proposal is valid or not is only a side battle.
>
> The real battle currently going on is between the "Internet"
> model (the horizontal layered model) and the vertical
> stovepipes of the PSTN model.
>
> The Internet model is the end-to-end model originally
> intended by SIP according to e-mail. If you have a sip URI
> you may use this URI to contact at least the proxy hosting the AoR.
> The media-stream is then transferred end-to-end directly
> between the end-points.
>
> In the PSTN model only "networks" may exchange both
> signalling and medai streams. To do so, they need peering
> agreements, pretending to guarantee QoS, in reality to be
> able to charge per minute.
>
> This model is mainly supported by mobile and cable operators
> to keep up the current accounting regime, supported also by
> the fixed network operators eaten up by the former, and also
> by some VoIP getting greedy and also wanting to get their share.
>
> As Henry already stated the problem is surfacing by the
> question: "Do you get a public SIP URI for your VoIP service"
> If not, you may use IP-based Telephony, but you are behind a
> walled garden.
>
> Back to ENUM:
>
> One is only able to use User ENUM if he has a Public SIP URI,
> and he may then link this SIP URI with an
> E.164 number in e164.arpa
>
> If he doesn't, the only "Public" identifier he has is an E.164 number.
> If his provider decides to use SIP within his walled garden
> network, he need some kind of addressing. Since this is SIP,
> a SIP URI is useful, but the "domain" names used here cannot
> be resolved on the public Internet. So the provider needs
> some private DNS to resolve even his own users. If one of
> this users wants to contact users of other providers, he may
> either use SIP URI, but this is problematic because his
> provider may not be able to resolve this URIs. So they stick
> to E.164 numbers. Here you still have as default the PSTN to
> interconnect.
>
> But providers of course also want to interconnect via IP, so
> the Carreir may now use ENUM technology to map the
> E.164 numbers to - ok this is now the question:
>
> The answer to this question is depending on what kind of ENUM
> he is useing:
>
> In the worst case he may use private ENUM in his own network
> to find the egress SBC into an "extranet" shared between
> providers, the egress SBC connect to the proper extranet and
> is querying an "ENUM" in this extranet to find the ingress
> SBC of the provider hosting the number and this ingress SBC
> is finally querying the ENUM in the destination network to
> find the proxy hosting the subscriber.
>
> But there are other models.
>
> So to answer your questions for the requirements we need
> first to discuss all potential peering models and ENUM configurations.
>
> We did this at ETSI for two years and included the only major
> models in ETSI TS 102 055.
>
> The whole issue will finally not be decided by a standards body.
> it will be decided by the end-user, because he will finally
> have the choice to use both models in parallel at his mobile
> device. He may chose either to query User ENUM ar let the
> call be set-up by his IMS provider.
>
> -richard
>
> PS: you may compete with everybody, but not with your
> customer (Clay Shirky on fax-mail)
>
> 
>
> .
>
>
> ________________________________
>
> Von: Patrik Fältström [mailto:paf at cisco.com]
> Gesendet: Fr 08.07.2005 21:44
> An: Stastny Richard
> Cc: Richard Shockey; enum at ietf.org
> Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda
> items forIETF Paris)
>
>
>
>
> On Jul 8, 2005, at 19:25, Stastny Richard wrote:
>
> > Rich Shockey wrote:
> >
> >> as some here might postulate the exposure of the URI of
> the ALG may
> >> or may not be visible to A. all parties as in the use of
> >> .carrier.e164.arpa B.
> >> just visible to the club as in 3GPP.NET or e164MSO.ORG and the
> >> visibility of the ALG URI does not necessarily imply a
> formal peering
> >> agreement between party A and party B.
> >>
> >
> > I question for clarification, especially to Patrik:
> >
> > Are we talking here about requirements for carrier ENUM -in private
> > enterprise trees?
> > -in carrier trees within their network to find egress ALGs
> (or SBCs or
> > GWs)?
> > -in shared walled garden trees such as GSMA
> > (whatchamanameitcurrently) to find ingress ALGs?
> > -in (partially or wholely) public other trees such as e174.info?
> > -or in carrier.c.c.164.arpa or c.c.carrier.e164.arpa?
> >
> > or altogether?
> >
> > If it is last, I will come back in two years and look how
> far you are
> > with the requirements and I do not think I will have missed a lot
>
> I want at least SOME requirements. At least enough to be able
> to see the difference between the various proposals.
>
> I know you (and myself) reject some of the proposals and
> thinking that have been passed around on this list. To be
> able to *REALLY* reject those, I want to know the
> requirements that are behind the proposals.
>
> I.e. enough so that the requirements can be attacked instead
> of the solutions that claim to respond to all of them.
>
> But not more.
>
>      paf
>
>
> >
> > -richard
> >
> >
> >
> >
> >
> > ________________________________
> >
> > Von: enum-bounces at ietf.org im Auftrag von Richard Shockey
> > Gesendet: Fr 08.07.2005 19:06
> > An: Patrik Fältström; Richard Shockey
> > Cc: enum at ietf.org
> > Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items
> > forIETF Paris)
> >
> >
> >
> > At 12:48 PM 7/8/2005, Patrik Fältström wrote:
> >
> >
> >
> >> On Jul 8, 2005, at 16:44, Richard Shockey wrote:
> >>
> >>
> >>> ...there is a requirement among service providers for
> some form of
> >>> database technology that, based on a E164 number, can provide
> >>> information on how to route a service to a point of carrier
> >>> interconnection or ALG as expressed as a URI.
> >>>
> >>
> >> Ok, this is for me one requirement. Sorry for maybe not
> being clear.
> >>
> >>
> >>> For privacy reasons this information needs to be restricted to
> >>> service providers and not generally available to end users.
> >>>
> >>
> >> Is the requirement that this information (the mapping from E.164 to
> >> URI) is only to be visible for the party that need to
> know, or "any
> >> service provider being part of the same club"?
> >>
> >
> > oh fine distinction can you elaborate a bit ?...what is the
> difference
> > been 'party that needs to know' or 'service provider being
> part of the
> > same club' .. what is the distinction?
> >
> > as some here might postulate the exposure of the URI of the
> ALG may or
> > may not be visible to A. all parties as in the use of
> > .carrier.e164.arpa B.
> > just visible to the club as in 3GPP.NET or e164MSO.ORG and the
> > visibility of the ALG URI does not necessarily imply a
> formal peering
> > agreement between party A and party B.
> >
> > What the egress ALG does once it gets in INVITE is a matter between
> > consenting capitalists.
> >
> > Does that help?
> >
> >
> >
> >>    paf
> >>
> >>
> >>
> >>
> >
> >
> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Richard Shockey, Director - Member of Technical Staff NeuStar Inc.
> > 46000 Center Oak Plaza  -   Sterling, VA  20166
> > sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
> > ENUM +87810-13313-31331
> > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1
> > 815.333.1237
> > <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at) 
> > neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org>
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> >
> > _______________________________________________
> > enum mailing list
> > enum at ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum
> >
> >
>
>
>
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum