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

From: "Kevin Johns" <[email-masked]>
Date: Wed, 1 Aug 2007 12:11:57 -0600

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?
 
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?)
 
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.
 
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?
 
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?
 
Overview, 1st sentence state 'this technique'. What technique is being
referred to? I assume Outbound procedures?
 
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.
 
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.
_______________________________________________
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