Subject: RE: [Speermint] Use Case draft

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 24 Oct 2006 12:53:31 -0400

David,

I had understood this the same way.  That the direct or indirect
referred to the SIP INVITE, not the ENUM lookups.

Mike

> -----Original Message-----
> From: David Schwartz [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 11:37 AM
> To: Uzelac, Adam; [email-masked]
> Subject: RE: [Speermint] Use Case draft
> 
> Hi Adam.
> 
> Inline.
> 
> > David - excellent draft and thank you for compiling!  One 
> thing that I 
> > noticed and thought a bit odd was your definition of "Bi-Lateral or 
> > direct peering".  You state - "For the purposes of this 
> document, VSPs 
> > upload their numbers to an externally reachable location service
> denoted
> > as D-PSP." - To me, this is not direct because the location 
> function 
> > that you define is done outside of the 
> > originating-domain/terminating-domain relationship.
> 
> DS: The point I am trying to make here is as follows. When 2 
> VSPs want to share their user information with each other they can:
> 
>     1. Do the equivalent of a zone transfer of all their 
> users to each other so that a local copy of this information 
> is available to the O-VSP.
>     2. Have the O-VSP send an INVITE to the T-VSPs registrar 
> and have T-VSP either proxy the INVITE or send a 3XX back
>     3. Same as 2 only use ENUM to query a private tree 
> operated at T-VSP
>     4. Store this information in a mutually accessible location
>         4a. Possibly push/pull this information to a local 
> copy at both O-VSP and T-VSP
> 
> Options 1 will almost never happen. Why? Because in reality 
> new users are constantly being added/removed not to mention 
> porting in/out of numbers and since each VSP has many 
> bilateral relationships each possibly of a different nature, 
> this model will not scale as well as other options.
> 
> Options 2/3 will also probably not happen since again there 
> are multiple relationships and O-VSP will have to send many 
> INVITES to different VSPs to get an answer. Forking in this 
> case is a kludge and doesn't really help. 
> 
> Option 4 (and 4a) is the only reasonable approach. This is 
> the reason for the worldwide push for either ENUM or 
> Infrastructure ENUM. To try to get all the location 
> information into 1 place. Remember. The signaling and media 
> are still traveling between VSPs and hence I still consider 
> this Direct. Would you agree that public ENUM in this case 
> fits the direct model? I think so. So just replace the public 
> ENUM with a private ENUM that does nothing more than hold the 
> data for all interested parties and you have the same thing.
> 
> > Per the speermint terminology draft:
> > "Direct peering describes those cases in which two service 
> providers 
> > interconnect without using an intervening layer 5 network."
> 
> DS: I interpret this as intervening in terms of signaling or 
> media NOT number lookup. Am I wrong?
> 
> > -AU
> 
> Thanks for your comments Adam.
> 
> D.
> 
> _______________________________________________
> 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: "Stastny Richard" <[email-masked]>
Date: Wed, 25 Oct 2006 09:49:13 +0200

> referred to the SIP INVITE, not the ENUM lookups.

This is what I also wanted to say. We should keep the separation in
scope
of ENUM and SPEERMINT up, even if real implementations may mix up
this issue.

BTW, excellent draft, David and Eli

Richard

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Tuesday, October 24, 2006 6:54 PM
> To: David Schwartz; Uzelac, Adam; [email-masked]

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 25 Oct 2006 19:03:57 -0400

I am with you guys on this one I believe. Just so I understand....So if
it's an ENUM look-up for a trusted 3rd party to satisfy a location
request, but the SIP Invite/Media are direct between VSP-o and VSP-t,
then it's direct.  BUT if, for some reason or another (I am not
advocating, just asking the question) it's a SIP INV/3XX exchange to the
trusted 3rd party to satisfy a location request, it's indirect?

-AU

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Tuesday, October 24, 2006 12:54 PM
To: David Schwartz; Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] Use Case draft

David,

Mike

> DS: The point I am trying to make here is as follows. When 2 VSPs want

> to share their user information with each other they can:
> 
>     1. Do the equivalent of a zone transfer of all their users to each

> other so that a local copy of this information is available to the 
> O-VSP.
>     2. Have the O-VSP send an INVITE to the T-VSPs registrar and have 
> T-VSP either proxy the INVITE or send a 3XX back
>     3. Same as 2 only use ENUM to query a private tree operated at 
> T-VSP
>         4a. Possibly push/pull this information to a local copy at 
> both O-VSP and T-VSP
> 
> Options 1 will almost never happen. Why? Because in reality new users 
> are constantly being added/removed not to mention porting in/out of 
> numbers and since each VSP has many bilateral relationships each 
> possibly of a different nature, this model will not scale as well as 
> other options.
> 
> Options 2/3 will also probably not happen since again there are 
> multiple relationships and O-VSP will have to send many INVITES to 
> different VSPs to get an answer. Forking in this case is a kludge and 
> doesn't really help.
> 
> Option 4 (and 4a) is the only reasonable approach. This is the reason 
> for the worldwide push for either ENUM or Infrastructure ENUM. To try 
> to get all the location information into 1 place. Remember. The 
> signaling and media are still traveling between VSPs and hence I still

> consider this Direct. Would you agree that public ENUM in this case 
> fits the direct model? I think so. So just replace the public ENUM 
> with a private ENUM that does nothing more than hold the data for all 
> interested parties and you have the same thing.
> 
> DS: I interpret this as intervening in terms of signaling or media NOT

> number lookup. Am I wrong?
> 
> > -AU
>

---

From: "David Schwartz" <[email-masked]>
Date: Thu, 26 Oct 2006 11:11:50 +0200

That's an interesting question.

I view the location process itself as not interfering with the
direct/indirect status regardless of the underlying protocol used for
the query. Based on this even if you use 3XX to external location but do
not signal that entity in terms of actual call routing it should still
be direct.

I think it's a lot cleaner.

D.

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 1:04 AM
To: Michael Hammer (mhammer); David Schwartz; [email-masked]
Subject: RE: [Speermint] Use Case draft

-AU

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Tuesday, October 24, 2006 12:54 PM
To: David Schwartz; Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] Use Case draft

David,

Mike