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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
