RE: [MEDIACTRL] Re: Requirements Comment

["Even, Roni" <[e-mail]>]

correct

> -----Original Message-----
> From: Diego B [mailto:[e-mail]]
> Sent: Wednesday, March 21, 2007 1:12 PM
> To: Even, Roni
> Cc: Eric Burger; [e-mail]
> Subject: Re: [MEDIACTRL] Re: Requirements Comment
> 
> 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