|
List Info
Thread: Outbound-10 comments
|
|
| Outbound-10 comments |
 
Canada |
2007-09-19 15:40:59 |
|
| 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.
|
| Re: Outbound-10 comments |
Canada |
2007-09-20 10:06:16 |
|
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
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 sip-implementors cs.columbia.edu for questions on current sip
Use sippingietf.org for new developments on the application of sip
|
[1-2]
|
|