RE: [MEDIACTRL] Re: Requirements Comment

["Chris Boulton" <[e-mail]>]

Just for future reference - I am in favor of 'carrier pigeon' support
with QOS (http://www.ietf.org/rfc/rfc2549.txt?number=2549).  Let not get
discriminatory.

Chris.
 

-----Original Message-----
From: Eric Burger [mailto:[e-mail]] 
Sent: 21 March 2007 08:43
To: Steve Buko; Gary Munson; [e-mail]
Subject: Re: [MEDIACTRL] Re: Requirements Comment

Actually, H.323, ISDN, SS7, and non-RFC 1149 compliant carrier pigeon
are
all out of scope.

We can revisit those bearer technologies at a future date.


On 3/20/07 3:37 PM, "Steve Buko" <[e-mail]> wrote:

> Ok.  This is a very basic decision that the group needs to make IMO.
> Apparently I am late to the party and this decision may have already
> been made, but I would like everyone to revisit.  It seems to me that
we
> are biting off a whole lot more than we really need to.
> 
> App Server 3PCC signaling has already been defined in RFC 3725 - "Best
> Current Practices for Third Party Call Control (3pcc) in the Session
> Initiation Protocol (SIP)".
> 
> I really don't see the need for this workgroup to define this level of
> operation.  I do think the group must define how the media control
> protocol identifies the call leg (SIP,H.323,ISDN,ISUP,etc) when
sending
> media control protocol bodies to the MS.
> 
> Steve Buko 
> 
> 
> 
> |-----Original Message-----
> |From: [e-mail] [mailto:[e-mail]]
> |Sent: Tuesday, March 20, 2007 3:24 PM
> |To: [e-mail]
> |Subject: RE: [MEDIACTRL] Re: Requirements Comment
> |
> |I'm more or less on the same wavelength as Lorenzo. I don't think we
> |should ignore the topic of call control signaling, since there is a
> |relationship. I feel it should be in scope, although there could be
> |different ways to handle that (requirements or illustrations or
> |assumptions).
> |
> |Gary
> |
> |-----Original Message-----
> |From: Steve Buko [mailto:[e-mail]]
> |Sent: Tuesday, March 20, 2007 10:05 AM
> |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.
> |
> |_______________________________________________
> |MEDIACTRL mailing list
> |[e-mail]
> |https://www1.ietf.org/mailman/listinfo/mediactrl
> |Supplemental Web Site:
> |http://www.standardstrack.com/ietf/mediactrl
> 
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

_______________________________________________________________________
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



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. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.


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