Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 11 Apr 2006 16:06:25 -0600

I just want to make sure I understand your statement below...

If a redirect proxy is used, the call flow will look more like this:

  L (or S)
 //
O---T

Not this:

 S
 /\
O--T

FYI...when I think of redirect proxy, I think of a proxy that issues a
3XX message to O in response to an INVITE.  Are you speaking of it more
generically?

--Daryl M.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 9:10 PM
To: 'Uzelac, Adam'; [email-masked]
Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering

Ahh, yes I see - I thought you were talking about redirect.
-hadriel

> -----Original Message-----
> From: Uzelac, Adam [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 10:35 PM
> To: Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering
> 
> I can't agree in a proxied(non-redirect) call flow.  Also, there may
be
> a requirement to determine which T-Network to term the call to should
> there be more than one.  There could be a subsequent T-Network proxy
> involved.  So the call would be signaled from O-Network to S-Network,
> and then maybe S-Network to T-Network to determine ultimate T-Network
> end point.
> 
> Adam Uzelac
> 
> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 9:59 PM
> To: Uzelac, Adam; [email-masked]
> Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering
> 
> Hi Adam,
> 
> If S is doing a redirect/proxy, isn't it just the location lookup
> mechanism for O--T?  (a trusted+shared location-lookup)
> 
> So there's really just:
>   L
>  /
> O---T.
> 
> Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :)
> 
> -hadriel
> 
> 
> > -----Original Message-----
> > From: Uzelac, Adam [mailto:[email-masked]]
> > Sent: Friday, April 07, 2006 10:37 AM
> > To: [email-masked]
> > Subject: [Speermint] 2 Basic Constructs for SIP Peering
> >
> > I have gnawed on the latest series of threads, and while wadding
> > through the noise and rhetoric, it appears to me that there are 2
> > basic constructs for SIP peering.  Subscribing to Brian's notion
that
> > we must try to keep this simple - at least at this stage - it seems
to
> 
> > boil down to the following: (I acknowledge that there may be
> > contextual
> > variations)
> >
> > Option A) Session routing by 3rd party.
> >
> >  S
> >  /\
> > O--T
> >
> > In this model, O-Network queries S-Network (signaling) for routing
> > options.  S-Network redirects or proxies signaling request to
> T-network.
> > There is an assumption that L3 connectivity exists between all
three,
> > though S-Network would not be transit for media, but possible for
> > signaling.  The media flows directly from O-Network to T-Network.
> >
> > Option B) Direct bi-lateral routing.
> >
> > O--T
> >
> > In this model, O-Network signals T-Network directly, and receives
> > routing instructions.  Media would follow the same relationship,
maybe
> 
> > not the same path, but same bi-lateral relationship.  Should there
be
> > more than one L3 peering point, any peering point may be used, but
it
> > all follows the same contextual relationship between O-Network and
> > T-Network.
> >
> > I find it possible to apply either Option A or Option B to public,
> > private, and even carrier (even carrier pigeon) environments.  Maybe
I
> 
> > am pointing out the obvious, but that's OK as I have been often
> > accused of being master of the obvious.  ;)
> >
> > Adam Uzelac
> >
> > _______________________________________________
> > 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: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 13 Apr 2006 21:05:00 -0400

Hi Daryl,
Are you referring to my comment?  I was saying a redirect-proxy S is
logically similar to O using a lookup function to a lookup database L.

The line wasn't meant as a uni-directional path, but as a logical
bi-directional one.  For a redirect, yes I assumed a 3xx to an invite.  It's
effectively a location lookup function, although obviously the L node makes
the lookup "decision" so to speak, and can do so based on its local
policies, rather than having O implement a lookup function based on returned
policies.  But then one could also implement a DNS box to return different
responses based on its internal policies as well (though it would be much
more cumbersome for it to do so without other information that's in the
Invite).

I agree with Adam that if it's not a redirect-node in the middle, then it's
the O-S-L triangle. (or it could be a straight line for signaling if S is a
stateful proxy, or b2bua)

The advantages of S being stateful is it can perform policies based on full
session knowledge (e.g., session load capacity of T), among other things.

-hadriel

> From: Malas, Daryl [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 6:06 PM
> To: Hadriel Kaplan; Uzelac, Adam; [email-masked]