Re: [MEDIACTRL] Re: Requirements Comment

[Eric Burger <[e-mail]>]

It’s not (to be used to initiate calls), but we need to make that explicit.


On 3/21/07 10:57 AM, "Steve Buko" <[e-mail]> wrote:

> If your statement below is accurate ...
> 
> |have a single control connection
> |from the AS to the MS, from which one can,
> |amongst other things, initiate calls
> 
> then I have no argument and will drop this issue.
> 
> My impression was that we should support a 1:1, 1:many, and many:1
> relationships between media control channels and call legs for media control
> purposes only. 
> 
> I was not aware that the media control framework would be used to initiate
> calls.
> 
> 
> Steve Buko
> 
> 
> |-----Original Message-----
> |From: Eric Burger [mailto:[e-mail]]
> |Sent: Wednesday, March 21, 2007 10:47 AM
> |To: Steve Buko; [e-mail]
> |Subject: Re: [MEDIACTRL] Re: Requirements Comment
> |
> |It is very much in scope as it is one of the issues to be resolved.  One
> |extreme model of media control is to have a single control connection
> |from
> |the AS to the MS, from which one can, amongst other things, initiate
> |calls
> |and manipulate RTP streams (i.e., calls the AS is unaware of).  Another
> |extreme model of media control is that every call leg at the media
> |server is
> |a distinct SIP dialog at the application server.
> |
> |What is not in scope is modifying standard SIP call flows.
> |
> |
> |On 3/21/07 10:06 AM, "Steve Buko" <[e-mail]> wrote:
> |
> |> Roni,
> |>
> |> I think I understand your point and do not have an issue with this.
> |>
> |> From your option 2 below, my believe here is that from the mediactrl
> |> perspective, SIP signaling for the establishment of the call legs and
> |media
> |> session is not in scope.  What is in scope is the SIP signaling
> |required to
> |> establish a TCP connection for media control and the definition of a
> |media
> |> control protocol.
> |>
> |> For option 1 below (full solution requirements), SIP signaling for
> |call legs
> |> and media session establishment may be in scope.  Certainly some
> |flavor of
> |> signaling is required to do this, but it may not be SIP.
> |>
> |> If we go with Option 1, then we should certainly reuse existing RFCs
> |or IDs as
> |> possible examples but not try to redefine this set of operations.
> |>
> |> I agree we should make it clear which point of view we are using to
> |address
> |> the requirements.
> |>
> |>
> |> Steve Buko
> |>
> |>
> |>
> |> |-----Original Message-----
> |> |From: Even, Roni [mailto:[e-mail]]
> |> |Sent: Wednesday, March 21, 2007 9:54 AM
> |> |To: Steve Buko; Eric Burger; [e-mail]
> |> |Subject: RE: [MEDIACTRL] Re: Requirements Comment
> |> |
> |> |Steve,
> |> |I think I see were the problem here. I also discussed it with Martin.
> |> |
> |> |We can look at the requirements from two perspectives.
> |> |
> |> |1. The full solution requirements. How do you achieve a system
> |solution
> |> |2. Protocol only requirements.
> |> |
> |> |My point of view was the full solution requirements. This does not
> |mean
> |> |that the protocol needs to solve it since the requirement can be
> |> |addressed by other methods. Some of these system requirements can be
> |> |addressed in different means using other protocols and the working
> |group
> |> |should not endorse one way to address it.
> |> |
> |> |I think that we need to agree on what should the requirement cover -
> |is
> |> |it the protocol requirements or the system solution requirements.
> |> |
> |> |In this specific case if we look at protocol than I assume that we do
> |> |not need this requirement.
> |> |If we look at system solution requirement there need to be at least
> |on
> |> |way to do it.
> |> |
> |> |My view is that we should have system solution but maybe we should
> |> |mention that they are such.
> |> |
> |> |Thanks
> |> |Roni Even
> |> |
> |> |> -----Original Message-----
> |> |> From: Steve Buko [mailto:[e-mail]]
> |> |> Sent: Tuesday, March 20, 2007 4:05 PM
> |> |> To: Even, Roni; Eric Burger; [e-mail]
> |> |> Subject: RE: [MEDIACTRL] Re: Requirements Comment
> |> |>
> |> |> Right.  I think it all boils down to who owns this.
> |> |> My opinion is that this is not in scope for this group.  This is
> |not
> |> |> specific to media control.
> |> |>
> |> |> I really don't see this as being much different than a SIP AS
> |running
> |> |in
> |> |> 3PCC.  We don't need to define how an AS handles 3PCC and how it
> |> |> establishes the media.
> |> |>
> |> |> In the SIP 3PCC example, the inbound SIP INVITE comes to the AS and
> |it
> |> |> creates a new call leg to the MS with a separate INVITE.  The
> |INVITE
> |> |to
> |> |> the MS contains the SDP from the remote UA (or a modified version
> |of
> |> |it).
> |> |> In the end, the SDP in the 200OK from the MS is sent to the remote
> |UA.
> |> |> Media flows between the remote UA and the MS.  I don't think the
> |media
> |> |> control framework should try to define this process.
> |> |>
> |> |> The media control framework should only define how the AS interacts
> |> |with
> |> |> the MS to establish a control path.  The media control protocol
> |should
> |> |> define the language used to control the media server using the
> |media
> |> |> control framework.
> |> |>
> |> |>
> |> |> Steve Buko
> |> |>
> |> |>
> |> |> |-----Original Message-----
> |> |> |From: Even, Roni [mailto:[e-mail]]
> |> |> |Sent: Tuesday, March 20, 2007 2:55 PM
> |> |> |To: Steve Buko; Eric Burger; [e-mail]
> |> |> |Subject: RE: [MEDIACTRL] Re: Requirements Comment
> |> |> |
> |> |> |This is a good example.
> |> |> |
> |> |> |You have an h.323 call leg from the H.323 UA to the AS
> |(H.225+H.245).
> |> |> |The AS uses SIP to the MS for media server control (I think we are
> |> |not
> |> |> |defining media control but media server control).
> |> |> |
> |> |> |Now the H.323 UA will send an Open logical channel to the AS. The
> |AS
> |> |> |needs to respond with a transport address for the media in the
> |Open
> |> |> |Logical Channel ack. From where does the AS get this address. My
> |view
> |> |> |that it need to get it from the MS and this is the reason for the
> |> |> |requirement.
> |> |> |
> |> |> |Roni
> |> |> |
> |> |> |
> |> |> |> -----Original Message-----
> |> |> |> From: Steve Buko [mailto:[e-mail]]
> |> |> |> Sent: Tuesday, March 20, 2007 3:47 PM
> |> |> |> To: Eric Burger; [e-mail]
> |> |> |> Subject: RE: [MEDIACTRL] Re: Requirements Comment
> |> |> |>
> |> |> |> Another quick example might be an H.323 AS.
> |> |> |> It would use SIP only to establish the media control framework
> |> |path.
> |> |> |>
> |> |> |> Steve Buko
> |> |> |>
> |> |> |>
> |> |> |> |-----Original Message-----
> |> |> |> |From: Steve Buko [mailto:[e-mail]]
> |> |> |> |Sent: Tuesday, March 20, 2007 2:38 PM
> |> |> |> |To: Eric Burger; [e-mail]
> |> |> |> |Subject: RE: [MEDIACTRL] Re: Requirements Comment
> |> |> |> |
> |> |> |> |IMO we need to keep the MCF (media control framework) and the
> |MCP
> |> |> |(media
> |> |> |> |control protocol) separate and as open as possible.
> |> |> |> |
> |> |> |> |I think there are multiple use cases here.  One that comes to
> |mind
> |> |is
> |> |> |> |PSTN / ISUP, etc.
> |> |> |> |In this scenario, RTP and SIP are not used for call control or
> |> |media
> |> |> |> |transport.  The AS will be managing the call control external
> |to
> |> |the
> |> |> |> |MCF.  The AS will use the MCF and MCP to control the media
> |server
> |> |> |only.
> |> |> |> |
> |> |> |> |
> |> |> |> |My view is that the MCF should not be defined to handle call
> |> |control
> |> |> |> |signaling.  The MCF should be defined only for the transport of
> |> |the
> |> |> |MCP.
> |> |> |> |
> |> |> |> |The AS's call control signaling and media transport negotiation
> |> |> |should
> |> |> |> |be out of scope for this workgroup.
> |> |> |> |
> |> |> |> |
> |> |> |> |
> |> |> |> |Steve Buko
> |> |> |> |
> |> |> |> |
> |> |> |> ||-----Original Message-----
> |> |> |> ||From: Eric Burger [mailto:[e-mail]]
> |> |> |> ||Sent: Tuesday, March 20, 2007 2:30 PM
> |> |> |> ||To: [e-mail]
> |> |> |> ||Subject: [MEDIACTRL] Re: Requirements Comment
> |> |> |> ||
> |> |> |> ||I missed that one. IMHO, the AS has no need nor right to know
> |the
> |> |> |RTP
> |> |> |> ||address of the endpoint nor the termination address of the
> |media
> |> |> |> |server.
> |> |> |> ||What is the use case?
> |> |> |> ||
> |> |> |> ||--
> |> |> |> ||Sent from my wireless e-mail device. Sorry if terse.  We all
> |need
> |> |> |> ||lemonade: see <http://www.standardstrack.com/ietf/lemonade>
> |for
> |> |what
> |> |> |> ||lemonade is.
> |> |> |> ||
> |> |> |> ||-----Original Message-----
> |> |> |> ||From: Steve Buko <[e-mail]>
> |> |> |> ||To: Eric Burger; [e-mail] <[e-mail]>
> |> |> |> ||Sent: Tue Mar 20 06:16:38 2007
> |> |> |> ||Subject: Requirements Comment
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||I have a general issue regarding our current set of
> |requirements
> |> |and
> |> |> |> ||thought it might be a good idea to get a thread going on this
> |> |prior
> |> |> |to
> |> |> |> ||our Thursday meeting.
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||draft-even-media-server-req-02.txt
> |> |> |> ||<http://www.standardstrack.com/ietf/mediactrl/draft-even-
> |media-
> |> |> |server-
> |> |> |> ||req-02.txt>  states the following
> |> |> |> ||
> |> |> |> ||³10.  The MS shall supply the media addresses (RTP transport
> |> |> |address)
> |> |> |> ||to be used to the AS²
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||draft-dolly-xcon-mediacntrlframe-03.txt
> |> |> |> ||<http://www.standardstrack.com/ietf/mediactrl/draft-dolly-
> |xcon-
> |> |> |> ||mediacntrlframe-03.txt>  states the following
> |> |> |> ||
> |> |> |> ||³REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify
> |RTP
> |> |> |> ||connections to a Media Server²
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||In my view, we have two main problems to solve.
> |> |> |> ||
> |> |> |> ||1)     define a media control framework that will be used to
> |> |> |transmit a
> |> |> |> ||given media control protocol.
> |> |> |> ||
> |> |> |> ||2)    define a media control protocol used to control a media
> |> |> |server.
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||I agree that the media control framework should use SIP/SDP to
> |> |> |specify
> |> |> |> ||the protocol / transport used to negotiation the TCP port and
> |> |> |> ||transmit/receive the media control protocol.
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||However, I would offer that the media control protocol defined
> |by
> |> |> |this
> |> |> |> ||group should be ..
> |> |> |> ||
> |> |> |> ||1)     call control signaling agnostic
> |> |> |> ||
> |> |> |> ||2)    media transport agnostic
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||For this requirement Š
> |> |> |> ||
> |> |> |> ||draft-even-media-server-req-02.txt
> |> |> |> ||<http://www.standardstrack.com/ietf/mediactrl/draft-even-
> |media-
> |> |> |server-
> |> |> |> ||req-02.txt>  states the following
> |> |> |> ||
> |> |> |> ||³10.  The MS shall supply the media addresses (RTP transport
> |> |> |address)
> |> |> |> ||to be used to the AS²
> |> |> |> ||
> |> |> |> ||I don¹t understand why the AS would need the media addresses
> |and
> |> |> |would
> |> |> |> ||like to think that the AS would like to control a media server
> |> |that
> |> |> |may
> |> |> |> ||not be using RTP in all scenarios.
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||For this requirement Š
> |> |> |> ||
> |> |> |> ||draft-dolly-xcon-mediacntrlframe-03.txt
> |> |> |> ||<http://www.standardstrack.com/ietf/mediactrl/draft-dolly-
> |xcon-
> |> |> |> ||mediacntrlframe-03.txt>  states the following
> |> |> |> ||
> |> |> |> ||³REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify
> |RTP
> |> |> |> ||connections to a Media Server²
> |> |> |> ||
> |> |> |> ||I agree that SIP/SDP should be used to establish/negotiate the
> |> |TCP
> |> |> |> ||port/address used for media control transport, however I don¹t
> |> |think
> |> |> |> ||RTP comes into play from a media control framework
> |perspective.
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||My high level comment is that we should not limit the use of
> |our
> |> |> |media
> |> |> |> ||control protocol to media servers that only support SIP and
> |RTP.
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||Steve Buko
> |> |> |> ||
> |> |> |> ||
> |> |> |> ||
> |> |> |>
> |> |>
> |>
> |||||____________________________________________________________________
> |_
> |> |_
> |> |> |_
> |> |> |> ||Notice:  This email message, together with any attachments,
> |may
> |> |> |contain
> |> |> |> ||information  of  BEA Systems,  Inc.,  its subsidiaries  and
> |> |> |affiliated
> |> |> |> ||entities,  that may be confidential,  proprietary,
> |copyrighted
> |> |> |and/or
> |> |> |> ||legally privileged, and is intended solely for the use of the
> |> |> |> ||individual or entity named in this message. If you are not the
> |> |> |intended
> |> |> |> ||recipient, and have received this message in error, please
> |> |> |immediately
> |> |> |> ||return this by email and then delete it.
> |>
> |
> |
> |_______________________________________________________________________
> |Notice:  This email message, together with any attachments, may contain
> |information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> |entities,  that may be confidential,  proprietary,  copyrighted  and/or
> |legally privileged, and is intended solely for the use of the individual
> |or entity named in this message. If you are not the intended recipient,
> |and have received this message in error, please immediately return this
> |by email and then delete it.
> 


_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

_______________________________________________
MEDIACTRL mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl