Subject: RE: [Sipping] Service Identification in SIP - Routing decissionsbased on Require/P-R

From: Jeroen van Bemmel <[email-masked]>
Date: Sat, 24 Feb 2007 00:40:08 +0100

Paul,
The model realized in IMS is perhaps more accurately described as a UAC selecting a UAS with a specific intent (e.g. PoC), that UAS in turn acting as a UAC to select an appropriate UAS (still for PoC, on behalf of the initiating UAC) and finally that second UAS acting again as UAC to select a target UAS (device) which supports PoC

If you have a device and I have one, we can try to setup a session and negotiate the least common denominator as features. The PoC use case is more about selecting an appropriate next hop from a heterogeneous set of many (times 3)

Considering PoC as a capability / feature is confusing, I'll argue that from a user perspective it is more "I want to PoC with X" as opposed to "I want to communicate with X and I'll use whatever matching capabilities our devices support". It is about user intent, which appears difficult to capture in a generic INVITE. Perhaps a new method "PoC"?

Regards,
Jeroen

-----Oorspronkelijk bericht -----
Van: "Paul Kyzivat" <[email-masked]>
Aan: "Paul Kyzivat" <[email-masked]>
CC: [email-masked]; "Christer Holmberg (JO/LMF)" <[email-masked]>
Verzonden: 23-2-07 15:45
Onderwerp: Re: [Sipping] Service Identification in SIP - Routing decissionsbased	on Require/P-R

Some further thoughts on this subject:

Typically, some of the capabilities used in a call are *negotiated* 
between the caller and the callee. As a result, those that will be used 
are not known for certain at the time the request is sent. And the 
results of that negotiation may differ depending on which of various 
candidate targets is selected.

Apparently one key intended use of the service id is to bring in one or 
more intermediate nodes that are specific to the capabilities that will 
be used in the call. These intermediate nodes must be selected *before* 
the UAS is selected and the negotiation is done. For that to work, one 
of two things must happen:

- the proxy that selects those intermediate nodes
   must be prescient about what capabilities will be negotiated

- or the selection of UAS and the negotiation of capabilities to be
   used must be somehow constrained to be consistent with the
   capabilities supported by the selected intermediate nodes.

If we agree that prescience is infeasible, I guess we must assume that 
the selection and negotiation will be constrained. We of course have a 
mechanism for that: it is the Require header. There are also other 
mechanisms that provide constraints of some sort. For instance the SDP 
offer constrains what is permitted in the answer. (It does *not* however 

_______________________________________________
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, 23 Feb 2007 21:18:08 -0500

Jeroen van Bemmel wrote:
> Paul,
> The model realized in IMS is perhaps more accurately described
> as a UAC selecting a UAS with a specific intent (e.g. PoC),
> that UAS in turn acting as a UAC to select an appropriate UAS
> (still for PoC, on behalf of the initiating UAC) and finally
> that second UAS acting again as UAC to select a target UAS (device)
> which supports PoC

I disagree. The originating UAC inserts an address identifying the 
terminating AOR. So the originating UAC is not selecting the originating 
PoC server.

If one of the proposals in jonathan's draft (inserting a Route header 
with a URN for a PoC server) then I would agree that the originating UAC 
as selecting both the originating PoC server and the target AOR.

I  also don't see that the originating PoC server is doing anything 
about selecting either a terminating PoC server or the final terminating 
UAS. It is just leaving criteria as they were set by the originating UAC.

Its unclear to me whether the originating UAC and/or the terminating PoC 
server is the primary influence over which terminating UAS is selected, 
and the flip side of that is also unclear - whether the originating UAC 
is selecting the terminating PoC server. To determine that, we would 
need to examine some non-trivial use cases.

Consider a case where there are two different UAs both registered to the 
same AOR, as well as another UA that doesn't support PoC. Then some 
other UAC calls this AoR. It could potentially select among the 
registered UAs using callerprefs. (IMS even specifies that the 
terminating S-CSCF shoujld apply callerprefs.) If a terminating PoC 
server is brought in, AFAIK it leaves the callerprefs alone, so that the 
terminating UAS is still selected via criteria provided by the 
originating UAC.

I do think it would be good if things were arranged so that it *did* 
work as you suggest. But I think that will require some different 
mechanisms.

> If you have a device and I have one, we can try to setup a
> session and negotiate the least common denominator as features.
> The PoC use case is more about selecting an appropriate next hop
> from a heterogeneous set of many (times 3)

