Subject: Re: [Sip] Outbound-10 comments

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 11:22:54 -0800

Jerry, Peter,

Per consenus in Chicago we have ;keep in outbound-11 instead of ;keep- 
stun and ;keep-crlf.  I believe this fix addresses your comments.

thanks,
-rohan

On Sep 20, 2007, at 8:06 AM, [email-masked] wrote:
> I agree with Jerry here, and believe this has come up before (?).   
> It is pointless for the originating UA to try to impose, or infer,  
> the keepalive mechanism before it can know what is applicable.
>
> An additional comment along these lines.
> > a. UA sends REGISTER to the proxy with a "outbound" tag in the  
> Supported header.
> ...
> > c. If the "outbound" tag is present in the 200 OK, and if the  
> transport is UDP, using the STUN keep alive, other connection based  
> transport using crlf keep alive.
>
> Step a) would really imply the originating UA MUST support both  
> keepalive mechanisms, and c) implies it MUST begin using the  
> appropriate one after 200 OK.  The usage is implied, not explicit,  
> which I believe is sufficient in this case.  Alternatively, the  
> usage could be made more explicit by listing the supported k-a  
> mechanisms in Supported exchange, or some such.  This should be  
> spelled out either way.
>
> -- Peter Blatherwick 
>
>
>
>
> Jerry Yin <[email-masked]>
> 19.09.07 16:40
>
>
>         To:        [email-masked], [email-masked], [email-masked]
>         cc:
>         Subject:        [Sip] Outbound-10 comments
>
>
>
> Hi Cullen and Rohan,
>
> In the draft, it requires the UA configure the next hop route  
> header with "keep-stun", "keep-crlf", or "timed-keepalive" tags.  
> This would cause some problems.
>
> 1. As an example, the route-set contains this route header as  
> indicated in section 9 example:
> Route: <sip:pri.example.com;lr;keep-stun>
> If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or  
> TLS, the keep-stun will be useless. Vice versa, if the  
> pri.example.com is resolved as UDP, and if "keep-crlf" was manually  
> configured, it is not working either.
>
> 2. Before sending the REGISTER request, the admin/or user does not  
> know what keep-alive mechanism the proxy (or edge proxy) supports.  
> Blindly configure the keep-stun, or keep-crlf would cause the  
> problem that the draft indicated itself in section 8: "the node  
> could be blacklisted for UDP traffic".
> The better approach is to let the UA and the proxy to negotiate,  
> not manually configure from UA side.
> a. UA sends REGISTER to the proxy with a "outbound" tag in the  
> Supported header.
> b. Proxy insert the "outbound" tag in the 200 OK, if the UA  
> indicated that it supports the outbound.
> c. If the "outbound" tag is present in the 200 OK, and if the  
> transport is UDP, using the STUN keep alive, other connection based  
> transport using crlf keep alive.
> There would be no way to mass up by configurations with this  
> approach. Let me know if I missed something.
>
> Regards,
> Jerry Yin
>
>
> Yahoo! oneSearch: Finally, mobile search that gives answers, not  
> web links. _______________________________________________
> 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
>

_______________________________________________
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

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 11:38:29 -0800

Hi Sergio,

I believe all your concerns have been addressed in outbound-11,  
except that the example in Section 9 needs to be rewritten.  The keep- 
stun and keep-crlf parameters have been merged into a single 'keep'  
parameter.  A few more comments inline.

thanks,
-rohan

On Sep 20, 2007, at 3:22 PM, [email-masked] wrote:
> Hi,
>
>  I composed the email below a month ago related to this thread and  
> thought that I was missing something so I did not posted it, but it  
> seems that there are some issues pending with the keepalive label  
> and processing.
>
>  Sorry to introduce more questions:
>
> --
>
>  My comments are about the keep-stun label.
>
>  It is not very clear how the UA discovers that the Edge Proxy  
> supports STUN.
>
>
> In section 8 (keepalive processing). I read
>
> "   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 allows a UA to  
> inspect
>    the URI to decide if it should attempt to send STUN requests to  
> this
>    location.  For example, an edge proxy could insert this parameter
>    into its Path URI so that the registering UA can discover the edge
>    proxy supports STUN keepalives."
>
> Q1. Why "an edge proxy COULD insert this parameter into its Path  
> URI" and not MUST ? (considering that the UA supports STUN)

