Subject: RE: [Sipping] Service Identification in SIP

From: "Elwell, John" <[email-masked]>
Date: Wed, 14 Feb 2007 10:57:01 +0000

Having followed this thread, I too find the chess example very contrived. If
chess moves are sent as voice commands, then surely it would be acceptable
for the normal telephone application to answer the call, i.e., the remote
player listens to the move, performs this move on a conventional or
electronic chess board and speaks his next move. The calling UA should not
care whether the call is answered by a computer application or a person.
Furthermore, even if the audio needs to consumed by a particular chess
application at the called UA, then other media in the same session such as
video or messaging might not be. So any qualification of the nature of media
to be exchanged probably should be at the media level, not at the session
level or SIP level. As yet another variation, what if the players set up a
conventional telephone call and then mutually agree to switch in their chess
applications?

Now, let's consider another case. I establish an MSRP session. Within this
MSRP session I can send messages with various MIME attachments that are
intended for consumption by various applications. I should not need to know
in advance what applications I will use during the course of the MSRP
session. All I should put in the INVITE request is the fact that I want to
establish an MSRP session.

John 

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: 13 February 2007 18:19
> To: [email-masked]
> Subject: RE: [Sipping] Service Identification in SIP
> 
> It must be my lack of imagination for not being able to come up with a
> credible usage scenario, given the following:
> 
> - Is playing chess by voice a credible usage scenario? :-)
> Especially since voice recognition is now so often found in PCs and in
> mobile phones as well. In other words, chess playing by voice may also
> be an endpoint application, without any network involvement. Actually,
> if placed in the endpoint it works just as well on poor 
> bandwidth links
> by contrast to chess in the network that may require adequate 
> broadband.
> 
> - Is anyone's boss or spouse going to approve extra phone 
> charges above
> the flat rate for playing chess at a time when the gaming industry has
> pioneered free VoIP?
> Will such a service be taxed extra and if yes using by what criteria?
> Gambling comes to my mind :-)
> 
> - VoIP is reported in the press as a give-away and I have seen no
> reports of any VoIP provider recording a profit on VoIP. I assume the
> losses are often hidden by bundling in triple play, etc.
> 
> Given my lack of imagination, can anyone share a more credible usage
> scenario for Service Identification in SIP?
> 
> What's the use of a standard without a credible usage scenario?
> 
> Thanks, Henry
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Göran Eriksson AP (KI/EAB)<[email-masked]>
Date: Thu, 15 Feb 2007 00:34:28 +0100

My humble, perhaps faulty, understanding of the "chess game" was not that voice commands were used to control the chess itself, rather
that the chess game, while having some IP-based proprietary gaming interaction protocol, also had a feature letting
the users talk to each others while playing. The scenario are two, or more, users play a chess game of the (Inter)net, talkin
to eachother from time to time during the game (yeah, don't ask me if I think people will love this!!).

The purpose, as I understand it, was a)to show that the 'voice component' in the chess game application is similar to that
in a stand alone POC-Only application when it comes to exchange and transfer of voice samples and associated floor control
and b) to point to differences, for instance when it comes to supplementary services, which may not apply in the chess game case.

Perhaps it is important to be clear on the assumed user device realisation, as far as I understand it:

 The "chess game + voice" example is, as I understand it, discussed under the assumption that voice and chess game is
 managed by custome designed appliction, or client, which is a necessary/likely approach in a mobile device given the
 limited MMI (and also other factors in the mobile context).

 In a PC, I could easily handle this as two different applications/client, like when I use Skype/MSN to talk to my friends while
 playing some turn based game, but again, the discussion is held under the assumption that usability requirements
 leads to an application client integrating voice and chess game events.

The alternative device realisation You describe- different clients managing different portions of what is negotiated in the SDP or MSRP MIME attachment- 
is, I think, a good illustration of the need to be precise and explicit about the assumed device architecture when discussing the "service identification" issue(s).

Regards
Göran

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: den 14 februari 2007 11:57
To: Henry Sinnreich; [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

Having followed this thread, I too find the chess example very contrived. If chess moves are sent as voice commands, then surely it would be acceptable for the normal telephone application to answer the call, i.e., the remote player listens to the move, performs this move on a conventional or electronic chess board and speaks his next move. The calling UA should not care whether the call is answered by a computer application or a person.
Furthermore, even if the audio needs to consumed by a particular chess application at the called UA, then other media in the same session such as video or messaging might not be. So any qualification of the nature of media to be exchanged probably should be at the media level, not at the session level or SIP level. As yet another variation, what if the players set up a conventional telephone call and then mutually agree to switch in their chess applications?

Now, let's consider another case. I establish an MSRP session. Within this MSRP session I can send messages with various MIME attachments that are intended for consumption by various applications. I should not need to know in advance what applications I will use during the course of the MSRP session. All I should put in the INVITE request is the fact that I want to establish an MSRP session.

John 

> - Is playing chess by voice a credible usage scenario? :-) Especially 
> since voice recognition is now so often found in PCs and in mobile 
> phones as well. In other words, chess playing by voice may also be an 
> endpoint application, without any network involvement. Actually, if 
> placed in the endpoint it works just as well on poor bandwidth links 
> - Is anyone's boss or spouse going to approve extra phone charges 
> above the flat rate for playing chess at a time when the gaming 
> industry has pioneered free VoIP?
> 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
> 

