Subject: [MEDIACTRL] SIP Control Framework - Issues

From: "Chris Boulton" <[email-masked]>
Date: Mon, 6 Aug 2007 12:53:10 +0100

There are a couple of issues to discuss for the next version of the SIP
Control Framework and it would be extremely useful to get the Work
Groups input.  

-          SIP option tag in SIP Control Framework

The draft currently defines a SIP option tag for negotiation of the core
SIP Control Framework
(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework
-05.txt).  If the group decides to proceed down this route we will need
to hand this over to the SIP work group and its experts.  On reflection,
I feel that this might not be an appropriate use of a Sip option tag.  I
have taken MSRP
(http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-
19.txt) as the driving example.  It also used SDP to convey a media type
that defines its support + connection details.  I personally think that
we should remove the SIP option tag from the SIP Control Framework and
rely on SDP negotiation.

-          SIP 'Control-Packages' header in SIP Control Framework

The current version of the draft uses a Control-Packages SIP header to
negotiate the actual extension packages that can be used on a Control
Channel.  This work would also need to be handed over to the SIP working
group.  On reflection it is (in my opinion) not the best place to
negotiate this information.  I suspect it should be done within the
control channel itself (either re-using or defining a new primitive)
once the channel is set up.  This also allows packages to be dynamically
added/removed from the session without causing SIP signalling to be
triggered.

Please think carefully about these two issues as they impact heavily the
next version of the document.

Chris.

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 6 Aug 2007 20:12:28 +0200

Hi Chris,

I agree with your thoughts on both the points you raised.

Cheers,
Lorenzo

On Monday 06 August 2007 13:53:10 Chris Boulton wrote:
> 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.

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

---

From: "Adnan Saleem" <[email-masked]>
Date: Mon, 6 Aug 2007 23:22:13 -0700

Chris,
 
I agree with both of your suggestions.
 
thanks
 
Adnan

________________________________

From: Chris Boulton [mailto:[email-masked]] 
Sent: August 6, 2007 4:53 AM
To: [email-masked]
Subject: [MEDIACTRL] SIP Control Framework - Issues

Chris.

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.

---

From: Diego B <[email-masked]>
Date: Tue, 07 Aug 2007 10:05:25 +0300

Hi;
I agree with your reflections.
In the SDP case, there is something MMUSIC have to handle or agree ?

Regards
Diego B

Chris Boulton wrote:
>
> There are a couple of issues to discuss for the next version of the 
> SIP Control Framework and it would be extremely useful to get the Work 
> Groups input.
>
> The draft currently defines a SIP option tag for negotiation of the 
> core SIP Control Framework 
> (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-05.txt). 
> If the group decides to proceed down this route we will need to hand 
> this over to the SIP work group and its experts. On reflection, I feel 
> that this might not be an appropriate use of a Sip option tag. I have 
> taken MSRP 
> (http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-19.txt) 
> as the driving example. It also used SDP to convey a media type that 
> defines its support + connection details. I personally think that we 
> should remove the SIP option tag from the SIP Control Framework and 
> rely on SDP negotiation.
>
> - SIP ‘Control-Packages’ header in SIP Control Framework
>
> Channel. This work would also need to be handed over to the SIP 
> working group. On reflection it is (in my opinion) not the best place 
> to negotiate this information. I suspect it should be done within the 
> once the channel is set up. This also allows packages to be 
> dynamically added/removed from the session without causing SIP 
> signalling to be triggered.
>
> Please think carefully about these two issues as they impact heavily 
> the next version of the document.
>
> Chris.
>
>
>
> ------------------------------------------------------------------------
>

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 7 Aug 2007 08:49:58 +0100

Hi;

[Chris Boulton] It will most definitely require interaction with the
MMUSIC group.

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 7 Aug 2007 11:24:37 +0200

I'm also OK with suggestions from Chris.

Simon
-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: [email-masked]

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

> I agree with both of your suggestions.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Xiao Wang <[email-masked]>
Date: Tue, 07 Aug 2007 20:35:50 +0800

Right, I agree with you. However, I think supporting what kind of packages
is the ability of MRC and MRS, using SDP to negotiate this ability 

is a good way.

The control channel is installed by SDP, I think packages may be an
attribute of control channel, so we can dynamically added/removed packages
by SDP.

Xiao

  _____  

From: Chris Boulton [mailto:[email-masked]] 
Sent: Monday, August 06, 2007 7:53 PM
To: [email-masked]
Subject: [MEDIACTRL] SIP Control Framework - Issues

There are a couple of issues to discuss for the next version of the SIP
Control Framework and it would be extremely useful to get the Work Groups
input.  

The draft currently defines a SIP option tag for negotiation of the core SIP
Control Framework
(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-05.
txt).  If the group decides to proceed down this route we will need to hand
this over to the SIP work group and its experts.  On reflection, I feel that
this might not be an appropriate use of a Sip option tag.  I have taken MSRP
(http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-19.t
xt) as the driving example.  It also used SDP to convey a media type that
defines its support + connection details.  I personally think that we should
remove the SIP option tag from the SIP Control Framework and rely on SDP
negotiation.

The current version of the draft uses a Control-Packages SIP header to
negotiate the actual extension packages that can be used on a Control
Channel.  This work would also need to be handed over to the SIP working
group.  On reflection it is (in my opinion) not the best place to negotiate
this information.  I suspect it should be done within the control channel
itself (either re-using or defining a new primitive) once the channel is set
up.  This also allows packages to be dynamically added/removed from the
session without causing SIP signalling to be triggered.

Chris.

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.