Re: [MEDIACTRL] Re: Requirements Comment

[Diego B <[e-mail]>]

What do you mean with a single control connection ?
 tha for the same AS and MS exists only one connection between them or 
that the AS can only be connected to
one MS ?

Like Steve, I was thinking of a full 1:many and many:1 relation between 
AS and MS.

And, pls can you explain what do you mean with initiate calls ?

Thanks
Diego B

Eric Burger wrote:
> 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
>   



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