Subject: Re: [MEDIACTRL] MS capabilities

From: Eric Burger <[email-masked]>
Date: Tue, 03 Apr 2007 23:35:47 -0400

The AS needs to understand SDP *IF AND ONLY IF* it forwards non-SIP, non-SDP
calls.  However, for SIP calls (which is what most of us care about), the AS
*DOES NOT NEED* to understand SDP.

Please don't burden us with the corner case.  If you are building a full
signaling gateway (e.g., H.323 - SIP or ISUP - SIP), the little bit extra to
do SDP is trivial.  If you are building a SIP application server, there is
no need to build-in a requirement to parse SDP.

On 3/29/07 11:53 AM, "Lorenzo Miniero" <[email-masked]> wrote:

> Hi Roni and Eric,
> 
> I was thinking the same thing: the AS will need to gateway different
> CSP, and so will need to parse and talk SIP/SDP anyway in order to
> forward non-SIP calls to the MS.
> 
> Lorenzo
> 
> 
>> Eric,
>> So that goes to the question if the AS is B2BUA.
>> 
>> What about the event package, who consolidate it if the conference span
>> over two MS.
>> 
>> What about H.323 clients calling an XCON AS, do you see the AS just
>> sending H.323 to the MS.
>> 
>> Roni
>> 
>>> -----Original Message-----
>>> From: Eric Burger [mailto:[email-masked]]
>>> Sent: Thursday, March 29, 2007 5:25 PM
>>> To: Even, Roni
>>> Cc: [email-masked]
>>> Subject: Re: [MEDIACTRL] MS capabilities
>>> 
>>> Wrong layer in the stack:  "label" is an SDP attribute.  That means
>> the AS
>>> MUST parse and understand the SDP, hack in a label, associate it with
>> a
>>> SIP
>>> dialog and track it around.  Requiring the AS to parse and understand
>> SDP
>>> is
>>> not good.  Allowing it is good, if the AS *does* care about
>> manipulating
>>> SDP, but I would offer that will be rare.
>>> 
>>> The AS lives in the SIP level of the stack.  The *only* thing the AS
>> must
>>> track is SIP dialogs.  I could see, as a hack to work around busted
>>> B2BUA's,
>>> adding a dialog identifier header.  Moreover, I could see the value of
>>> that
>>> header being the AS' view of CallID, To, and From.  The MS would
>> consider
>>> it
>>> an opaque tag.
>>> 
>>> I *really* do not like that approach, as it burdens the MS with a ton
>> of
>>> state, associating this opaque tag with the real dialog ID.  Worse
>> yet, it
>>> re-opens all of the security problems enumerated in mscl-thoughts
>>> <http://www.faqs.org/ftp/internet-drafts/draft-burger-mscl-thoughts-
>>> 01.txt>.
>>> 
>>> 
>>> On 3/29/07 11:14 AM, "Even, Roni" <[email-masked]> wrote:
>>> 
>>>> Eric,
>>>> I am repeating myself. We had the same issue in the conference event
>>> package;
>>>> need to correlate between users and media in the notification and
>> the
>>> SIP
>>>> dialog. RFC 4575 only use SIP information.
>>>> Roni
>>>> 
>>>>> -----Original Message-----
>>>>> From: Eric Burger [mailto:[email-masked]]
>>>>> Sent: Thursday, March 29, 2007 3:19 PM
>>>>> To: Diego B
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [MEDIACTRL] MS capabilities
>>>>> 
>>>>> [As participant]
>>>>> 
>>>>> To reiterate: B2BUA's are undefined network elements.  It is not
>> worth
>>>>> debating if they are good or bad.  Let us just say that it is the
>>>>> responsibility of the B2BUA to keep up with new protocols, not the
>>>>> responsibility of the IETF to hack protocols to keep up with poor
>> B2BUA
>>>>> implementations.  A good B2BUA implementation will manage the
>> protocol
>>>>> appropriately.
>>>>> 
>>>>> [I am saying this as participant, and not chair, as I might be
>>> convinced
>>>>> that we need such a beast anyway.  Jumping way ahead to
>> implementation,
>>> I
>>>>> can just imagine Keith and Dean's reaction when we send a
>> requirement
>>> to
>>>>> the
>>>>> SIP Work Group asking for a mechanism (i.e., header) that looks,
>> acts,
>>> and
>>>>> behaves like the SIP Dialog ID, but isn't the SIP Dialog ID...]
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/29/07 6:31 AM, "Diego B" <[email-masked]> wrote:
>>>>> 
>>>>>> Inline
>>>>>> 
>>>>>> Regards
>>>>>> Diego B
>>>>>> 
>>>>>> Chris Boulton wrote:
>>>>>>> I agree, we can not decide on how the deployment may look like.
>>>>>>> There can be a B2BUA for several reasons ( I can think of:
>> Billing
>>>>>>> Mediation, Policy, Codec enforcement,
>>>>>>> Bandwith Allocation based on SDP negotiation on a wireless
>>> environment,
>>>>>>> etc).
>>>>>>> 
>>>>>>> [Chris Boulton] There COULD be - BUT we certainly shouldn't mold
>> out
>>>>>>> core solution based on the presence of a meddling middle box.
>>>>>>> 
>>>>>> [DB] Yes, I agree with you, but those boxes are widely deployed.
>> It is
>>>>> not
>>>>>> an sporadic example. Those B2BUA are everywhere.
>>>>>> 
>>>>>>> We may check others possibilities to coreleate  the SIP dialog
>> and
>>> the
>>>>>>> media channel.
>>>>>>> Anything related to the AS<==>MS Dialog ID can be broken by a
>> B2BUA
>>> in
>>>>>>> the middle
>>>>>>> (AS<==>B2BUA<==>MS)
>>>>>>> 
>>>>>>> [Chris Boulton] Yes - The core solution will currently break.
>>>>>>> 
>>>>>>> We can think of an identifier sent from the MS to the AS in the
>> 200
>>> OK
>>>>>>> in a SIP header tag.
>>>>>>> ( A similar method was proposed to return the KA mechanism in the
>>>>>>> outbound draft).
>>>>>>> 
>>>>>>> [Chris Boulton] What is the difference?  You are still not
>> guaranteed
>>>>>>> that a B2BUA will pass this through - remember, nothing in their
>>>>>>> behavior is standard in this context.
>>>>>>> Just a draft description:
>>>>>>> AS "hints" (optional) a Session ID to the MS in the new SIP
>> Header
>>> tag.
>>>>>>> if the MS accepts the session ID, it replicates it on the 200 OK
>>>>>>> if not, it returns a new generated ID to the AS.
>>>>>>> 
>>>>>>> [Chris Boulton] Again - how do you know for sure this traverses
>> the
>>>>>>> B2BUA?
>>>>>>> 
>>>>>> [DB]I don't know (Keep reading). But if this is a case, a B2BUA
>> will
>>>>>> break any new SIP extension
>>>>>> that adds/extends  SIP headers.
>>>>>>> Then this Session ID is used in the control channel.
>>>>>>> 
>>>>>>> Now any B2BUA in the middle must forward any unknown SIP
>> header/tag
>>>>>>> untouched :)
>>>>>>> 
>>>>>>> [Chris Boulton] BINGO!!!! - This is the very reason why this
>> can't be
>>>>> in
>>>>>>> the core solution.
>>>>>>> 
>>>>>> [DB] You reach the smiley ;)
>>>>>>> I saw this behavior so far, any comments ?
>>>>>>> 
>>>>>>> [Chris Boulton] As I said earlier - we should keep the core
>> without
>>>>> such
>>>>>>> assumptions.  If folks REALLY think this is a requirement then we
>>> need
>>>>>>> to look at an extension Relay solution (as MSRP has done) which
>> is
>>>>> aware
>>>>>>> of its requirements.  I think that should be the basis for
>> further
>>>>>>> discussion in the future.
>>>>>>> 
>>>>>> [DB] This is a basic requirement. And I think this has to be
>> defined
>>>>> soon.
>>>>>> I agree with you that we should keep the core without such
>>> assumptions,
>>>>> but
>>>>>> we have real world out there that uses B2BUAs and we can not
>> ignore
>>> it.
>>>>>> Diego B
>>>>>> 
>>>>>>> Chris.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Information contained in this e-mail and any attachments are
>> intended
>>>>> for the
>>>>>>> use of the addressee only, and may contain confidential
>> information
>>> of
>>>>>>> Ubiquity Software Corporation. All unauthorized use, disclosure
>> or
>>>>>>> distribution is strictly prohibited.  If you are not the
>> addressee,
>>>>> please
>>>>>>> notify the sender immediately and destroy all copies of this
>> email.
>>>>> Ubiquity
>>>>>>> Software Corporation plc, a company registered under the laws of
>>>>> England and
>>>>>>> Wales, Registration 2719723, registered offices at Eastern
>> Business
>>>>> Park,
>>>>>>> Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales,
>>> United
>>>>>>> Kingdom.
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 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
>>> 
>>> 
>>> 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
>> 
> 

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: "Adnan Saleem" <[email-masked]>
Date: Tue, 3 Apr 2007 20:59:00 -0700

