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

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 12 Apr 2006 10:20:00 -0400

I am thinking more generically.  When considering 300 Multiple Choices,
O-Network proxy would query S/L-Network proxy, and S/L-Network Proxy
_may_ need to communicate with any number of potential T-Networks that
may be able to eligible to term the session to the ultimate T-Network
where called UA resides.  With that said, we are speaking that both
constructs are valid.  Redirect blind, and Redirect with some forwarding
resolution activity.

Adam

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 6:06 PM
To: Hadriel Kaplan; Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering

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:20:14 -0400

Agreed, but if S doesn't have that direct knowledge of how to reach T, or if
O has multiple S's, then they're either hunting which takes too long, or
forking which could create big virtual broadcasts across a web of
middle-providers.
-hadriel

> Sent: Wednesday, April 12, 2006 10:20 AM
> To: Malas, Daryl; Hadriel Kaplan; [email-masked]