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