Subject: [Speermint] RE: Regulatory requirements [was Re: Equal Access...]

From: "Stastny Richard" <[email-masked]>
Date: Fri, 3 Mar 2006 15:38:22 +0100

Hi Bob,

I think before we make such decisions, we should first clarify
what we are talking about.

Equal Access aka Carrier selection is basically
a PSTN construct, allowing the end-user to order
the originating (access) network which long-distance
network (transit) to use (with the intrinsic assumption that
you cannot select your access network - if you can,
an CLEC normally does not have to provide carrier
selection. And you of course cannot select the terminating
network. The basic idea is to provide competition in tariffs

You have either pre-selection and/or call-by-call
In case of call-by-call you select the carier by
dialling CAC + CIC = numbers

If we now introduce carrier selection within
SPEERMINT, we face some problems

A. Simple solution: Carrier selection is only
valid for calls on the PSTN, so if you dial a
CAC, you force the call to the PSTN and use the
same regime.

B. If we extend carrier selection also to IP 
Interconect, we face a lot of definition problems
1. What IS a Carrier? An L5 intercon SP or a L3 
transit provider. Do you force an Intercon SP
even if you could reach the core-T direct?

2. What is the reason. charging? Are there charges?
Which one? Termination charges, transit charges,May
there be brokers with different termination charges
Or may the reason now be selection of QoS networks?

3. Routing in SPEERMINT is done via SIP URIs
Numbers have already be translated into SIP URIs
How do you select a carrier? Can you force a route
in SIP. What is the UA input equivalent to CAC + CIC?
Do we use the same CICs? Note that CICs are normally 
nationally defined. Do we need global CICs? ITU-T will
happily revive the discussion about this ;-)

Etc

My proposal is to first discuss the basic problems
we have with IP interconnect

Note: nobody knows up-to-now if end-user will really
request carrier selection on IP.

Cheers
Richard

