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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
