Subject: RE: [mediactrl] RE: [XCON] Media Server Control

From: Eric Burger <[email-masked]>
Date: Fri, 15 Jul 2005 00:16:29 +0100 (BST)

Details described in
<http://www.ietf.org/internet-drafts/draft-burger-mscl-thoughts-00.txt>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, July 14, 2005 6:50 PM
> To: MARJOU Xavier RD-MAPS-LAN
> Cc: Chris Boulton; MixerControl
> Subject: Re: [mediactrl] RE: [XCON] Media Server Control
> 
> hi xavier,
> 
> the primary issue is the use of sip info which the ietf does 
> not like to be used as a general purpose transport (although 
> it frequently is). sip info has been debated many times on 
> different ietf lists, with different proposals about how to 
> overcome the issues. for example, jonathan rosenberg wrote a 
> draft on "info considered harmful" and dean willis wrote a 
> draft on "info packages". both drafts are expired but you can 
> probably find them on line somewhere.
> 
> the goal of the mscs draft is to suggest an alternative 
> transport mechanism to sip info that leverages standardized 
> mechanisms (e.g. comedia). another possibility is to define a 
> new sip method. eric burger mentions this is a draft he has 
> recently released. both drafts stem from conversations 
> between chris, eric, and myself on media server models and 
> transport protocols. we thought that it would be beneficial 
> to bring our discussions to a wider audience to provoke 
> greater discussion of possible solutions and the issues.
> 
> cheers,
> timm
> 
> MARJOU Xavier RD-MAPS-LAN wrote:
> > Hi,
> >  
> > I think that having again another new protocol complicates 
> things at 
> > the AS side and delays hopes to quickly have interoperable 
> ASs and MSs (e.g.
> > needs for MSCS stacks, for new APIs in AS, for new testing 
> tools, ...).
> >  
> > What is the blocking point when conveying XML commands in 
> SIP messages 
> > (as done in MSCML and MSML)?
> >  
> > Best Regards,
> > Xavier
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > *From:* [email-masked] [mailto:[email-masked]] *On 
> > Behalf Of *Chris Boulton
> > *Sent:* vendredi 1 juillet 2005 11:41
> > *To:* [email-masked]
> > *Subject:* [XCON] Media Server Control
> > 
> > All,
> > 
> >  
> > 
> >             Just a short mail to make you aware of a new draft that 
> > has been submitted to the internet draft archives.  It is a first 
> > attempt at defining a framework using SIP for media server 
> control.  
> > The draft can be found at 
> > 
> http://www.ietf.org/internet-drafts/draft-boulton-media-server
> -control-00.txt.
> > All input is greatly appreciated.
> > 
> >  
> > 
> > Please note that this draft is not submitted as part of the XCON 
> > Working Group so please do NOT provide comments on the XCON mailing 
> > list.  A dedicated mailing list has been set up to discuss 
> this topic.  
> > I have included the details at the end of the mail.
> > 
> >  
> > 
> > Best Regards,
> > 
> >  
> > 
> > Chris.
> > 
> >  
> > 
> >  
> > 
> > 
> ----------------------------------------------------------------------
> > --------------------------------------------
> > 
> >  
> > 
> > Instructions:-
> > 
> >  
> > 
> > -          generate a mail to [email-masked] 
> > <mailto:[email-masked]>
> > 
> > -          place text 'subscribe mediactrl' in the body of 
> the message 
> > (plain text)
> > 
> > -          Follow remaining on-screen instructions to confirm list 
> > subscription
> > 
> >  
> > 
> > All subsequent mails need to be sent to 
> > [email-masked]
> > <mailto:[email-masked]>
> > 
> > *//*
> > 
> >  
> > 
> > 
> > 
> > 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.  Unless otherwise expressly agreed in 
> writing signed by 
> > an officer of Ubiquity Software Corporation, nothing in this 
> > communication shall be deemed to be legally binding. Thank-you
> 
> --------------------------
> Ubiquity Software does not control or endorse the content, 
> messages or information found in this mail list and it 
> specifically disclaims any liability with regard to these 
> communications.
> Ubiquity Software reserves the right the restrict access to 
> any communications in violation of the Terms and Conditions 
> of Use for this website or as otherwise deemed improper.
> 

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 15 Jul 2005 09:14:14 +0100 (BST)

Xavier - totally agreed with Tim.  The idea is not to produce something
that adds confusion but to ultimately have a solution that is
consolidating and acceptable.

Chris.

-----Original Message-----
From: Tim Melanchuk [mailto:[email-masked]] 
Sent: 14 July 2005 23:50
To: MARJOU Xavier RD-MAPS-LAN
Cc: Chris Boulton; MixerControl
Subject: Re: [mediactrl] RE: [XCON] Media Server Control

hi xavier,

