Subject: [Sip] WGLC comments on sip-outbound-10

From: Nils Ohlmeier <[email-masked]>
Date: Sun, 5 Aug 2007 18:02:54 +0200

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.

2.1 Definitions

"outbound-proxy-set  A set of SIP URIs...."

Proposed improvement:
outbound-proxy-set: A set of SIP URIs...

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-masked]>;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-masked]>;reg-id=1;...

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...

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.

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.

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.

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.

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.

4th paragraph on page 23:

"Furthermore, the Registrar MUST NOR include this option-tag..."

Fix:
Furthermore, the Registrar MUST NOR include this option-tag...

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.

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?

Cheers
  Nils Ohlmeier

_______________________________________________
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