Subject: [MEDIACTRL] Minutes

From: Eric Burger <[email-masked]>
Date: Wed, 06 Dec 2006 21:46:41 -0500

Any comments on the minutes?  If not, I'll remove the DRAFT legend and call
them done.

Thanks.

http://www3.ietf.org/proceedings/06nov/minutes/mediactrl.txt

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 7 Dec 2006 03:48:41 -0600

Eric, looks good, Martin 

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, December 06, 2006 9:47 PM
To: Media Control
Subject: [MEDIACTRL] Minutes

Any comments on the minutes?  If not, I'll remove the DRAFT legend and
call
them done.

Thanks.

---

From: "Adnan Saleem" <[email-masked]>
Date: Thu, 7 Dec 2006 11:47:27 -0800

A few comments and proposed changes to Charter wording.

1. "The expectation is such a means would build upon existing SIP, SNMP, and
other protocol facilities."

   >> Propose removing SNMP from this section as it seems to imply use of
SNMP
   >> is required/preferred. I think it's a bit too early to decide on SNMP
in 
   >> the charter while SNMP may not be the preferred interface for this.

2. "Given the above-mentioned conferencing example, the work of this group
is of interest to the XCON work group, as this protocol will describe the
"Protocol used between the conference controller and the mixer(s)." Thus we
expect to work closely with XCON."

   >> The "work closely" may be interpreted in many ways, so I think this
should be
   >> clarified. I think that the work we do in MediaCtrl should certainly
ensure that
   >> it meets XCON's media processing needs, and not that the work we do in
MediaCtrl
   >> to feed into and drive XCON in anyway.

3. "The protocol suite also is an embodiment of the ISC/Mr interface from
the 3GPP IMS architecture"

   >> Suggest rephrasing to "The protocol suite may be used to meet the
needs of the ISC/Mr interface"

4. "If the work group requires extensions to SIP, the work group will
forward those extensions to the SIP work group for consideration and
refinement"

   >> this may go without saying, but we may want to add that "extensions to
SIP should be avoided if possible"

thanks

Adnan

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 11 Dec 2006 10:30:57 +0100

Hi Adnan,

> [cut]

Would such a statement really be needed? Even if extensions would be 
added to SIP, their use would be limited to the AS-MS interaction, and 
not affect any other kind of existing interactions from the UA towards 
anyone, since as I've understood the MS will never have direct signaling 
with any UA.

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]

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sat, 16 Dec 2006 23:32:37 +0100

Aside from the fact that when the MS is driven by a server, that server is quite frequently acting in 3rd part call control mode, and therefore provides UA functionality, currently the 3GPP IMS procedures so allow the UE (i.e. UA for the end user) to address the MRFC. Whether operators would release such a URI is up to the operators.

Regards

Keith 

> From: Lorenzo Miniero [mailto:[email-masked]] 
> Sent: 11 December 2006 09:31
> To: [email-masked]
> Subject: Re: [MEDIACTRL] Charter
> 
> Hi Adnan,
> 
> > [cut]
> >
> >    >> this may go without saying, but we may want to add that 
> > "extensions to SIP should be avoided if possible"
> >   
> 
> Would such a statement really be needed? Even if extensions 
> would be added to SIP, their use would be limited to the 
> AS-MS interaction, and not affect any other kind of existing 
> interactions from the UA towards anyone, since as I've 
> understood the MS will never have direct signaling with any UA.
> 
> Cheers,
> Lorenzo
> 
> --
> Dipartimento di Informatica e Sistemistica Università degli 
> Studi di Napoli "Federico II"

---

From: Eric Burger <[email-masked]>
Date: Tue, 19 Dec 2006 15:09:12 -0500

Precisely.

On 12/16/06 5:32 PM, "Drage, Keith (Keith)" <[email-masked]>
wrote:

> Aside from the fact that when the MS is driven by a server, that server is
> quite frequently acting in 3rd part call control mode, and therefore provides
> UA functionality, currently the 3GPP IMS procedures so allow the UE (i.e. UA
> for the end user) to address the MRFC. Whether operators would release such a
> URI is up to the operators.
> 
> Regards
> 
> Keith
>