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

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 7 Apr 2006 11:12:46 -0400

Brian,

I agree.  Though in most of the scenarios I know of, O-S-T looks like
O-T via B2BUAs and Media Relay.

Adam

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 11:05 AM
To: Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering

I think people want to have option c

O-S-T

That is, the media goes through S as well as the signaling.

I think that is agnostic to public/private/carrier I don't think it
changes much.

Brian

-----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

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 8 Apr 2006 11:40:32 +0200

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

The location function is one of the basic functions SPEERMINT needs to work on
 
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)
 
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]
 
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
 
> 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.
 
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

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

> Sent: Friday, April 07, 2006 10:35 PM
> To: Hadriel Kaplan; [email-masked]
> 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
>
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 9:59 PM
> 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
>
>
> > 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)
> >
> > am pointing out the obvious, but that's OK as I have been often
> > accused of being master of the obvious.  ;)
> >
> > Adam Uzelac
> >

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Apr 2006 21:13:13 +0200

>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?

If it is breaking the end-to-end flow on L3 between the UAs
IMHO Yes

Richard

Von: Uzelac, Adam [mailto:[email-masked]]
Gesendet: Mi 12.04.2006 16:04
An: Stastny Richard; Hadriel Kaplan; [email-masked]
Betreff: RE: [Speermint] 2 Basic Constructs for SIP Peering

[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

> O---T.

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

[adam] I agree.

[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?

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

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

Richard

> 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.
> > 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
>
> > 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.
> > 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.
> >
> > private, and even carrier (even carrier pigeon) environments.  Maybe

> > I