RE: [MEDIACTRL] Re: Requirements Comment

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

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.

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