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

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Apr 2006 14:43:20 -0400

That's a good idea Mike. 

> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, April 13, 2006 11:09 AM
> 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?)
> 
> 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.
> 
> 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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 13 Apr 2006 22:52:06 -0400

I like the requirements aspect in the draft (sections 5, 6)

My suggestion is to separate requirements into a separate draft so that
they can be dealt w/ separately. The message flows lie somewhere in the
middle of reality and fiction and the fictitious ones should probably
wait :)

-Medhavi.

> Sent: Wednesday, April 12, 2006 4:27 PM
> To: [email-masked]
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> This draft describes the message flows associated with the SPEERMINT
> routing architecture. We show message flows in several peering
> scenarios.
> 
> 
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org with the word unsubscribe in the body
> of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-penno-message-flows-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.1/309 - Release Date:
4/11/2006

---

From: "Malas, Daryl" <[email-masked]>
Date: Fri, 14 Apr 2006 11:04:48 -0600

I don't really have a strong argument against this, so perhaps it was a
bad example in the beginning....and not specifically intended or
specified in the draft.  

One wild thought, which may have multiple solutions already available...

I was thinking in line with a TN located in the user part of the SIP
URI.  An ENUM server could respond with this type of information in the
SIP URI, such as, sip:[email-masked]...companyA.com may be
acting as an IXC in order to reach user 3035551212, when in fact the
user actually exists at [email-masked]; however, I
(companyC.com) am not directly peered to companyB.com. CompanyA.com may
be peered with CompanyB.com, and provides a least cost route instead of
terminating over the PSTN. 

Perhaps it is a funky, edge example...but I can foresee this occurring.

--Daryl M.

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

Michael Hammer (mhammer) wrote:
> 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.

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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 14 Apr 2006 13:41:35 -0400

Daryl,

When you see a sip URI of form local@domainB, only domain B really knows
for sure how to handle the local part (it may not be DN).  If in fact
the DN is owned by companyB, for companyA to assert ownership of that
number might run afoul of national numbering authority regulations.
Best not to go there.  Even if not, it could insert confusion into
systems that see or store such information.

It may be better to keep the targeting of the request in the Request-URI
separate from the routing of the message that can be done by the Route
header.  What you seem to be reaching for is the additional query
capability, that in cases where the ENUM returns a sip:[email-masked]
and you can't get to domainB for some reason is the ability to look up
domainB and find some intermediary domainC through which the call could
be routed:

R-URI: sip:[email-masked]  (I made it so A and B number are from and to)
From: sip:DN@domainA
Route: domainC    (C is "transit" L5 carrier)

Although, domainB should be routable at L3 once the DNS dip tells you
what the IP address is, perhaps there are some business reasons for not
going direct.  But, if we do our job well, that should be for some
function beyond just routing.

Mike

> From: Malas, Daryl [mailto:[email-masked]] 
> Sent: Friday, April 14, 2006 1:05 PM
> To: Richard Shockey; Michael Hammer (mhammer)
> Cc: Stastny Richard; [email-masked]; Reinaldo Penno; 
> [email-masked]
> I don't really have a strong argument against this, so 
> perhaps it was a bad example in the beginning....and not 
> specifically intended or specified in the draft.  
> 
> I was thinking in line with a TN located in the user part of 
> the SIP URI.  An ENUM server could respond with this type of 
> information in the SIP URI, such as, 
> sip:[email-masked]...companyA.com may be acting as 
> an IXC in order to reach user 3035551212, when in fact the 
> (companyC.com) am not directly peered to companyB.com. 
> CompanyA.com may be peered with CompanyB.com, and provides a 
> least cost route instead of terminating over the PSTN. 
> 
> Cc: Stastny Richard; Malas, Daryl; [email-masked]; Reinaldo 
> Penno; [email-masked]
> 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
> Richard Shockey, Director - Member of Technical Staff NeuStar Inc.

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 14 Apr 2006 21:00:19 +0200

I would like to add regarding ENUM:
 
We need to distinguish which type of ENUM we are talking about:
In User ENUM it is the end-user who enters the SIP AoR (if he gets one from his provider ;-)

in public infrastructure ENUM it is the CoR hosting the number in question
He is entering what he wants that somebody elso should see:
 
1. he may enter the public user identity aka AoR, 
2. but he may also enter the ingress point of a transit network, it is his decision
 
How the transit network then routes the call to the final destination network is up to 
the transit network, they may use a private ENUM
 
What is entered into private ENUMs is private.
 
Richard

________________________________

Von: Michael Hammer (mhammer) [mailto:[email-masked]]
Gesendet: Fr 14.04.2006 19:41
An: Malas, Daryl; Richard Shockey
Cc: Stastny Richard; [email-masked]; Reinaldo Penno; [email-masked]
Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows

Daryl,

Mike