Subject: [Sip] Question on non-outbound registrations in outbound

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 09:35:58 -0500

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-masked]", but  
"forward the call to sip:[email-masked]'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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 20 Oct 2008 08:38:08 +0200

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-masked] [mailto:[email-masked]] 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:

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-masked]", but "forward
the call to sip:[email-masked]'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-masked] for questions on current sip Use
[email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2008 08:21:24 -0400

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?

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 20 Oct 2008 14:23:52 +0200

Hi, 

>
>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

need.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2008 09:34:47 -0400

Perhaps it would be better if outbound specified a special form of 
contact address that was clearly bogus for routing in its own right, to 
avoid any confusion that its value is significant when outbound is used.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 20 Oct 2008 20:50:14 +0200

Hi,
 
>avoid any confusion that its value is significant when outbound is used.

When sending the REGISTER, the UAC doesn't know whether the registrar supports outbound in the first place, so whatever "special form" it used it must work also in those cases.

I guess it depends on if/how much the registrar cares about the contact, since it is going to route based on the Path.

Regards,

Christer

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Oct 2008 21:17:22 -0500

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:

> from
> "forward
> MUST