Subject: [Sipping] Question about keep-alives in Outbound draft

From: "Brian Stucker" <[email-masked]>
Date: Thu, 19 Jul 2007 23:50:32 -0500

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.

Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF response to
the first edge-proxy as well.

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.

Further, you only show a NAT/FW between the first edge-proxy and the
User-Agent in the figure for section 3.4. 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?

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.

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.

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?

Regards,
Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 20 Jul 2007 09:20:07 -0700

> seems to also limit generation of STUN keep-alives to the User-Agent

one-hop.  one-hop only Mister Kamarov.

> the first edge-proxy as well.

yes.

I don't think either of these statements is hazy.  Can you propose a  
rewording?

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

> 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

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.

> bindings/pinholes open between the various edge-proxies and the

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.

> visited network and the IBCF in the home network.

How do SIP messages make it today from a P-CSCF to an S-SCSF?

> that this is always the case even though outbound only keeps the last

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