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

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

[adam] Comments inline...

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Saturday, April 08, 2006 5:41 AM
To: Hadriel Kaplan; Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering

> So there's really just:
>   L
>  /
> O---T.

The location function is one of the basic functions SPEERMINT needs to
work on

[adam] I agree.
 
Of course the simplest case is defined in RFC 3263, but there are more
complex cases - e.g. a redirect/proxy server, eventaually also involving
an ENUM lookup, this is basically what VPF or XConnect are providing.
(the second is policy, i.e. if you are able to access the given proxy)

[adam] It's in the redirect/proxy scenario that I am thinking that there
could (maybe should) be communications between the S-Network and the
T-Network to determine if S-Network should direct the session to the
T-Network.  With this said, I am thinking back to a triangle model of:
[adam]
  S
  /\
 O--T
 
Another task may be to translate personal URIs or enterprise AoRs
hosted by a SP to the ingress proxy of the SP e.g.
Sip:[email-masked] -> sip:[email-masked]

[adam] I don't know if this task would be a requirement or not.  Might
be up to the implementor to determine, but to me this doesn't have
anything to do with routing of the session.
 
The main task of a "location function" is to provide the out-bound proxy
of the O-domain (one of) the ingress proxy(s) of the T-domain
 
> 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.
 
With terminating networks it is like Highlander there can only be one

[adam] Great movie!  I am thinking that all O-Networks will not be
interconnected possible to all T-Networks.  Therefore some (I hesitate
stating) transit network options may need to be considered.  Transit
here meaning not the _ultimate_ T-Network where the called party
resides, but granted, it is the T-Network from the O and S-Network's POV
for that call.  The S-Network may be aware of multiple routes to the
ultimate T-Network via some transits, one path may have different
characteristics than another. If the consensus here is that transits
will not be considered, than B2BUAs would be required to hide the
topology as you state below.
 
> 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.
 
>From the point of the O-domain there is only one T-domain ingress point
If there are a bunch of T-domains hidden behind does not matter for the
O-domain or to be precise: it MUST NOT.

[adam] Should I read this MUST NOT as stating that a T-Network, if not
the ultimate T-Network where calling party resides, must use B2BUAs?
 
The reason for topology hiding proxies is topology hiding
 
If for example the mobile networks decide to open up the IPX GSMA
network to be reached by selected partners from the Internet, they will
put ingress proxies at the border of their network, and all what a
O-domain on the internet will see for a AoR hosted by the mobile
networks will be the ingress proxies of IPX.
 
The routing to the real t-domain (teh specific mobile network will then
be done via the ingress proxy

The O-domain is not concerend

[adam] The O-Network (domain) may not be concerned, but does the
S-Network need to be?

Richard

________________________________

Von: Hadriel Kaplan [mailto:[email-masked]]
Gesendet: Sa 08.04.2006 05:09
An: 'Uzelac, Adam'; [email-masked]
Betreff: 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:16:42 -0400

Hi Adam, comments inline...

> anything to do with routing of the session.

I think what Richard meant, or at least I think is a problem, is if
bi-lateral peering agreements are needed, then it's very difficult to
imagine every provider having one with every other one.  I would assume a
tiered/chained model would occur, whereby some enterprises or small
providers would only be reachable through a set of providers they have
relationships with.  

If that's true, then there would probably be a chain of such providers that
would need to be transited to reach the final destination.  So if a provider
wants to send a session to the final one, it has to figure out how to reach
it, and it can't just be one DNS lookup, or even a lookup that results in
"use this federation to reach me".  It could be a lookup of the final
target's domain that results in a "use federation X", and then a lookup of X
that results in "use Y" and so on until a federation directly reachable by O
is found.  Someone had a draft on this into spearmint I think.  It's not
very optimal on a call-by-call basis, but the only other alternative is to
use TRIP I think. (which had that model down pat, since it included
accumulated costs as well)

Even handing the call off to an S domain to figure out will only work if S
has such knowledge itself.  And that's essentially the same problem faced by
O if it doesn't use an S.

-hadriel