Subject: RE: [Speermint] Use Case draft

From: Daryl Malas <[email-masked]>
Date: Fri, 27 Oct 2006 11:01:45 -0600

In my mind, I agree with David.  I separate the LF look up from
direct/indirect status.  The LF lookup can comprise of ENUM or 3XX.
Even though SIP is used for the 3XX, this is still the "LF" phase. In
order for an indirect peering method to take place, the subsequent
INVITE after the 3XX is actually sent to a SF of a 3rd party provider to
be proxied to the (indirect) peer.

--Daryl

On Thu, 2006-10-26 at 15:17 -0400, Michael Hammer (mhammer) wrote:
> In the example Adam gives, the SIP method is just another mechanism to
> query and get the real address to which a *new* INVITE is sent directly.
> In other words the subsequent INVITE is a new dialog and the route set
> does not include the previously queried one.
> 
> So, I would see that as direct.
> 
> Mike
>  
> 
> > -----Original Message-----
> > From: David Schwartz [mailto:[email-masked]] 
> > Sent: Thursday, October 26, 2006 5:12 AM
> > To: Uzelac, Adam; Michael Hammer (mhammer); [email-masked]
> > Subject: RE: [Speermint] Use Case draft
> > 
> > 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
> > 
> > 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,
> > 
> > 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

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint