Subject: Re: [Sipping] I-D on service identification now available

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Jul 2007 00:57:59 -0400

inline.

Christer Holmberg (JO/LMF) wrote:
> Hi,
> 
> I have some questions/issues on the draft.
> 
> Q1.
> ---
> 
> Chapter 4 gives a few examples where it is claimed that signalling
> information can be used to determine the service. I haven't had time to
> look at the examples in detail yet, but let's assume they are ok.

This section raises examples where people said that the service could 
NOT be differentiated based on signaling. This gets rebutted later in 
the document.

> 
> However, later chapter 6.2 says:
> 
> "Given that the information in the signaling message always conveys
> enough information to identify the service,..."
> 
> Can we make such a statement purely based on a few examples in chapter
> 4??? Or, have I missunderstood something?

Well, the draft is saying that if two signaling messages are completely 
identical, they do the same thing and therefore provide the same 
service. So if you believe there are cases where signaling cannot 
differentiate, please provide the examples.

> 
> I would also like to include at least a couple of more examples:
> 
> - "Game 1 vs Game 2"

Presumably game 1 and game 2 use some kind of stream to exchange game 
moves or something. Those would use different media types and be 
signaled differently in the SDP.

> 
> - "Telephony vs VoIP"   
> 
> (Telephony refers to the case where e.g. supplementary services
> functions are applied, in the UA and/or an AS)

This particular case is just ill-defined. In what cases would a voice 
session be considered telephony, and in which cases, voip? Does the 
caller need to know which one they are asking for? Do I have to have a 
different phone number for each? Or do I get one if the caller comes 
through a PSTN gateway via a POTS phone, but not if they call via an IP 
phone? WHat is the actual user experience here?

<flame>
I also must say, I despise the very implications these names are trying 
to convey. Its sort of saying that, "telephony (as in the thing you've 
had in your house the last 50 years)" is good. VoIP, that is some toy 
that makes calls on the Internet but doesnt have any features. Its bad." 
That is bogus, of course, and pure marketing hyperbole. You, me and 
everyone else on this list have been working hard to make VoIP as rich, 
and richer than, traditional telephony.

Rest assured, even if I did understand the conditions under which you 
get one or the other, I would never refer to the feature-rich thing as 
"telephony" and the feature-poor one as "VoIP. in any document I put my 
name on.
</flame>

> 
> 
> For the part which talks about using SDP information to determine the
> service, I would also like the draft to talk about the following cases:
> 
> - There is no SDP in the INVITE

There are really two cases here.

In case 1, the caller does in fact know what they want to do (i.e., I 
want to do an audio and video session), but for whatever reason, they 
have decided to send an offerless INVITE.

In case 2, for example 3pcc, the entity sending the INVITE really does 
have no idea what the media content of the session is going to be, and 
so sends an offerless INVITE.

Interestingly, in case 2, having a service identifier in a header 
inserted by the UA doesn't help either. The reason is that, the 3pcc 
controller just doesn't know, so it can't put a header or a body or 
anything else in, to provide more information. In these cases, I think 
REFER is much better. So my answer is, this is just a good example of 
why REFER is better than 3pcc. Your service identification is broken no 
matter what you try to do, if you use 3pcc.

In case 1, since the caller does know what it wants, why did it send an 
offerless INVITE? Perhaps its a late binding to an IP address or 
something. In that case, you should be sending an INVITE with SDP, and 
just include a=inactive and update it when you have your IP address. So 
my point is, if the offerer knows the content of the media session it 
wants, it should signal it.

> 
> - Additional streams and SDP information may be added after the initial
> INVITE has been sent

Well, in this case the information clearly IS in the SDP. SO you could 
account for it, authorize QoS for it, or whatever. What are you 
concerned about post-initial-INVITE? APplication dispatch?

> 
> 
> Q2.
> ---
> 
> Chapter 5.7 is a little unclear. I think you should get more details on
> how the "dispatcher" knows which terminals supports gaming (based on
> registration information etc) and once the INVITE reaches the terminal,
> how it is routed to the appropriate application.

