Subject: [Sip] Outbound-05: Editorial comments

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 31 Oct 2006 05:33:45 +0100

Hi,

Some editorial comments on outbound-05:

Abstract:
---------

Instead of:

"It also defines keep alive behaviors needed to keep NAT bindings open"

...I propose that we should say something like:

"It also defines how SIP implements the STUN keepalive usage
[reference]"

Introduction:
-------------

Instead of:

"The key idea of this specification"

...I propose that we should say something like:

"The key idea of the outbound mechanism defined in this specification"

Because, the are two key ideas in the spec: the outbound mechanism and
the STUN keepalive for SIP.

Instead of:

"This mechanism also uses a keep alive mechanism over each flow so that
the UA can detect when a
flow has failed."

...I propose that we should say something like:

"This specification also defines how SIP implements the STUN keepalive
usage. The keepalive mechanism is used by outbound to keep NAT bindings,
and to allow the UA to detect when a flow has failed. The keepalive
mechanism can also be used as a stand-alone function, or together with
other SIP extensions".

Chapter 3.5:
------------

Instead of:

"This specification describes using STUN [I-D.ietf-behave-rfc3489bis]
over the same flow as the SIP traffic to
perform the keepalive."

...I propose that we should say something like:

"This specification describes the usage of the STUN keepalive usage
[I-D.ietf-behave-rfc3489bis] over the same flow as the SIP traffic to
perform the keepalive. The SIP implementation of the STUN keepalive
usage is described in chapter 8 of this specification."

Chapter 8:
----------

In generel I think this chapter is good, but I don't think we should
talk about "flows" here, becuase the chapter is not part of outbound
itself (I also still strongly think that we should define a flag which
can be inserted in Path/Service-Route, but that issue is discussed in
another thread).

So, I think it would be enough to say something like:

"The STUN messages can be used to verify that connectivity is still
available, and to provide periodic keepalives in order to keep NAT
bindings open.

...and:

"A SIP node MUST NOT send STUN requests unless it has an explicit
indication that the target next hop SIP server claims to support STUN." 

Regards,

Christer

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