Subject: RE: [Sipping] netann Open Issue #1: Media on Hold

From: "Eric Burger" <[email-masked]>
Date: Fri, 21 Mar 2003 01:31:32 -0500

The difference is, "we can do better than the PSTN."

Timing out is just a bow to reality.

> -----Original Message-----
> From: Tim Melanchuk [mailto:[email-masked]]
> Sent: Thursday, March 20, 2003 5:25 PM
> To: Eric Burger
> Cc: Sipping (E-mail)
> Subject: Re: [Sipping] netann Open Issue #1: Media on Hold
> 
> 
> why do we need different behaviour for each type of service?
> 
> - conf: time moves forward (no choice)
> - dialog: implementation dependent
> - ann: pause the stream
> 
> we do need to handle having a dialog (in the sip sense) created
> on hold for some 3pcc scenarios and should not start playing
> until it is taken off hold.
> 
> however i don't see a big difference between an announcemnt
> "timing out" based upon some implementation dependent timeout,
> or simply having it time forward.
> 
> 
> Eric Burger wrote:
> > Problem:
> > What does the media server do when the UAC issues a 'hold' 
> (see RFC3264)?  The options are:
> > 	Do not send media, but have time move forward;
> > 	Suspend playing media;
> > 	Make a choice based on how the media was put on hold
> > 	Let the UAC signal behavior
> > 
> > Note that hold is not an issue for early media: it is not 
> possible to put early media on hold.  Also note that the 
> semantics for putting a conference leg on hold is already 
> well defined.
> > 
> > 
> > For VoiceXML, Dean had an excellent suggestion of throwing 
> an exception: let the application decide what to do.  
> However, it will take about a year to standardize that 
> behavior through the W3C.
> > 
> > There were rumblings of not specifying behavior for 
> announcements.  I really don't want to do that because that 
> approach will create different user experiences for the same 
> activity, based on implementation.
> > 
> > An issue with suspending media is it is possible to have a 
> session on hold indefinitely, whereas most announcements are 
> bounded in time.  For example, an announcement could have 
> duration=30000, which would normally disconnect the session 
> after 30 seconds.
> > 
> > Letting the UAC signal behavior is unrealistic as the UAC 
> probably does not know that it is calling a media server.
> > 
> > 
> > 
> > Here is the updated proposal:
> > 
> > Dialog service: Implementation dependent; suggest throwing 
> an exception.
> > Announcement service: Suspend playout; implementation 
> dependent timeout (if any) after which media server sends a BYE.
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> > 
> 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Tim Melanchuk <[email-masked]>
Date: Mon, 24 Mar 2003 09:23:34 -0800

consistency can be considered an element of good design.
i wasn't aware that "because" could as well. :-)

if anyone else cares about this issue, i'd like to know.
otherwise can we say that it "may suspend playout" rather
than "must" and see how important this is to providers of
announcement services.