This section (all of section 5), is not about mechanism. It is about 
problems people are looking for service ID to solve for them. I think it 
is clear from 5.7 that people want to be able to dispatch to different 
devices based on the service.

> 
> 
> Q3.
> ---
> 
> How does the draft relate to draft-rosenberg-sip-app-media-tag-00 and
> draft-DRAGE-sipping-service-identification-00, which were made available
> a while ago?

This draft provides the architectural framework for the other two. The 
app-media-tag draft deals with an issue that was raised, which is that 
callee caps doesn't provide enough granularity to signal capabilities 
for specific application media types, and so we need to have a new 
capability for that. It is addressing your question on 5.7 above.

THe drage-sipping draft discusses this optimization of doing a service 
identification in a proxy, and caching it within the message so nodes 
within the same network don't need to redo it.

-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

_______________________________________________
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: Wed, 04 Jul 2007 18:36:50 -0400

> "telephony" and the feature-poor one as "VoIP. in any document I put my 

There may be another way to view this distinction:

- "telephony" is voice with the *old*, limited, hard to use set of features.

- "voip" is voice with the new, modern, more capable and easier to use 
set of features.

Even so, I agree with Jonathan that making such a distinction is a bad 
idea. These things need to interoperate. When I call somebody I can't in 
general know whether they support "telephony" or "voip".

Nor do I think it is reasonable to have *different* applications in my 
phone to support the the notion that these are different services. IMO 
there should be one application that provides access to all capabilities 
that might be used during a call. Depending on the capabilities the 
other party happens to have available and enabled, some of the 
capabilities of my application may not be functional for a given call, 
or for *part* of a call.

For example, my device may support both audio and video. I shouldn't 
have to choose a separate, audio only, device to call a "telephony" 
user. Rather I just call with what capabilities I have. If it turns out 
that the other party doesn't have video then my video won't be of use in 
this call, but I'm still using the same application. Maybe later in the 
same call the other user will enable a video capability and we can then 
both use it. Or maybe the call will be transfered to another party that 
does have such a capability.

I expect the above isn't very controversial, because it has been 
discussed for a long time, and so is familiar. But I think the same 
situation should hold for PTT. If a PTT caller sends a call to somebody 
that has a regular audio sip phone, I see no reason why this can't 
result in reaching some accomodation so that the call is established.

Service identifiers simply get in the way of this kind of behavior.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 16 Jul 2007 10:25:40 +0200

Hi,

>- "voip" is voice with the new, modern, more capable and 
>easier to use set of features.

Obviously I've used some sensitive wording here. However, the issue was
NOT what we call the use-cases, but how we differentiate them.

As I said, in one case (the one I called "telphony", but please forget I
used that word) network provided additional functionality (e.g.
supplementary services provided by application servers etc) may be
inserted in the path. 
 
>Nor do I think it is reasonable to have *different* applications in my
phone to support the the notion that these are different services.

I think it is important to distinguish between service identification
and application identification. What I am talking about now is service
identification.

And, I am not saying that the same physical application can't be used
for different things. But, you could also have the same service, but
different applications (games, for example).

But, that is an implementation issue, and not for us to decide.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jul 2007 08:19:41 -0400

> supplementary services provided by application servers etc) may be

Some questions that come to mind are:

- is this functionality that the UA could not provide for itself?
- is this functionality being provided by servers associates with
   the UAC or with the UAS?
- if it is something the UA *could* do, but chooses not to do,
   can the other end tell the difference?
- Does splicing a server into the path this say change the nature
   of the sip protocol?

	Thanks,
	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 17 Jul 2007 12:25:38 +0200

Hi Paul, 

