Subject: [Sip] WGLC comments on sip-outbound-10: further concerns for registrar

From: <[email-masked]>
Date: Thu, 2 Aug 2007 10:50:43 +0300

Hi,

After cleaning up the Section 6 from some apparently
redundant text I finally got my thoughts focused to
some aspects of the registrar behaviour defined in 
the remaining pieces of text. Here are the related
comments:

6.  Registrar Mechanisms

Minor technical:

   "The registrar MUST be prepared to receive,
   simultaneously for the same AOR, some registrations that use
   instance-id and reg-id and some registrations that do not."

Which specific use cases this is expected to cover:
a) for the same AOR but from different devices; or
b) for the same AOR even from one single device so
   that one REGISTER contains reg-id while another 
   does not; or
c) for the same AOR from one single device so that
   a single REGISTER would contain multiple Contacts,
   some of them having reg-id while others not ?

To me the cases b) and c) do not make sense so I suggest
scoping this statement for case a) as follows:
"The registrar MUST be prepared to receive,
 for the same AOR (from different devices), 
 some registrations that use instance-id and 
 reg-id and some registrations that do not."

Minor technical:

   "The Registrar MAY be configured 
   with local policy to reject any registrations that do not include 
   the instance-id and reg-id, or with Path header field values that 
   do not contain the 'ob' parameter.

If REGISTER request with mixed type of Contacts is allowed
(case c above) some text has to be added how to handle such 
REGISTER requests if the proxy has been configured a local 
policy to reject registrations without reg-id or instance-id.
Shall the registrar reject the whole request or only
those contacts which are not according to the policy ?

Minor technical:

   "The registrar MUST store all the Contact parameters 
   in the binding and SHOULD also store the time at which the 
   binding was last updated."

   "and SHOULD update the time the binding was last updated."

Maybe this has been explained earlier, but I did not find
from the document any reason why the registrar should store
the time at which the binding was last updated. Why should
it do that ? At least the time should not be needed for 
replacing earlier registrations with newer ones, which
is described in section 3.2 like this: "If the instance-id
and reg-id are the same as a previous registration for the 
same AOR, the registrar replaces the old Contact URI and 
flow information."

Related Nit for Section 3.2:

As pointed out in my earlier email, in my opinion
the storing the Contact URI is not necessary for Outbound
so that the section 3.2 should say: "If the instance-id
and reg-id are the same as a previous registration for the 
same AOR, the registrar replaces the old binding and 
flow information."

Regards,

Erkki 

_______________________________________________
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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Aug 2007 18:20:31 -0500

Some more WGLC on sip-outbound-10
---------------------------------

-------

Section 4.4: change "timed-keepalives" to "time-keepalive" (there are at
least 2 instances of 
this mistake).

-------

The example in section 9 should use TCP instead of of UDP, since TCP is
preferred (as
discussed in section 14). Furthermore, if the UDP example is used, it
should show
the rport parameter in the Via header.

It should be clarified that the last paragraph of 4.3 only applies to
UDP.

------

I would like to see more details in section 9 about how the "ob",
"rport" and Route and
Record-Route headers (i.e., including the keep-XXX parameter) are used
by a UA that 
supports outbound procedures, when sending requests using Outbound (like
INVITE for example).

Also, it would be helpful to see an example where the outbound proxy is 
not co-located with the Registrar, so we could see how the Path header
is used,
including the "ob" parameter (as per the procedures of 5.1). This stuff
is non-trivial
and would benefit greatly from an example flow (with the messages
content).
Distinguishing between 'ob' in Contact and in Path/Route seems
important.

In other words, a flow (with messages) illustrating what an edge proxy
does for both
registration and for further requests such as INVITE.

------

Finally, the procedures in 5.3 on "incoming" requests is not that clear
on what it actually
mean "on the wire". It says the following:

   For an incoming request, the proxy removes
   the Route header field value and forwards the request over the
   'logical flow' identified by the flow token, that is known to deliver
   data to the specific target UA instance. 

Does it just mean that the request will be forward on the same TCP or
UDP flow, and 
that there is no additional requirements? Nothing on the wire that will
show that outbound
is being used (Is the flow token supposed to be inserted by the Proxy)?
On that front,
message 8 in the example of section 9 has a flow token, where does it
come from?
This is very confusing since the Caller might not use Outbound, so where
does this
token come from, and what it is used for in this example? How is the
token of the
Callee given to the Caller???

It is also no clear from the
example how the Caller knows to reattempt the INVITE to the secondary
proxy (wouldn't
this be handled in the terminating side's domain?). 

There is no description of UAS requirements in the draft. Does it mean
that there are none
whatsoever? (I'm talking about a UAS that is using outbound receiving
incoming requests). If
so, there should be a UAS section stating so.

Is it possible for example that incoming requests might be received by
the UAS on different 
flows (because of reboot for example)? In the same session??