Subject: [Sipping] Suggested direction for discussions on service identification

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 11 Mar 2007 15:18:11 +0200

Folks,

as a chair, I would like to direct our discussions on service
identification to a few topics. Below, I have tried and summarized some
of the issues that have been discussed on the mailing list, and
suggested concrete topics for discussion.

Note that I am sending this email as a chair. That is, it does not
contain my personal opinion on any of the topics below. The intention
with this email is to focus discussions on a few topics that, once
clarified, may help us make some progress as a WG.

1) Non-backwards compatible services (e.g., PoC). Unless user agents
understand the special logic that relates to the service, they will not
be able to do the right thing. It has been proposed to use the Require
header field to identify these services. It has also been proposed to
use feature tags in Accept-Contact header fields together with the
"require" and "explicit" parameters. When these parameters are used a
proxy will only forward the request to contacts that have explicitly
indicated that they support the desired feature set.

It seems that the end result is similar and that no matter in which
header field the token identifying the service is placed, the
requirements would be met.

However, there is an important difference between both mechanisms: the
IANA registration policy for new tokens. Require header fields can only
carry option-tags, which need to be defined in standards-track RFCs.
Feature tags, on the other hand, can be vendor-specific and are
registered in the IANA registry as such.

Therefore, I would like to see explicit discussions on the IANA
registration policy we want for these non-backwards-compatible services.

Questions we may want to ask ourselves are: do we want require a
standards-track RFC for this type of non-backwards-compatible service?
If so, should the PoC specs be copy/pasted into an RFC or a one-page RFC
pointing to the OMA spec would be enough?

2) Enhanced experience. Some services are backwards compatible. That is,
even if the other endpoint does not understand the service, a session
can be established. However, if the other end understands the service,
users get, somehow, an enhanced experience.

An example of this type of service could be a multimedia telephony
service, which might include things such as mandatory support for
certain supplementary services.

It has been proposed to use feature tags and caller preferences for this
type of service. I would like to see discussions on whether or not this
way of using caller preferences is appropriate.

3) SIP-established sessions as a transport for proprietary information.
Some applications use SIP to establish generic media streams in order to
exchange application-specific information on top of them. For example, a
network game may use SIP to establish a TCP stream between two endpoints
and then send the position of its players (or whatever information the
game needs to transfer) over that TCP stream. Another game may establish
a similar TCP stream, but transfer different information in a different
format over it. The same example would be valid if both applications
used MSRP streams instead of TCP streams.

I would like to see discussions on how we want to identify those two
applications (i.e., both games in the example above). Do we want to use
the same mechanism as in 1)?

4) Network support and interactions with caller preferences. It has been
discussed that services in the three categories above sometimes require
network support. Therefore, an entity in the network may need to be able
to identify the service a given SIP request relates to. Note that
network support may be required in the originating and terminating
networks, and that different mechanisms may be used to implement network
support in an originating network or in a terminating network.

I would like to see discussions on possible interactions between
services that require network support and caller preferences. What
happens if a UA sends an INVITE that uses caller preferences to indicate
that the user would prefer to use multimedia telephony but that would be
OK using PoC should multimedia telephony not be available. Are both, the
multimedia telephony and the PoC application servers, included in the
signalling path, just in case?

Cheers,

Gonzalo
SIPPING co-chair

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Sun, 11 Mar 2007 12:55:25 -0600

> the same mechanism as in 1)?

I'm currently thinking that request-URI parameters (once we fix SIP to 
deliver said parameters to the UA) could makea great way to identify 
specific applications at the UA. This might also work for some of the 
other use cases (questions 1 and 2) but seems to be especially suitable 
for this use case.

The other alternative is to use some richer alternative to SDP in the 
session description.

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 11 Mar 2007 16:07:06 -0400

Gonzalo,

Thanks for trying to herd us unruly cats into some more productive 
discussion on this subject. Comments on your points inline.

Gonzalo Camarillo wrote:
> be able to do the right thing.

Is there a difference between this category and your category 3? As I 
understand it this is just an instance of that. Or maybe a combination 
of 3 and 4.

> It has been proposed to use the Require

There is a significant difference.

