I think it's pretty obvious if you don't register at least one, you won't get any calls.
But ok for the mofidified text. > -----Original Message----- > From: Kevin Johns [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 20, 2008 14:53 > To: Audet, Francois (SC100:3055); [email protected] > Cc: Rohan Mahy; Cullen Jennings > Subject: RE: [Sip] Outbound-12 comments > > Just one further thought on the first topic below, otherwise > I am ok with the rest. > > -----Original Message----- > From: Francois Audet [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 20, 2008 3:48 PM > To: Kevin Johns; [email protected] > Cc: Rohan Mahy; Cullen Jennings > Subject: RE: [Sip] Outbound-12 comments > > See below. I've trimmed the things we are either fixing > already or where we have closed. > > > -----Original Message----- > > From: Kevin Johns [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 20, 2008 14:01 > > To: Audet, Francois (SC100:3055); [email protected] > > Cc: Rohan Mahy; Cullen Jennings > > Subject: RE: [Sip] Outbound-12 comments > > > > > 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. > <kcj> This is good. Can we further clarify that the UAC MUST > attempt to register at least one or is that just plain obvious? > > > > Section 4.2.1, Initial Registration - this section makes no > > reference > > > to the keep-timer. It would seem that this should be > > discussed in the > > > same context as detecting outbound support in the registration > > > response? It is covered in section 4.4 but seems out of > place as a > > > first reference. > > > > You mean the Flow-Timer? I'm not sure why we would want to > discuss the > > > Flow-Timer in the section about Registration. Can you be > more specific > > > on what you are looking for? > > <kcj> Yes I meant flow-timer, sorry for the confusion. > Given there is > > text in 4.2.1 to examine the registration response for > presence of the > > > outbound option-tag it seemed reasonable to identify all the > > parameters the UA should look for in the response. No big deal if > > folks are comfortable with the current text. > > Yes, but there is already a forward reference to 4.4. It says: > > If outbound registration succeeded, as indicated by the > presence of > the outbound option-tag in the Require header field of > a successful > registration response, the UA begins sending keepalives as > described in Section 4.4." > > > > 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. > > _______________________________________________ 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