_______________________________________________
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: "Henry Sinnreich" <[email-masked]>
Date: Wed, 14 Feb 2007 16:01:07 -0800

Göran Eriksson wrote:

> having some IP-based proprietary gaming interaction protocol

Yes, your understanding is correct and there is a booming gaming industry out there working exactly this way.

Where we disagree is that there is a need felt in the gaming industry to have application level network infrastructure in the middle and helpful operators to charge extra for IP based games.

But there no sense in us trying to convince anyone to avoid planting network intermediaries for extra charging for IP based games. 

Could I just get a ticket to the show to watch the enthusiastic reception by users and game manufacturers? :-)

Thanks, Henry

-----Original Message-----
From: Göran Eriksson AP (KI/EAB) [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 3:34 PM
To: Elwell, John
Cc: [email-masked]
Subject: Device architecture? WAS: RE: [Sipping] Service Identification in SIP

Regards
Göran

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: den 14 februari 2007 11:57
To: Henry Sinnreich; [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

John

---

From: Göran Eriksson AP (KI/EAB)<[email-masked]>
Date: Thu, 15 Feb 2007 01:39:31 +0100

I very much agree with You there Henry! I do recognise the need to give *some classes of applications*, read telephony replacement, the possibility
to make whatever nethead, monolithic, tower of Babel, architecture that that industry need BUT I DO NOT, personally, what
any particular application class enforce/prevent/impose such an architecture on other applications, such as game, chat, etc.

The issue is of course that there is a great interest out there for telephony as such, and of course all telco operators are concerned with
the future business. This may easily lead to application/industry specific requriements getting into the (SIP) protocol(s), something that at least should
be avoided as much as possible, and if not possible, then at least contained.

And You're right- they will (try to) plant such charging devices there, because the name of the (market economy) game is they will if they can.

The funny side of this is that the IMS must probably also support gaming traffic, but not in a way that kills gaming traffic for instance by stupid charging. 
Telco operators are more and more under pressure to provide real consumer value and charge reasonably. We'll see...

Regards
Göran

PS. The show I would like to see is the one where users get to know that they will not have to pay for neither telephony, broadband access, mobile access,
expensive PC programs or OS's, music, IPTV, games, PC, mobile phone, etc for that matter! And yes, please no commercials also, :-)!!

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: den 15 februari 2007 01:01
To: Göran Eriksson AP (KI/EAB); Elwell, John
Cc: [email-masked]
Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identification in SIP

Thanks, Henry

-----Original Message-----
From: Göran Eriksson AP (KI/EAB) [mailto:[email-masked]]
Sent: Wednesday, February 14, 2007 3:34 PM
To: Elwell, John
Cc: [email-masked]
Subject: Device architecture? WAS: RE: [Sipping] Service Identification in SIP

My humble, perhaps faulty, understanding of the "chess game" was not that voice commands were used to control the chess itself, rather that the chess game, while having some IP-based proprietary gaming interaction protocol, also had a feature letting the users talk to each others while playing. The scenario are two, or more, users play a chess game of the (Inter)net, talkin to eachother from time to time during the game (yeah, don't ask me if I think people will love this!!).

The purpose, as I understand it, was a)to show that the 'voice component' in the chess game application is similar to that in a stand alone POC-Only application when it comes to exchange and transfer of voice samples and associated floor control and b) to point to differences, for instance when it comes to supplementary services, which may not apply in the chess game case.

 The "chess game + voice" example is, as I understand it, discussed under the assumption that voice and chess game is  managed by custome designed appliction, or client, which is a necessary/likely approach in a mobile device given the  limited MMI (and also other factors in the mobile context).

 In a PC, I could easily handle this as two different applications/client, like when I use Skype/MSN to talk to my friends while  playing some turn based game, but again, the discussion is held under the assumption that usability requirements  leads to an application client integrating voice and chess game events.

The alternative device realisation You describe- different clients managing different portions of what is negotiated in the SDP or MSRP MIME attachment- is, I think, a good illustration of the need to be precise and explicit about the assumed device architecture when discussing the "service identification" issue(s).

Regards
Göran

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: den 14 februari 2007 11:57
To: Henry Sinnreich; [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Feb 2007 21:24:01 -0500

> to eachother from time to time during the game (yeah, don't ask me if I think people will love this!!).

Well, that is not my understanding of the example Jonathan had used as 
an example. But nevertheless, lets go with it for a moment...

>  leads to an application client integrating voice and chess game events.

I don't think the analogy holds. Presumably the chess control protocol 
would be another media stream in the same session. It seems that the 
only key requirement here is that both media streams be accepted by 
something that understands how to deal with them. You may have a very 
special application for this in your mobile device. But it would be 
perfectly reasonable for the callee to have a PC that has a UA that 
delegates the chess protocol to a chess game and the voice stream to a 
general purpose media player.

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Thu, 15 Feb 2007 11:17:15 +0100

Hi,

I've been following this thread too, and I think perhaps it's useful to
put the problem -whatever it is- in context to focus things a bit.

The pattern we're looking at here is the typical "application uses
underlying protocol". To scope it down a little bit I'll consider two
far ends of this pattern:

* stupidly simple underlying protocol (SSUP): TCP, where TCP offers one
single "service" to the application: reliable bi-directional data stream
exchange. All applications using TCP know the kind of service they're
getting, so the only artifact that each protocol agent needs to earn the
day is the local and remote port numbers. Each application "registers"
with a local socket bound to those ports, and if multiple applications
want to share the ports they need an intermediary that performs the
multiplexing/demultiplexing using artifacts opaque to the TCP agent.

* unbounded complexity underlying protocol (UCUP): WS, where the range
of services available to an application is unlimited. Thus, in order to
use the available services an application needs a detailed formal
description of those services and their providers. Interoperability is
guaranteed by those descriptions, and an application does not need to
support a whole service specification by the letter in order to
use/provide that service successfully.

I think that a fair amount of the debate around SIP services stems from
each one's standpoint. Some stand more on the SSUP side, where SIP just
provides well-defined and scoped "basic multi-media communication", and
each application out there must make its own arrangements if something
more rich or complex wants to be used/provided. Others, however, stand
more on the UCUP side, where SIP is a mechanism on top of which a
potentially unbounded number of inter-operable richer services could be
provided.

I'd say that IETF people tend to be SSUP heads, while telecom people
tend to be UCUP heads. I think this is caused by the different business
models each group makes a living for.

Regards,
/Javier

Elwell, John wrote:
> Having followed this thread, I too find the chess example very
> contrived. If chess moves are sent as voice commands, then surely it
> would be acceptable for the normal telephone application to answer
> the call, i.e., the remote player listens to the move, performs this
> move on a conventional or electronic chess board and speaks his next
> move. The calling UA should not care whether the call is answered by
> a computer application or a person.      
> Furthermore, even if the audio needs to consumed by a particular
> chess application at the called UA, then other media in the same
> session such as video or messaging might not be. So any qualification
> of the nature of media to be exchanged probably should be at the
> media level, not at the session level or SIP level. As yet another
> variation, what if the players set up a conventional telephone call
> and then mutually agree to switch in their chess applications?      
> 
> Now, let's consider another case. I establish an MSRP session. Within
> this MSRP session I can send messages with various MIME attachments
> that are intended for consumption by various applications. I should
> not need to know in advance what applications I will use during the
> course of the MSRP session. All I should put in the INVITE request is
> the fact that I want to establish an MSRP session.     
> 
> John
> 
>> It must be my lack of imagination for not being able to come up with
>> a credible usage scenario, given the following:
>> 
>> Will such a service be taxed extra and if yes using by what
>> criteria? Gambling comes to my mind :-) 
>>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 15 Feb 2007 11:05:40 -0800

Göran,

I really appreciate very much even the limited part of agreement we have here and the right of operators to try to monetize IMS the best they can.

Besides the extra charges, I had forgotten to mention the control over features and innovation that such an approach would give the operators.
 
I suspect that endpoint application developers will dislike this even more. Endpoint application developers will have even more incentives to resist such control by operators over their product development.

This is already felt by mobile phone manufacturers who are not that happy to have their features controlled by operators. This bubble is going to burst one way or another.

Most likely that this issue will be decide in the Internet marketplace and by regulators, so please file this exchange so we can draw some insight on predictions in the near future.

Thanks, Henry

-----Original Message-----
From: Göran Eriksson AP (KI/EAB) [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 4:40 PM
To: Henry Sinnreich; Elwell, John
Cc: [email-masked]
Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identification in SIP

Regards
Göran

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: den 15 februari 2007 01:01
To: Göran Eriksson AP (KI/EAB); Elwell, John
Cc: [email-masked]
Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identification in SIP

Thanks, Henry

-----Original Message-----
From: Göran Eriksson AP (KI/EAB) [mailto:[email-masked]]
Sent: Wednesday, February 14, 2007 3:34 PM
To: Elwell, John
Cc: [email-masked]
Subject: Device architecture? WAS: RE: [Sipping] Service Identification in SIP

Regards
Göran

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: den 14 februari 2007 11:57
To: Henry Sinnreich; [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

John