[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] I-D on service identification now available
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
jdrosen at cisco.com 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP