RE: [MEDIACTRL] Re: Requirements Comment

["Even, Roni" <[e-mail]>]

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.

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