Subject: [MEDIACTRL] Re: Requirements Comment

From: "Eric Burger" <[email-masked]>
Date: Tue, 20 Mar 2007 06:30:14 -0700

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 <[email-masked]>
To: Eric Burger; [email-masked] <[email-masked]>
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Steve Buko" <[email-masked]>
Date: Tue, 20 Mar 2007 06:38:15 -0700

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:[email-masked]]
|Sent: Tuesday, March 20, 2007 2:30 PM
|To: [email-masked]
|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 <[email-masked]>
|To: Eric Burger; [email-masked] <[email-masked]>
|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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Steve Buko" <[email-masked]>
Date: Tue, 20 Mar 2007 06:47:11 -0700

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:[email-masked]]
|Sent: Tuesday, March 20, 2007 2:38 PM
|To: Eric Burger; [email-masked]
|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:[email-masked]]
||Sent: Tuesday, March 20, 2007 2:30 PM
||To: [email-masked]
||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 <[email-masked]>
||To: Eric Burger; [email-masked] <[email-masked]>
||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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 20 Mar 2007 15:54:50 +0200

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

> From: Steve Buko [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2007 3:47 PM
> To: Eric Burger; [email-masked]
> Subject: RE: [MEDIACTRL] Re: Requirements Comment
>

---

From: <[email-masked]>
Date: Tue, 20 Mar 2007 09:56:23 -0400

Regarding

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 believe that requirement was stated partly because at the time it was
(apparently?) the view of the group that that was the case that really
mattered - certainly my view. I'm not against revisiting that, but I
think we want to be careful about specifically what cases we believe
we're covering. Not sure we want to be completely agnostic, i.e. that
the signaling/transport can be anything at all. (For example, inband
signaling somewhere in the path?)

cheers,

Gary

-----Original Message-----
From: Steve Buko [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 9:47 AM
To: Eric Burger; [email-masked]
Subject: RE: [MEDIACTRL] Re: Requirements Comment

Steve Buko 

|-----Original Message-----
|From: Steve Buko [mailto:[email-masked]]
|Sent: Tuesday, March 20, 2007 2:38 PM
|To: Eric Burger; [email-masked]
|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:[email-masked]]
||Sent: Tuesday, March 20, 2007 2:30 PM
||To: [email-masked]
||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 <[email-masked]>
||To: Eric Burger; [email-masked] <[email-masked]>
||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.

---

From: "Steve Buko" <[email-masked]>
Date: Tue, 20 Mar 2007 07:04:57 -0700

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:[email-masked]]
|Sent: Tuesday, March 20, 2007 2:55 PM
|To: Steve Buko; Eric Burger; [email-masked]
|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:[email-masked]]
|> Sent: Tuesday, March 20, 2007 3:47 PM
|> To: Eric Burger; [email-masked]
|> 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:[email-masked]]
|> |Sent: Tuesday, March 20, 2007 2:38 PM
|> |To: Eric Burger; [email-masked]
|> |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:[email-masked]]
|> ||Sent: Tuesday, March 20, 2007 2:30 PM
|> ||To: [email-masked]
|> ||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 <[email-masked]>
|> ||To: Eric Burger; [email-masked] <[email-masked]>
|> ||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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: <[email-masked]>
Date: Tue, 20 Mar 2007 10:24:23 -0400

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:[email-masked]] 
Sent: Tuesday, March 20, 2007 10:05 AM
To: Even, Roni; Eric Burger; [email-masked]
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 

|> |I think there are multiple use cases here.  One that comes to mind
is
|> ||lemonade: see <http://www.standardstrack.com/ietf/lemonade> for
what
|> ||I have a general issue regarding our current set of requirements
and
|> ||"10.  The MS shall supply the media addresses (RTP transport
|> ||to be used to the AS"
|> ||"REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify RTP
|> ||connections to a Media Server"
|> ||For this requirement ...
|> ||"10.  The MS shall supply the media addresses (RTP transport
|> ||to be used to the AS"
|> ||I don't understand why the AS would need the media addresses and
|> ||For this requirement ...
|> ||"REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify RTP
|> ||connections to a Media Server"
|> ||port/address used for media control transport, however I don't
think
|||_____________________________________________________________________

---

