Hi, >Can we be careful about terminology here? >I don't think this has anything to do with third party registration. >Third party registration is when identity of the UA performing the registration differs from the To-URI of the REGISTER request. > >I think what this was intended to be about is when a Contact address used in a REGISTER terminates at a different place from the device sending the REGISTER request. > >Now I guess the Contact address itself is irrelevant in outbound, to the extent that its never resolved via 3263. We normally expect it to be consistent with the source of the register request, >but does it really matter?
I don't think so. Incoming requests will be sent to where the REGISTER came from, no matter what's in the Contact. Regards, Christer Christer Holmberg wrote: > Hi Dean, > > How would the keep-alives work for 3rd party registration? How would I > know that you have registered me, and that I now have to send > keep-alives (and where I would have to send the keep-alives)? > > And, how would you know if the flow that you have registered for me > fails, in which case you should establish a new flow for me? > > Regards, > > Christer > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Dean Willis > Sent: 17. lokakuuta 2008 17:36 > To: SIP IETF > Subject: [Sip] Question on non-outbound registrations in outbound > > The current draft says: > 4.2.3. Non Outbound Registrations > > In an initial registration, a User Agent MUST NOT include a reg-id > header parameter in the Contact header field if the registering UA > is > not the same instance as the UA referred to by the target Contact > header field. (This practice is occasionally used to install > forwarding policy into registrars.) > > A UAC also MUST NOT include an instance-id feature taf or reg-id > Contact header field parameter in a request to un-register all > Contacts (a single Contact header field value with the value of > "*"). > > This strikes me as odd in several ways. > > The reg-id lets us know "which registration we are talking about". The > instance-id lets us know "which specific UA-appearance we are talking > about". > So for a 3rd-party registration, it might be useful to have reg-id or > instance-id values. Assume for example a voice-mail server that > registers a low q-value contact for an AOR, so that calls will > eventually reach it in a no-answer scenario. Withdrawing just those > specific registrations would seem to require a selection mechanism > from the set of registrations, and reg-id would appear to satisfy this need. > > > In a different use case, assume a 3rd party registration is used to > install forwarding policy. The use of an instance-id in such a > registration would seem to allow the forwarding policy to target one > specific instance of the set of contacts registered to the target. In > other words, not "forward the call to sip:[EMAIL PROTECTED]", but > "forward the call to sip:[EMAIL PROTECTED]'s cell phone". > > Now it's entirely possible that neither of these scenarios actually > work. But I don't see in the discussion of outbound anything about WHY > they wouldn't work, which means that the requirements language (the > MUST in outbound) is unsupported. I don't like unsupported > requirements in a specification. > -- > Dean > > _______________________________________________ > 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 > _______________________________________________ > 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 > _______________________________________________ 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
