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
