Subject: Re: [Sipping] draft-melanchuk-sipping-msml-00.txt

From: "Vishal Phirke" <[email-masked]>
Date: Thu, 7 Aug 2003 09:24:58 -0400

Hi Tim,
I have question regarding msml.
MSML defines three classes of media processing objects, viz., network
connection, conference and dialog execution context. Out of these first two
are physical entities within a media server whereas dialog execution
context is an abstract thing, and a dialog will be typically bound to a
network connection at the time of creation. The discription of the
<dialogstart> element says that  "A media stream is created between the
dialog execution environment and the connection or conference".  I
understand the second endpoint but I am not sure what is the definition of
dialog execution environment. As per my understanding, assuming dialog is
made up of MOML constructs such as play and record, the typical requirement
will be to switch the stream between player and recorder. But I can't see
how a <join> at dialog level can indicate which resource to connect to. Can
you elaborate more on the dialog execution environment?
-Vishal

                      Tim Melanchuk                                                                        
                      <[email-masked]        To:       Chris Boulton <[email-masked]>             
                      m>                       cc:       Garland Sharratt <[email-masked]>,        
                      Sent by:                  <[email-masked]>                                         
                      <sipping-admin@ie        Subject:  Re: [Sipping] draft-melanchuk-sipping-msml-00.txt 
                      tf.org>                                                                              

                      08/06/2003 08:43                                                                     
                      PM                                                                                   

thanks for your review and comments! nits will be reflected in the
next revision. responses to questions are inline below.

cheers,
timm

Chris Boulton wrote:

 > - Would any benefit be gained from including an optional 'order'
 > attribute on primitive elements so that when 'pipe' is used, the order
 > is determined explicitly rather than following a logical path?
 >
this question is related to MOML. the goal was to provide several simple
topology schemas to cover the common use cases. i think that explicit
control of topology (i.e. as in mpcp) may be useful. i'm not sure that
explicit ordering in this case would have benefit and may introduce
additional error cases. did you have any specific benefits in mind?

 > - Was there a reason that JOIN/UNJOIN were limited to id1 + id2.  Could
 > it not have just been id, that was forced to appear at least twice?
 > This would allow you to join >2 media streams in one transaction.
 >
simplicity. msml already allows multiple <join> elements to be present
in a single transaction. allowing multiple streams to be identified in
a single join introduces more complexity and makes failure handling
more difficult.

 >
 > - <result> element should say that the response code corresponds to the
 > SIP response code received for the transaction.
 >
i'm not quite sure what you mean here. the response attribute in <result>
is for the msml transaction. it just happens to be carried in the response
to the sip message which conveyed the msml transaction. however msml is
designed to be neutral to the transport mechanism and this correlation
may not exist in all cases.

 > from MSML: Media objects may be defined using MOML or other suitable
media
 >    resource description languages. A media server which supports
 >    <insert> and <remove> must support MOML and may support other
 >    languages.
 >
 > Should this be a 'MUST' or is it not possible to only use another
 > 'suitable media resource description language' with MSML?
 >
a media resource description language is required. the "must" requires
that there be at least one common language to insure interoperability.
it does not preclude that other languages are supported.

_______________________________________________
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

_______________________________________________
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

---

From: Tim Melanchuk <[email-masked]>
Date: Thu, 07 Aug 2003 16:53:31 -0700

vishal, i hope the following explanation helps. please let me
know if you still have any questions or comments.

"dialog execution environment" is intended to be a generic term
which represents a black box from the msml perspective. that is,
msml creates media streams to and from the black box, and the
behaviour in the black box is specified by the dialog language.

moml allows an application to specify how (and when) primitives
are wired together. when primitives are defined to execute
sequentially, (i.e. are not in a group), then each primitive
is connected to a media stream in turn. when one completes, the
next is connected etc. when used with msml, the media stream
is the "target" of the <dialogstart>.

when primitives are grouped for concurrent execution, then
the primitives may be bridged to the "target" depending upon
the <group> topology as described in section 2.2 of moml for
a one dimensional group. the dimension of a group defines
the number of media streams which it supports. a dialog has
one media stream.

timm