If that is the purpose of the service id, then it has not been very well 
explained. This call model is very strange - pretty far from anything 
sip was designed for. If this is the goal, its going to take more work 
to figure out if/how to accomplish it.

> Considering PoC as a capability / feature is confusing, I'll argue
> that from a user perspective it is more "I want to PoC with X" as
> opposed to "I want to communicate with X and I'll use whatever
> matching capabilities our devices support". It is about user intent,
> which appears difficult to capture in a generic INVITE. Perhaps a
> new method "PoC"?

I think this could be achieved as follows:

- each UA that wants to receive PoC calls establishes a relationship
   with a PoC server that will be supporting it. (TBD how this is
   done.) The PoC server registers with the AoR on behalf of the UA.
   If there are any capabilities that the UA wants advertised, then
   the PoC server provides them in its registration. PoC would be
   advertised as one of the capabilities.
   (If there are multiple UAs that do PoC, then each will have an
   association with a PoC server and there will be a registration
   for each.)

- incoming calls to the AoR simply consider the registered PoC server
   as one of the registered contacts. Selection among those contacts
   is normal. There could be forking to all. Or callerprefs could be
   used to select a contact that supports PoC, or non-PoC.

- for originating PoC calls, the UA could include a Route header that
   sends the request first to its associated PoC server. And it could
   include callerprefs to select PoC at the termination.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 25 Feb 2007 15:15:05 +0100

Paul,

My points are that:
a) this is not a proxy selection problem, but a UAS selection problem (and 
mechanisms for proxy selection are lacking, see outbound discussions)
b) this is not a single selection problem, but three distinct cases. Most 
likely a single mechanism will not cover all of these

I understand the PoC issue as follows: when compared to a regular voice 
call, signaling for PoC uses
- the same request method (INVITE)
- the same mime type (SDP)
- the same media (audio)

As a result, there is currently no way to configure the initial filter 
criteria such that PoC signaling goes to one (PoC) UAS, and regular voice 
calls goes to another (voice) UAS. (the separation is due to deployed 
legacy, we can keep argueing this model but this is the starting point for 
IMS systems).

The 3GPP requirement should state "we need a way to distinguish between 
voice calls and PoC calls". Instead, they went one step further and state 
"we need a service identifier".

There is an additional, implicit 3GPP requirement that the chosen solution 
should be consistent with the current IMS architecture. That means that a 
Route header based solution (e.g. service URN) is not acceptable: there is 
already a mechanism for next hop selection (IFC), adding pre-loaded route 
headers would introduce a second mechanism. A similar argument applies to 
the mechanisms you are proposing below (registration with PoC server): this 
would be too different from the current mechanisms / architecture

And then there is a third requirement, apparent from the proposed solution: 
the solution should be generic enough such that it can also be used in other 
cases besides PoC. Possibly also the lengthy process of developing a 
standards track specification for each case is seen as a hurdle.

>From IETF side the requirement is also that the solution should be 
consistent with the current SIP architecture (as defined in the various 
RFCs). This means that if there is an existing, standardized mechanism that 
can solve this problem, that would be preferrable over a new mechanism / 
header (service identifier).

A second argument from IETF side, is that (a) the IETF does not standardize 
services and (b) people view this model of separating things into arbitrary 
services as "evil". Perhaps if we consider PoC as a voice call that requires 
"floor-control", similar to a voice call that would use "session-timer" or 
other features, we can mitigate this issue. There will probably always 
remain people who don't agree here, but assuming our goal is to come to a 
solution, the question is now: can current mechanisms solve the PoC case?

I believe the answer is YES, using a combination of caller prefs and 
Require, as follows:
1 - for originating UAS: IFC are configured to select UAS based on presence 
of "Require: floor-control"
2 - for terminating UAS: same
3 - for end-point selection: use callerprefs with an implicit preference for 
support of floor-control (derived from the Require header)

Alternative for (3) is to use explicit preferences instead. What may be 
confusing some people is the use of the word "preferences" in the name of 
the mechanism (it sounds optional, "nice to have", whereas PoC is 
intentional, "required"). I believe that the combination of callerprefs + 
Require does give the desired semantics and results.

Added benefit (though perhaps not initially/first concern for 3GPP) is that 
this also takes care of the case where a PoC request ends up at a UAS that 
does not support it.

Regards,
Jeroen

