Re: [MEDIACTRL] Re: Requirements Comment

[Diego B <[e-mail]>]

So to summarize;
There is a 1:many and many:1 relation between AS and MS where in each 
AS:MS connection can be several sessions managed.

Regards
Diego B

Even, Roni wrote:
> Single connection means between an AS and an MS. This control channel may be used for controlling many sessions managed by an AS on the MS
>
> You can have many AS connect to one MS and one AS may connect to many MS
>
> Roni
>  
>
>   
>> -----Original Message-----
>> From: Diego B [mailto:[e-mail]]
>> Sent: Wednesday, March 21, 2007 1:02 PM
>> To: Eric Burger
>> Cc: [e-mail]
>> Subject: Re: [MEDIACTRL] Re: Requirements Comment
>>
>> 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
>>     



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