Subject: [Speermint] Phone numbers (was I-D draft-bhatia-sip-peering-00.txt)

From: "Stastny Richard" <[email-masked]>
Date: Fri, 3 Mar 2006 10:00:45 +0100

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

Routing between SPEERMINT (VoIP) SP is done only with SIP URIs
(this is also specified in IMS 3GPP TS 123.228, any
public user identity given by a phone number MUST be translated
first to an SIP URI)

The basic question for SPEERMINT therefore is:
is there any difference in routing and/or policy
if the original requested end-point was given
by a phone number.

Note: there are E.164 numbers and non-E.164 numbers

If yes, we may run into the same header field problem
as it is currently discussed in ECRIT. We may need
an phone (E.164) number marker.

An additional remark: in Infrastructure ENUM, the
Core-T SP (I like your definitions, they are very
helpful) is always the SP hosting the E.164 number,
in User ENUM this need not to be the case

Is there then a difference in policy and/or routing
if the SIP URI is derived from User ENUM or 
Infrastructure ENUM?

Do we need two different markers?

Any thoughts?

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