Subject: [Sip] WGLC comments on sip-outbound-10

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Aug 2007 09:43:46 +0100

1. "The UA can also include a reg-id parameter which is used to allow
the
   registrar to detect and avoid keeping invalid contacts when a UA
   reboots or reconnects after its old connection has failed for some
   reason."
Surely if outbound behaviour is required it is necessary to include
reg-id. So it should say "The UA also includes...."

2. "When the proxy goes to forward a
   request to a given target, it looks and finds the flows over which it
   received the registration."
In the case being described here in 3.2 there is only a single flow. Add
", in this case, only a single flow".

3. "The proxy then forwards the request on
   that flow, instead of resolving the Contact URI using the procedures
   in RFC 3263 [4] and trying to form a new flow to that contact.  This
   allows the proxy to forward a request to a particular contact over
   the same flow that the UA used to register this AOR."
This seems a bit circular. It effectively says that by forwarding on the
existing flow it enables the proxy to forward on the existing flow! I
think the second of these two sentences can be deleted.

4. "To convey its instance-id in both requests and responses, the UA
   includes a "sip.instance" media feature tag as a UA characteristic
   [7] ."
The sending of instance-id in responses does not seem to be specified
anywhere, so perhaps this sentence should only refer to requests. On the
other hand, perhaps the intention is to send an instance-id in a contact
in a response, as described for requests in 4.3. If so, a section on
sending responses is required.

5. "These ordinary registration requests include a distinct reg-id
   parameter in the Contact header field."
There is no RFC2119 language here. Shouldn't it say something like:
"If outbound behavior is required, registration requests MUST
include..."

6. "4.3.  Sending Requests"
I am not sure whether this section is intended to cover all requests
(including REGISTER requests) or requests other than REGISTER. If the
latter, the title should be "Sending Requests other than REGISTER".

7. "The contact is formed normally in that the UAC uses the IP address
of
   the device (even if the device is behind a NAT)."
This does not allow for the use of a GRUU in non-REGISTER requests.

8. "Note that the requirements in this section
   applies to both REGISTER requests received from an Edge Proxy as well
   as requests received directly from the UAC."
I think this note is intended to refer only to the current paragraph,
not the entire section.

9. "then the proxy MUST send the request over the same
   'logical flow' saved with the binding that is known to deliver data
   to the specific target UA instance."
It is the logical flow that is know to deliver data to the UA, not the
binding. I think it should say:
"then the proxy MUST send the request over the same
   'logical flow' saved with the binding, since that flow is known to
deliver data
   to the specific target UA instance."

10. "8.  STUN Keepalive Processing"
This section contains a mixture of requirements on a UA and requirements
on a server. It would be good practice to separate these.

11. "Note that UACs MUST NOT
   use an ambiguous configuration option such as "Work through NATs?" or
   "Do Keepalives?" to imply next hop STUN support."
I am not sure about RFC2119 language here. First, it does not express a
protocol requirement. Second, the whole statement is a note. Third, the
requirement is vague and hard to test. I would have thought it
sufficient to say "should not". If RFC2119 language is really considered
necessary, it should not be stronger than "SHOULD NOT" because of the
vagueness of the requirement.

12. "Later, after
   the Primary reboots, The Callee discovers the flow failure and
   reestablishes a new flow to the Primary."
Alternatively the proxy might discover the flow failure before the
Primary reboots, although it cannot  of course successfully re-establish
the flow until after reboot. Perhaps it should say:
"Later, after the Primary reboots, the Callee successfully reestablishes
a new flow to the Primary. Keepalive checks and any failed attempts to
re-establish the flow are not shown."

13. "The value of the reg-id MUST NOT be 0 and MUST be less than 2**31."
According to the ABNF, the value can be less than or equal to 2**31.

NITS
- Change "the Registrar MUST NOR" to "the Registrar MUST NOT".
- Change "Note that the requirements in this section
   applies" to "Note that the requirements in this section
   apply"

John

_______________________________________________
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

---

From: Byron Campen <[email-masked]>
Date: Tue, 7 Aug 2007 14:42:51 -0500

Re-sending this since it has been a while, and to get it in the same  
thread as some of the other reviews.

********************************************************************

	Here's the notes from my first pass.

NITS/editorial:

Sec 3.2
"The UA can also include a reg-id parameter which..."

Are we not assuming the UA is trying to do outbound?

Sec 4.2
"This specification assumes the set
    is determined via any of a number of configuration mechanisms, and
    future specifications can define additional mechanisms such as using
    DNS to discover this set."

Seems like this sentence is unnecessary. If you really feel the need  
to explicitly call out the fact that multiple mechanisms may exist,  
and that these mechanisms will be defined in future standards, you  
could maybe say something like:

"The mechanism or mechanisms used to configure UAs are outside the  
scope of this specification, and will be defined in future  
specifications."

If you feel the need to mention a configuration mechanism based on  
DNS, you might want to move it away from the statement that says "out  
of scope" ;)

Sec 4.2.1
It is probably obvious that third-party registrations cannot use  
outbound, but it helps the flow if you lead off with this statement.

Sec 4.3
"Unless there are
    privacy reason not to include an instance-id,"
Mixing singular and plural.

Sec 4.4
"For UDP, the upper bound of 29
       seconds was selected so that multiple STUN packets could be sent
       before 30 seconds based on information that many NATs have UDP
       timeouts as low as 30 seconds.  "

