RE: [MEDIACTRL] SIP Control Framework

Hi Lorenzo - thanks for the input.  Some comments in-line.

Chris.

-----Original Message-----
From: Lorenzo Miniero [mailto:lorenzo.miniero@unina.it] 
Sent: 11 September 2007 10:29
To: mediactrl@ietf.org
Subject: [MEDIACTRL] SIP Control Framework

Hi Chris and all,

just some lines to give you all a small review on the framework work. I
already
thought it was a very good work, so I'm happy to see it as a WG item
now.

I noticed you removed the headers in the initial negotiation (Requires:
escs,
Control-Packages: ..), leaving this further negotiation to after the
channel
has been setup. I think it's good to have it there, considering it's
more
flexible, but wouldn't a previous negotiation be good as well? e.g. if
the MS
doesn't support a CP the AS needs, then the control channel wouldn't
need to be
opened at all. I remember a discussion in Prague about having these
negotiation
in the SDP itself, even if I'm not sure it would be the best solution.
What are
your feelings about this?

[Chris Boulton] I agree that it would be useful (hence the reason I
first put it in SIP headers).  My gut feeling is that it should be kept
out of the core framework.  We 'could' then define an extension draft
for MMUSIC that defines some new SDP attributes.  The attributes could
then provide a hint of supported packages and enable the call to be
rejected before the channel it setup.  Do others think this is a good
path forward? 

Then, I have a doubt regarding the chosen acronyms. SCFW is used in
control
messages, but ESCS instead is used in the COMEDIA negotiation. Wouldn't
a
single name be better to avoid confusion?

[Chris Boulton] I am happy to align the tokens - any objections?

I also noticed a potential ambiguity in the text. At the beginning the
Content-Length header in control framework messages is stated to be a
MUST,
even if no payload is attached (which would mean CL=0). But in the 10.1
figure,
it is reported to be optional. Which one is true? I'd prefer to have it
optional for bodyless messages, but that's just my two cents.

[Chris Boulton] Yes - I suspected this might cause confusion - I will
take a close look at the text around content-length.

Finally, a couple of errors I've found in the example at the end:
        1) the SIP BYE and its 200 OK both still have leftovers from the
previous version (the Requires: escs and the Control-Packages header);
        2) REPORT messages with an XML blob body are missing the
Content-Length
header.

[Chris Boulton] Great - thanks.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl