Subject: RE: [Sipping] Conferencing for UAs

From: [email-masked]
Date: Tue, 24 Feb 2004 16:00:03 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Gonzalo Camarillo
> Sent: 24.February.2004 14:06
> To: sipping
> Cc: Alan Johnston; Orit Levin; Garcia Miguel.An (Nokia-NRC/Helsinki)
> Subject: [Sipping] Conferencing for UAs
> 
> 
> 
> Hello,
> 
> some comments on the following draft:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conf
> erencing-03.txt
> 
> The focus of a conference returns the conference URI in the contact 
> header field of the 200 OK for the INVITE. The UAC uses this URI to 
> SUBSCRIBE to the conf package (using a new dialog)...
> 
> Why are we forcing the focus to use the same URI for receiving the 
> INVITEs from all the users and for receiving the SUBSCRIBEs? 
> I believe 
> the solution would be cleaner if we defined a new header field (e.g., 
> Associated-Conf-State) that carried a globally routable URI. 
> The 200 OK 
> for the initial INVITE (or the INVITE in a dial-out case) would carry 
> this header field. This would keep separate the URI used for 
> joining the 
> conference and the URI used for subscribing to the state of 
> the conference.

I don't see what the problem is here and why it is a problem? Why do they need to be separate. Both the INVITEs and SUBSCRIBEs are destined to the same resource.

You have a resource (in this case a conference ID). You invite yourself to that resource. You also subscribe to that resource, using the same URI. Note that the Request-URI on the SUBSCRIBE request carries the resource you are subscribing to.

/Hisham

> 
> This is actually the approach that the draft below follows:
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-tr
> ansac-package-00.txt
> 
> We define the Associated-Transactions-State to be returned, 
> for example, 
> in the 200 OK of a MESSAGE sent to an exploder. Note that we had to 
> create this new header because MESSAGE does not carry a Contact 
> header... following the same approach in both, the 
> conferencing work and 
> the exploders work would be good, in my opinion.
> 
> Comments?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 24 Feb 2004 16:26:10 +0200

Hello,

> I don't see what the problem is here and why it is a problem? Why do
> they need to be separate. Both the INVITEs and SUBSCRIBEs are
> destined to the same resource.

You send an INVITE to a conference server that will INVITE the rest of 
the participants in the conference. This INVITE is creating:

1) a dialog
2) an INVITE explosion
3) a conference

I find it cleaner to have three separate URIs instead of a single URI 
where the server figures out what the UAC is trying to do by looking at 
the contents of the request (in this case, the event header).

In addition, the application server handling the presence for the 
conference may not be co-located with the entity handling the SIP 
signalling for the conference.

Furthermore, when you deal with requests that do not establish a dialog 
(e.g., MESSAGE), the server needs to convey the URI of the resource to 
the UAC using a different mechanism (Contact is not allowed). It would 
be good to use the same mechanism for requests that create a dialog and 
for requests that do not create a dialog. This avoids overloading the 
Contact header field.

I believe that having something like this:

Associated-Resource: sip:[email-masked];purpose=conference-state
Associated-Resource: sip:[email-masked];purpose=explosion-state

makes it easier for the UAC to know what can be done; it is more explicit.

Gonzalo

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Alan Johnston <[email-masked]>
Date: Tue, 24 Feb 2004 08:49:05 -0600

At 04:26 PM 2/24/2004 +0200, Gonzalo Camarillo wrote:
>You send an INVITE to a conference server that will INVITE the rest of the 
>participants in the conference. This INVITE is creating:
>
>1) a dialog
>2) an INVITE explosion
>3) a conference

No - this is the problem.  You are looking at your single narrow 
application.  Conferencing is a very broad application, and we have 
developed a very general framework and set of primitives.  It is a mistake 
to invent a whole new set to fit a single application, or change our 
framework to fit your application.

Sending an INVITE creates a dialog.  Period.  Everything else that happens, 
happens because of properties (we call it policy) of the URI.  Your 
application (conference policy of a URI) may cause a conference (called a 
focus) to be created, and an INVITE explosion (called a dial out 
participant list).

>(e.g., MESSAGE), the server needs to convey the URI of the resource to the 
>UAC using a different mechanism (Contact is not allowed). It would be good 
>to use the same mechanism for requests that create a dialog and for 
>requests that do not create a dialog. This avoids overloading the Contact 
>header field.
>

