Subject: RE: [Sipping] Service Identification in SIP

From: "Andrew Allen" <[email-masked]>
Date: Thu, 15 Feb 2007 22:26:33 -0500

I'll have a crack at laying out examples showing the utility of service
identification.

First a gaming example somewhat similar to Jonathan's. Take a network
based multiplayer game (Chess, D&D, Quake, Pool, Roulette, virtual golf,
etc.....). This game allows multiple users to participate in the game
either as players or as observers. An audio stream is established so
that players and observers can exchange comments on the game along with
the media stream (either using MSRP or an application specific data
transport that is used to exchange game commands and game position
updates between the participants and the game server which also acts as
a focus. The gaming session is established using SIP and SDP over a SIP
network such as IMS that has Application Servers that perform telephony
call features for basic voice only telephony and multimedia "rich"
telephony calls. The multimedia telephony sessions also support combined
audio with MSRP and other application specific data streams (such as
whiteboards) in a call. Now gaming sessions don't require telephony
service call feature handling in fact this isnt even desired however
based on the SIP and SDP it isnt possible to determine whether an INVITE
request is related to a telephony call or a gaming session and hence
whether the request needs to be routed via an Application Server that
performs telephony call features or not. In addition users may have
multiple devices only one of which has the application that understands
the game. Other devices that the user has registered against his AoR may
handle audio for telephony and other voice applications but if Alice
invites Bob to play her favourite game it is not very interesting if Bob
accepts the gaming session on a device that can only accept the audio
stream. Also even when the terminal that has the game application
receives the INVITE the correct application in that terminal needs to be
identified to accept the session. In addition service providers may
charge different rates for telephony and for games. I also don't want to
be charged telephony per minute call rates for playing my game.  

Here is another example that I think shows that service identification
doesn't just apply to INVITE and sessions but also can apply to other
requests such a MESSAGE as well. SIP MESSAGE method is being used for
Instant messaging applications but it is also being used for many non
Instant Messaging applications as well. These include as a replacement
SIP transport for transporting encapsulated SMS (Short Message Service)
contents (see 3GPP SMS over IP), as a transport for Group Advertisement
documents for Push To Talk (see OMA PoC), as a notification transport
for various Push Services (see OMA SIP Push). Each of these different
service applications of SIP MESSAGE method requires routing to different
Application Servers in the network, delivery to different applications
in the terminal and the ability to be charged for separately. The only
SIP header that differentiates each of these different useages of SIP
MESSAGE is the Content-Type header but routing based on Content-Type is
a very bad idea. Firstly the Content-Type doesn't identify the service
specifically but some content related to a subset of the service. Also
as the service evolves the Content-Types used may change or new ones may
be added and this shouldn't require updating the routing rules of the
proxies or the internal application invocation logic in endpoints. The
possibility of Multipart MIME Content-Types makes parsing of
Content-Types by proxies inefficient and complex and potentially
impossible if the message body is encrypted. What is needed is a means
compliant with standard SIP Routing mechanisms that allow SIP proxies to
efficently route these different MESSAGE requests to the appropriate
servers, endpoints and invoke applications within endpoints. I think
Jonathan's draft is a good basis for doing this.

Another example using INVITE is IPTV. IPTV may be established using
INVITE containing SDP with both Audio and Video streams. How does the
network determine the difference between an IPTV related INVITE and one
related to multimedia telephony that supports video? Certainly it is not
desired that the IPTV INVITE invoke telephony call features in an
Application Server and you probably don't want the IPTV INVITE being
routed to your mobile phone (unless it's a mobile TV service). It is
likely that an SDP offer for IPTV is for a unidirectional media stream
but this is real convoluted to use as the basis for routing and
charging. 

In adddition it is possible that an INVITE doesn't contain SDP at all
and then there is no basis in SDP for determining the related service.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, February 10, 2007 11:50 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

I've attempted to re-read the threads that Gonzalo referred to, and the
major limitation that I see is the lack of any concrete example of why
these identifiers are needed.  Probably the IMS people have discussed
this so many times that they've forgotten the detailed rationale behind
the requirement.  But I'm a net-head, (and most of the people here are
net-heads) and the SIP systems that I've dealt with show no evidence of
needing "service identification", they're pure proxies, and requests are
passed transparently end-to-end.

Could somebody please lay out an example showing the utility of service
identification?

   From: "Salvatore Loreto (JO/LMF)" <[email-masked]>

   I think that everyone here agree that there is the possibility to use
a
   media in different ways, and that we need a distinction about what
the
   capabilities are and how they are used, whatever will be the
mechanism
   that at the end we will identify to do that.

Respectfully, I disagree.  We do need ways of identifying the
capabilities of SIP agents and transports, but I see no necessity of
creating specified bundles of capabailities, and then constraining
dialogs to require an initial agreement as to which bundle of
capabilities will be used.

One of the central features of Internet architecture is that agents
negotiate compatibility on a feature-by-feature basis; there are no
"profiles" which must be known on a network-wide basis.  (And I have
observed that this feature is of significant commercial value.)

In regard to identifying an "application" to process the dialog (and I
use "application" in a standard computing way), I see no reason that a
user cannot select URI-parameters to append to his AOR, and arrange for
his UA to route invites with those URI-parameters to the appropriate
application.  (And given the rich mechanisms for redirection in SIP, the
application need not even reside at a UA which is registered for the
AOR.)  These URI-parameters can be formally or informally standardized,
or established ad-hoc by each user.

In regard to PoC (as someone said, "a specialized floor-control
protocol") and similar features, SIP currently has mechanisms for
indicating support of features and requiring that a recipient support a
feature before accepting a call (the Supported and Requires headers, and
simply using the feature).  The only limitation I can see that might
need to be addressed is that there is no way to create an option tag for
a new feature that one has invented that is not yet thoroughly
standardized.

But I now discover RFC 3261 section 8.1.1.9:

   The option tags listed MUST only refer to extensions defined in
   standards-track RFCs.  This is to prevent servers from insisting that
   clients implement non-standard, vendor-defined features in order to
   receive service.  Extensions defined by experimental and
   informational RFCs are explicitly excluded from usage with the
   Supported header field in a request, since they too are often used to
   document vendor-defined extensions.

So I see that as a fundamental architectural decision, SIP does not
permit sending INVITEs that require specialized recipients, excepting if
the specialization is standards-track.

Dale

_______________________________________________
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

---------------------------------------------------------------------
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.

_______________________________________________
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: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Fri, 16 Feb 2007 18:28:15 +0200

Hi Andrew,

your mail reinforce my idea that what we need, or what we are looking
for, is something that specify the ***context*** for a specific call.

/sal

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2007 11:18:42 -0500

> I'll have a crack at laying out examples showing the utility of service

The examples are good. I think it is important not only to see how a 
service id could be used to solve these cases - it is also important to 
see if they could be addressed without service ids, using some existing 
mechanism.

> performs telephony call features or not.

I'm not at all sure of the above.

For this example, the session will be between an UA and a game server 
that can be viewed as a conference focus. So how does that session get 
established? I can see three plausible ways:
- each player calls the server.
- the server calls a player, either based on out of band input
   (e.g. web access) or by another player sending a REFER to the
   game server

When a player calls the game server, originating "features" are still 
applicable. E.g. outbound call blocking.

When the game server calls the player's UA, terminating "features" are 
also probably still applicable. E.g. inbound call blocking is still 
applicable. Perhaps voicemail isn't, but that is hardly different in 
other cases where a caller doesn't want to be routed to voicemail, and 
should possible to handle via caller preferences.

In general, "mandatory" services at either the originating or 
terminating sides most likely need to be applied because if they aren't 
then it will open a target for a caller who wants to bypass those 
features. In the case of optional features, there ought to be some 
mechanism for callers to bypass them if they don't want them.

> In addition users may have
> stream.

I definitely don't consider the service id to be the right solution for 
selecting a UA that supports the combination of media that a caller 
wants to use. Using service ids for this would imply that every 
meaningful combination of media be given a distinct service id. That is 
not a reasonable solution to the problem.

There are a variety of possible approaches to solving that problem. 
Callerprefs is a possible answer, though it provides no guarantees. 
There are also solutions involving SDP - indications of dependency among 
streams has been proposed. Its also possible to use preconditions to 
negotiate an acceptable combination of media.

This has been a problem just waiting for a critical mass of desire for a 
solution. Maybe this is the time to solve it.

> Also even when the terminal that has the game application
> identified to accept the session.

I'm not convinced of this one. In most cases this will be a no-brainer - 
there will only be one reasonable candidate. In cases where there are 
multiple candidates, it would be preferable to have the target device do 
so based on intrinsic attributes of the session, rather than artificial 
tags applied to it. (E.g. if MSRP is involved, use the IM application.) 
And if there is ambiguity and a suboptimal choice is made, the user 
ought to be able to change it without taking the call down.

> In addition service providers may

Well, the call will be to a game server, and it will involve some sort 
of media. The server may or may not be known to the SP.

If the game server is known to the SP, then it can adjust the billing as 
it wishes.

If the game server is unknown to the SP, then the SP would be stupid to 
reduce its billing based on a claim by the caller or callee that this is 
a game. If there are tangible differences in the resources provided by 
the SP (e.g. different bandwidth media streams) then billing can be 
adjusted based on that.

I don't see how a service id makes anything better here.

> in the terminal and the ability to be charged for separately.

As far as handling by the receiving UA, it seems to me that the MIME 
type is perfectly adequate as a way to get the message properly 
processed, just as is done with attachments to email messages.

I'm not sure I understand where these need to be routed to an AS. 
Perhaps for store and forward SMS. Why is that any different than 
voicemail, where a server is the UA of last resort?

If something is needed, e.g. for routing to a B2BUA, it seems like 
callerprefs should work. If not, potentially a proxy could route based 
on the MIME type of the body.

So I'm not convinced you need service id to do this.

> The only
> specifically but some content related to a subset of the service.

It works ok for email. And *especially* for MESSAGE, which is a 
datagram, it seems just right to me: please see that this is processed 
by something that understands the content. The type of the content can 
be narrowed as much as desired to achieve the desired selectivity.

> Also

As MIME types change, the recipients need to understand them anyway.

And what is going to happen as the definition of a service changes? Will 
it get a new service id so you can be sure it is processed by something 
that understands it? Or will it keep the same service id but run the 
risk of being routed to an incompatible target?

I don't think the problem is substantially different whether you use 
MIME types of service ids.

> impossible if the message body is encrypted.

If you want a particular sort of intermediate server involved in a 
request then its indeed possible that selecting based on MIME type won't 
be ideal. Doing based on callerprefs, with the intermediate server being 
treated as a first class candidate target, may be an alternative.

> What is needed is a means

Using Route headers with URNs is indeed a possibility here. But how the 
originator arranges for such a header to be present when the request 
reaches the terminating side is hard for me to see. And how to ensure 
that the terminating side is capable of honoring that is also problematic.

> but this is real convoluted to use as the basis for routing and

I think using differences in SDP to distinguish this is quite 
appropriate. It might be more than just unidirectional streams. For 
instance it might call for bandwidth and/or resolution that a phone 
won't support.

Nor do I find the bypassing of telephony services to be an issue. Either 
they are still meaningful, or it will be clear that they shouldn't be 
applied based on the nature of the call, without need for a service id.

As for charging, as I mentioned earlier, either the SP knows the source 
and can adjust the charging accordingly, or it doesn't know the source 
in which case it must charge based on the type of resources it is 
providing without knowing how they are being used.

> and then there is no basis in SDP for determining the related service.

Well clearly an offerless invite means the caller desires the callee to 
choose the nature of the call. This doesn't present any new problems 
that aren't also present as a result of mid-call changes in the media 
used in a call. For instance, I could call you, and ask if you would 
like to see my latest video. Then switch the stream to hi def streaming 
video. This isn't much different than switching from voice to fax.

In part I think this demonstrates the folly of basing an architecture on 
the assumption that you can splice servers into a call at the beginning 
that will be appropriate for everything that might happen subsequently 
on that session. If you need servers in the middle of the call, then 
there had better be some way to introduce or change them mid-call 
if/when the nature of the call changes.

I also think that this again identifies the general problem of 
negotiating a mutually acceptable set of media during call 
establishment, as mentioned above. Again I don't see service ids as the 
right solution to this problem. The SDP capability work that Flemming is 
doing might be of some relevance here - it might permit sending an 
offerless invite with capabilities, so that UASs that can't live with 
the capabilities of the caller can refuse the call.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 11:00:00 -0500

> performs telephony call features or not.

Sure it does. In the case of the game, there would be a media stream for 
the proprietary gaming moves. If it is using MRSP, then the content 
types that are listed in the SDP for MSRP indicate that.

> accepts the gaming session on a device that can only accept the audio

Right, so its reasonable to apply caller prefs here too, to route the 
request to devices that support the required content types.

> be charged telephony per minute call rates for playing my game.  

You can do all of that. In this particular example there are very 
specific things in the SDP that indicate that this is a game vs. text chat.

> a very bad idea.

Why? This is widely used practice for email.

  Firstly the Content-Type doesn't identify the service
> specifically but some content related to a subset of the service.

This depends on how good a job you do at defining your content types.

If you use very targeted content types it works great. For example, if 
you define a content type specific for push for notifying a device of 
new configs, then that type indicates exactly what is happening. If you 
use text/plain, and then define some special format for that text, you 
are correct its not sufficient. This is why we have the 
Content-Disposition header field.

  Also
> impossible if the message body is encrypted. 

Well, thats a different problem. But if it turns out to be one, we could 
  just define mecahnisms for signaling the internal content type and 
disposition.

> Jonathan's draft is a good basis for doing this.

Require is there for when that is the only recourse; I am hoping it is 
not often needed, and in fact if its just for PoC I will be happy. In 
the examples you give above, I think existing sip mecahnisms suffice to 
identify the service.

> but this is real convoluted to use as the basis for routing and

In this case, the caller or called party identify the app.

FOr example, if a user uses SIP INVITE to connect to a movie, I would 
suggest an INVITE that looks like:

INVITE urn:movies:TheReturnOfTheKing SIP/2.0

In this case, the identity of the called party says it all.

> and then there is no basis in SDP for determining the related service.

Ahhh.

Now that is a good point. Let me make a separate post on that.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com