Re: [dispatch] VIPR - proposed charter version 3

"Mohammad Al-Taraireh (maltarai)" <maltarai@cisco.com> Wed, 07 July 2010 20:29 UTC

Return-Path: <maltarai@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A3A3A68B8 for <dispatch@core3.amsl.com>; Wed, 7 Jul 2010 13:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rplUEEF8bXIs for <dispatch@core3.amsl.com>; Wed, 7 Jul 2010 13:29:08 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E07033A686B for <dispatch@ietf.org>; Wed, 7 Jul 2010 13:29:07 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOOANEytJV2a/2dsb2JhbACgGHGlYJpghSQEg3iGcg
X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="129714588"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2010 20:29:04 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o67KT4kS000841; Wed, 7 Jul 2010 20:29:04 GMT
Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 15:29:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 07 Jul 2010 15:28:17 -0500
Message-ID: <04CA7DCC63584C4D8967FF818D80965B01B2C8AB@XMB-RCD-113.cisco.com>
In-Reply-To: <35FE871E2B085542A35726420E29DA6B044A97DA@gaalpa1msgusr7a.ugd.att.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] VIPR - proposed charter version 3
Thread-Index: AcseDpl3J0uCvU1BTXGGKoe3KS5c9wAAF1YAAAB1gFA=
References: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com><EDC652A26FB23C4EB6384A4584434A04022F40FB@307622ANEX5.global.avaya.com> <AANLkTinCs4ooaP7qczjOf_CMJB2tZg9XR9Ro5H-WWHK6@mail.gmail.com><EDC652A26FB23C4EB6384A4584434A04022F4219@307622ANEX5.global.avaya.com><001201cb1ade$4195f680$c4c1e380$@us><A20EB9EA-DC3B-45A8-882A-F569AC2CA4D8@cisco.com> <35FE871E2B085542A35726420E29DA6B044A97DA@gaalpa1msgusr7a.ugd.att.com>
From: "Mohammad Al-Taraireh (maltarai)" <maltarai@cisco.com>
To: "PFAUTZ, PENN L (ATTCORP)" <pp3129@att.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Richard Shockey <richard@shockey.us>
X-OriginalArrivalTime: 07 Jul 2010 20:29:04.0275 (UTC) FILETIME=[0AB09E30:01CB1E13]
Cc: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] VIPR - proposed charter version 3
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2010 20:29:10 -0000

These are excellent questions, however, they are almost implementation
specific.  Any node that is in the routing path, and terminates the call
(to apply some kind of policy or feature like call forwarding) can
potentially give you a ViPR SIP route to reach that node by passing the
pstn assuming the validation for that call happen successfully, which in
turn means that this node must be ViPR enabled. 

In cases where learned ViPR routes fail due to the number being
unallocated or assigned to a different carrier, the ViPR call should
fail in this case, and the call should be forced to go over the pstn
again to allow re learn the new SIP route. 

ViPR provides on going self learning, and healing if necessary for ViPR
calls that fail to get setup. Of course some of this need to be spelled
out in the specification. 

Mo A

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Wednesday, July 07, 2010 4:06 PM
To: Cullen Jennings (fluffy); Richard Shockey
Cc: DISPATCH list
Subject: Re: [dispatch] VIPR - proposed charter version 3

Cullen:
I think you example represents one of the concerns some of us have. Say
you've temporarily set up forwarding or used a specific long distance
carrier for a particular call. Should the forwarded-to or currently
chosen carrier be able to represent itself as a domain that should be
routed to once you remove forwarding or stop using a particular LD
carrier? Likewise, if you (God forbid:-) port your number from AT&T to
Verizon will there be mechanisms to delete AT&T as a route-to domain?

Penn
-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Cullen Jennings
Sent: Wednesday, July 07, 2010 3:56 PM
To: Richard Shockey
Cc: DISPATCH list
Subject: Re: [dispatch] VIPR - proposed charter version 3


I agree with Richard that finding the single administrative organization
that "owns" a phone number is a huge rat hole but that's not what we are
trying to do with "responsible" in this context - I would like to point
out the charter text

    In this context, "responsible" means an
    administrative domain, which is at least one of the domains, to
which
    a PSTN call to this phone number would be routed.

So let's consider my mobile phone number. It's an AT&T plan, so AT&T
could route it anywhere. It's in the US so Nuestar could change the LNP
database to route it anywhere. Cisco pays for it so I imagine the right
Cisco person could call up AT&T and have the number sent to anywhere.
It's my number in that Cisco lets make take it when I leave and I can
move it to another carrier of my choosing so I can make it go anywhere.
Right now it is forwarded to google voice because I am in Calgary and
want it to ring my phone at home instead of paying roaming charges.
(Thank you Google for making the one place you can use google voice
outside the US be where I just happen to live). So Google could route it
anywhere - they currently are routing it to Rogers, Tellus, AT&T, and
probably a few more - any of those carriers could route it anywhere. And
google uses someone like Level 3 to do that routing so they could route
it anywhere. And who knows how many other internet or PSTN transit prov
 iders and peering like providers had a chance to route it anywhere. The
sheer number of SS7 dips that happen in a single call to my cell number
results in is probably more than the  SS7 vendors ever imagined in their
wildest dreams. Yah VoIP.  So in some sense all these operators are
"responsible" for making sure that my call is not say routed to the
wrong place. However, they seem to do a fine job of that and if they
stopped doing a fine job of that I would adjust the carriers
"responsible" for my number such that they did do a fine job of it. 

Part of the idea in ViPR was to realize that finding a single owner of a
number is a rat hole and instead focus on the fact that several domains
all cooperate to terminate a call to a given number. So I don't see a
problem with the "responsible" - it nicely side steps the whole
"ownership" issue with numbers yet still results in a workable solution
that results in similar security properties to the existing PSTN which
seem to be adequate for many purposes.

Cullen

( and just to repeat my previous email on the subject, all my posts
related to VIPR are from me as an individual contributor and not as
chair. Mary will handle the chair stuff for this topic )


On Jul 3, 2010, at 12:33 PM, Richard Shockey wrote:

> 
> "finding domains that claim to be responsible for a given phone
number"
> 
> This IMHO is flat out impossible. Validating or authenticating an
entity
> that is "responsible for a phone number" is as bad as  " who is the
carrier
> of record" , is a massive rathole. Cullen and Johathan should know
better.
> Certs? LNP ? 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch