********************************************************************
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.1It 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 wholeIt 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.3What 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 thetransport 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
