RE: [MEDIACTRL] Re: Requirements Comment

["Steve Buko" <[e-mail]>]

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