No.  There is policy related to the conference URI.  Not an endless set of 
Associated-Something header fields that try to describe a set of 
application specific information.  And we need general mechanisms to find 
out and modify the policy associated with that URI.  This the work being 
done in XCON.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

>This communication is confidential and intended solely for the 
>addressee(s). Any unauthorized review, use, disclosure or distribution is 
>prohibited. If you believe this message has been sent to you in error, 
>please notify the sender by replying to this transmission and delete the 
>message without disclosing it. Thank you.
>
>E-mail including attachments is susceptible to data corruption, 
>interruption, unauthorized amendment, tampering and viruses, and we only 
>send and receive e-mails on the basis that we are not liable for any such 
>corruption, interception, amendment, tampering or viruses or any 
>consequences thereof.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 12:47:22 -0500

>> destined to the same resource.

I agree.

> the participants in the conference. This INVITE is creating:

You just jumped to the most complex of cases that combines a bunch of 
things. Not every invite to a focus generates an invite explosion.

As I see it, I send an INVITE to the address of some entity that I want 
to talk to. Sometimes it turns out to be a conference focus, sometimes 
not. Either way I am communicating with that entity.

If I want to know more about that entity than I get by virtue of my 
invitation, I send some other request to the address of that entity, 
defined by the remote contact address of my dialog. I could send OPTIONS 
for some info. Or I can send SUBSCRIBE if I want to request event updates.

Taken to extreme, what you suggest would lead to a different address for 
OPTIONS, for MESSAGE, for PUBLISH, for REGISTER, etc. And maybe 
different addresses for each kind of subscription.

I don't want to go there.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 Feb 2004 09:47:26 +0200

Hi Alan,

I understand that my comments come late in the game and that it might be 
impossible to change the conferencing framework at this point. In any 
event, I do not agree with your statement below:

> application.

I believe I am actually looking at a much wider range of applications 
than just conferencing. So, to me, the problem is that the conferencing 
framework is too focused on a "single narrow application"; conferencing.

In a conferencing service, there is a single resource created by the 
initial INVITE; a conference. That's why the server can use the Contact 
header field to send it back to the UAC. If you think of services that 
create more than one resource (e.g., an explosion and a conference), the 
server may not want to use the same URI for both. Moreover, 
conceptually, is is not a good thing to use the same URI to identify 
both resources.

So, my main concern is the semantics overload of the Contact header. (We 
abused this header when design REGISTER as well, by the way. That's why 
I do not want to do it again.)

In my opinion, the Contact header is the URI where you send subsequent 
requests within the dialog. If the server wants to tell the client that 
a resource (e.g., a conference) has been created, it can use a different 
header to include the URI of such a resource. Note that, if you want 
both URIs to be the same (like in the conferencing case), you can do it.

Contact: sip:[email-masked];isfocus
Resource: sip:[email-masked];isfocus

An entity receiving these headers would use the URI in the Contact 
header to send subsequent requests *within* the dialog, and the URI in 
the other header to send requests *outside* that dialog (e.g., SUBSCRIBE 
to the conference package).

In brief, instead of sticking the conference URI in a Contact header and 
label that URI with an isfocus parameter so that the UAC figures what is 
going on, I find it more explicit to use a different header. Although, 
as I said, I understand that this comment comes late and that may not be 
useful at this point.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 Feb 2004 12:20:09 +0200

Hi,

as an additional note, the following draft
http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00

proposes to carry a policy URI for the conference in a Call-Info 
header... what I am proposing is a more general mechanism that can carry 
all the URIs of the resources created by a request.

Otherwise, we would place the policy URI in the call-info header, the 
explosion URI in the associated-explosion header, the conference URI in 
the contact header, etc, etc... I want a cleaner way (e.g., a single 
header) to provide the URIs of the resources associated to a request.

Associated-Resource: sip:[email-masked];purpose=conference-state
Associated-Resource: sip:[email-masked];purpose=explosion-state
Associated-Resource: sip:[email-masked];purpose=conference-policy

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Feb 2004 10:09:19 -0500

Bonzalo,

I am *slightly* warming to your point, but I am concerned that there is 
a slippery slope here and it will require a great deal of care to avoid 
heading down that slope.

I agree that policy URI for conferences is an analogous kind of usage. 
I'm not yet convinced that such an approach should be used often, or 
that we need a more general way to return such things. For cases where 
it is appropriate, call-info may be a sufficient mechanism.

I am definitely not convinced that we need separate URIs for requests 
within a dialog and outside of one. We are concurrently working on the 
GRUU proposal with the intent that we can use the same URI for both.

