Subject: [Sipping] Application identification with callee caps/caller preferences (Was SIP)

From: Dean Willis <[email-masked]>
Date: Wed, 28 Apr 2004 08:05:44 -0500

Moving to SIPPING, because that's where this belongs.

Following up on a previous thread:

Paul Kyzivat wrote:

 > Dean Willis wrote
>> Of course, I'm still deeply confused between:
>> 1) preference/capability negotiation enabled by offer/answer
>> 2) preference/capability negotiation enabled by callee-caps/caller-pref.
> 
> Forking and offer/answer provide a partial solution. But offer/answer 
> doesn't give you a way to say you don't want the call unless your 
> offered media are accepted. At least not an easy way. Conceivably some 
> new extension to preconditions could be made to handle this kind of 
> thing. Lacking that you run the risk of having an unsuitable device 
> answer, even if there is a suitable device present.
> 
> Callerprefs gives you an increased likelihood that you will end up with 
> a suitable device.

The above is a "good start".

One of the challenges I'm faced with regularly is helping SIP-using 
designers decide what to negotiate with O/A and what to negotiate with 
prefs/caps.

Someone even asked me yesterday why we don't just do everything with 
prefs/caps and deprecate O/A.

So, if somebody out there is looking for a meaningful task, it might be 
reasonable to undertake a clear explanation of the relationship and 
usage of these related mechanisms. Perhaps we should see what kind of 
consensus we have here on the list . . .

Here's a debate to consider: Let's say I want to make a voice 
push-to-talk call to somebody. This means I'm wanting to use 
push-to-talk behavior, and negotiate a floor control protocol and voice 
codec to be used within the call.

We seem to have consensus that the voice codec, port numbers, and IP 
addresses involved are to be described in SDP and negotiated in O/A 
mode. That's "traditional SIP".

How about the floor control protocol to use? Prefs/Caps or O/A? My 
personal guess is that this is O/A.

And here's the hard one -- Is the desire for push-to-talk behavior 
something that should be expressed as caller preferences and matched by 
the routing function to a termination whose callee-caps indicate 
compatibility, or is it something that should be described in an SDP 
offer/answer? Or something else entirely?

--
Dean

_______________________________________________
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: David Oran <[email-masked]>
Date: Wed, 28 Apr 2004 11:33:13 -0400

--On Wednesday, April 28, 2004 8:05 AM -0500 Dean Willis 
<[email-masked]> wrote:

[snip]
> push-to-talk call to somebody. This means I'm wanting to use push-to-talk
> behavior, and negotiate a floor control protocol and voice codec to be
> used within the call.
>
> addresses involved are to be described in SDP and negotiated in O/A mode.
> That's "traditional SIP".
>
and traditional everything else multimedia as well...

> personal guess is that this is O/A.
I'd say O/A as well, since for me the dividing line is:
- am I singaling WHAT media I want to do or can do: Callerprefs/calleecaps
- am I signaling HOW I can do it (codec, protocol, etc.): O/A

So, I guess I'd express the need to a cnference with floor control through 
callerprefs and negotiate the floor control protocol and parameters thereof 
with O/A.

> offer/answer? Or something else entirely?
What exactly is "push-to-talk" as an application? Is it a half-duplex 
session? If so, I suspect I'd signal that I want a half-duplex session in 
the prefs/caps. Whether push-to-talk is just a form of floor control is, I 
think, the interesting design question.

Dave.

---

From: Alan Johnston <[email-masked]>
Date: Wed, 28 Apr 2004 11:34:57 -0500

At 11:33 AM 4/28/2004 -0400, David Oran wrote:

>callerprefs and negotiate the floor control protocol and parameters 
>thereof with O/A.

It depends.

SIP is often used to establish multimedia sessions, which result in RTP 
flows.  If the floor control "session" is established using SIP, then O/A 
applies.

However, if floor control is not established through SIP but is a parallel 
control stream, then what is needed is a conference focus that supports the 
required floor control protocol, and an ability for the focus to provide a 
URI to the user to establish this separate channel.

In this case, then a Require/420 exchange is appropriate.

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

---

From: David Oran <[email-masked]>
Date: Wed, 28 Apr 2004 12:49:53 -0400

[snip]
>> So, I guess I'd express the need to a cnference with floor control
>> through  callerprefs and negotiate the floor control protocol and
>> parameters  thereof with O/A.
>
> It depends.
>
Sure. I agree.

> However, if floor control is not established through SIP but is a
> parallel control stream, then what is needed is a conference focus that
> supports the required floor control protocol, and an ability for the
> focus to provide a URI to the user to establish this separate channel.
>
Yes, I agree.

> In this case, then a Require/420 exchange is appropriate.
It seems that if the two protocols are "parallel" then I'm not sure SIP 
should have any say on how the state synchronization is done. Using 
requires/420 is one possibility, of course, an alternative might be using 
SDP preconditions.

Dave.

>> session? If so, I suspect I'd signal that I want a half-duplex session
>> in  the prefs/caps. Whether push-to-talk is just a form of floor control
>> is, I  think, the interesting design question.
>>
>> Dave.
>>
>>> --
>>> Dean
>>>
>>>
>>>
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Apr 2004 14:14:59 -0400

Dean Willis wrote:
>> Callerprefs gives you an increased likelihood that you will end up 
>> with a suitable device.
> 
> 

Well, that would be silly. Prefs/caps don't provide sufficient detail to 
establish a media session.

Clearly prefs/caps is the way to go for things that aren't expressed at 
all in O/A - things that don't have to do with the media streams themselves.

There is an area of overlap around media-related things. IMO it would be 
better to enhance O/A to cover those cases. For instance, saying "I only 
want a session if I can have both audio and video", or "I want an audio 
session but I'm not yet prepared to tell you where to send it - please 
respond, if you can, with an audio offer".

This sort of thing *could* be done with preconditions. But there seems 
to be a (justifiable) reluctance to invent new uses for preconditions. 
(Or even to use the existing ones.)

Prefs/caps provides *some" of this functionality using what is perceived 
to be a lighter weight mechanism. In the absence of something better, it 
is reasonable to use it.

> consensus we have here on the list . . .

Does the above help?

> personal guess is that this is O/A.

I need to know more about how the floor control is intended to work 
before I would begin to answer this.

> offer/answer? Or something else entirely?

I don't think this can be done entirely with O/A if you really require 
the push-to-talk behavior, at least for any plausible definition of 
push-to-talk that I can imagine. I think anything you might offer would 
be answered by a regular sip phone, ignoring/refusing the push-to-talk 
features.

	Paul