Re: [Sip] Outbound-10 comments

[Rohan Mahy <[e-mail]>]

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, [e-mail] 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 [e-mail]:
>
>> 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 <[e-mail]>
>> 19.09.07 16:40
>>
>>         To:     [e-mail], [e-mail], [e-mail]
>>         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 [e-mail] for questions on current sip
>> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip