Subject: [Sipping] Re: conference-package-08 comments

From: Cullen Jennings <[email-masked]>
Date: Tue, 01 Feb 2005 10:34:23 -0800

inline

On 1/31/05 4:12 PM, "Orit Levin" <[email-masked]> wrote:

> Inline, 
> 
> Orit. 
> 
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>> Sent: Saturday, January 29, 2005 8:05 AM
>> To: sipping; Orit Levin
>> Cc: Rohan Mahy; Dean Willis
>> Subject: conference-package-08 comments
>> 
>> 
>> I gave this a very quick read and I like it. I should read it
>> carefully at some point. Few concerns...
> According to my records, the last call for this draft ended more than a
> month ago... :-) 

>> 
>> If bob is disconnecting on one instance but had dialed back
>> in and connecting, how can you use the entity as the the
>> index of the endpoint and have it be unique?
>> 
> The design was that the schema will represent the "aggregated" abstract
> call signaling status information per endpoint collectively for all
> potentially existing dialogs. In other words, it will show to most
> recent and the most important information. In this case it could be the
> "connecting" status, for example. If the detailed call status is
> absolutely needed (and permitted to be divulged to the conference state
> subscriber) then the client can learn the dialog id (from the package)
> and SUBSCRIBE to the dialog package in parallel to the conference
> package and ahead of time.
> 

I don't see any discussion of this in the draft. I think it is the wrong
design. I think the conference package should be able to simultaneous
represent both.

> Theoretically and generally to the package design, in the future IFF
> absolutely necessary, any "entity URI" used as a key can contain a URI
> parameter distinguishing between the keys.
> 
>> How can a device that had multiple audio of video streams use
>> the proto as a key and have it be unique?
>> 
> "proto" is not the key for a media stream. The key is an "id" attribute
> which MUST be unique among endpoint's streams and generated by the
> conference state generator. It SHOULD have the same value as the "mid"
> from the "Grouping media lines in SDP" RFC.

Oops sorry - I got confused on the id. However, I'm still not sure I see how
mid works. For one, it is only unique with a set of SDP and it seems you
need it unique across different calls. Next, I see in the draft you just
make up an id for things like 323. How will a 323 device be able to
correlate. Seems problematic.

> 
>> When we get the above items sorted out, this looks like it is
>> ready for last call to me.
>> 
> I will address the formatting and the editorial comments in the 48
> editor's hours. 
This document has problems that can not be fixed in auth 48.

>> 
>> The dialog identifiers are often the only thing that stops
>> people from being able to spoof midcall messages (like BYE)
>> into SIP sessions. I think we need some security
>> considerations around when the conference package should
>> reveal this and when it should not. Actually, I'm sort of
>> wondering if it ever should.
>> 
>> The way this is defined the conference certainly could
>> protect users privacy but there is not much in the draft that
>> helps implementers know how they might go about this.
>> 
>> After a user is disconnected, how long do they stay listed as
>> entry that is disconnected before they are just deleted.
>> 
>> 
>> More NIT like things ....
>> 
>> Why is the call into the media instead of inside the endpoint
>> 
>> I was surprised that the XML was only a SHOULD be valid
>> instead of MUST but don't care if you leave it this way
>> 
>> I was surprised that S/MIME was SHOULD - I guess I would have put SIPS
>> 
>> There are weird control characters in the draft. Some lines
>> look too long 
>> 
>> Defining active as after start-time just adds to the
>> confusion of what start-time is and makes active weird too. I
>> think this is the the wrong definition. I would use active to
>> mean that if you use signaling to connect to the provided
>> URLs to join the conference, it might work.
>> 
>> The "when" field should require that the time in in  UTC
>> 
>> conference-medias-type should be restrict to the the MIME media types
>> 
>> sharepoint? 
>> 
>> max-user-count: What do you put if the number of users is unlimited
>> 
>> I think all the things that are used as indexes should be attributes
>> 
>> The XML indentation is messed up
>> 
>> I did not really look at the schema but I assume the XML is
>> appropriately extensible...
>> 
>> 
> 

_______________________________________________
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