Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 May 2010 09:37:48 -0700

I agree with Hadriel's argument that the SSP should service the 
subscriptions, since it "owns" the URIs. 

I also agree that we 
should not add a dependency on VERMOUTH. 

What I'm not sure about
 is why servicing subscriptions at the SSP or PBX is a matter of 
policy.  Are there situations in which servicing the subscriptions at 
the PBX would make sense?  We're always talking about URIs owned by the 
SSP, correct?

On 5/18/10 5:12 PM, Adam Roach wrote:

We're down to a fairly small number of open issues on GIN.

Currently, section 7.2.2 of the GIN document describes some fairly 
specific behavior for "reg" event handling. In particular, it says that 
subscriptions to the state of a single phone number are forwarded by the
 SSP to the PBX. There's some logic in the document about why I thought 
this was a Good Idea, and even "important."

    At the most 
recent interim, we had a fairly long discussion about whether this was 
actually the "right" thing to do. Hadriel made some convincing arguments
 that the SSP should service the subscriptions, since it really "owns" 
the URIs in question.

    The "vermouth" draft delves a bit 
deeper into some related issues, but it's somewhat less developed than 
GIN at this point. We don't want to make GIN dependent on vermouth, and 
we really can't leave a treatment of the "reg" event package out of GIN:
 GIN deals intimately with registration. Under any reasonable "you break
 it you buy it" principle, we're on the hook for coming up with a sane 
treatment of the "reg" event package.

    After an off-list 
exchange with Hadriel, I *think* we're both okay if that treatment is as
 simple as "here are the properties if you handle it at the SSP, here 
are the properties if you handle it at the PBX, and which you choose is a
 matter of policy." (I don't mean to put words in Hadriel's mouth, and 
I'm sure he'll correct me if my summary isn't consistent with his 
position).

    This approach is actually pretty well in line with
 the way that event packages are handled in general. It also allows for 
some clever (if complicated) solutions to the problem in which the SSP 
services the subscription, but incorporates information it has learned 
from the PBX (say, through back-end subscriptions). Basically, it gets 
us back to what the IETF does well -- defining protocol mechanisms -- 
while leaving concrete architectures up to other organizations.

 Please comment on whether you think this is a reasonable way to address
 this open issue. If there is enough support, I'll craft some formal 
text and put it in GIN.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 May 2010 13:15:16 -0400

Bernard Aboba wrote:
> I also agree that we should not add a dependency on VERMOUTH.
> 
> What I'm not sure about is why servicing subscriptions at the SSP or PBX 
> is a matter of policy.  Are there situations in which servicing the 
> subscriptions at the PBX would make sense?  We're always talking about 
> URIs owned by the SSP, correct?

They are *owned* by the SSP, but *delegated* to the PBX.
The SSP doesn't know very much about those AORs - only that they are 
delegated to the PBX. The PBX has much more information - e.g. about 
registered UAs.

You could think of this like a symbolic link in a file system, to a 
directory. Sometimes you want info about the link, sometimes about the 
target of the link.

I guess you could have a subscription to sip:[email-masked] just 
return the info that there is one registered contact: 
sip:+12125551234@<pbx-contact-address>. But then the subscriber would 
need to subscribe to that contact to get the interesting information. 
And we don't have a way to get a subscription there.

	Thanks,
	Paul

>     At the most recent interim, we had a fairly long discussion about 
> whether this was actually the "right" thing to do. Hadriel made some 
> convincing arguments that the SSP should service the subscriptions, 
> since it really "owns" the URIs in question.
> 
>     The "vermouth" draft delves a bit deeper into some related issues, 
> but it's somewhat less developed than GIN at this point. We don't want 
> to make GIN dependent on vermouth, and we really can't leave a treatment 
> of the "reg" event package out of GIN: GIN deals intimately with 
> registration. Under any reasonable "you break it you buy it" principle, 
> we're on the hook for coming up with a sane treatment of the "reg" event 
> package.
> 
>     After an off-list exchange with Hadriel, I *think* we're both okay 
> if that treatment is as simple as "here are the properties if you handle 
> it at the SSP, here are the properties if you handle it at the PBX, and 
> which you choose is a matter of policy." (I don't mean to put words in 
> Hadriel's mouth, and I'm sure he'll correct me if my summary isn't 
> consistent with his position).
> 
>     This approach is actually pretty well in line with the way that 
> event packages are handled in general. It also allows for some clever 
> (if complicated) solutions to the problem in which the SSP services the 
> subscription, but incorporates information it has learned from the PBX 
> (say, through back-end subscriptions). Basically, it gets us back to 
> what the IETF does well -- defining protocol mechanisms -- while leaving 
> concrete architectures up to other organizations.
> 
>     Please comment on whether you think this is a reasonable way to 
> address this open issue. If there is enough support, I'll craft some 
> formal text and put it in GIN.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 May 2010 14:29:02 -0500

