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

From: "MARJOU Xavier RD-MAPS-LAN" <[email-masked]>
Date: Fri, 15 Jul 2005 10:13:01 +0100 (BST)

Hi, 

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

-----Original Message-----
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

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
> *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-0
0.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

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.

---

From: Tim Melanchuk <[email-masked]>
Date: Fri, 15 Jul 2005 16:32:02 +0100 (BST)

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

Xavier

-----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,

Of *Chris Boulton

be found at

Best Regards,

Chris.

Instructions:-

(plain text)

*//*

---

From: [email-masked]
Date: Tue, 19 Jul 2005 08:34:41 +0100 (BST)

First thanks Tim, Chris and Eric for your interesting contributions.
I believe that both architecture can co-exist and answer to different 
network constraints.

It is funny how we always re-invent the same things: similar  
architectures are already used
into IN networks when a SCP (AS into IP world) need to drive a SRP 
(MS/MRF into IP world).

- SIP + INFO XML can be compared to INAP indirect link. INAP commands 
are embedded within ISUP messages.

- SIP + MSCS can be compared to INAP direct link. ISUP link between 
switch and SRP and TCAP/INAP link between
SRP and SCP.

It is very instructive to study those networks topologies. Into IP/IMS 
world we will find the same advantages and
drawbacks for each architecture.
(note that it is the reason why the Alcatel SIP/XML solution - AMSML - 
is optimized to make the porting of existing
IN/INAP applications easy).
But the IP/IMS network architecture is highly more flexible than IN 
networks and there are less reasons to
build a 'direct link' solution.

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.

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). 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.

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 ?
I agree that it would be cleaner but I do not really feel an urgent need 
for it.

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)
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:

-----Original Message-----
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

-----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

(e.g.

...).

Behalf
Of *Chris Boulton

has

at

can
be found at

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:-

(plain text)

*//*

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

--------------------------
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: Tim Melanchuk <[email-masked]>
Date: Tue, 19 Jul 2005 20:58:48 +0100 (BST)

hi david,
thanks for your comments. i have one comment to add below.
[email-masked] wrote:
[snip]
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). 
this prtoposal is not adding a new stack. i suspect that any
device that supports sip, likely supports tcp. "mscs" is
simply a neutral media type that we chose. it could have
as easily been "msml" or "amsml" if we wanted to carry
those existing languages over tcp control channels rather
than in-dialog INFO reuqests.
cheers,
timm
--------------------------
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.