The "Registrar" and "Authoritative proxy" definitions are prety tight, sure. That's OK with me.
The problem is that you have no consistent term in the document for "the place where the UAC sends both requests and keep alives". In some places it's called "host", in others "server", in others "edge proxy", in others "registrar", depending on topology. In other places, it's just avoided altogether, e.g.., the request is "sent" as oppose to the request is "sent to edge proxy". If we don't want to use the term "outbound proxy" that is used consistently in RFC 3261 (presumably because it's both an "outbound" and an "inbound" proxy at the same time, and because it means "the outbound proxy that conforms to the this draft"), then let's use "Edge proxy" consistently. And we should state that "An Edge proxy is an Outbound Proxy (as per RFC 3261) that conforms to the requirements of this specification" (if the statement is true). That would mean that in your co-located scenario, it would be a "Registrar/Edge Proxy" instead of "Registrar/Proxy", and in your multiple connection scenario, it would be "Edge Proxy 1" and "Edge Proxy 2". Would that work? > -----Original Message----- > From: Rohan Mahy [mailto:[EMAIL PROTECTED] > Sent: Friday, July 20, 2007 10:57 > To: Audet, Francois (SC100:3055) > Cc: Rohan Mahy; Stucker, Brian (RICH1:AR00); Cullen Jennings; > [email protected] > Subject: Re: Question about keep-alives in Outbound draft > > François, > > We started off using the term outbound proxy in previous > versions of the draft and many people complained that the > term did not have a meaningful or useful definition. It was > one of those "its what I mean" definitions. I think the > definitions of edge proxy, authoritative proxy, registrar, > and UAC are pretty tight. There certainly might be some > places where we say "host" or "client" or "proxy" where we > should be saying something more well defined, but if so, I > would like to change them to the correct terms, not to > outbound proxy". > > AFAIK, going back to outbound proxy will be a big step > backwards for the document. Also, the registrar and proxy > together is the simplest case to explain and I think it is > still the most common topology. > > thanks, > -rohan > > > On Jul 20, 2007, at 10:32 AM, Francois Audet wrote: > > Moving to proper mailing list (i.e., sip). > > > > Rohan, I also think that the draft could be a little bit > clearer about > > where the CRLF is sent, and where it stops, but I think it's a > > consequence of how section 3 is structured, and the terms we use. > > > > If we made the concept of "Outbound proxy" a bit clearer in the > > document, and use it throughout, and specifically say that > the CRLF is > > sent to the outbound proxy, it would read much better. > > > > Section 3 and above don't even use the term "outbound proxy" and > > instead uses euphemisms such as "edge proxy", "proxy", "registrar", > > "host" and "server". > > > > Furthermore, it starts with a special case (co-located > Registrar and > > Proxy), and finishes with the the general case (outbound proxy is > > separate from the Registrar). > > > > I would suggest the following editorial changes: > > > > - Move section 3.4 to where 3.2 currently is. > > > > - Remove the word "Proxy" in the box that says "Registrar/Proxy" > > (i.e., > > it should just say "Registrar". There is no need for having a > > proxy > > necessarily co-located in the Registrar, and it's immaterial to > > this > > draft. > > > > - The box that say "Edge1" and "Edge2" should really be labelled > > "Outbound Proxy 1" and "Oubound Proxy 2". The text should also > > use the term "outbound proxy" instead of "edge proxy", and it > > should just explain that often this configuration is called > > and "edge proxy". > > > > - In section 3.2 (which would now be 3.3), clarify that > this is just a > > special case of the outbound proxy and Registrar being co-located. > > Also use the term "outbound proxy" in the diagram and the text, as > > appropriate. > > > > - In section 3.3 (which would now be 3.4), clarify that the > Host1 and > > Host2 are really the outbound proxy 1 and 2, in the diagram. > > > > - In section 3.5, use the term "outbound proxy" instead of server > > when talking about the entity receiving the ping and sending the > > pong. > > > > - Section 5 should use the term "Outbound proxy" instead of "Edge > > proxy". > > > > - Section 5.4 is where we should say the "oubound proxy" does not > > forward the keep alives. > > > > - Section 9 should use the terms "Primary outbound proxy" and > > "Secondary > > > > outbound proxy". > > > > Cheers > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:[EMAIL PROTECTED] > >> Sent: Friday, July 20, 2007 09:20 > >> To: Stucker, Brian (RICH1:AR00) > >> Cc: Rohan Mahy; Cullen Jennings; [EMAIL PROTECTED]; Audet, Francois > >> (SC100:3055) > >> Subject: Re: Question about keep-alives in Outbound draft > >> > >> > >> On Jul 19, 2007, at 9:50 PM, Brian Stucker wrote: > >> > >>> Cullen/Rohan, > >>> > >>> I have a question about keep-alive behavior in the -10 > >> version of the > >>> outbound draft. > >>> > >>> How far are keep-alives propagated along the flow created at > >>> registration? > >>> > >>> The text seems a bit hazy on how far it is expected for a > >> keep- alive > >>> to be propagated along the flow. Section 8 has text in the last > >>> paragraph on page 25 that seems to imply that STUN > >> keep-alives go no > >>> further than the edge proxy immediately adjacent to the > >> client device. > >>> Section > >>> 4.4.3 > >>> seems to also limit generation of STUN keep-alives to the > >> User-Agent > >>> only. > >> > >> one-hop. one-hop only Mister Kamarov. > >> > >>> Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF > >> response to > >>> the first edge-proxy as well. > >> > >> yes. > >> > >> I don't think either of these statements is hazy. Can you > propose a > >> rewording? > >> > >>> Inclusion of the keep-stun or keep-crlf parameters for a Path URI > >>> inserted by an edge proxy or registrar outside of the one in the > >>> outbound-proxy-set seems moot as earlier edge-proxies that don't > >>> support these mechanisms would ostensibly drop the keep-alives. > >> > >> if these parameters find their way into a URI handled by another > >> proxy (instead of the UAC), they will be ignored (and no > keepalives > >> will be generated by the proxy). > >> > >>> Further, you only show a NAT/FW between the first > >> edge-proxy and the > >>> User-Agent in the figure for section 3.4. > >> > >> yes. that was part of our design assumptions. we had a > hum on that > >> about a year ago. We assume that there is a full SIP connectivity > >> among any of the proxies and that anything necessary to make that > >> work is taken care of. > >> > >>> However, the spec never really > >>> says very clearly what should occur at the edge-proxy: > >> should it check > >>> for freshness of the next-hop towards the registrar or not, > >> based upon > >>> what it observed in the Path header coming back in the > registration > >>> response? > >> > >> It says very clearly what to actually do and I hope it > doesn't even > >> hint that you should even begin to think about such a > heinous thing > >> as sending keepalives to the registrar from the EP. > >> > >>> Is there a reason that edge-proxies are not expected to > regenerate/ > >>> relay the appropriate keep-alive message to the next entry > >> on the Path > >>> vector? > >>> Not doing so means that some other mechanism must be > >> employed to keep > >>> bindings/pinholes open between the various edge-proxies and the > >>> registrar proxy. > >> > >> If that problem exists in your environment, it is > completely out of > >> the scope of outbound. The spec is about routing traffic over > >> outbound-initiated flows from the UA. > >> > >>> For instance, in IMS you can have a P-CSCF in the visited network > >>> talking to an IBCF in the visited network that is connected > >> to an IBCF > >>> in the home network that finally terminates at the S-CSCF > >> in the home > >>> network of the user that is registering. A NAT/FW is likely > >> to exist > >>> between the UA and the visited P-CSCF as well as between > >> the IBCF in > >>> the visited network and the IBCF in the home network. > >> > >> How do SIP messages make it today from a P-CSCF to an S-SCSF? > >> > >>> Another possible example (I believe) would be in the case > of p2psip > >>> where you may have multiple hops between the client and the node > >>> acting as a registrar for the DHT algorithm. Wouldn't you > >> want to keep > >>> the entire path to the node storing your contact > information in the > >>> DHT alive or is there some other property of the DHT > algorithm that > >>> ensures that this is always the case even though outbound > >> only keeps > >>> the last hop fresh? > >> > >> p2psip has some unique requirements. I don't think > outbound prevents > >> p2psip from addressing their requirements, but they are > certainly not > >> the concerns that outbound intended to address. > >> > >> thanks, > >> -rohan > >> > >> > >>> Regards, > >>> Brian > >> > >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
