Subject: [straw] draft-kaplan-straw-b2bua-loop-detection-00: comments and questions

From: Brett Tate <[email-masked]>
Date: Tue, 14 Aug 2012 07:05:42 -0700

Howdy,

The following are a few comments and questions concerning draft-kaplan-straw-b2bua-loop-detection-00.

Thanks,
Brett

----

Should this draft be limited to requests outside of a dialog?  More specifically, I'm concerned with the potential of vendors lowering the initial Max-Forwards based upon the number of Route entries within dialog.

Concerning the following section 5 quote, the requirement to only decrement by 1 causes the B2BUA to be uselessly vulnerable to receiving large Max-Forwards values (potential impacts are discussed within RFC 5393).  Section 7's flexibility to act differently might be good enough to address my concern; however it might be good to reiterate that RFC 3261 indicates that the maximum is 255 to help protect handling if higher values are received.  My preference is to always allow a B2BUA to decrement by more than 1 similar to what a UA can do when selecting the initial value.

"All B2BUA types MUST copy the received Max-Forwards header field
 from the received SIP request on their UAS side, to any request(s)
 they generate on their UAC side, and decrement the value, as if they
 were a Proxy following [RFC3261]."

Also concerning the above quote, some services should cause the resulting requests to not proxy/decrement the Max-Forwards.  For instance a received INVITE might cause sending NOTIFY and multiple INVITEs.  The NOTIFY likely would not use the received/decremented Max-Forwards; similarly generating a new Max-Forwards for some of the INVITEs may be appropriate if specific services cause an INVITE to be sent after receiving an INVITE.

Concerning the following section 5 quote, RFC 3261 does not require the request to be rejected.  For instance, it specifically allows the OPTIONS to be acknowledged with a 200 response.

"Being a UAS, B2BUAs MUST also check the received Max-Forwards header
 field and reject the request if the value is zero, as defined in
 [RFC3261]."

Concerning the following section 5 quote, it should be updated to indicate "which SHOULD be 70".  This would better reflect RFC 3261 section 16.6 without introducing ambiguity with prior MUST.

"If the received request did not contain a Max-Forwards header field,
 one MUST be created in any requests generated in the UAC side with a
 default value of 70, as described for Proxies in section 16.6 part 3
 of [RFC3261]."

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information.  If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, or by sending an email to [email-masked], and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.