Hi, Two comments inline.
>> > Section 4.2.1, Initial Registration, 2nd para - Is the opening >> > sentence well understood by all? "For each outbound proxy >> URI in the >> > set, the UA SHOULD send a unique REGISTER in the normal way >> using this >> >> > URI as the default outbound proxy." >> >> I think it's clear. What do you propose we change? >> <kcj> I was not necessarily proposing a change. I just wanted >> to make sure folks were comfortable with the language 'a >> unique REGISTER in the normal way'. When I read this it was >> unclear to me what unique was referring to? Is the REGISTER >> unique in that each must have a different reg-id or that a >> unique call-id is used or both? Further if the normal way is >> RFC 3261 then why not state a REGISTER per RFC 3261 with the >> following enhancements...? > > What about this: > > For each outbound proxy URI in the set, the UAC SHOULD send > a REGISTER request using this URI as the outbound proxy. I'm OK with "... a REGISTER request (with a unique Call-ID), using ..." We added "unique" at someone's request because he was no sure if he should use the same call-id and tags. >> > Section 4.2.2, Subsequent REGISTER requests, The first sentence - >> > "Re-registrations and single Contact de-registrations use the same >> > instance-id and reg-id values as the corresponding initial >> > registration." Suggest making this normative >> >> You mean saying: >> "Re-registrations and single Contact >> de-registrations MUST use the same instance-id and reg-id >> values as the corresponding initial registration." >> <kcj> Yes this is my suggestion >> >> Rohan? > > I'm OK with this recommendation. I'm not happy with this MUST. The quoted statement already *is* normative. It is not necessary to include a MUST statement to make a statement normative. Excessive and unnecessary use of RFC 2119 language impairs clarity and readability. Based on several requests from readers, I removed a lot of extraneous MUSTs and the spec was much easier to read. thanks, -rohan _______________________________________________ Sip mailing list https://www.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