>>> - "voip" is voice with the new, modern, more capable and easier to 
>>> use set of features.
>> 
>> Obviously I've used some sensitive wording here. However, the issue 
>> was NOT what we call the use-cases, but how we differentiate them.
>> 
>> As I said, in one case (the one I called "telphony", but please
forget 
>> I used that word) network provided additional functionality (e.g.

I am sure there are things the UA could do itself, but if the service is
provided by the network it is provided by the ASes. 

>- is this functionality being provided by servers associates with the
UAC or with the UAS?

Some supplementary services are provided with the UA associated with the
UAC, others with the UAS.

>- if it is something the UA *could* do, but chooses not to do, can the
other end tell the difference?

If a user subscribes to a service, and activates it, it assumes the
network will handle it.

>- Does splicing a server into the path this say change the nature of
the sip protocol?

Not in my opinion.

Regards,

Christer

> 
> 	Thanks,
> 	Paul
> 
> >> Nor do I think it is reasonable to have *different* 
> applications in 
> >> my

---

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Wed, 18 Jul 2007 10:30:05 +0200

Hello,
I have a couple of questions related to
draft-rosenberg-sip-app-media-tag-00

"3.  'sip.app-subtype Media Feature Tag'

   The 'sip.app-subtype' media feature tag is of type token with a case-
   sensitive equality relationship.  Its value can be any registered or
   private MIME application sub-type."

In order to use an application-identifier as an app-subtype, is it
necessary to create a corresponding MIME type of
application/application-identifier?

What is the difference between the +sip.app-subtype media feature tag
and the "type" SIP media feature tag defined in RFC 2913?

Regards,
Peter

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: 04 July 2007 05:58
To: Christer Holmberg (JO/LMF)
Cc: IETF Sipping List
Subject: Re: [Sipping] I-D on service identification now available

inline.

Christer Holmberg (JO/LMF) wrote:
> information can be used to determine the service. I haven't had time 
> to look at the examples in detail yet, but let's assume they are ok.

<flame>

-Jonathan R.

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Wed, 18 Jul 2007 14:38:25 +0200

Hi,
 
actually I think should be also usefull insert in the draft at least one sdp signaling example.
 
regards
Sal

________________________________

Da: Dawes, Peter, VF-Group [mailto:[email-masked]]
Inviato: mer 7/18/2007 11:30
A: IETF Sipping List
Oggetto: RE: [Sipping] I-D on service identification now available -draft-rosenberg-sip-app-media-tag-00

Hello,

Regards,
Peter

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 04 July 2007 05:58
To: Christer Holmberg (JO/LMF)
Cc: IETF Sipping List
Subject: Re: [Sipping] I-D on service identification now available

inline.

<flame>

-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 <http://www.jdrosen.net/>                          PHONE: (973) 952-5000
http://www.cisco.com <http://www.cisco.com/>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 19 Jul 2007 12:35:42 +0200

Hi, 

>signaled differently in the SDP.

They don't need to have different media types (they don't need to have
media at all).

But, in some cases this could of course be more related to application
identification than to service identification.

Another example is when you have a phone and voice recognition. The SDP
can be identical for both cases.

>In case 2, for example 3pcc, the entity sending the INVITE 
>really does have no idea what the media content of the session is going

>to be, and so sends an offerless INVITE.
> 
>why REFER is better than 3pcc. Your service identification is 
>broken no matter what you try to do, if you use 3pcc.
> 

>offerless INVITE? Perhaps its a late binding to an IP address or
something. In that case, you should be sending an INVITE with 
>SDP, and just include a=inactive and update it when you have your IP
address. So my point is, if the offerer knows the content of the media
session it 
>wants, it should signal it.

It could also be due to interworking.

I have also seen proposals regarding early media handling procedures
using sofferless INVITEs, but I think we can keep that out of the
discussion for the moment.

>problems people are looking for service ID to solve for them. 
>I think it is clear from 5.7 that people want to be able to dispatch to

>different devices based on the service.

Ok, I can see now that the chapter talks about service dispatching. When
I saw the game example I was thinking of application dispatching.

Your draft doesn't talk much about application dispatching. Chapter 5.1.
touches it, but the text talk about service dispatching. I guess the
draft doesn't separate services from applications.

Regards,

Christer