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