the primary issue is the use of sip info which the ietf does not
like to be used as a general purpose transport (although it
frequently is). sip info has been debated many times on different
ietf lists, with different proposals about how to overcome the
issues. for example, jonathan rosenberg wrote a draft on
"info considered harmful" and dean willis wrote a draft on
"info packages". both drafts are expired but you can probably
find them on line somewhere.

the goal of the mscs draft is to suggest an alternative
transport mechanism to sip info that leverages standardized
mechanisms (e.g. comedia). another possibility is to define
a new sip method. eric burger mentions this is a draft he
has recently released. both drafts stem from conversations
between chris, eric, and myself on media server models and
transport protocols. we thought that it would be beneficial
to bring our discussions to a wider audience to provoke
greater discussion of possible solutions and the issues.

cheers,
timm

MARJOU Xavier RD-MAPS-LAN wrote:
> Hi,
>  
> I think that having again another new protocol complicates things at
the 
> AS side and delays hopes to quickly have interoperable ASs and MSs
(e.g. 
> needs for MSCS stacks, for new APIs in AS, for new testing tools,
...).
>  
> What is the blocking point when conveying XML commands in SIP 
> messages (as done in MSCML and MSML)?
>  
> Best Regards,
> Xavier
> 
>
------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
Behalf 
> Of *Chris Boulton
has 
> been submitted to the internet draft archives.  It is a first attempt
at 
> defining a framework using SIP for media server control.  The draft
can 
> be found at 
http://www.ietf.org/internet-drafts/draft-boulton-media-server-control-0
0.txt.  
> Please note that this draft is not submitted as part of the XCON
Working 
> Group so please do NOT provide comments on the XCON mailing list.  A 
> dedicated mailing list has been set up to discuss this topic.  I have 
> included the details at the end of the mail.
> 
>  
> 
> Best Regards,
> 
>  
> 
> Chris.
> 
>  
> 
>  
> 
>
------------------------------------------------------------------------
------------------------------------------
> -          place text 'subscribe mediactrl' in the body of the message

> Information contained in this e-mail and any attachments are intended 
> disclosure or distribution is strictly prohibited.  If you are not the

> addressee, please notify the sender immediately and destroy all copies

> of this email.  Unless otherwise expressly agreed in writing signed by

> communication shall be deemed to be legally binding. Thank-you

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.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 19 Jul 2005 10:09:23 +0100 (BST)

[Chris Boulton] Hi David - thanks for the feedback - some comments
in-line.

The main drawback of the SIP/XML solution is probably that all SIP 
messages exchanged between the AS and the
MRF goes through SIP proxies and thus generate CPU resources usage. 
Since we use a lot of 'in session' messages (INFO),
this processing will be more expensive than traditionnal SIP calls. But 
this problem can be easily solved using the
correct SIP network architecture. E.g. a specialized SIP proxy (MRF-C) 
that is only involved into the processing of the initial
INVITE request. Of course if your requests go through several proxies, 
SIP INFO is not the good solution.

[Chris Boulton] Certainly.  It is more than likely that the architecture
will fit closely with IMS MRF-C/MRF-P and have a tight signaling
association.  But as you point out, in architectures that cover
geographical distribution, it could be possible for SIP to traverse
multiple nodes.

Application servers already have a SIP stack. Many efforts have been 
made by SIP stack suppliers to develop now opimized
stacks. Adding a new stack (MSCS) would make the AS more complex and 
thus more expensive. I am sure that this new stack
will be added only if there are very good arguments to do it (technicals

and/or economics).

[Chris Boulton] Well - I'm not sure about the complexity.  The reliable
pipe would only be responsible for exchanging XML blobs which would
require minimal transaction load (compared to SIP).

 The SIP + INFO XML tends to be now the
de-facto standard. Even if there are still some pressures to use H.248. 
Sure, the remaining problem is that we are using
different XML protocols.

[Chris Boulton] It may be currently used but that is because of no
'real' alternative.  The idea of this group is to specify something that
will make it through the standards process - this is not INFO.

I agree that the SIP INFO message is used to send a lot of different 'in

session' informations : media server control,
user inputs (DTMFs), .... What would be the benefit of having for 
example a 'MEDIA' request ?

[Chris Boulton] As above - INFO will not make it as a standards
mechanism for this work - see
http://www.softarmor.com/wgdb/docs/draft-rosenberg-sip-info-harmful-00.t
xt

I agree that it would be cleaner but I do not really feel an urgent need

for it.

[Chris Boulton] From a standardization point of view - I disagree.

If there is really a need for a MSCS solution, why not quite simply 
using VoiceXML/http as proposed by netann ?
(maybe with the add of CCXML)

[Chris Boulton] Very good for voice IVR and simple conferencing
functionality BUT we are looking for advanced, explicit conferencing
that can be applied to varying media types.