From: "Steve Buko" <[email-masked]>
Date: Tue, 20 Mar 2007 07:37:59 -0700

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: [email-masked] [mailto:[email-masked]]
|Sent: Tuesday, March 20, 2007 3:24 PM
|To: [email-masked]
|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:[email-masked]]
|Sent: Tuesday, March 20, 2007 10:05 AM
|To: Even, Roni; Eric Burger; [email-masked]
|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:[email-masked]]
||Sent: Tuesday, March 20, 2007 2:55 PM
||To: Steve Buko; Eric Burger; [email-masked]
||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:[email-masked]]
||> Sent: Tuesday, March 20, 2007 3:47 PM
||> To: Eric Burger; [email-masked]
||> 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:[email-masked]]
||> |Sent: Tuesday, March 20, 2007 2:38 PM
||> |To: Eric Burger; [email-masked]
||> |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:[email-masked]]
||> ||Sent: Tuesday, March 20, 2007 2:30 PM
||> ||To: [email-masked]
||> ||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 <[email-masked]>
||> ||To: Eric Burger; [email-masked] <[email-masked]>
||> ||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
[email-masked]
|https://www1.ietf.org/mailman/listinfo/mediactrl
|Supplemental Web Site:
|http://www.standardstrack.com/ietf/mediactrl

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 09:43:16 +0100

Actually, H.323, ISDN, SS7, and non-RFC 1149 compliant carrier pigeon are
all out of scope.

We can revisit those bearer technologies at a future date.

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 21 Mar 2007 10:53:39 +0200

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

> Sent: Tuesday, March 20, 2007 4:05 PM
> 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.
>

---

From: "Steve Buko" <[email-masked]>
Date: Wed, 21 Mar 2007 02:06:44 -0700

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:[email-masked]]
|Sent: Wednesday, March 21, 2007 9:54 AM
|To: Steve Buko; Eric Burger; [email-masked]
|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:[email-masked]]
|> Sent: Tuesday, March 20, 2007 4:05 PM
|> To: Even, Roni; Eric Burger; [email-masked]
|> 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:[email-masked]]
|> |Sent: Tuesday, March 20, 2007 2:55 PM
|> |To: Steve Buko; Eric Burger; [email-masked]
|> |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:[email-masked]]
|> |> Sent: Tuesday, March 20, 2007 3:47 PM
|> |> To: Eric Burger; [email-masked]
|> |> 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:[email-masked]]
|> |> |Sent: Tuesday, March 20, 2007 2:38 PM
|> |> |To: Eric Burger; [email-masked]
|> |> |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:[email-masked]]
|> |> ||Sent: Tuesday, March 20, 2007 2:30 PM
|> |> ||To: [email-masked]
|> |> ||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 <[email-masked]>
|> |> ||To: Eric Burger; [email-masked] <[email-masked]>
|> |> ||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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 10:46:39 +0100

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" <[email-masked]> wrote:

> 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.
> 
> |> |> ||³10.  The MS shall supply the media addresses (RTP transport
> |> |address)
> |> |> ||to be used to the AS²
> |> |> ||
> |> |> ||
> |> |> ||
> |> |> ||³REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify RTP
> |> |> ||connections to a Media Server²
> |> |> ||
> |> |> ||
> |> |> ||
> |> |> ||
> |> |> ||
> |> |> ||For this requirement Š
> |> |> ||
> |> |> ||³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
> |> |> ||For this requirement Š
> |> |> ||
> |> |> ||³REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify RTP
> |> |> ||connections to a Media Server²
> |> |> ||
> |> |> ||port/address used for media control transport, however I don¹t
> |think

---

From: "Steve Buko" <[email-masked]>
Date: Wed, 21 Mar 2007 02:57:19 -0700

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:[email-masked]]
|Sent: Wednesday, March 21, 2007 10:47 AM
|To: Steve Buko; [email-masked]
|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" <[email-masked]> 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:[email-masked]]
|> |Sent: Wednesday, March 21, 2007 9:54 AM
|> |To: Steve Buko; Eric Burger; [email-masked]
|> |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:[email-masked]]
|> |> Sent: Tuesday, March 20, 2007 4:05 PM
|> |> To: Even, Roni; Eric Burger; [email-masked]
|> |> 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:[email-masked]]
|> |> |Sent: Tuesday, March 20, 2007 2:55 PM
|> |> |To: Steve Buko; Eric Burger; [email-masked]
|> |> |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:[email-masked]]
|> |> |> Sent: Tuesday, March 20, 2007 3:47 PM
|> |> |> To: Eric Burger; [email-masked]
|> |> |> 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:[email-masked]]
|> |> |> |Sent: Tuesday, March 20, 2007 2:38 PM
|> |> |> |To: Eric Burger; [email-masked]
|> |> |> |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:[email-masked]]
|> |> |> ||Sent: Tuesday, March 20, 2007 2:30 PM
|> |> |> ||To: [email-masked]
|> |> |> ||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 <[email-masked]>
|> |> |> ||To: Eric Burger; [email-masked] <[email-masked]>
|> |> |> ||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.

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 11:01:34 +0100

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" <[email-masked]> wrote:

> 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. 
>

---

From: Diego B <[email-masked]>
Date: Wed, 21 Mar 2007 13:02:14 +0200

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

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 21 Mar 2007 13:06:51 +0200

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