Same view here, ie a SIP application server should never
need to parse SDP when interfacing with MS. If needed in
support of signalling gateways etc, then this is certainly
out of scope.

Adnan

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: April 3, 2007 8:36 PM
To: Lorenzo Miniero
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

On 3/29/07 11:53 AM, "Lorenzo Miniero" <[email-masked]> wrote:

>> What about the event package, who consolidate it if the conference 
>> span over two MS.
>> 
>>> B2BUA's, adding a dialog identifier header.  Moreover, I could see 
>>> the value of that header being the AS' view of CallID, To, and From.  
>>> The MS would
>> consider
>>> it
>>> an opaque tag.
>>> 
>>>>>>> Mediation, Policy, Codec enforcement, Bandwith Allocation based 
>>>>>>> on SDP negotiation on a wireless
>>> environment,
>>>>>>> etc).
>>>>>>> 
>>>>>>> ( A similar method was proposed to return the KA mechanism in 
>>>>>>> the outbound draft).
>>>>>>> 

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: "Even, Roni" <[email-masked]>
Date: Wed, 4 Apr 2007 09:38:51 +0300

Hi guys,
So please let me know where is BFCP running. Creating a BFCP connection
is done via SDP.
Roni

> From: Adnan Saleem [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 6:59 AM
> To: 'Eric Burger'; 'Lorenzo Miniero'
> Cc: [email-masked]
> Subject: RE: [MEDIACTRL] MS capabilities
> 
> 
> The AS needs to understand SDP *IF AND ONLY IF* it forwards non-SIP,
non-
> SDP
> calls.  However, for SIP calls (which is what most of us care about),
the
> AS
> signaling gateway (e.g., H.323 - SIP or ISUP - SIP), the little bit
extra
contain
affiliated
and/or
individual

---

From: Peili Xu <[email-masked]>
Date: Wed, 04 Apr 2007 15:11:46 +0800

Hi Eric

I don't think we need to make a single general
regulation on whether AS should touch SDP or not. 
Application Server is such a general term which may or
may not do any thing.
Whether to parse SDP should be discussed case by case
depending on what "application" is excecuted.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 11:36 AM
To: Lorenzo Miniero
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

The AS needs to understand SDP *IF AND ONLY IF* it
forwards non-SIP, non-SDP calls.  However, for SIP calls
(which is what most of us care about), the AS *DOES NOT
NEED* to understand SDP.

Please don't burden us with the corner case.  If you are
building a full signaling gateway (e.g., H.323 - SIP or
ISUP - SIP), the little bit extra to do SDP is trivial.
If you are building a SIP application server, there is
no need to build-in a requirement to parse SDP.

On 3/29/07 11:53 AM, "Lorenzo Miniero"
<[email-masked]> wrote:

>>> MUST parse and understand the SDP, hack in a label,
associate it 
>>> with
>> a
>>> SIP
>>> dialog and track it around.  Requiring the AS to
parse and 
>>> understand
>>> I *really* do not like that approach, as it burdens
the MS with a 
>>> ton
<http://www.faqs.org/ftp/internet-drafts/draft-burger-ms
cl-thoughts-
>>>> I am repeating myself. We had the same issue in the
conference 
>>>> event
>>>>>>> assumptions.  If folks REALLY think this is a
requirement then 
>>>>>>> we

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: Diego B <[email-masked]>
Date: Wed, 04 Apr 2007 10:29:17 +0300

Hi
I thinks the question is if it is *mandatory*
for the AS to "talk" SDP in order to be complain with the
Media Control Framework, if it is a core requirement.

Regards

Diego B (:-:) MailVision Ltd.  
mailto:[email-masked] 
sip:[email-masked] 
http://www.mailvision.com

Peili Xu wrote:
>> I was thinking the same thing: the AS will need to
>>     
> gateway different 
>   
>> CSP, and so will need to parse and talk SIP/SDP anyway
>>     
> in order to 
>   
>>> What about the event package, who consolidate it if
>>>       
> the conference 
>   
>>> span over two MS.
>>>
>>> What about H.323 clients calling an XCON AS, do you
>>>       
> see the AS just 
>   
>>> sending H.323 to the MS.
>>>
>>> Roni
>>>
>>>       
>>>> Wrong layer in the stack:  "label" is an SDP
>>>>         
> attribute.  That means
>   
>>> the AS
>>>       
>>>> not good.  Allowing it is good, if the AS *does*
>>>>         
> care about
>   
>>> manipulating
>>>       
>>>> The AS lives in the SIP level of the stack.  The
>>>>         
> *only* thing the AS
>   
>>> must
>>>       
>>>> track is SIP dialogs.  I could see, as a hack to
>>>>         
> work around busted 
>   
>>>> B2BUA's, adding a dialog identifier header.
>>>>         
> Moreover, I could see 
>   
>>>> the value of that header being the AS' view of
>>>>         
> CallID, To, and From.  
>   
>>>> The MS would
>>>>         
>>> consider
>>>       
>>>> it
>>>> an opaque tag.
>>>>
>>>> state, associating this opaque tag with the real
>>>>         
> dialog ID.  Worse
>   
>>> yet, it
>>>       
>>>> re-opens all of the security problems enumerated in
>>>>         
> mscl-thoughts
>   
>>>> On 3/29/07 11:14 AM, "Even, Roni"
>>>>         
> <[email-masked]> wrote:
>   
>>>>> Eric,
>>>>> need to correlate between users and media in the
>>>>>           
> notification and
>   
>>> the
>>>       
>>>> SIP
>>>>         
>>>>>> To reiterate: B2BUA's are undefined network
>>>>>>             
> elements.  It is not
>   
>>> worth
>>>       
>>>>>> debating if they are good or bad.  Let us just say
>>>>>>             
> that it is the 
>   
>>>>>> responsibility of the B2BUA to keep up with new
>>>>>>             
> protocols, not the 
>   
>>>>>> responsibility of the IETF to hack protocols to
>>>>>>             
> keep up with poor
>   
>>> B2BUA
>>>       
>>>>>> implementations.  A good B2BUA implementation will
>>>>>>             
> manage the
>   
>>> protocol
>>>       
>>>>>> appropriately.
>>>>>>
>>>>>> [I am saying this as participant, and not chair,
>>>>>>             
> as I might be
>   
>>>> convinced
>>>>         
>>>>>> that we need such a beast anyway.  Jumping way
>>>>>>             
> ahead to
>   
>>> implementation,
>>>       
>>>> I
>>>>         
>>>>>> can just imagine Keith and Dean's reaction when we
>>>>>>             
> send a
>   
>>> requirement
>>>       
>>>> to
>>>>         
>>>>>> the
>>>>>> SIP Work Group asking for a mechanism (i.e.,
>>>>>>             
> header) that looks,
>   
>>> acts,
>>>       
>>>> and
>>>>         
>>>>>> behaves like the SIP Dialog ID, but isn't the SIP
>>>>>>             
> Dialog ID...]
>   
>>>>>>
>>>>>> On 3/29/07 6:31 AM, "Diego B"
>>>>>>             
> <[email-masked]> wrote:
>   
>>>>>>> Inline
>>>>>>>
>>>>>>> Regards
>>>>>>> Diego B
>>>>>>>
>>>>>>> Chris Boulton wrote:
>>>>>>>               
>>>>>>>> I agree, we can not decide on how the deployment
>>>>>>>>                 
> may look like.
>   
>>>>>>>> There can be a B2BUA for several reasons ( I can
>>>>>>>>                 
> think of:
>   
>>> Billing
>>>       
>>>>>>>> Mediation, Policy, Codec enforcement, Bandwith
>>>>>>>>                 
> Allocation based 
>   
>>>>>>>> [Chris Boulton] There COULD be - BUT we
>>>>>>>>                 
> certainly shouldn't mold
>   
>>> out
>>>       
>>>>>>>> core solution based on the presence of a
>>>>>>>>                 
> meddling middle box.
>   
>>>>>>> [DB] Yes, I agree with you, but those boxes are
>>>>>>>               
> widely deployed.
>   
>>> It is
>>>       
>>>>>> not
>>>>>>             
>>>>>>>> We may check others possibilities to coreleate
>>>>>>>>                 
> the SIP dialog
>   
>>> and
>>>       
>>>> the
>>>>         
>>>>>>>> media channel.
>>>>>>>> Anything related to the AS<==>MS Dialog ID can
>>>>>>>>                 
> be broken by a
>   
>>> B2BUA
>>>       
>>>> in
>>>>         
>>>>>>>> the middle
>>>>>>>> (AS<==>B2BUA<==>MS)
>>>>>>>>
>>>>>>>> [Chris Boulton] Yes - The core solution will
>>>>>>>>                 
> currently break.
>   
>>>>>>>> We can think of an identifier sent from the MS
>>>>>>>>                 
> to the AS in the
>   
>>> 200
>>>       
>>>> OK
>>>>         
>>>>>>>> in a SIP header tag.
>>>>>>>> ( A similar method was proposed to return the KA
>>>>>>>>                 
> mechanism in 
>   
>>>>>>>> the outbound draft).
>>>>>>>>
>>>>>>>> [Chris Boulton] What is the difference?  You are
>>>>>>>>                 
> still not
>   
>>> guaranteed
>>>       
>>>>>>>> that a B2BUA will pass this through - remember,
>>>>>>>>                 
> nothing in their 
>   
>>>>>>>> AS "hints" (optional) a Session ID to the MS in
>>>>>>>>                 
> the new SIP
>   
>>> Header
>>>       
>>>> tag.
>>>>         
>>>>>>>> if the MS accepts the session ID, it replicates
>>>>>>>>                 
> it on the 200 OK 
>   
>>>>>>>> [Chris Boulton] Again - how do you know for sure
>>>>>>>>                 
> this traverses
>   
>>> the
>>>       
>>>>>>>> B2BUA?
>>>>>>>>
>>>>>>>>                 
>>>>>>> [DB]I don't know (Keep reading). But if this is a
>>>>>>>               
> case, a B2BUA
>   
>>> will
>>>       
>>>>>>>> Then this Session ID is used in the control
>>>>>>>>                 
> channel.
>   
>>>>>>>> Now any B2BUA in the middle must forward any
>>>>>>>>                 
> unknown SIP
>   
>>> header/tag
>>>       
>>>>>>>> untouched :)
>>>>>>>>
>>>>>>>> [Chris Boulton] BINGO!!!! - This is the very
>>>>>>>>                 
> reason why this
>   
>>> can't be
>>>       
>>>>>> in
>>>>>>             
>>>>>>>> the core solution.
>>>>>>>>
>>>>>>>>                 
>>>>>>>> [Chris Boulton] As I said earlier - we should
>>>>>>>>                 
> keep the core
>   
>>> without
>>>       
>>>>>> such
>>>>>>             
>>>>>>>> to look at an extension Relay solution (as MSRP
>>>>>>>>                 
> has done) which
>   
>>> is
>>>       
>>>>>> aware
>>>>>>             
>>>>>>>> of its requirements.  I think that should be the
>>>>>>>>                 
> basis for
>   
>>> further
>>>       
>>>>>>> [DB] This is a basic requirement. And I think
>>>>>>>               
> this has to be
>   
>>> defined
>>>       
>>>>>> soon.
>>>>>>             
>>>>>>> I agree with you that we should keep the core
>>>>>>>               
> without such
>   
>>>> assumptions,
>>>>         
>>>>>> but
>>>>>>             
>>>>>>> we have real world out there that uses B2BUAs and
>>>>>>>               
> we can not
>   
>>> ignore
>>>       
>>>> it.
>>>>         
>>>>>>> Diego B
>>>>>>>
>>>>>>>               
>>>>>>>> Chris.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Information contained in this e-mail and any
>>>>>>>>                 
> attachments are
>   
>>> intended
>>>       
>>>>>> for the
>>>>>>             
>>>>>>>> use of the addressee only, and may contain
>>>>>>>>                 
> confidential
>   
>>> information
>>>       
>>>> of
>>>>         
>>>>>>>> Ubiquity Software Corporation. All unauthorized
>>>>>>>>                 
> use, disclosure
>   
>>> or
>>>       
>>>>>>>> distribution is strictly prohibited.  If you are
>>>>>>>>                 
> not the
>   
>>> addressee,
>>>       
>>>>>> please
>>>>>>             
>>>>>>>> notify the sender immediately and destroy all
>>>>>>>>                 
> copies of this
>   
>>> email.
>>>       
>>>>>> Ubiquity
>>>>>>             
>>>>>>>> Software Corporation plc, a company registered
>>>>>>>>                 
> under the laws of
>   
>>>>>> England and
>>>>>>             
>>>>>>>> Wales, Registration 2719723, registered offices
>>>>>>>>                 
> at Eastern
>   
>>> Business
>>>       
>>>>>> Park,
>>>>>>             
>>>>>>>> Building 3, Wern Fawr Lane, St. Mellons, Cardiff
>>>>>>>>                 
> CF3 5EA, Wales,
>   
>>>> United
>>>>         
>>>>>>>> Kingdom.
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
> attachments, may
>>>>>> 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
>>>>         
> attachments, may
>>>> 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
>>>

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 4 Apr 2007 13:42:35 +0300

Diego,
The thread tried to discuss how to corelate between the media streams in the SDP with the AS/MS protocol.
I suggested using the label attribute as being done in the event package. I still think that for conferencing the AS is the focus (Or the central control) so it termintes the signaling with the users.
As for IVR, this is can be discussed. For audio only this is not an issue but for multimedia the AS may want to know if to direct the call to a video IVR or an audio IVR.
 
To me the discussion is about what is a simple case that does not require the AS to understand the SDP and if this simple case is the scope of the work
Roni

________________________________

מאת: Diego B [mailto:[email-masked]]
נשלח: ד 04/04/2007 10:29
אל: Peili Xu
עותק לידיעה: [email-masked]
נושא: Re: [MEDIACTRL] MS capabilities

Hi

Regards

Diego B (:-:) MailVision Ltd. 
mailto:[email-masked]
sip:[email-masked]
http://www.mailvision.com <http://www.mailvision.com/>

---

From: "Xavier Marjou" <[email-masked]>
Date: Wed, 4 Apr 2007 13:59:35 +0200

> *DOES NOT NEED* to understand SDP.

What if I have the following case? An endpoint sends a SIP INVITE with
a SDP containing media1 and media2. If one MS is dedicated to media of
type media1, and another MS is dedicated to media of type media2, the
AS needs to understand SDP, doesn't it?

Xavier