Nor am I convinced that we need separate URIs for INVITE and SUBSCRIBE, 
when the logical resource is the same for both. (E.g. join a conference 
vs request info (via sip) for the same conference.)

The key is determining when things are truly distinct resources. One 
hint is that they are addressed with different protocols. That is one 
justification for separating conference policy from conference focus.

Operations that do too much at once (e.g. create multiple distinct 
resources) raise a red flag for me - they aren't necessarily wrong, but 
they require extra consideration because they are inclined to be complex 
to understand. So hopefully there won't be many requests that need to 
reference multiple "output" resources.

	Paul

Gonzalo Camarillo wrote:
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
> 
> send and receive e-mails on the basis that we are not liable for any 
> such corruption, interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 Feb 2004 17:41:21 +0200

Paul,

I believe we are in agreement. You use different URIs for different 
resources. Additionally, it is not wise to overload too much a request 
so that it creates too many resources. We agree on these two points.

In any event, an INVITE that creates a conference, an explosion, and a 
policy URI is not such a strange example. Another example that covers 
what you said about different protocols would be an INVITE that, in 
addition to creating a conference (identified by a SIP URI), creates a 
mailing list for the conference (indentified by a mailto: URI).

In addition, the mechanism used to convery the URIs of these resources 
to the UAC should not be INVITE specific, because requests such as 
MESSAGE can also trigger the creation of new resources (e.g., a 
explosion of MESSAGEs).

Thanks,

Gonzalo

Paul Kyzivat wrote:

>> header... what I am proposing is a more general mechanism that can 
>> carry all the URIs of the resources created by a request.
>>
>> explosion URI in the associated-explosion header, the conference URI 
>> in the contact header, etc, etc... I want a cleaner way (e.g., a 
>> single header) to provide the URIs of the resources associated to a 
>> request.
>>
>> interruption, unauthorized amendment, tampering and viruses, and we 
>> only send and receive e-mails on the basis that we are not liable for 
>> any such corruption, interception, amendment, tampering or viruses or 
>> any consequences thereof.
>>
>>

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Feb 2004 09:44:18 -0600

At 09:47 AM 2/25/2004 +0200, Gonzalo Camarillo wrote:
>>No - this is the problem.  You are looking at your single narrow application.
>
>I believe I am actually looking at a much wider range of applications than 
>just conferencing. So, to me, the problem is that the conferencing 

Gonzalo,

If you are saying that some of your exploder services do not have a 
conferencing component, then I agree.  Some of the exploder services seem 
to just be a "request to fork" to a set of URIs.  Others definitely have 
conferencing semantics.  The ones with conferencing semantics, I believe, 
can be, and should be modeled using the conferencing framework.

The problem is that each method seems to have a different set of semantics 
as to what exploding that method means - INVITE is handled differently from 
SUBSCRIBE, from MESSAGE.   From a high level, exploders may seem to be a 
consistent set of services.  However, as I delve into the details and think 
about call flows (something  absent from any of the exploder drafts), a 
different story emerges.

I think we need to explore exactly the services and call flows that are 
being envisioned for exploders before proposing major changes to our 
conferencing framework, which I believe is well understood and documented.

>server may not want to use the same URI for both. Moreover, conceptually, 
>is is not a good thing to use the same URI to identify both resources.

As Paul has pointed out - they are the same resource.  Additionally, it is 
a trivial SIP routing issue to fix this - many proxies do method-based 
request routing - that would completely solve your problem of sending 
SUBSCRIBEs to a different UA than the initial request.

>abused this header when design REGISTER as well, by the way. That's why I 
>do not want to do it again.)
>
>requests within the dialog. If the server wants to tell the client that a 
>resource (e.g., a conference) has been created, it can use a different 
>header to include the URI of such a resource. Note that, if you want both 
>URIs to be the same (like in the conferencing case), you can do it.
>
>An entity receiving these headers would use the URI in the Contact header 
>to send subsequent requests *within* the dialog, and the URI in the other 
>header to send requests *outside* that dialog (e.g., SUBSCRIBE to the 
>conference package).

No.  A GRUU should be used in the Contact, and its routing is valid outside 
the dialog.

>going on, I find it more explicit to use a different header. Although, as 
>I said, I understand that this comment comes late and that may not be 
>useful at this point.

I think much more work is needed before the working group can evaluate the 
exploders work and see how and if it fits in with existing concepts and 
approaches.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2004 14:13:01 +0200