Kinda awkward. I think you could trim out the "so that multiple STUN  
packets could be sent before 30 seconds" without sacrificing clarity.

eg.
"For UDP, the upper bound of 29
       seconds was selected based on information that many NATs have UDP
       timeouts as low as 30 seconds. "

Sec 4.5
"...at least one consecutive keepalive response was received."

"...at least two consecutive keepalive responses were received."?

Sec 5.1
"   When an Edge Proxy receives a registration request with a reg-id
    header parameter in the Contact header field, it needs to determine
    if it (the edge proxy) will have to be visited for any subsequent
    requests sent to the user agent identified in the Contact header
    field, or not.  If the Edge Proxy determines that this is the case,
    it inserts its URI in a Path header field value as described in RFC
    3327 [5].  If the Edge Proxy is the first SIP node after the UAC, it
    either MUST store a "flow token"--containing information about the
    flow from the previous hop--in its Path URI, or reject the request.
    The flow token MUST be an identifier that is unique to this network
    flow.  The flow token MAY be placed in the userpart of the URI.  In
    addition, the first node MUST include an 'ob' URI parameter in its
    Path header field value.  If the Edge Proxy is not the first SIP  
node
    after the UAC it MUST NOT place an 'ob' URI parameter in a Path
    header field value.  The Edge Proxy can determine if it is the first
    hop by examining the Via header field.
"

This is a little awkward/rambling. Here's my shot at making it easier  
to read.

"   When an Edge Proxy receives a registration request with a reg-id
    header parameter in the Contact header field, it must determine
    whether it is the first SIP node after the UAC. The Edge Proxy can
    determine if it is the first hop by examining the Via header field.

    If the edge proxy is the first SIP node after the UAC, it MUST  
insert
    a Path header field value, whose URI MUST contain both a flow-token
    and an 'ob' parameter, or it MUST reject the request. The flow token
    MUST be a unique identifier for the network flow from the previous
    hop, and MAY be placed in the userpart of the URI.

    If the Edge Proxy is not the first SIP node after the UAC, it MAY
    still insert a Path header field value as described in RFC 3327 [5],
    but this value MUST NOT contain an 'ob' URI param.
    "

Sec 6, para 7
"The Registrar MUST include the 'outbound' option-tag (defined in
    Section (Section 12.1)) "

Looks like an xref is not doing what you intended.

Sec 6, para 7
"Furthermore, the Registrar MUST NOR
    include this option-tag..."

Sec 6, para 7
"Note that the requirements in this section
    applies to... "
Mixing singlar and plural.

Sec 6, para 8
"To be compliant with this specification, registrars which can receive
    SIP requests directly from a UAC without intervening edge proxies
    MUST implement STUN NAT Keepalives on its SIP UDP ports as described
    in Section 8 and when it receives a double-CRLF sequence on a
    connection oriented transport such as TCP or SCTP, it MUST
    immediately respond with a single CRLF over the same connection."

Awkward, how about:

"
Registrars that can receive SIP requests directly from a UAC (ie,
without intervening edge proxies) are required to implement the same
keepalive mechanisms as edge proxies (see Sec 5.4).
"

Sec 6, as a whole

It felt like the logic for determining whether outbound processing  
should be done was excessively spread out in this section. I could  
propose alternate text if you like.

Sec 7
"
    The proxy uses normal forwarding rules looking at the next-hop  
target
    of the message and the value of any stored Path header field vector
    in the registration binding to decide how to forward the request and
    populate the Route header in the request.  If the proxy stored
    information about the flow over which it received the REGISTER for
    the binding, then the proxy MUST send the request over the same
    'logical flow' saved with the binding that is known to deliver data
    to the specific target UA instance.
"

Awkward. How about:

"
    When the Authoritative Proxy doubles as a registrar, targets may  
have
    flow information associated with them (see Sec 6). When forwarding a
    request to a target that is associated with a flow, the proxy MUST
    send the request over said flow. Otherwise, the proxy will forward
    the request as it would normally.
"

Minor technical:

(Where should this go?)
Probably should mention that an endpoint using outbound will not be  
able to target-refresh if the edge proxy uses Record-Routes to store  
flow-tokens (provided the Dialog was established over a flow). This  
is because the edge proxy would end up routing according to flow- 
tokens in the Route-Set, which is invariant (ie, not effected by a  
target-refresh at all).

Sec 4.4.3
What if STUN requests are not answered? How many unanswered STUN  
requests must go by before the UA considers the flow dead? Will the  
occasional dropped UDP packet be sufficient evidence that the flow is  
dead?

Sec 8
"When a URI is created that refers to a SIP node that supports STUN as
    described in this section, the 'keep-stun' URI parameter, as defined
    in Section 12 MUST be added to the URI."

This can be interpreted as saying "If your server element supports  
STUN, every single URI you create that refers to it needs to have a  
keep-stun param." I don't know if this is what you intended. There  
might be valid reasons for not wanting to advertise STUN support on  
every URI you mint (indeed, not every such URI will be useful; what  
good will having 'keep-stun' in a Route header be, for example?)

Sec 8.1
"When STUN is used together with SigComp [24] compressed SIP messages
    over the same flow, how the STUN messages are sent depends on the
    transport protocol.  For UDP flows, the STUN messages are simply  
sent
    uncompressed, "outside" of SigComp."

Since STUN is only used over UDP, we can get rid of the "depends on  
transport protocol" stuff.

Major technical:

No problems.

Best regards,
Byron Campen