Just read section 6.1 . Should the attribute be missing in the answer, it implicitly means sendrecv, i.e. it is forbidden!
Andrea -----Original Message----- From: David Benoit [mailto:[EMAIL PROTECTED] Sent: mercoledì 27 giugno 2007 16.21 To: Andrea Rizzi Cc: 'varun'; [email protected] Subject: Re: [Sip-implementors] Call hold and a = inactive Option 3 is definitely legal for clients that were written before RFC 3254 existed as it is the default value (i.e. if B sends A "sendonly" and A responds with no state, it defaults to "sendrecv"). Please tell me specifically what part of RFC 3264 you mean when you said it is forbidden as I can find no reference to that. Thanks, David On Wed, Jun 27, 2007 at 03:51:41PM +0200, Andrea Rizzi wrote: > Option 3 is forbidden by RFC3264! > > Andrea > > -----Original Message----- > From: David Benoit [mailto:[EMAIL PROTECTED] > Sent: mercoled? 27 giugno 2007 15.20 > To: varun > Cc: Andrea Rizzi; [email protected] > Subject: Re: [Sip-implementors] Call hold and a = inactive > > Hi, > > The exchange of the activation state can be thought of like the following > conversation (which may aid in the understanding): > > User B wants to put A on hold so it sends "sendonly" to A: > - Hey A, I'm not going to send you any media for a while, so please > don't think that the call is dead because of that. I'll let you know > when I'm back. > > In response to that, A has a number of options. > > Option 1: User A sends back "recvonly": > - Hey B, thanks for telling me that. I won't send you any media until > you tell me otherwise, but I will still pay attention to anything you > send to me. > > Option 2: User A sends back "inactive": > - Hey B, thanks. It you aren't going to listen, I'm not going to listen > either. Let me know when you want to talk again. > > Option 3: User A sends back "sendrecv": > - Hey B, thanks for telling me that, but I don't really care. I'm not > going to kill your call because you don't send me any media. I will > still send you media and you can just ignore it. You can still send > me media and I'll pay attention to it. > > > It is not really clear which of the options should be chosen in all > cases. And all of these options are valid and legal responses. > > For option 1, this means that media won't be flowing from A to B, but as > soon as B wants to start sending media again, it will be accepted by A > even before the "off hold" exchange happens. > > For option 2, no media should flow between A and B or visa versa. > However, this means that some clients may not accept any media from the > other side until the state changes, meaning the completion of the "off > hold" exchange would have to happen before media was accepted. This is > sometimes problematic if there is more delay in the signaling (either from > the path or the processing) than there is for the media. This is a real > problem on a lot of networks, so be careful. > > Option 3 is more like option 1 than 2. As B should really "discard" any > media it receives after sending out the "sendonly" (as it has said to A "I > don't want your media"), it is actually okay that A keeps sending to B. > It only "wastes" bandwidth. However, in some cases the A may be a piece > of equipment not capable of setting this particular option (either because > it is old, incorrect, etc.). > > So, this isn't really a prescription for what you should do. If you are a > UA (i.e. a client) I would tend toward option 1. It has the least chance > of introducing any type of problem where the media from B will get lost > when B takes the call off hold. > > David > > On Wed, Jun 27, 2007 at 05:46:51AM -0700, varun wrote: > > Hi, > > I have still not got a complete answer. > > Case1: Putting a call on hold by using send only(Party > > A) and the other end(Party B) reposning by recvonly , > > this case still has one directional media path > > open(From A->B). > > What is the case when the other end(Party B) responds > > with a = inactive... > > does it mean no media path in both directions or same > > as case 1( one way media from A->B)/. > > Please reply ASAP. > > > > Thanks > > varun > > --- Andrea Rizzi <[EMAIL PROTECTED]> wrote: > > > > > There are no violations at all in responding with > > > inactive, and as you > > > mentioned this will suspend any media, as the > > > holding procedure is > > > definitively a new offer/answer exchange. > > > Actually, in my opinion, this would be the preferred > > > way to implement the > > > call hold service, to save bandwidth, of course by > > > guessing that the > > > terminal responding with inactive is able to play a > > > locally-generated hold > > > tone. Moreover, I've seen very few holding terminals > > > sending content (as a > > > hold tone or music) over RTP after a > > > sendonly/recvonly exchange. > > > > > > Andrea > > > > > > ------------------------------ > > > > > > Message: 7 > > > Date: Tue, 26 Jun 2007 20:14:01 -0700 (PDT) > > > From: varun <[EMAIL PROTECTED]> > > > Subject: [Sip-implementors] Call hold and a = > > > inactive > > > To: [EMAIL PROTECTED] > > > Message-ID: > > > <[EMAIL PROTECTED]> > > > Content-Type: text/plain; charset=iso-8859-1 > > > > > > Hi, > > > If user B wants to put user A on Hold, it can send a > > > = > > > sendonly to A and expects A to return a = recvonly. > > > This way there is a one way audio channel open from > > > B > > > to A. > > > What if user A responds with a = inactive..is that > > > valid? Does it mean that media streams are on Hold > > > in > > > both directions? > > > > > > Thanks > > > varun > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > [email protected] > > > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > > > > > > > ____________________________________________________________________________ > ________ > > Looking for a deal? Find great prices on flights and hotels with Yahoo! > FareChase. > > http://farechase.yahoo.com/ > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > -- > [EMAIL PROTECTED] | Principal Software Engineer | +1-902-832-2649 > "Complex problems have simple, neat and wrong solutions" - H. L. Menken -- [EMAIL PROTECTED] | Principal Software Engineer | +1-902-832-2649 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
