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

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

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: David Meyer <[email-masked]>
Date: Fri, 14 Apr 2006 10:17:48 -0700

> IMHO the whole issue is completely out of scope in speermint

	That much I can agree with.

	Dave