> From: Diego B [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2007 1:02 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] Re: Requirements Comment
> 
> >> I was not aware that the media control framework would be used to
> initiate
> >> calls.
> >>
> >>
> >> Steve Buko
> >>
> >>

---

From: Diego B <[email-masked]>
Date: Wed, 21 Mar 2007 13:12:08 +0200

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:
>>> It’s not (to be used to initiate calls), but we need to make that
>>>       
>> explicit.
>>     
>>>> relationships between media control channels and call legs for media
>>>>         
>> control
>>     
>>>> purposes only.
>>>>
>>>> |It is very much in scope as it is one of the issues to be resolved.
>>>>         
>> One
>>     
>>>> |and manipulate RTP streams (i.e., calls the AS is unaware of).
>>>>         
>> Another
>>     
>>>> |> perspective, SIP signaling for the establishment of the call legs
>>>>         
>> and
>>     
>>>> |media
>>>> |> |I think I see were the problem here. I also discussed it with
>>>>         
>> Martin.
>>     
>>>> |> |
>>>> |> |addressed by other methods. Some of these system requirements can
>>>>         
>> be
>>     
>>>> |> |I think that we need to agree on what should the requirement cover
>>>>         
>> -
>>     
>>>> |is
>>>> |> |In this specific case if we look at protocol than I assume that we
>>>>         
>> do
>>     
>>>> |> |> In the SIP 3PCC example, the inbound SIP INVITE comes to the AS
>>>>         
>> and
>>     
>>>> |it
>>>> |> |> In the end, the SDP in the 200OK from the MS is sent to the
>>>>         
>> remote
>>     
>>>> |UA.
>>>> |> |> The media control framework should only define how the AS
>>>>         
>> interacts
>>     
>>>> |> |with
>>>> |> |> |The AS uses SIP to the MS for media server control (I think we
>>>>         
>> are
>>     
>>>> |> |not
>>>> |> |> |Now the H.323 UA will send an Open logical channel to the AS.
>>>>         
>> The
>>     
>>>> |AS
>>>> |> |> |that it need to get it from the MS and this is the reason for
>>>>         
>> the
>>     
>>>> |> |> |requirement.
>>>> |> |> |
>>>> |> |> |Roni
>>>> |> |> |
>>>> |> |> |
>>>> |> |> |> |In this scenario, RTP and SIP are not used for call control
>>>>         
>> or
>>     
>>>> |> |media
>>>> |> |> |> |signaling.  The MCF should be defined only for the transport
>>>>         
>> of
>>     
>>>> |> |the
>>>> |> |> |MCP.
>>>> |> |> |> |
>>>> |> |> |> |The AS's call control signaling and media transport
>>>>         
>> negotiation
>>     
>>>> |> |> |should
>>>> |> |> |> ||I missed that one. IMHO, the AS has no need nor right to
>>>>         
>> know
>>     
>>>> |the
>>>> |> |> |RTP
>>>> |> |> |> ||thought it might be a good idea to get a thread going on
>>>>         
>> this
>>     
>>>> |> |prior
>>>> |> |> |to
>>>> |> |> |> ||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
>>     
>>>> |> |> |> ||However, I would offer that the media control protocol
>>>>         
>> defined
>>     
>>>> |by
>>>> |> |> |this
>>>> |> |> |> ||like to think that the AS would like to control a media
>>>>         
>> server
>>     
>>>> |> |that
>>>> |> |> |may
>>>> |> |> |> ||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
>>>> |> |> |> ||legally privileged, and is intended solely for the use of
>>>>         
>> the
>>     
>>>> |> |> |> ||individual or entity named in this message. If you are not
>>>>         
>> the
>>     
>>>> |> |> |intended
>>>> |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
>>

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 21 Mar 2007 13:14:15 +0200

correct

> Sent: Wednesday, March 21, 2007 1:12 PM
> To: Even, Roni
> Cc: Eric Burger; [email-masked]
> > 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
> >
> >>>> |> |> |> ||lemonade: see
> <http://www.standardstrack.com/ietf/lemonade>
> >>>> |for
> >>>> |> |what
> >>>> |> |> |> ||lemonade is.
> >>>> |> |> |> ||

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 13:38:23 +0100

I was referring to the connection between any given AS with any given MS.
The relationship is for the control channel.  AS:MS is n:n.

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 21 Mar 2007 15:48:14 +0100

Steven,

At the risk of being a process weenie, the next e-mail I received on this 
list was Cullen's saying that the working group had been FORMED, so I would 
certainly hope that the number of decisions that have been made by the 
working group is fairly low.

(How can you be late if the announcement went out this week? :-)

Spencer

From: "Steve Buko" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 20, 2007 3:37 PM
Subject: RE: [MEDIACTRL] Re: Requirements Comment

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.

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 16:02:26 +0100

Agreed!

(With Chair Hat On)

Of course, some things *have* been agreed - that is how we got the charter
:-)