If the next hop from the UA is the registrar, there will be no edge  
proxy and therefore probably no Path header.

> Q2. In what other header can I also add the keep-stun, so that it  
> will be still present when I get back a response?

the Path header or the Service-Route header for example.  This could  
just be learned through configuration.

> Note that in the example of section 9 the responses 200-OK haven't  
> any keep-stun

This will get fixed when I overhaul the example.

> (Also mentioned in http://www1.ietf.org/mail-archive/web/sip/ 
> current/msg20295.html)
>
>
> Q3. For the case in this example, How will the Callee know that it  
> is allowed to send STUN keepalives? (no keep-stun present)
>
> For the case in the example, and considering:
>
>       "Typically, a SIP node first sends a SIP request and waits to
>       receive a final response (other than a 408 response) over a flow
>       to a new target destination, before sending any STUN messages."
>
> The callee will never send the keepalives...
>
> --
> Part II
>
>
>  In my opinion, the edge proxy MUST add a list of the supported  
> mechanisms for keepalive in the 200-OK response to REGISTER. The  
> list MUST include ALL the supported mechanisms (so the UA can for  
> example know that if some mechanism is not available for the  
> transport it used to register there are other mechanisms for other  
> protocols. In this case the UA will form a new flow by registering  
> using another protocol.)
>
> Example 1:
>
> UA sends REGISTER over UDP.
> It gets back a 200 OK with only keep-crlf.
> UA recognizes that STUN is not available, so a UDP flow can not  
> succeed. Then it sends a REGISTER over TCP.
>
> Example 2:
>
> UA sends REGISTER over UDP.
> It gets back a 200 OK with keep-crlf and keep-stun.
> UA recognizes that keep-crlf is present so (its logic) can judge  
> that TCP is a better choice.
> Then the UA forgets using UDP and switches to TCP: sends a REGISTER  
> over TCP.
>
> Q: Should not be handy to have something like keep-Scrlf so the UA  
> can knows that TLS is also supported? The same for DTLS.
>
>
>
>
> Sergio
>
>
> Quoting [email-masked]:
>
>> It is
>> pointless for the originating UA to try to impose, or infer, the  
>> keepalive
>> mechanism before it can know what is applicable.
>>
>>> Supported
>> header.
>>> transport
>> is UDP, using the STUN keep alive, other connection based  
>> transport using
>> crlf keep alive.
>>
>> keepalive
>> mechanisms, and c) implies it MUST begin using the appropriate one  
>> after
>> 200 OK.  The usage is implied, not explicit, which I believe is  
>> sufficient
>> in this case.  Alternatively, the usage could be made more  
>> explicit by
>> listing the supported k-a mechanisms in Supported exchange, or  
>> some such.
>> This should be spelled out either way.
>>
>> -- Peter Blatherwick
>>
>>
>>
>>
>>
>>
>> header with
>> "keep-stun", "keep-crlf", or "timed-keepalive" tags. This would  
>> cause some
>> problems.
>>
>> TLS, the
>> keep-stun will be useless. Vice versa, if the pri.example.com is  
>> resolved
>> as UDP, and if "keep-crlf" was manually configured, it is not working
>> either.
>>
>> know
>> what keep-alive mechanism the proxy (or edge proxy) supports. Blindly
>> configure the keep-stun, or keep-crlf would cause the problem that  
>> the
>> draft indicated itself in section 8: "the node could be  
>> blacklisted for
>> UDP traffic".
>> The better approach is to let the UA and the proxy to negotiate, not
>> manually configure from UA side.
>> Supported
>> header.
>> transport is
>> UDP, using the STUN keep alive, other connection based transport  
>> using
>> crlf keep alive.
>>  Yahoo! oneSearch: Finally, mobile search that gives answers, not web
>> links. _______________________________________________

---

From: [email-masked]
Date: Tue, 4 Dec 2007 04:04:50 -0500

Yes, it does.  I checked the related changes and they look fine.  Thanks.,
-- Peter

Rohan Mahy <[email-masked]>
01.12.07 14:22
 
        To:     [email-masked]
        cc:     Rohan Mahy <[email-masked]>, Jerry Yin 
<[email-masked]>, [email-masked], [email-masked]
        Subject:        Re: [Sip] Outbound-10 comments

Jerry, Peter,

thanks,
-rohan