Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 14 Apr 2006 08:05:28 -0400

I agree.  This should not be about reaching some PSTN number.  And
presumably, you are contacting this peering point because a previous DNS
or equivalent dip has indicated that a particular domain can be reached
through this peering point.

Mike

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Friday, April 14, 2006 4:27 AM
> To: Malas, Daryl; Michael Hammer (mhammer); [email-masked]; 
> Reinaldo Penno; [email-masked]
> Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows 
> 
> Daryl]  Contact routing wasn't my primary reason for doing 
> this, but I did think of that as an option.  You could 
> specify NPA-NXX or similar you are providing routes to as a 
> peering entity.  Also, this would allow a method for 
> dynamically updating supported peering routes if you were not 
> using a common routing location server.  I certainly do not 
> think exchanging telephony routes is an efficient or even 
> realistic method for some peering architectures, but if I 
> wanted to peer with another operator and only provide routing 
> for a certain block of numbers...it may be an acceptable 
> method.  Obviously, I may want to do a LNP query to make sure 
> the TN hasn't been ported away from my peer before I route to 
> them, but it could work for 10k blocks, etc..
> 
> [Richard]
> IMHO the whole issue is completely out of scope in speermint
>  
> Richard
> 
> 
> ________________________________
> 
> Von: Malas, Daryl [mailto:[email-masked]]
> Gesendet: Fr 14.04.2006 00:03
> An: Michael Hammer (mhammer); [email-masked]; Reinaldo 
> Penno; [email-masked]
> Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows 
> 
> 
> 
> Comments in-line...
> 
> Daryl M.
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, April 13, 2006 12:09 PM
> To: [email-masked]; Reinaldo Penno; [email-masked]
> Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows
> 
> To the authors of draft-penno-message-flows-00.txt,
> 
> One part of this that didn't seem quite right to me was the 
> use of mutual Registrations between Proxy 1 or domain A and 
> Proxy 2 of domain B.  (e.g., Do you intend to do some type of 
> Contact routing?)
> 
> 
> [Daryl]  Contact routing wasn't my primary reason for doing 
> this, but I did think of that as an option.  You could 
> specify NPA-NXX or similar you are providing routes to as a 
> peering entity.  Also, this would allow a method for 
> dynamically updating supported peering routes if you were not 
> using a common routing location server.  I certainly do not 
> think exchanging telephony routes is an efficient or even 
> realistic method for some peering architectures, but if I 
> wanted to peer with another operator and only provide routing 
> for a certain block of numbers...it may be an acceptable 
> method.  Obviously, I may want to do a LNP query to make sure 
> the TN hasn't been ported away from my peer before I route to 
> them, but it could work for 10k blocks, etc..
> 
> Could I ask by way of suggestion why you don't use mutual 
> Subscribe/Notify?  That would require the same authentication 
> and authorization to the requesting domain and would likely 
> be much richer in terms of XML documents that could be 
> supplied to the other domain in a Notify.  An event package 
> per federation type could be defined, for example.
> 
> 
> [Daryl]  I think this is an interesting idea, and I am still 
> chewing on it.  I am trying to evaluate the positives and 
> negatives for accomplishing it with either method or a 
> combination of both based on architecture.  Thanks for the input.
> 
> What do you think?
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:[email-masked]]
> > Sent: Thursday, April 13, 2006 12:55 PM
> > To: 'Reinaldo Penno'; [email-masked]
> > Subject: RE: [Speermint] SPEERMINT Routing Architecture 
> Message Flows
> >
> > The call flows shown are pretty much as would be expected from the 
> > trapezoid model in RFC 3261 using well defined SIP proxy behavior 
> > (lengthy section in RFC 3261).
> >
> > Why use B2BUA that have no defined behavior at all?
> >
> > Is it possible to standardize undefined behavior?
> >
> > Thanks, Henry
> >
> > 
> >
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[email-masked]]
> > Sent: Wednesday, April 12, 2006 3:27 PM
> > To: [email-masked]
> > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows
> >
> > Hello,
> >
> > We wrote a draft to help frame our discussions.
> >
> > Thanks,
> >
> > Reinaldo
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> >
> >       Title           : SPEERMINT Routing Architecture 
> Message Flows 
> >       Author(s)       : R. Penno, et al.
> >       Filename        : draft-penno-message-flows-00.txt
> >       Pages           : 19
> >       Date            : 2006-4-12
> >      
> > This draft describes the message flows associated with the 
> SPEERMINT 
> > routing architecture. We show message flows in several peering 
> > scenarios.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt
> >
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> 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: Richard Shockey <[email-masked]>
Date: Fri, 14 Apr 2006 09:30:50 -0400

> through this peering point.

Correct... the translation of the PSTN number to some URI is the ENUM function. 
Now that said in those countries with full database number portability such as 
the US you cannot effectively delegate on 10,000 or 1,000 number blocks. The 
resolution to point of interconnection must be at the full E.164 number.

-- 

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

---

From: "Patrick Melampy" <[email-masked]>
Date: Fri, 14 Apr 2006 10:43:18 -0400

When enum fails -- should that be out of scope? 

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Friday, April 14, 2006 9:31 AM
To: Michael Hammer (mhammer)
Cc: Malas, Daryl; Stastny Richard; [email-masked]
Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows

> through this peering point.

Correct... the translation of the PSTN number to some URI is the ENUM
function. 
Now that said in those countries with full database number portability such
as 
the US you cannot effectively delegate on 10,000 or 1,000 number blocks. The

--