Paul Kyzivat wrote:
> terminating AOR. So the originating UAC is not selecting the
> originating PoC server.
>
> with a URN for a PoC server) then I would agree that the originating
> UAC as selecting both the originating PoC server and the target AOR.
>
> about selecting either a terminating PoC server or the final
> terminating UAS. It is just leaving criteria as they were set by the
> originating UAC.
> Its unclear to me whether the originating UAC and/or the terminating
> PoC server is the primary influence over which terminating UAS is
> selected, and the flip side of that is also unclear - whether the
> originating UAC is selecting the terminating PoC server. To determine
> that, we would need to examine some non-trivial use cases.
>
> Consider a case where there are two different UAs both registered to
> the same AOR, as well as another UA that doesn't support PoC. Then
> some other UAC calls this AoR. It could potentially select among the
> server is brought in, AFAIK it leaves the callerprefs alone, so that
> the terminating UAS is still selected via criteria provided by the
> originating UAC.
>
> If that is the purpose of the service id, then it has not been very
> well explained. This call model is very strange - pretty far from
> anything sip was designed for. If this is the goal, its going to take
> more work to figure out if/how to accomplish it.
>
>> CC: [email-masked]; "Christer Holmberg (JO/LMF)"
>> <[email-masked]> Verzonden: 23-2-07 15:45
>> Onderwerp: Re: [Sipping] Service Identification in SIP - Routing
>> decissionsbased on Require/P-R Some further thoughts on this subject:
>>
>> between the caller and the callee. As a result, those that will be
>> used are not known for certain at the time the request is sent. And the
>> Apparently one key intended use of the service id is to bring in one
>> or more intermediate nodes that are specific to the capabilities that
>> will be used in the call. These intermediate nodes must be selected
>> *before* the UAS is selected and the negotiation is done. For that to 
>> work,
>> one of two things must happen:
>>
>> If we agree that prescience is infeasible, I guess we must assume
>> that the selection and negotiation will be constrained. We of course have
>> a mechanism for that: it is the Require header. There are also other
>> mechanisms that provide constraints of some sort. For instance the
>> SDP offer constrains what is permitted in the answer. (It does *not*
>> however

---

From: [email-masked]
Date: Sun, 25 Feb 2007 09:50:26 -0500

From: Paul Kyzivat <[email-masked]>

   > [edited]

      [edited]

OK, this is starting to make sense.

Dale

---

From: [email-masked]
Date: Sun, 25 Feb 2007 09:55:51 -0500

From: Jeroen van Bemmel <[email-masked]>

   Considering PoC as a capability / feature is confusing, I'll argue
   that from a user perspective it is more "I want to PoC with X" as
   opposed to "I want to communicate with X and I'll use whatever
   matching capabilities our devices support". It is about user
   intent, which appears difficult to capture in a generic
   INVITE. Perhaps a new method "PoC"?

OK, but *why* do the users think that?  From a naive point of view,
push-to-talk is simply a user interface issue, and I can't see why the
user would be dissatisfied if the system fell back into an ordinary
full-duplex audio call, which, after all, is *better* than a PTT
connection.

I'm sure that there is some reason the cellular industry set up PoC in
a different way than ordinary calls, but I don't see why we have to
carry it forward into SIP.

And if PoC really is a "separate silo" from ordinary telephony, why
can't it just be handled by some systematic modification of AORs?
When the UA is doing a PoC mode, it can append ";poc" to the To and
>From URIs, and the destination proxy will know to route the call to an
appropriate application server.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 25 Feb 2007 16:49:09 +0100

Dale,

> full-duplex audio call, which, after all, is *better* than a PTT

What is "better" when depends on the usage context and the subjective 
definition of "better". I am sure there are cases where users would be 
sattisfied with a regular audio call after they pressed the "PoC" button. 
Likewise, you will also find users who would be unpleasantly surprised. 
Let's work from the assumption that there exist distinct user experiences 
"regular voice" and "push-to-talk", and that a user can choose one or the 
other. Assume that users are not willing to accept "regular voice" when they 
choose "push-to-talk", and vice versa

> carry it forward into SIP.

I must admit I am not familiar with the details of PoC, but I imagine for 
example that for a regular voice conference you would need audio mixing, 
whereas for a group PoC session you would not. The difference should somehow 
be signaled.

> appropriate application server.

That is equivalent to saying "why can't it just be handled by systematically 
including a header that says 'PoC'", which is exactly what 3GPP is doing 
with its proposal for a service identifier. Is there really a difference?

Regards,
Jeroen