---

From: Diego B <[email-masked]>
Date: Wed, 21 Mar 2007 17:12:32 +0200

Hi;
In general requirements item 7
> 7. The MS shall supply the media addresses (RTP transport address)
> to be used to the AS
I hope RTP is given as an example and not the only transport to be 
supported.
For example MSRP can be another transport to be supported.

In IVR requirement, why there is no requirements for recording a session 
(to an external or internal storage), or a mix of sessions ?
There is also no requirements for transcoding or session rely

Regards
Diego B

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 19:13:03 +0100

Nope, RTP is the only transport to be supported.  MSRP relays are
fundamentally different from Media Servers.  Again, the media server needs
to give an application-level representation of the leg, but most likely
(i.e., not bloody likely) not the RTP IP address / port number.

IVR: recording, yes.  Internal storage: probably to a URI;
implementation-specific if the media server supports file: (which might
resolve to NFS, anyway).

IVR Mixing: that's the definition of conferencing, so that is not in the IVR
world.

Transcoding: I guess we always assumed that "just happens."  Probably should
mention it, anyway.

---

From: "Steve Buko" <[email-masked]>
Date: Wed, 21 Mar 2007 11:46:41 -0700

|Again, the media server needs
|to give an application-level representation of the leg, but most likely
|(i.e., not bloody likely) not the RTP IP address / port number.

Agreed, regarding the representation of the leg.

I think the most "open" way for this to be accomplished is for the media
control "protocol" to define the process by which the AS and MS generate
an identifier that is associated with each call leg.

I'm not sure that this should be tied to RTP for this representation
though.  Doing so will limit the use of our work to RTP only use cases
when there really isn't a good reason to do so.  At the end of the day,
the AS simply wants to control the media operations for a particular
call leg.  It needs an identifier for that call.

If we do this right and define an extensible procedure for defining this
call leg identification, our work could be used in many scenarios other
than SIP/RTP.

Steve Buko 

|-----Original Message-----
|From: Eric Burger [mailto:[email-masked]]
|Sent: Wednesday, March 21, 2007 7:13 PM
|To: Diego B; [email-masked]
|Subject: Re: [MEDIACTRL] Re: Requirements Comment
|
|Nope, RTP is the only transport to be supported.  MSRP relays are
|fundamentally different from Media Servers.  Again, the media server
|needs
|to give an application-level representation of the leg, but most likely
|(i.e., not bloody likely) not the RTP IP address / port number.
|

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 21 Mar 2007 20:03:51 +0100

> an identifier that is associated with each call leg.

Yes, I agree too. The first thing that comes to my mind would be using some kind
of generic 'session' identifier, whereas this mixer session could easily map to
a conference, to a call among two or more users or to whatever the AS could
need the mixer for. In the same way, generic 'peer' entities could be used to
identify the involved parties.

> call leg identification, our work could be used in many scenarios other

Cheers,
Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Eric Burger <[email-masked]>
Date: Thu, 22 Mar 2007 00:23:24 +0100

I would strongly suggest people review RFC 4722 and draft-saleem-msml-02 for
the use of SIP dialog identifiers for addressing legs.

---

From: "Adnan Saleem" <[email-masked]>
Date: Thu, 22 Mar 2007 04:10:48 -0700

Hi Roni,

The Requirements slides and the requirements draft
(draft-even-media-server-req-02.txt) have an old/invalid 
reference to MSML.

draft-melanchuk-sipping-msml-07
draft-melanchuk-sipping-moml-06

should be:

draft-saleem-msml-02
(http://www.ietf.org/internet-drafts/draft-saleem-msml-02.txt)

thanks

Adnan

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 22 Mar 2007 13:13:11 +0200

Thanks,
The draft for sure.
In the slides I trued to look what are the latest and I apologize if I
made a mistake.
Roni

> From: Adnan Saleem [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 1:11 PM
> To: Even, Roni; [email-masked]
> Subject: Requirements (current protocols)
> 
> 
> Hi Roni,
>

---

From: "Adnan Saleem" <[email-masked]>
Date: Thu, 22 Mar 2007 04:18:30 -0700

NP, thanks for updating this in the next rev of 
the draft.

Adnan 

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: March 22, 2007 4:13 AM
To: Adnan Saleem; [email-masked]
Subject: RE: Requirements (current protocols)

Thanks,
The draft for sure.
In the slides I trued to look what are the latest and I apologize if I made
a mistake.
Roni

> (draft-even-media-server-req-02.txt) have an old/invalid reference to 
> MSML.
>