Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identificatio n in SIP

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Feb 2007 11:15:30 +0000

Mallesh,
 
Yes, I agree that some means of selecting a preferred device might be
needed, but that is indeed what RFC3841/3840 does. Why do you consider this
overkill?
 
John

  _____  

From: Malleswara Rao Ankem [mailto:[email-masked]] 
Sent: 15 February 2007 10:54
To: Elwell, John
Cc: Göran Eriksson AP (KI/EAB); [email-masked]
Subject: Re: Device architecture? WAS: RE: [Sipping] Service Identificatio n
in SIP

Inorder to identify a endpoint that has the capabilities to serve a very
specialized functionality, I guess it is simpler to name the functionality.
Naming the functionality not only helps in decision making while routing the
request to that specific endpoint but also helps the endpoint identify which
specialized application on the endpoint can take up the responsibility.
Instead of all the routing entities looking into the SDP/message bodies it
should be easier/faster if they can look for a specific header. 
I thought feature tag mechanisms indicated in the RFC3841/3840 combination
should have sufficed but implementing those RFCs seems to be a overkill for
describing/selecting/routing requests to the specific endpoint and also
choosing a service/feature/application on the endpoint. 
 
-Mallesh

On 2/15/07, Elwell, John <[email-masked]
<mailto:[email-masked]> > wrote: 

Göran,

Your interpretation is different from what is stated in the Rosenberg draft.
Anyway, let's not dwell on this particular use case, which may or may not be

realistic. The important thing is whether the media being sent is suitable
for general purpose devices or requires or could be used by some special
class of application.

If a medium is somehow specialised ( e.g., audio modulated for
interpretation
by a modem or fax machine), then the necessary information needs to be
conveyed along with the m-line in the SDP. Perhaps even if it is
human-intelligible voice but with a restricted repertoire of words that make

it suitable for a particular class of application, maybe that information
too should be conveyed with the m-line. Perhaps the case described in
Jonathan's draft fits this latter category: I believe the medium is just 
regular voice that can be interpreted by a human, but is also constrained in
its repertoire of words such that it can be used by a chess application.

The important thing is that there be sufficient information in the SDP to 
allow appropriate application selection at the end device. I am not
convinced by a need for information at the SIP level during call
establishment, because of course SDP can be re-negotiated during the call
( e.g., when the users decide to use a particular application) and what is
indicated in SIP at call establishment time might no longer be valid later
in the call.

John

> -----Original Message----- 
> From: Göran Eriksson AP (KI/EAB)
> [mailto:[email-masked]
<mailto:[email-masked]> ]
> Sent: 14 February 2007 23:34 
> To: Elwell, John
> Cc: [email-masked] <mailto:[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. 
>
> 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:  <mailto:[email-masked]>
[email-masked]]
> Sent: den 14 februari 2007 11:57
> To: Henry Sinnreich; [email-masked]  <mailto:[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
>
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:[email-masked]
<mailto:[email-masked]> ]
> > Sent: 13 February 2007 18:19
> > To: [email-masked] <mailto:[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>
https://www1.ietf.org/mailman/listinfo/sipping 
> > This list is for NEW development of the application of SIP Use
> > [email-masked]
<mailto:[email-masked]>  for questions on current sip Use
> > [email-masked] <mailto:[email-masked]>  for new developments of core SIP 
> >
>
> _______________________________________________
> Sipping mailing list    <https://www1.ietf.org/mailman/listinfo/sipping>
https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked]
<mailto:[email-masked]>  for questions on current 
> sip Use [email-masked] <mailto:[email-masked]>  for new developments of core
SIP 

_______________________________________________
Sipping mailing list    <https://www1.ietf.org/mailman/listinfo/sipping>
https://www1.ietf.org/mailman/listinfo/sipping 
This list is for NEW development of the application of SIP
Use [email-masked]
<mailto:[email-masked]> for questions on current sip 
Use [email-masked] <mailto:[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: "Malleswara Rao Ankem" <[email-masked]>
Date: Thu, 15 Feb 2007 18:35:55 +0530

>From a "dumb" terminal perspective it is a overkill. The reason being those
RFCs (3841/3840) not only provide macro-capability identification (through
feature tags) but also very granular, micro-capability (method based or
other parameters) based routing and service selection. A endpoint claiming
support for the same need to implement all the recommendations or has to be
partially be non-compliant for most other parts of those RFCs.
I understand that a service can be described by a feature tag or can be
described by the session parameters that would be involved in the session. I
guess you would agree that while former is less complex when I dont intend
to be interoperable with all the devices on the earth while latter though
powerful but that device would still need to understand the feature tags cuz
the RFCs talk about it.
If feature tags can be accepted as service identifiers then why not service
urns ?

-Mallesh

On 2/15/07, Elwell, John <[email-masked]> wrote:
>  ------------------------------
> *From:* Malleswara Rao Ankem [mailto:[email-masked]]
> *Sent:* 15 February 2007 10:54
> *To:* Elwell, John
> *Cc:* Göran Eriksson AP (KI/EAB); [email-masked]
> *Subject:* Re: Device architecture? WAS: RE: [Sipping] Service
> Identificatio n in SIP
>
>
> On 2/15/07, Elwell, John <[email-masked] > wrote:
> >
> > Göran,
> >
> > > [mailto:[email-masked]]
> > > Cc: [email-masked]
> > > From: Elwell, John [mailto: [email-masked]]
> > > To: Henry Sinnreich; [email-masked]
> > > > From: Henry Sinnreich [mailto:[email-masked] ]
> > > > To: [email-masked]
> > > > [email-masked] for questions on current sip Use
> > > > [email-masked] for new developments of core SIP
> > > >
> > >
> > > Use [email-masked] for questions on current
> > > sip Use [email-masked] for new developments of core SIP
> > >
> >