Hi Nils,
The example still needs to be overhauled and will address the concern
you raised.
On Aug 5, 2007, at 9:02 AM, Nils Ohlmeier wrote:
Hello,
sorry for being with my comments. Please find one minor technical
issue and
several NITs below.
Minor Technical:
9. Example Message Flow
The 200 OK on page 28 contains no Path header, which should carry
the ob and/or the keepalive URI parameters to allow the UA to detect
that Oubound is supported and used. How can the UA detect that
outbound is supported and used for this flow when it receives a
200 OK like this one?
In the case there is an edge proxy included which supports outbound
the 200 OK should have the Path header with the parameters. If the
edge proxy does not support outbound, the Path header should not
have the parameters. If the edge proxy does not even support the
Path extension, outbound can not be supported either.
But how does the UA detect that the Registrar supports and uses
outbound in case there is no edge proxy involved?
The easiest and simple solution to me would be that the Registrar
has to include a Path header into the reply which points to itself
and carries the required parameters.
Another alternative would be to rely only on the Suported/Required
header and do not look at the Path URI at all. Then the keepalive
algorithm would be implicitly determined by the used transport, but
that would also mean that there is no way for the Registrar to let
the UA know that it supports the optional TCP Keepalive algorithm.
And the Supported/Required header would have to be included into
the reply by edge proxy (in case), which is, I think, against the
normal
usage of these headers.
NITs:
1. Introduction
"This specification allows SIP registration when the
UA is behind such a firewall or NAT."
Proposed improvement:
This specification ensures that the UA if it is behind
such a firewall or NAT is reachable by the registrar after
the first successful initial registration.
The UA is now also allowed to form a flow for dialog-forming requests
2.1 Definitions
"outbound-proxy-set A set of SIP URIs...."
Proposed improvement:
outbound-proxy-set: A set of SIP URIs...
fixed
3.2 Single Registrar and UA
"
REGISTER sip:example.com;keep-crlf SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1;branch...
...
Contact: <sip:[EMAIL PROTECTED]>;reg-id=1;...
"
Why have Via and Contact different IPs? I assume
this is a type and should look like this:
REGISTER sip:example.com;keep-crlf SIP/2.0
Via: SIP/2.0/TCP 192.168.0.2;branch...
...
Contact: <sip:[EMAIL PROTECTED]>;reg-id=1;...
fixed
3.3 Multiple Connections from a User Agent
"..., so mechanism like SRV can be used..."
Proposed improvement:
..., so mechanism like DNS SRV can be used...
fixed
4.1 Instance ID Creation
"... as the device knows no other UUIDs were generated at this time."
Proposed improvement:
... as the device knows no other UUIDs were generated at this
time on this device.
fixed
4.2.1 Registration by Other Instances
Is the second paragraph about unregister only ment for this
particular case or for all UAs supporting this draft?
To me it semms at it is ment for all UAs, as the star Contact
should match all bindings anyway. Otherwise it should be explained
somewhere what a star Contact with an instance-id and/or reg-id
means.
fixed. star with instance-id is not allowed.
4.4 Detecting Flow Failure
The last paragraph talks about tags in the URIs of the
outbound-proxy-set. Are these tags are still used after the Chicago
meeting? If so, then there should be a refence to chapter 12.
ok
5.4 Edge Proxy Keepalive Handling
Why is TCP Keepalive not mentioned in this section?
I think it should mention that this an optional keepalive mechanism
for the edge proxy.
fixed
6. Registrar Mechanisms: Processing REGISTER Requests
Last paragraph on page 22:
"First the registrar examines the first Path header field value,
if any."
Proposed improvement:
First the registrar examines the first (bottom most) Path header
field value, if any.
I think "first" is clear enough.
4th paragraph on page 23:
"Furthermore, the Registrar MUST NOR include this option-tag..."
Fix:
Furthermore, the Registrar MUST NOT include this option-tag...
fixed
8. STUN Keeplalive Processing
1st paragraph on page 26:
"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."
Why should an UA start sending any STUN messages when it received
any non-2xx reply?
I think the sentence above should be limited to 2xx responses only
as indication that the flow is "established" and the UA can send
STUN messages now.
good point. fixed
12.2 SIP/SIPS URI Parameters
Why is there no Parameter for the optional TCP Keepalive?
Or should the sections talking about TCP Keepalive as an optional
alternative be deleted from the document?
TCP keepalive references have been removed from the document. The UA
can always use TCP keepalives, but the UA cannot know that the next
hop will respond (this is a ping with no pong).
thanks,
-rohan
_______________________________________________
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