Caller preferences are *preferences* - there is no guarantee they will 
be honored. And the focal point for them is in proxies, for the 
selection of which retargetings will be tried. There is some expectation 
that the UAS will also apply the preferences and potentially reject 
calls that don't fit. But that is still a preference.

REQUIRE is stronger. The UAS MUST reject the request if it doesn't 
support the option. But REQUIRE isn't expected to influence retargeting, 
though I guess there is no reason why it can't be.

These can both have roles, but which is applicable depends on the 
details of the service.

> standards-track RFC for this type of non-backwards-compatible service?

Yes, I think so. That will have the effect of discouraging too many of 
these, and encouraging the finding backward compatible ways of 
accomplishing the same thing.

> certain supplementary services.

I still don't understand what this is. Specifically, I can't think of 
anything that falls into this category and yet isn't distinguished in 
some other way.

Are you talking about supplementary services provided by the UAs 
themselves? Or about ones provided by some server that must Record-Route 
itself, or inject itself as a B2BUA, in order to provide the service. 
I'm guessing you mean the latter.

We have seen few if any examples of this sort of thing brought up for 
discussion. (Maybe we will in BLISS, not that it is getting going.) Its 
hard to prove without some examples, but I have a feeling that 
everything that can be done by a server in the call path can also be 
done by a UA explicitly making requests to a server when it needs help 
to accomplish something. For example, we do have some examples of how a 
UA can involve a transcoder if/when it needs transcoding services.

So I'm not convinced this is a valid justification for service ids.

> way of using caller preferences is appropriate.

If you meant the UA itself, then the kinds of things already covered by 
3841 seem to be what you are talking about.

> the same mechanism as in 1)?

IMO this sort of thing is best handled by added attributes in SDP. In 
this case the media are *not* the same. This is much like selecting 
codecs, but in this case it isn't with RTP.

We already have cases like this. MSRP is one, and MRCP is another.

> network support.

First, as I noted above, I'm far from convinced that it is the place of 
the intermediate network nodes to decide they will be needed and force 
their way into the call. A much cleaner model would be for the UAs make 
their own decision that a network server is required and then take 
explicit signaling action to involve such a server in the call.

> Therefore, an entity in the network may need to be able
> to identify the service a given SIP request relates to.

Note that doing this violated the e2e principle.

> Note that

I've stated elsewhere my skepticism that this can be made to work. So 
you won't see an answer to this from me right now. I'm looking forward 
to some explanation and examples by those that are in favor of this 
approach.

	Thanks,
	Paul

---

From: "Andrew Allen" <[email-masked]>
Date: Mon, 12 Mar 2007 03:12:44 -0400

Gonzalo,

Whilst I welcome focusing the discussion on technical issues rather than
the philosophical arguments that will simply use up the meeting time I
am concerned that your proposal seems very much to focus on the use of
Accept-Contact for various aspects rather than the actual proposals in
draft-rosenberg-sipping-service-identification-00. 

Although I know that several companies within 3GPP have proposed the use
of Accept-Contact as the protocol element for transporting service
identifiers this is not part of Jonathan's proposal in the draft
currently and as far as I am aware not part of any draft submitted to
SIPPING. While I have no problem with us discussing alternative
mechanisms including the use of Accept-Contact as part of the discussion
I think that the focus of the discussion should be foremost around the
proposals in the current draft.

In your current proposal for discussion only the proposed use of Require
is actually from the current draft. 

Specifically we need to also discuss:

1) how Application Servers that perform service logic in the home domain
of the UAC can be inserted in the route. The draft's current proposal is
to use a preloaded Route header containing the Service Identifier in a
URN format for that.

2) how UAs can obtain the service identifiers needed to communicate
properly with other UAs in other domains that need service identifiers
in order to have the appropriate service logic, policies and routing
applied. The draft proposes the use of Service URIs and Service Instance
URIs and the use of Presence and GRUU based mechanisms to generate and
communicate these URIs containing the service identifiers.

3) How Application Servers that perform service logic in the terminating
domain can be routed to based on Service Identifiers. The draft bases
terminating domain routing upon domain routing policies for the Service
URI that is inserted in the Request-URI.

