Subject: RE: [Sip] Outbound: Stunning who?

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 11 Jul 2006 11:04:30 -0400

Dave,

I think there are 3 possible topologies:
R=registrar
E=edge
O=outbound
C=client

+-+  +-+  +-+
|R|  |R|  |R| home
| |  +-+  +-+
| |   |    |
| |  +-+  +-+
|E|  |E|  |E| home
| |  | |  +-+ 
| |  | |   |
| |  | |  +-+
|O|  |O|  |O| visited
+-+  +-+  +-+ 
 |    |    |
+-+  +-+  +-+
|C|  |C|  |C|
+-+  +-+  +-+
 1    2    3

1=monolithic proxy
2=home network IMS
3=visited network IMS

Confusion may depend on which picture people have in their head at the
moment.

All, feel free to correct or modify if I missed something.

Mike

> -----Original Message-----
> From: Dave Oran (oran) 
> Sent: Tuesday, July 11, 2006 7:21 AM
> To: IETF SIP List
> Subject: Re: [Sip] Outbound: Stunning who?
> 
> 
> On Jul 11, 2006, at 3:28 AM, Jeroen van Bemmel wrote:
> 
> > Joel,
> >
> > see inline
> >
> [snip]
> >> The only problem is that if the UAC sends STUN packets, in the 
> >> presence of an edge proxy, those STUN packets will be 
> addressed to, 
> >> and (if they arrive) be consumed by the edge proxy.  In 
> other words, 
> >> the entity which needs to support STUN is not the entity 
> identified 
> >> by the URI with the keepalive=stun parameter, nor is it
> >> the entity which placed the support: outbound in the header.   
> >> Whatever one thinks about the safety of sending STUN based on a 
> >> configured parameter, that configuration ought to relate to the 
> >> server to which the STUN is being sent.
> >>
> >> As far as I can tell, the desire for and verification of 
> STUN usage 
> >> ought to be a matter between the UAC and the edge proxy, and ought 
> >> not be tied up with the outbound URI or the behavior of 
> the outbound 
> >> proxy.
> >>
> >
> > Edge proxies *are* outbound proxies, the "home proxy" is 
> the outbound 
> > proxy when there are no edge proxies
> >
> Needless to say, I find this incredibly confusing. It's clear 
> Joel does too. I wonder how many other people are wandering 
> around in this maze as badly as I am.
> 
> I thought this whole effort was about managing transport 
> connections from UAs to the "SIP cloud" such that the user 
> doesn't lose service because SIP routing can't figure out how 
> to get requests destined for the UA to the proxy that happens 
> to have the transport connection to the UA at this moment.
> 
> If I'm misinformed on this, I suspect some other folks are too.
> 
> >> Feel free to tell me I have missed the point,
> If you missed the point, I missed the point...
> 
> I'll quickly comment that when I looked over outbound again 
> last night, I got the distinct impression that MOST of the 
> complexity is due to trying to solve one particular use case 
> - the UA wants to maintain transport connections to proxies 
> in different domains and be able to receive calls whichever 
> of the connections (and hence whichever of those doimains) 
> happens to be working.
> 
> I once worked out a pretty simple scheme (at least one I 
> think is much simpler than outbound) for the case where all 
> that's needed is redundant transport connectivity to the UA 
> from proxies in the same edge proxy farm. (I described this 
> to Dean late last night and I think he got it, so maybe 
> there's somebody else who shared my hallucination here).
> 
> Dave Oran.
> 
> >> Joel
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Jul 2006 12:44:50 -0400

That's interesting, but does not align with how I read the outbound draft.
The proxies identified as the "outbound set" (which are presumably 
the outbound proxies) are teh targets of the registration requests 
from the user.  Hence, I believe the outbound proxies are intended to 
be the registrars.
And the Edge Proxy is specifically stated to be the first proxy from the user.

Whatever else is going on, if different readers are getting pictures 
this disparate from the draft, we need to clarify the draft.

Yours,
Joel

PS: There is actually an assumption in all of this that the first 
proxy is outside of ones NAT.  Otherwise, the client can not STUN 
anyone, since the entity he has an IP address for, his first proxy, 
would also be inside the NAT boundary.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 11 Jul 2006 20:56:35 +0200

Hi Joel,

> The proxies identified as the "outbound set" (which are presumably the 
> outbound proxies) are teh targets of the registration requests from the 
> user.  Hence, I believe the outbound proxies are intended to be the 
> registrars.

No, the registration requests are targeted at the home domain as usual (ie 
request URI == domain from AoR). Any discovered URI is added as the topmost 
Route header, it is the first hop but not (necessarily) the final 
destination of the REGISTER.

That being said, there seems something wrong with the text in section 4.2. 
When interpreted literally, it reads as if the UA would always have an 
outbound-proxy-set with at least 2 entries, making the example given in 
section 3.2 (direct registration) impossible (because there would 
"typically" be a Route header).

I think the text should say "UAs obtain at configuration time *zero* or more 
SIP URIs representing the default outbound-proxy-set." to allow for this 
case

> Whatever else is going on, if different readers are getting pictures this 
> disparate from the draft, we need to clarify the draft.
>
> Yours,
> Joel
>
> PS: There is actually an assumption in all of this that the first proxy is 
> outside of ones NAT.  Otherwise, the client can not STUN anyone, since the 
> entity he has an IP address for, his first proxy, would also be inside the 
> NAT boundary.
>

That is the assumption / limitation that the outbound draft makes: if there 
is NAT, it is located between the UA and the proxy to which the discovered 
outbound URI resolves.

Regards,

jeroen

---

From: Dean Willis <[email-masked]>
Date: Tue, 11 Jul 2006 15:55:30 -0500

On Jul 11, 2006, at 11:44 AM, Joel M. Halpern wrote:

> from the user.  Hence, I believe the outbound proxies are intended  
> to be the registrars.
> Whatever else is going on, if different readers are getting  
> pictures this disparate from the draft, we need to clarify the draft.

Yep. I'm pretty sure I invented the term "outbound proxy" (in the sip  
context, at least) some years ago, but even so the way I read the  
draft we were ending up stunning helpless edge proxies that were  
between the UAs and the "outbound" proxies and had no way to complain  
about it. Worse than the Taser-happy Dallas police, I think.

The root of the problem, I think, is that this draft intertwingles  
the proxy behavior (supporting stun) with the registrar behavior  
(supporting "outbound" parallel registrations).

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 11 Jul 2006 23:09:30 +0200

> The root of the problem, I think, is that this draft intertwingles  the 
> proxy behavior (supporting stun) with the registrar behavior  (supporting 
> "outbound" parallel registrations).

That, plus the fact that "outbound" is really about receiving inbound 
requests (from the UA perspective). An "outbound" proxy is traditionally 
something to which a UA sends its outbound requests, typically starting with 
REGISTER.

"draft-ietf-sip-inbound-nat-traversal" ?

Jeroen