On 5/24/10 11:37 AM, Bernard Aboba wrote:
> What I'm not sure about is why servicing subscriptions at the SSP or 
> PBX is a matter of policy.  Are there situations in which servicing 
> the subscriptions at the PBX would make sense?

Definitely. For reg-event, the PBX is the only entity that will know 
stuff like "this extension has three terminals registered." It's the 
only one that can say stuff like "the terminal for +12143290491 has 
registered a callee capability of 'video'". The SSP won't have the first 
foggy clue that these kinds of things are true.

All that said, I *understand* the position that you and Hadriel have put 
forth, and can see that it makes sense in certain architectures. 
Emphasis on the last three words of that sentence.

Which is why I've proposed the third way of putting in a discussion 
about the properties of servicing at the SSP versus the properties of 
servicing at the PBX, and leaving the actual decision -- which comes 
down to network architecture -- to SDOs who claim to do network 
architecture.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 May 2010 15:49:16 -0700

Thanks to Paul and Adam for the explanation.  Adding a paragraph or two explaining the reasoning might be helpful. 

Paul Kyzivat said:

"They are *owned* by the SSP, but *delegated* to the PBX.
The SSP doesn't know very much about those AORs - only that 
they are 
delegated to the PBX. The PBX has much more information - e.g. 
about 
registered UAs.
You could think of this like a symbolic link in a file system,
 to a 
directory. Sometimes you want info about the link, sometimes 
about the 
target of the link.
I guess you could have a subscription to sip:+12125551234 at 
SSP.net just 
return the info that there is one registered contact: 
sip:+12125551234@<pbx-contact-address>. But then the 
subscriber would 
need to subscribe to that contact to get the interesting 
information. 
And we don't have a way to get a subscription there.

	Thanks,
	Paul"

Date: Mon, 24 May 2010 14:29:02 -0500
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package

  I
agree with Hadriel's argument that the SSP should service the
subscriptions, since it "owns" the URIs. 

What I'm not sure about is why servicing subscriptions at the SSP or
PBX is a matter of policy.  Are there situations in which servicing the
subscriptions at the PBX would make sense?

Definitely. For reg-event, the PBX is the only entity that will know
stuff like "this extension has three terminals registered." It's the
only one that can say stuff like "the terminal for +12143290491 has
registered a callee capability of 'video'". The SSP won't have the
first foggy clue that these kinds of things are true.

All that said, I *understand* the position that you and Hadriel have
put forth, and can see that it makes sense in certain architectures.
Emphasis on the last three words of that sentence.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 May 2010 09:11:16 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: 24 May 2010 17:38
> To: [email-masked]
> I agree with Hadriel's argument that the SSP should service 
> the subscriptions, since it "owns" the URIs. 
> 
> What I'm not sure about is why servicing subscriptions at the 
> SSP or PBX is a matter of policy.  Are there situations in 
> which servicing the subscriptions at the PBX would make 
> sense?  We're always talking about URIs owned by the SSP, correct?
[JRE] Let's consider other event packages, presence say. Ignoring MARTINI for now, if a SUBSCRIBE request for presence is targeted at [email-masked], the example.com domain proxy has to use policy to know whether to route it to a presence server in that domain or simply to route to Alice's registered UA(s).

Now extending this to the MARTINI situation, if a SUBSCRIBE request for presence is targeted at [email-masked], the ssp.com domain proxy has to use policy to know whether to route it to a presence server within the SSP domain or route to the PBX. In the latter case the PBX has to use policy to know whether to route to a presence server associated with the PBX or simply to route to Alice's registered UA(s).

John

>     Currently, section 7.2.2 of the GIN document describes 
> some fairly specific behavior for "reg" event handling. In 
> particular, it says that subscriptions to the state of a 
> single phone number are forwarded by the SSP to the PBX. 
> There's some logic in the document about why I thought this 
> was a Good Idea, and even "important."
> 
>     At the most recent interim, we had a fairly long 
> discussion about whether this was actually the "right" thing 
> to do. Hadriel made some convincing arguments that the SSP 
> should service the subscriptions, since it really "owns" the 
> URIs in question.
> 
>     The "vermouth" draft delves a bit deeper into some 
> related issues, but it's somewhat less developed than GIN at 
> this point. We don't want to make GIN dependent on vermouth, 
> and we really can't leave a treatment of the "reg" event 
> package out of GIN: GIN deals intimately with registration. 
> Under any reasonable "you break it you buy it" principle, 
> we're on the hook for coming up with a sane treatment of the 
> "reg" event package.
> 
>     After an off-list exchange with Hadriel, I *think* we're 
> both okay if that treatment is as simple as "here are the 
> properties if you handle it at the SSP, here are the 
> properties if you handle it at the PBX, and which you choose 
> is a matter of policy." (I don't mean to put words in 
> Hadriel's mouth, and I'm sure he'll correct me if my summary 
> isn't consistent with his position).
> 
>     This approach is actually pretty well in line with the 
> way that event packages are handled in general. It also 
> allows for some clever (if complicated) solutions to the 
> problem in which the SSP services the subscription, but 
> incorporates information it has learned from the PBX (say, 
> through back-end subscriptions). Basically, it gets us back 
> to what the IETF does well -- defining protocol mechanisms -- 
>     Please comment on whether you think this is a reasonable 
> way to address this open issue. If there is enough support, 
> I'll craft some formal text and put it in GIN. 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 May 2010 09:54:49 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> 
> Bernard Aboba wrote:

