Subject: [Sipping] Does 'isfocus' indicate capability or behavior?

From: Aki Niemi <[email-masked]>
Date: Fri, 28 Jan 2005 10:00:59 +0200

Hi,

I recently encountered a problem related to conferencing, and more 
specifically to the use of the isfocus callee capability.

Currently, I believe the 'isfocus' callee capability tells the other end 
that the UA is a focus and will mix together all calls made to that 
contact URI. But does the absence of 'isfocus' indicate the opposite? 
This is where I think there is some ambiguity, i.e., does it indicate 
*capability* or currently active *behavior* only.

The problem is that a UA receiving an invitation should be able to 
determine whether the invitation is to a conference, or to a one-to-one 
call. I can imagine the pop-up window being different for each case, 
maybe even the UA software client. This determination is probably meant 
to be based on the 'isfocus', and whether it is true or false.

On the other hand, since 'isfocus' is a callee capability, it could be 
interpreted to mean that the UA can act as a focus, but isn't doing so 
at the moment. Meaning a focus-capable UA would include it in all INVITEs.

Or do we need a new callee-cap for that, named 'mayfocus'? Or instead of 
binary have the 'isfocus' callee capability have three states, {active, 
inactive, false}?

Cheers,
Aki

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jan 2005 09:00:15 -0500

> at the moment. Meaning a focus-capable UA would include it in all INVITEs.

I believe this means it is currently a focus. There are examples showing 
a dialog with a phone (no isfocus), and then a Join, after which the 
phone switches to a Contact with the isfocus parameter. This might still 
be on the phone.

However, I don't know how much value you can derive from that. You could 
be in a "conference" where there is only one other participant. And you 
could be in a conference that doesn't support floor control, or CPCP. I 
*think* there is a presumption that a contact with isfocus would support 
subscriptions to the conference event package. But of course you could 
be denied access to that.

I think probably you should consider the parameter as an indicator that 
you should try to subscribe to the conference event package. If that 
succeeds, then you can assume you are in a conference and can put up 
your special UI. If the parameter is absent, or you can't successfully 
subscribe to the event package, then just consider this to be a regular 
call.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Fri, 28 Jan 2005 17:02:12 +0200

ext Paul Kyzivat wrote:
...snip...

> subscribe to the event package, then just consider this to be a regular 

 From the user perspective, this is a bit too late. The user needs to 
know whether they are accepting a conference call or a regular call. And 
it would be useful to know that a regular call can be upgraded into a 
conference.

I'll also note that there are other callee capabilities (sip.events 
specifically) that inform of the capability to accept conference event 
subscriptions.

That said, this still leaves me wanting a way to distinguish between the 
capability and the characteristic in terms of a particular UA being a 
conference focus.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jan 2005 11:08:40 -0500

Aki Niemi wrote:
> 
> 
> ext Paul Kyzivat wrote:
> ...snip...
> 
>> I think probably you should consider the parameter as an indicator 
>> that you should try to subscribe to the conference event package. If 
>> that succeeds, then you can assume you are in a conference and can put 
>> up your special UI. If the parameter is absent, or you can't 
>> successfully subscribe to the event package, then just consider this 
>> to be a regular call.
> 
> 
> know whether they are accepting a conference call or a regular call.

Why does that matter?

You could indicate probable conference if the isfocus parameter is 
present, which may be enough for this purpose.

Or you could try subscribing to the event package even before answering 
the call.

> And 

That is a whole different question, that is probably hard to answer. If 
I just call you, my phone may provide me with the capability to upgrade 
to a conference. But that doesn't necessarily mean that *you* can cause 
my phone to upgrade this call to a conference. And I'm not expecially 
interested in telling you that I have the capability.

As I recall, part of the concept behind isfocus was that you would then 
be able to know if the call was upgraded to a conference in the middle 
of the call.

> specifically) that inform of the capability to accept conference event 

True.

> capability and the characteristic in terms of a particular UA being a 

So you want to know if the other party would accept an INVITE/Join to 
this dialog? Or do you have something else in mind?

Are you really thinking about this in relation to regular UAs (e.g. 
phones), or something special, like a conference bridge, that in some 
cases (e.g. PTT) might be used for two party calls as well?

If you are concerned with a conf bridge, then it seems simpler to expect 
it to report isfocus all the time, even for two party calls.

	Paul