> -----Original Message-----
> From: Bob Natale [mailto:[email-masked]]
> Sent: Friday, March 03, 2006 2:53 PM
> To: Stastny Richard
> Cc: [email-masked]
> Subject: Regulatory requirements [was Re: Equal Access...]
> 
> Hi Richard,
> 
> Concerning this observation from you (below):
> "The major problem with Equal Access is that this cannot be solved in
> SPEERMINT, because it is a national regulatory matter."
> 
> We will have to take at least a summary position, in our Requirements
> BCP document, wrt regulatory requirements.
> 
> I guess the possibilities include:
>    - Try to exclude everything that is (typically?) subject to such
> regulation?
>    - Try to include <ditto>?
>    - Deal with it on a case by case basis?
>    - Ignore this aspect for any otherwise necessary requirement and
> prescribe what we determine is best, leaving affected  SPs and users
to
> sort the matter out locally?
>    - Something else...?
> 
> Cheers,
> BobN
> 
> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Friday, March 03, 2006 5:12 AM
> To: Medhavi Bhatia; Livingood, Jason; [email-masked]
> Subject: [Speermint] Equal Access (was I-D
> draft-bhatia-sip-peering-00.txt)
> 
> > > " For example Equal Access is
> > >    a LEC (Local Exchange Carrier) requirement and an SP operating
as
> > an
> > >    LEC may be required to allow the subscriber his/her choice of
IXC
> > >    (IntereXchange Carrier) for certain set of calls.  In essence,
> > these
> > >    requirements may affect route policy for peering where the
> > downstream
> > >    peer is chosen based on origination's policy.  In this case,
the
> > >    Core-O and Core-T may be one and the same SP who peer through
an
> > >    Interconnect SP of the origination's choice."
> > >
> >
> > Equal Access gives a headache to anyone dealing with VoIP :). I
think
> it
> > is good to know what some VoIP SPs are dealing with especially when
we
> 
> > are starting discussions in the WG. As the draft says  in the last
> para
> > - it is
> > possible that this may affect only a minor set of deployments in the
> > end. Time will tell. Also, Equal Access is simply an example (I
can't
> > promise if there are not a host of other scenarios out there).
> 
> The major problem with Equal Access is that this cannot be solved in
> SPEERMINT, because it is a national regulatory matter.
> 
> In Europe it is part of the remedies to telcos having significant
market
> power (SMP). It is also a typical PSTN issue. So it depends first on a
> decision in which market VoIP is placed. If you put VoIP which is a
PSTN
> substitution into the fixed-line voice market, the existing remedies
for
> SMP providers such as carrier selection apply.
> 
> A typical candidate is VoB provided bundled with BB-access, e.g. a
XDSL
> access with a terminal adapter and a normal phone or an XDSL with an
> IP-phone.
> 
> This raises may questions such as:
> if you are able to unbundle your access and are able to choose another
> DSL provider, to you still need carrier selection?
> 
> Is carrier selection only valid for voice and voice related services,
> especially if the selected carrier still has only access via the PSTN?
> What if you switch during a call to video?
> 
> What does carrier selection imply with IP Interconnect?
> L5 Interconnect or also L3 transit?
> 
> A very nice example is if Core-O and Core-T is the same, e.g. running
on
> the same server, do you still have to provide carrier selection if the
> call is now forced via the PSTN?
> 
> Etc. etc.
> 
> Cheers
> 
> Richard
> 
> 
> 
> > -----Original Message-----
> > From: Medhavi Bhatia [mailto:[email-masked]]
> > Sent: Thursday, March 02, 2006 11:03 PM
> > To: Stastny Richard; Livingood, Jason; [email-masked]
> > Subject: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt
> >
> > Hi Richard,
> >
> > Sorry about the headache...
> > Hopefully my answers below will help :) Thanks for the quick read
> > anyway.
> >
> > Cheers,
> > Medhavi.
> >
> > >
> > > >The purpose of this document is to help the IETF community
> understand
> > >
> > > >   the route architectures being used today in SIP based peering
> > >
> > > >   environments and to outline a set of requirements based on the
> > same
> > >
> > > >   for discussion within the community
> > >
> > >
> > >
> > > Is this IMS in stealth mode?
> >
> > The intent of the draft is to describe what is deployed and the
> > requirements driving that. We can choose to ignore or accept some of
> > them based on WG discussion.
> >
> > (IMHO - I don't think IMS is deployed anywhere :)
> >
> > >
> > > The abstract should clearly state:
> > >
> > >
> > >
> > > The purpose of this draft is to help the IETF community understand
> IMS
> > ..
> > >
> > >
> > >
> > > In particular I have problems with the following para:
> > >
> > >
> > >
> > > "The call is originated at calling party "O", (called the
> > >   "Origination" in this document) and terminates at called party
"T"
> > >   (called the "Termination" in this document).  T may be a
> subscriber,
> > >   contact center, E911 operator etc.  The first hop and the last
hop
> > of
> > >   the call in Figure 1 pass through SPs providing L5 (in our case
> SIP)
> > >   access to the origination and termination and are called
Access-O
> > and
> > >   Access-T respectively.  In most cases these SPs will also
provide
> > the
> > >   physical access to the origination and termination devices.  The
> > >   Access SP function is not optional.  While a separate Access SP
> may
> > >   not exist, the function may be absorbed by the corresponding
Core
> > SP."
> > >
> > > A Core SP ALWAYS needs an Access SP if he is not providing the
> access
> > > by itself? In L5?
> > >
> >
> > It says three things: (a) Access SP is mandatory (b) Access SP "may"
> > provide
> > physical access (c) Access SP can be absorbed within the Core SP.
> Maybe
> > the
> > language can be improved, but I think we capture the case you are
> > talking about - an ASP (Vonage) like scenario!
> >
> > > And then we also have Interconnect SP = Transit
> > >
> > > What happened to the SIP Trapeziod?
> > >
> >
> > SIP Trapezoid is captured, since the Interconnect SP is optional
> (first
> > para on pg 4).
> > However, I think there could be a special section devoted to that.
> Note
> > that in no way
> > the draft is supposed to be prescriptive or designed to ignore the
> > trapezoid. Sorry if it sounds confusing -  we can fix that
problem...
> >
> > Also, Note that Inteconnect SPs today don't map to "Transit" as
> defined
> > in requirements
> > draft.
> >
> > > and may I remember on the req draft
> > >
> > > "3.6.2.  Layer 5 Peering
> > >
> > >    Layer 5 peering refers to interconnection of two service
> providers
> > >    for the purposes of SIP signaling.  Note that in the layer 5
> > peering
> > >    case, there is no intervening network.  That is, for purposes
of
> > this
> > >    discussion, there is no such thing as a "Layer 5 Transit
> Network"."
> > >
> > > The next problem I have with section
> > >
> >
> > I think maybe the draft needs to clarify that Interconnect SP is not
> the
> > same as Transit.
> > We can try to do this if lot of people feel the same and it really
> > affects the routing architecture selection (IMHO - it should not
have
> > any effect) in the end.
> >
> > >
> > >
> > > "5.2.  Addressing
> > >
> > >    The type of A-O-R for the termination may also affect what kind
> of
> > >    address location service is used.  Address location is done
> > typically
> > >    based on the following four characteristics of the
termination's
> > AOR.
> > >    In each case, we list the most common address location method
> used.
> > >
> > >
> > >    1.  Full E.164: ENUM or SP's local policy may be used.
> > >    2.  E.164 prefixes: SPs local policy is generally used.
> > >    3.  Full A-O-R: This is rarely used for routing in a peering
> > >        environment.
> > >    4.  Domain of A-O-R: DNS SRV or SPs local policy may be used."
> > >
> > >
> > >
> > > Within SPEERMINT only Call Routing Data (CRD) are used
> > >
> > > E.164 numbers are not CRD, they are also not A-o-R,
> > >
> > > E.164 numbers are names
> > >
> > > so E.164 number is out of scope in SPEERMENT
> > >
> >
> > I am not sure what I need to fix, but we can address it after WG
> > discussion.
> >
> > >
> > > And IMHO completely off is the idea to introduce carrier selection
> > > within VoIP
> > >
> > > " For example Equal Access is
> > >    a LEC (Local Exchange Carrier) requirement and an SP operating
as
> > an
> > >    LEC may be required to allow the subscriber his/her choice of
IXC
> > >    (IntereXchange Carrier) for certain set of calls.  In essence,
> > these
> > >    requirements may affect route policy for peering where the
> > downstream
> > >    peer is chosen based on origination's policy.  In this case,
the
> > >    Core-O and Core-T may be one and the same SP who peer through
an
> > >    Interconnect SP of the origination's choice."
> > >
> >
> > Equal Access gives a headache to anyone dealing with VoIP :). I
think
> it
> > is good to know what some VoIP SPs are dealing with especially when
we
> 
> > are starting discussions in the WG. As the draft says  in the last
> para
> > - it is
> > possible that this may affect only a minor set of deployments in the
> > end. Time will tell. Also, Equal Access is simply an example (I
can't
> > promise if there are not a host of other scenarios out there).
> >
> > Thanks,
> > Medhavi.
> >
> >
> >
> > > I have an headache
> > >
> > > Richard
> > >
> > > ________________________________
> > >
> > > Von: Livingood, Jason [mailto:[email-masked]]
> > > Gesendet: Do 02.03.2006 19:33
> > > An: [email-masked]
> > > Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt
> > >
> > >
> > > FYI for the WG on this draft.  This is on the tentative agenda at
> the
> > Dallas meeting (should
> > > be finalized shortly).
> > >
> > > Jason
> > >
> > > ________________________________
> > >
> > > From: Medhavi Bhatia [mailto:[email-masked]]
> > > Sent: Sunday, February 26, 2006 12:44 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; Livingood, Jason
> > > Subject: I-D draft-bhatia-sip-peering-00.txt
> > >
> > >
> > >
> > > Abstract
> > >
> > >
> > >
> > >    The purpose of this document is to help the IETF community
> > understand
> > >
> > >    the route architectures being used today in SIP based peering
> > >
> > >    environments and to outline a set of requirements based on the
> same
> > >
> > >    for discussion within the community.
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date:
> > 3/1/2006
> > >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Fri, 3 Mar 2006 09:44:58 -0500

I tend to agree with Richard - let's keep the core focus on service
provider (L5) peering. Carrier selection is something different and may
more properly be handled in other fora better attuned to PSTN issues
which, as Richard points out, have national variations.

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 9:38 AM
To: Bob Natale
Cc: [email-masked]
Subject: [Speermint] RE: Regulatory requirements [was Re: Equal
Access...]

Hi Bob,

Etc

Cheers
Richard

to
as
IXC
the
an
think
we
can't
market
PSTN
for
XDSL
on
"T"
hop
Access-O
provide
Core
problem...
of
have
termination's
as
IXC
the
an
think
we
can't