Probably the main difference between SIP/XML and SIP+MSCS would be in 
where is located the service logical.
A SIP INFO architecture tends to keep the service logical into the AS. 
The MRF-P can be considered as a high-level
peripheral that is completely driven by the AS.
A MSCS architecture would tend to upload/download a part of the service 
logical from the AS to the MRF.
Since the MRF embedds some specialized resources (even DSP), I believe 
that the resources of the MRF
should not be spent into parsing/processing too complex 
requests/scripts: the processing of a VoiceXML request
is more expensive than the processing a more basic XML command such as 
AMSML.

Best regards

David

Tim Melanchuk wrote:

> there is no denying that there are cetain desireable properties to
> a new method. also a certain amount of work (although that should not
> be the driving consideration).
>
> note that mscml currently has the concept of control
> dialogs that have special significance for conferencing. msml
> can also be used in this model although it is a little more
> flexible because it is transport neutral. info messages on
> these dialogs can affect the conference state and hence
> affect the media of multiple participants.
>
> all that mscs is doing is replacing sip info over
> an invite initiated control channel with a tcp control
> channel established using sip invite (for discovery and
> rendezvous reasons etc.). the focus was to see if we
> could use existing mechanism (comedia), rather than
> requiring new mechanism (sip method). the xml could
> potentially be unchanged.
>
> cheers,
> timm
>
>
>
>> First, thanks for your answers.
>>
>> I understand that INFO should not be used, but I'm still not
convinced
>> that another protocol is needed.
>> If there is no real problem with the current draft implementations
>> existing today (MSCML,MSML...), creating a new SIP request as
suggested
>> by Eric seems more reasonnable to me.
>> I know there are also some drawbacks with a new SIP request, but if I
>> try to compare with presence I hardly imagine that one would need to
set
>> up an INVITE negotiating a presence-protocol/tcp in SDP to publish
>> presence information. The SIP PUBLISH method is much easier to use. 
>> Xavier
>>
>>
>>
>> From: Chris Boulton [mailto:[email-masked]] Sent: vendredi 15 
>> juillet 2005 10:17
>> To: Tim Melanchuk; MARJOU Xavier RD-MAPS-LAN
>> Cc: MixerControl
>> Subject: RE: [mediactrl] RE: [XCON] Media Server Control
>>
>> the primary issue is the use of sip info which the ietf does not like
to
>> be used as a general purpose transport (although it frequently is).
sip
>> info has been debated many times on different ietf lists, with
different
>> proposals about how to overcome the issues. for example, jonathan
>> rosenberg wrote a draft on "info considered harmful" and dean willis
>> wrote a draft on "info packages". both drafts are expired but you can
>> the goal of the mscs draft is to suggest an alternative transport
>> mechanism to sip info that leverages standardized mechanisms (e.g.
>> comedia). another possibility is to define a new sip method. eric
burger
>> mentions this is a draft he has recently released. both drafts stem
from
>> conversations between chris, eric, and myself on media server models
and
>> transport protocols. we thought that it would be beneficial to bring
our
>> discussions to a wider audience to provoke greater discussion of
>> possible solutions and the issues.
>>
>> cheers,
>> timm
>>
messages

>>> dedicated mailing list has been set up to discuss this topic.  I 
>>> have included the details at the end of the mail.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> 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
>>
>>
>>
>> communication shall be deemed to be legally binding.  Thank you.
>>
>>
>
> Ubiquity Software does not control or endorse the content, messages or

> information found in this mail list and it specifically disclaims any 
> liability with regard to these communications.
> Ubiquity Software reserves the right the restrict access to any 
> communications in violation of the Terms and Conditions of Use for 
> this website or as otherwise deemed improper.
>

-- 
David Rio
Alcatel 8688 MRF - TPR
MSD/UCA-BU/Video & Music
Alcatel CIT - Rennes
+33 2 99 87 47 18
+33 6 70 06 45 14 (mob)

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 31 Jul 2005 13:56:24 +0100 (BST)

I do kind of fall into David's camp here.

Yes, there is more burden on proxies using INFO/MEDIA/MUMBLE.  However,
that proxy is most likely a MRFC, which "is built for it".

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2005 5:11 AM
To: [email-masked]; Tim Melanchuk
Cc: MARJOU Xavier RD-MAPS-LAN; Eric Burger; MixerControl
Subject: RE: [mediactrl] RE: [XCON] Media Server Control

and/or economics).

for it.

Best regards

David

convinced
suggested
set
to
sip
different
burger
from
and
our
messages

-- 
David Rio
Alcatel 8688 MRF - TPR
MSD/UCA-BU/Video & Music
Alcatel CIT - Rennes
+33 2 99 87 47 18
+33 6 70 06 45 14 (mob)