Hi Kevin,
I think all your comments have been addressed in outbound-11.
more inline.
thanks,
-rohan
On Aug 1, 2007, at 11:11 AM, Kevin Johns wrote:
Hi,
Here are my comments on outbound. A few technical comments and
several nits...
Kevin
Technical (minor)
Detecting Flow Failure - I could not find any text in this section
which provides requirements (nor informative guidance) on when a
flow should be considered failed. For CRLF it can be pretty
straight forward given there are no re-transmission algorithms
going on in the background (missed a response, immediatly send
another CRLF before declaring a failure or immediately declare the
flow failed). However, STUN does have a retransmission algorithm
that the UA would need to implement and presumably this would need
to complete before a flow is considered failed?
for UDP, the flow has failed when the STUN request fails (which
includes timing out after 7.9 secs). Normal STUN retransmits are
sent since these are normal STUN requests.
This is covered in sect 8, 9th paragraph.
Edge Proxy Mechanisms - A question on edge proxy behavior when the
registrar does not provide an indication of outbound support in the
REGISTER response. Assuming that the UAC indicated outbound support
and placed a reg-id in the contact header, the Edge Proxy would
create a flow token and add that to the Path header. The registrar
may not support outbound, but may support the Path header and store
that as part of the contact/AOR binding. If this is done, how is
the Edge Proxy to behave if it receives a request which contains a
Path header with a flow token? Is it to ignore the flow token and
follow standard forwarding rules per 3261 or do something else (act
on the flow token and forward per Outbound procedures?)
It is the responsibility of the UA to cleanup any registrations that
are unwanted. This includes any registration that had a Path header
with a flow token that is no longer of interest. I added this sentence:
If the registrar did not support outbound, the UA may have
unintentionally registered an unroutable contact. It is the
responsiblity of the UA to remove any inappropriate Contacts.
STUN Keepalive Processing - I think almost all of the points made
in RFC3489bis around how to define a STUN usage are addressed by
this section with the exception of usage of optional attributes (in
particular FINGERPRINT). I think it can be inferred that Outbound
does not require (nor recommend?) the use of optional attributes,
but it might be good to clarify that to ensure interoperable
implementations.
good point. I fixed this in section 8.
Nits:
Abstract - the last sentence states 'specifies the usage of
multiple connections'. I find this statement a bit ambiguous as it
does not provide any context as to what multiple connections are
used for?
fixed
Introduction, 1st paragraph, last sentence states 'this
specification allows SIP registrations when the UA is behind such a
firewall or NAT'. I thought this spec was about allowing inbound
requests from the proxy or registrar to the UA in the presence of a
firewall or NAT?
fixed
Overview, 1st sentence state 'this technique'. What technique is
being referred to? I assume Outbound procedures?
fixed
Summary of mechanism, 2nd paragraph, 2nd sentence states 'A failure
on a particular flow can be tried again on an alternate flow".
Suggest rewording to state A failure to deliver a request on a
particular flow can be re-attempted on an alternate flow.
fixed
Edge Proxy Keepalive Handling - This section makes it very clear
that STUN MUST be supported, but only implies that CRLF must be
supported. It would be nice to align the text for the two methods.
fixed
_______________________________________________
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
