Re: Question on non-outbound registrations in outbound

Thank you! That is exactly the sort of "Why this is a MUST" discussion  
I'm talking about.

--
dean


On Oct 20, 2008, at 1:38 AM, 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