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