Alan,

I agree with you that we do not want to change the conferencing 
framework at this point in time (I already said in my previous mail that 
I understood that my comments related to this came too late). Still, I 
found the discussion useful to understand your point of view.

In any event, the topic I am interested in is the creation of different 
resources (identified by URIs) by a single request. In particular, how 
to communicate those URIs to the UAC. (I sent separate comments on 
Hisham's draft.)

I hope we can discuss these issues in Korea.

Thanks,

Gonzalo

Alan Johnston wrote:

>> I understand that my comments come late in the game and that it might 
>> be impossible to change the conferencing framework at this point. In 
>> any event, I do not agree with your statement below:
>>
>> than just conferencing. So, to me, the problem is that the 
>> conferencing framework is too focused on a "single narrow 
>> application"; conferencing.
> 
> 
> Gonzalo,
> 
> conferencing component, then I agree.  Some of the exploder services 
> seem to just be a "request to fork" to a set of URIs.  Others definitely 
> have conferencing semantics.  The ones with conferencing semantics, I 
> believe, can be, and should be modeled using the conferencing framework.
> 
> The problem is that each method seems to have a different set of 
> semantics as to what exploding that method means - INVITE is handled 
> differently from SUBSCRIBE, from MESSAGE.   From a high level, exploders 
> may seem to be a consistent set of services.  However, as I delve into 
> the details and think about call flows (something  absent from any of 
> the exploder drafts), a different story emerges.
> 
>> initial INVITE; a conference. That's why the server can use the 
>> Contact header field to send it back to the UAC. If you think of 
>> services that create more than one resource (e.g., an explosion and a 
>> conference), the server may not want to use the same URI for both. 
>> Moreover, conceptually, is is not a good thing to use the same URI to 
>> identify both resources.
> 
> 
> As Paul has pointed out - they are the same resource.  Additionally, it 
> is a trivial SIP routing issue to fix this - many proxies do 
> method-based request routing - that would completely solve your problem 
> of sending SUBSCRIBEs to a different UA than the initial request.
> 
>> So, my main concern is the semantics overload of the Contact header. 
>> (We abused this header when design REGISTER as well, by the way. 
>> That's why I do not want to do it again.)
>>
>> requests within the dialog. If the server wants to tell the client 
>> that a resource (e.g., a conference) has been created, it can use a 
>> different header to include the URI of such a resource. Note that, if 
>> you want both URIs to be the same (like in the conferencing case), you 
>> can do it.
>>
>> the other header to send requests *outside* that dialog (e.g., 
>> SUBSCRIBE to the conference package).
> 
> 
> No.  A GRUU should be used in the Contact, and its routing is valid 
> outside the dialog.
> 
> 
>> In brief, instead of sticking the conference URI in a Contact header 
>> and label that URI with an isfocus parameter so that the UAC figures 
>> what is going on, I find it more explicit to use a different header. 
>> Although, as I said, I understand that this comment comes late and 
>> that may not be useful at this point.
> 
> 
> I think much more work is needed before the working group can evaluate 
> the exploders work and see how and if it fits in with existing concepts 
> and approaches.
> 
> Thanks,
> Alan Johnston
> MCI
> sip:[email-masked]
> 
>> Thanks,
>>
>> Gonzalo
>>
>>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 26 Feb 2004 13:04:56 -0600

At 02:13 PM 2/26/2004 +0200, Gonzalo Camarillo wrote:
>Alan,
>
>I agree with you that we do not want to change the conferencing framework 
>at this point in time (I already said in my previous mail that I 
>understood that my comments related to this came too late). Still, I found 
>the discussion useful to understand your point of view.

Gonzalo,

Glad to hear that.  I'd be happy to think about how to extend the 
conferencing work to cover the exploder scenarios you are proposing with 
MESSAGE, INVITE, and even REFER.    With the current drafts, I have a hard 
time understanding how to do this, but I look forward to 
clarifications.   The SUBSCRIBE exploder does not seem to have any 
conferencing semantics, but seems to be a SIMPLE application since it is 
tightly coupled to the presence application.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

>resources (identified by URIs) by a single request. In particular, how to 
>communicate those URIs to the UAC. (I sent separate comments on Hisham's 
>draft.)
>
>>the details and think about call flows (something  absent from any of the 
>>exploder drafts), a different story emerges.
>>is a trivial SIP routing issue to fix this - many proxies do method-based