4) the format of service identifiers. The draft proposes basing service
identifiers on URNs based upon the existing Service URN.

5) Dependencies on other drafts (such as GRUU and Loose Route).

I believe that discussion on these 4 items needs to also be part of the
agenda for the SIPPING discussion on this

regards
Andrew

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Sunday, March 11, 2007 8:18 AM
To: sipping
Cc: Mary Barnes
Subject: [Sipping] Suggested direction for discussions on
serviceidentification

Folks,

Cheers,

Gonzalo
SIPPING co-chair

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 12 Mar 2007 09:08:47 -0700

Andrew Allen wrote:

> Whilst I welcome focusing the discussion on technical issues rather 
> than the philosophical arguments

Well, one technical issue I am struggling with is service identification
is not scalable, since there are so many competing service models and
marketing cannot be forbidden to invent new ones all the time. It's
actually their job to do so and the engine of marketing. 

Do you expect IANA to have a huge and growing registry for service
definitions? 

How about holiday promotions and coupons for frequent fliers when the
service bundles are rearranged and the service logic may interact? 
I am not kidding.

Example: Additional (maybe free) voice mail notification over e-mail
with media attachment will be added if you subscribe to IM. How does one
specify voice mail (free?) over email, with media attachment,
conditioned by _new_ IM subscription? Specific coupons are allowed. How
would the BNF spec look like?

If the BNF for this 1,001th service is not registered with IANA, 
will voice mail fail?

Please don't focus on the possible weakness of my example, but address
the generic issue of scalability. 

Thanks, Henry

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Monday, March 12, 2007 2:13 AM
To: Gonzalo Camarillo; sipping
Cc: Andrew Allen; Mary Barnes
Subject: RE: [Sipping] Suggested direction for discussions
onserviceidentification
Importance: High

Gonzalo,

regards
Andrew

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Sunday, March 11, 2007 8:18 AM
To: sipping
Cc: Mary Barnes
Subject: [Sipping] Suggested direction for discussions on
serviceidentification

Folks,

Cheers,

Gonzalo
SIPPING co-chair

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 17 Mar 2007 10:09:08 +0100

Hi Paul,

> codecs, but in this case it isn't with RTP.

Media may or may not me the same. An scenario could be an endpoint 
implementing two games (e.g., doom and quake). Both games may be using 
the same protocol to transfer synchronization information between 
players. This protocol could run on top of, say, UDP.

In the RTP case, you may have the same codec, but different 
"applications" (e.g., fax or voice).

I was hoping to have discussions about these types of scenarios, whether 
or not people think they are valid scenarios and, if so, how could they 
be signaled.

Cheers,

Gonzalo

---

From: Eric Burger <[email-masked]>
Date: Mon, 19 Mar 2007 09:37:45 +0100

Um...

If doom and quake are using two different protocols, are they not using two
different protocols?

What am I missing?

> or not people think they are valid scenarios and, if so, how could they

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intendedch-3.2.2) with ESMTP id
	l2J8bkMs017361; Mon, 19 Mar 2007 01:37:46 -0700
Date: Mon, 19 Mar 2007 09:37:45 +0100
Subject: Re: SIP-established flows between applications WAS (Re: [Sipping]
	Suggested direction for discussions on service identification)
From: Eric Burger <[email-masked]>
To: Gonzalo Camarillo <[email-masked]>
Cc: sipping <[email-masked]>

Um...

If doom and quake are using two different protocols, are they not using two
different protocols?

What am I missing?

> or not people think they are valid scenarios and, if so, how could they

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intendedch-3.2.2) with ESMTP id
	l2J8bkMs017361; Mon, 19 Mar 2007 01:37:46 -0700
Date: Mon, 19 Mar 2007 09:37:45 +0100
Subject: Re: SIP-established flows between applications WAS (Re: [Sipping]
	Suggested direction for discussions on service identification)
From: Eric Burger <[email-masked]>
To: Gonzalo Camarillo <[email-masked]>
Cc: sipping <[email-masked]>

Um...

If doom and quake are using two different protocols, are they not using two
different protocols?

What am I missing?

> or not people think they are valid scenarios and, if so, how could they

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.