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

From: "Bob Natale" <[email-masked]>
Date: Fri, 3 Mar 2006 08:52:31 -0500

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: "Bob Natale" <[email-masked]>
Date: Fri, 3 Mar 2006 09:55:36 -0500

Hi Guys,

I understand your position re the specific topic of carrier selection
within equal access.

I changed the subject header on purpose:  We need to consider the
*general* case of regulatory requirements in the context of the
Requirements BCP charter item.

The best I can deduce from your responses so far is that we'll go with
the 3rd alternative I identified below:  Namely, we'll deal with that
broader question on a case by case basis...?

Cheers,
BobN

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

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,

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

> 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,
>