I don't think you can make that blanket statement.  The SSP could have other UA's registered for one or more of those same AoR's.  Unless we're explicitly saying it can't.(?)

> And we don't have a way to get a subscription there.

Yes we do.  Send the SUBSCRIBE to the contact (and path info as Routes) of that initial subscribe's notified xml doc entries.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 May 2010 10:00:13 -0400

> Of Adam Roach
> Sent: Monday, May 24, 2010 3:29 PM
> 
> 
> Definitely. For reg-event, the PBX is the only entity that will know stuff
> like "this extension has three terminals registered." It's the only one
> that can say stuff like "the terminal for +12143290491 has registered a
> callee capability of 'video'". The SSP won't have the first foggy clue
> that these kinds of things are true.

I guess one implicit assumption here is that the phones off the PBX register for an AoR of the SSP, but in the PBX.  I mean, let's say we've got "sip:[email-masked]".  Do the "terminals" off the PBX REGISTER for the literal AoR "sip:[email-masked]"?  

Because if they don't, then I don't see how a PBX processes a SUBSCRIBE for reg-event for "sip:[email-masked]" and shows registered contacts of those terminals with that as the aor.  I mean it could obviously, but it's not what 3680 says.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 May 2010 10:27:09 -0400

> I don't think you can make that blanket statement.  The SSP could have other UA's registered for one or more of those same AoR's.  Unless we're explicitly saying it can't.(?)

Yes, that is a potential, though outside the mainstream of the cases 
being considered.

> Yes we do.  Send the SUBSCRIBE to the contact (and path info as Routes) of that initial subscribe's notified xml doc entries.

This could be made to work, and may be the best alternative.

I think this would require that the published contact address either be 
a GRUU, or contain an embedded Route header that references the SSP in 
some way, or else depend on the notification containing the GRUU and the 
subscriber knowing enough to use that for the subsequent subscription.

Perhaps the last of those is the cleanest. But its not entirely clear to 
me how clients, who may not even know Martini mechanisms are in use, 
would know they should do this.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 May 2010 10:31:46 -0400

IIUC its most likely that we have "sip:[email-masked]" defined on the 
ssp, but the terminals are registering with "sip:[email-masked]".

I don't see that as a fundamental problem. If the ssp receives a 
subscribe for "sip:[email-masked]" and retargets it to 
"sip:[email-masked]" then the pbx processes the subscription based on the 
R-URI.

But note I just replied to your other mail in way that may make this moot.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 19:59:37 +0200

Hi,

IF the SUBSCRIBE was to be forwarded to the PBX, there are a few things that need to be considered.

Q1. How does the SSP know whether the PBX will be able to process the SUBSCRIBE in the first place? 

Yes, the SSP may have sent Allow: SUBSCRIBE, and it may have indicated support of the reg-event package, but that still doesn't mean it will support RECEIVING a subscription.

And, this again comes down to the question: what SIP role does the PBX represent in the first place? I think that is something that needs to be described in the draft. 

For example, there is a section called "PBX behavior". But, there is no SIP role called "PBX", as little as there is a SIP role called "B2BUA" etc.

Q2. Is there a trust issue? The notification sent from the PBX will most likely not be asserted by the SSP, or anyone else.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Tuesday, May 25, 2010 5:31 PM
To: Hadriel Kaplan
Cc: Bernard Aboba; [email-masked]
Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 20:00:08 +0200

The PBX may have sent Allow: SUBSCRIBE, that is...

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]
Sent: Tuesday, May 25, 2010 8:59 PM
To: Paul Kyzivat; Hadriel Kaplan
Cc: Bernard Aboba; [email-masked]
Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package

Hi,

Regards,

Christer

        Thanks,
        Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 27 May 2010 00:49:00 +0200

On Tue, May 25, 2010 at 4:31 PM, Paul Kyzivat <[email-masked]> wrote:
> IIUC its most likely that we have "sip:[email-masked]" defined on the ssp,
> but the terminals are registering with "sip:[email-masked]".
>

Yes, the consequence of taking GIN. End users register with another
AOR then they have to give their relations to be reached by.

/Hans Erik van Elburg