I would like to understand the full
proposal.
A single user can use multiple devices
running different signaling protocols (theoretically even from a single
device).
What do you mean by the CallID? The SIP
CallID?
I have the following concerns with your
proposal:
- SIP CallID is not general enough.
How do you ensure key uniqueness across different protocols?
- Having a concept of an endpoint
– is an important property of many signaling protocols. SIP is still
working on it (i.e. on GRUU). We have discussed this requirement over the
last year and we agreed to reflect it in the package. (For those who don’t
want to or doesn’t support it – the user AOR can be repeated
as the endpoint URI. It makes sense to add this clarification to the
text.)
In general, the dialog information is more
sensitive than the endpoint URI and one of the repeatedly expressed requirements
was to keep it optional.
I don’t see real technical problem
with using indexes as keys. This is the safest and widely used technique. These
indexes are used in the context of the XML document only. They should not be
used beyond it (e.g. in SDP or complementary XCON protocols).
Again, I feel OK with correcting the
mistakes, clarifying text, and satisfying Cullen’s requirement by “promoting”
the dialog – as long as it remains optional.
I feel very uncomfortable with redesigning
the package unless we have a WG majority and/or I hear explicitly from the WG
chairs.
Orit.
From: Cullen Jennings
[mailto:fluffy at cisco.com]
Sent: Sunday, February 06, 2005
5:23 PM
To: Orit Levin; sipping; Brian
Rosen
Cc: Rohan Mahy; Dean Willis;
gonzalo.camarillo at ericsson.com
Subject: Re: Conference Package
-09?
I would prefer to use the existing unique identifiers that we have instead of
having the focus create new identifiers that need to be mapped. Having multiple
names for things that could be named with one name always seems to cause
complications. I am also not keen on having primary and secondary keys for a
situation where we could do it with a single key.
So here is my proposal
The key for a user is the SIP AOR (as it is in the 08 draft - no change here)
The key for a endpoint is is the CallID
The key for a media stream is the mid (as it is in the 08 draft).
The hierarch here is that a conference has users, each users has one or more
calls (refereed to as endpoints), and each call has some number of media
streams. If you do this life is very clear. This is what you can discover from
SIP signaling that the focus will know about and be able to report. The focus
can not actually figure out if two calls are to the same endpoint or not - SIP
does not, and should not, reveal this. That is why the CallID, not the contact
should be the index. There are a long list of why using the contact will not
work with situations involving B2BUA including a very important B2BUA known as
the PSTN. Are two PSTN calls coming thought the same GW the same endpoint or
not?
I could be convinced the key for the media stream should be the label not the
mid. I'm not sure which it should be but assume there was a good reason to
choose mid. Can we add some text explaining why this choice?
Cullen
On 2/2/05 6:49 PM, "Orit Levin" <oritl at microsoft.com> wrote:
Guys,
I wished that the latest comments have been posted a month ago (before and
during the last call with the rest of the comments), but you have convinced me
that all of them together deserve refreshing the draft.
I completely agree that the package needs to define exactly what each
piece if information means. That being said, it does not need to specify how
"a complete" conference application uses it. It is up to each
application to specify what information to use and how to generate and populate
it. (In this sense, the package can mention examples only.) One of these
applications is the sipping-cc-conferencing. Another is going to be the
standard XCON, which will define how to actually use the information in the context
of its architecture. (It will most probably add more information to the
package.)
I don't see a problem to resolve the two "real issues" that Cullen
pointed out, add clarifications that Cullen asked for, revise the "media
entries" per Brian, and also clean the "editorial" mistakes
(such as the usage of "proto" instead of "media" and the
"label" examples).
My proposal to resolve the XML issues is as follows:
1. Add an optional attribute (called "call") to be used as a
secondary key to the "endpoint" element. This is just an index with
values (1, 2 ,3 , ...) to be generated by the Conferencing server which wants
to present the status information not per "endpoint", but per
"call" (i.e. per a signaling dialog). It is up to the server to
decide in what resolution to present the information to a specific package
subscriber. The subscriber will be able to understand both
"resolutions" by inspecting the provided keys.
2. Don't use the "mid" values as the key for the
"media" element. Instead, make the Conferencing server to populate
the media "id" attribute as an index counting the media streams (i.e.
with values (1, 2 ,3 , ...) ). Add a new optional sub-element to the
"media" element containing the actual "mid" values being used
in SDP (if needed).
3. Use plain index as a key to the media entries, move "media"
(i.e. the old "proto") as a sub-element, add a new sub-element
"label".
4. Rename all the "proto"s to something more appropriate (e.g.
"type").
Guys and the chairs, please, let me know ASAP whether we have a majority
here so that I can go ahead, make the changes, resubmit the draft, and keep
3GPP happy.
Orit.