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

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

I probably switched the E's and the O's, but that is why I threw this
out there, because this was the picture that came to mind from reading
the email thread.

Actually, the third possibility may be the one tripping up the words.

Case 1 is monolithic and likely in the home network only

Case 2 may allow for the O/E proxy to be either in a home or visited
network.  Does it matter?

Case 3 may need more explanation in the draft.

Is the following the correct picture?  Maybe my E and O are synonymous
and the O proxy should be labeled something else.

R=registrar
E=edge
O=outbound
C=client

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

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

If we can't draw the picture, we probably don't know what we mean.  
If this is wrong, please draw me another picture.

Mike

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Tuesday, July 11, 2006 12:45 PM
> To: Michael Hammer (mhammer); IETF SIP List
> Subject: RE: [Sip] Outbound: Stunning who?
> 
> 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.
> 
> At 11:04 AM 7/11/2006, Michael Hammer \(mhammer\) wrote:
> >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
> 

_______________________________________________
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