Subject: RE: [MMUSIC] Clarification on use of sendonly for hold

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Nov 2003 07:59:28 +0000

Jonathan,

Your reply below, and also the one you sent to Paul Kyzivat, are in line
with how I had interpreted things. However, we have encountered
implementations that offer sendonly on audio but do not supply music. The
problem we then have is whether a UAS should supply its own music. If it
receives inactive, clearly it is at liberty to do so. If it receives
sendonly, I believe it should not supply local music, because there may be
music or some other audio from the far end (although in many cases there is
not).

Some clarification in RFC3264 would be beneficial.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 04 November 2003 00:34
> To: Elwell, John
> Cc: [email-masked]'
> Subject: Re: [MMUSIC] Clarification on use of sendonly for hold
> 
> 
> To allow for situations where there is muzak or other media placed 
> while the call is on hold. That said, there is nothing wrong with 
> using inactive if you want, if you have no plans to do that.
> 
> -Jonathan R.
> 
> Elwell, John wrote:
> 
> > In section 8.4 of RFC3264 it says:
> > 
> > "Typically, when a user "presses" hold, the agent will 
> generate an offer 
> > with all streams in the SDP indicating a direction of 
> sendonly, and it 
> > will also locally mute, so that no media is sent to the far 
>  end, and no 
> > media is played out."
> > 
> > This seems strange. If the UA is not sending any media to 
> the far end, 
> > why not use "inactive" instead of "sendonly"?
> > 
> > John Elwell ([email-masked])
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Nov 2003 15:55:23 -0500

I agree that clarification would be good. The good and the bad of the 
current scheme is that the directionality of send/recv/sendrecv/inactive 
doesn't correlate directly to the general notion of "on hold".

But there is a general notion of "on hold" even if it isn't very well 
defined. The problem is that the relationship between going on/off hold 
to the direction attributes isn't entirely clear, as evidenced by John 
Elwell's experiences below.

	Paul