Question on non-outbound registrations in outbound

Dean Willis <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.