Subject: Re: [MEDIACTRL] Basic IVR qusetions.

From: Eric Burger <[email-masked]>
Date: Mon, 03 Mar 2008 19:15:12 -0500

This is also a major denial-of-service opportunity. The whole point of
stateless media servers is you actually have to commit the resources to use
them.  It would be really neat for Black Hat to reserve all of the media
resources without using any.

This means we would have to deal not only with the White Hat issues of an AS
reserving resources and then dying, we have to deal with bad guys, or good
guys with bugs, as well.

My opinion (as participant) is not to add anything with state that is not
associated with an ACTIVE endpoint/call/AS.

My question (as chair) is are we willing to take the plunge and make the
media server into a conference bridge / IVR system?  A bunch of messages
over the past week seem to go into that territory, and I am only hearing
Steve Buko and Lorenzo Minero objecting.  My voice on this topic only counts
as one vote.  It is the will of the work group that Spencer and I will go
with.

On 2/27/08 10:25 AM, "Spencer Dawkins" <[email-masked]> wrote:

> Hi, Roni,
>  
> OK, this is just distributed state management - we know how to do that, we
> just need to remember that we need to manage distributed state for prepared
> dialogs!
>  
> Thanks,
>  
> Spencer
>>  
>> ----- Original Message -----
>>  
>> From:  Even,  Roni <mailto:[email-masked]>
>>  
>> To: Spencer Dawkins <mailto:[email-masked]>  ; [email-masked]
>>  
>> Sent: Wednesday, February 27, 2008 12:41  AM
>>  
>> Subject: RE: [MEDIACTRL] Basic IVR  qusetions.
>>  
>> 
>>  
>>  
>> 
>> Spencer,
>>  
>> The issue I am  raising has to do with the life span of a prepared dialog (I
>> think this is  what you call garbage collection. One way is for an AS to
>> prepare all  potential dialogs when it connects to the MS and use them later.
>> This makes  sense if you can re-use dialogs. We have to remember that in some
>> applications  there are dialogs that repeated all the time. For example
>> ("welcome to the  conference bridge, please enter your pin code  number").
>>  
>>  
>>  
>> The other scenario of  AS restart should also be addressed, this is a good
>> point and should be solved  even if prepared dialogs are not re-used, this
>> means that if we have a timeout  on a prepared dialog this issue is also
>> resolved.
>>  
>> Roni
>>  
>>  
>>  
>>  
>>  
>>  
>> 
>>  
>>  
>> 
>> From:  [email-masked] [mailto:[email-masked]] On
>> Behalf Of Spencer Dawkins
>> Sent: Tuesday, February 26, 2008 7:04  PM
>> To:  [email-masked]
>> Subject:  Re: [MEDIACTRL] Basic IVR qusetions.
>>  
>>  
>>  
>>  
>> 
>> Hi,  Roni,
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>> Are you raising a garbage  collection issue here ("when can I discard the
>> prepared dialog?"), or an issue  about detecting that a restart has taken
>> place ("I'm holding a dialog for  someone who doesn't remember that I have
>> it"), or another  issue?
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>> Just so I  understand.
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>> Thanks,
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>> Spencer
>>  
>>>  
>>>  
>>> 
>>> ----- Original Message -----
>>>  
>>>  
>>> 
>>> From: McGlashan,  Scott <mailto:[email-masked]>
>>>  
>>>  
>>> 
>>> To: Even,  Roni <mailto:[email-masked]>  ; [email-masked]
>>>  
>>>  
>>> 
>>> Sent:  Tuesday, February 26, 2008 4:34 AM
>>>  
>>>  
>>> 
>>> Subject: Re:  [MEDIACTRL] Basic IVR qusetions.
>>>  
>>>  
>>> 
>>>  
>>>  
>>> Hi  Roni,
>>>  
>>>  
>>>  
>>> 1. Does this mean that I can send  a dialog prepare and one month later do a
>>> dialog start.  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>> 
>>> [scott] As  currently drafted, yes since the spec doesn't defined a maximum
>>> time that a  dialog can remain in the prepared state (cf. conference when it
>>> is created -  how long should it remain created without being used?). If you
>>> think this is  a problem, we can add a statement that the duration of the
>>> prepared  state is limited and then either state a  (recommended?) maximum
>>> time, or let the MS determine the  timeout.  Probably the stating a timeout
>>> on the spec would be  cleanest and consistent between implementations.
> 
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.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://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 4 Mar 2008 09:03:14 +0200

Eric,
What I asked was about a prepared dialog. The first point is that
currently there is no timeout for a prepared dialog. So you can send
prepare dialog today and send the start dialog tomorrow.

The other point is that prepared dialog is not using resources on the
MS. Dialog start is doing it so I do not see your point about stateful
MS. Only the AS knows about the prepared dialogs.

Roni

> -----Original Message-----
> Behalf Of Eric Burger
> Sent: Tuesday, March 04, 2008 2:15 AM
> To: [email-masked]
> stateless media servers is you actually have to commit the resources
to
> use
> This means we would have to deal not only with the White Hat issues of
an
> AS
> > OK, this is just distributed state management - we know how to do
that,
> we
> >> think this is  what you call garbage collection. One way is for an
AS
> to
> >> prepare all  potential dialogs when it connects to the MS and use
them
> later.
> >> This makes  sense if you can re-use dialogs. We have to remember
that
> in some
> >> The other scenario of  AS restart should also be addressed, this is
a
> good
> >> point and should be solved  even if prepared dialogs are not
re-used,
> this
> >> From:  [email-masked]
[mailto:[email-masked]]
> On
> >> Are you raising a garbage  collection issue here ("when can I
discard
> the
> >> place ("I'm holding a dialog for  someone who doesn't remember that
I
> have
> >>> [scott] As  currently drafted, yes since the spec doesn't defined
a
> maximum
> >>> time that a  dialog can remain in the prepared state (cf.
conference
> when it
> >>> is created -  how long should it remain created without being
used?).
> If you
> >>> think this is  a problem, we can add a statement that the duration
of
> the
> >>> time, or let the MS determine the  timeout.  Probably the stating
a
> timeout
> 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: [email-masked]
Date: Tue, 04 Mar 2008 14:28:40 +0100

Hi Eric/all,

> associated with an ACTIVE endpoint/call/AS.

I totally share this approach.

Ceers,

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl