Hi Erkki,
I believe I have addressed all your comments below except storing the
time (which is an issue for GRUU). See inline for more.
thanks,
-rohan
On Aug 2, 2007, at 12:50 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
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."
The registrar could receive from the same UA, one registration
through a edge proxy that supports outbound, and one that does not.
(a and b are allowed, but not c). The case of c) is already
prohibited by the text in section 4.2.1
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 ?
the whole request with a 400 Bad Request, since this combination is
clearly illegal.
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."
As I mentioned in another thread, the time is stored for consistency
with 3261 and for use with GRUU, but we could change this behavior if
we update GRUU accordingly.
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."
The Contact URI is still necessary (for retargeting), but your
sentence is still correct.
thanks,
-rohan
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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
