Comments inline... Thanks, Nataraju A B
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of varun > Sent: Tuesday, October 17, 2006 2:00 AM > To: Paul Kyzivat > Cc: [email protected]; gaurav > Subject: Re: [Sip-implementors] Query: Call Hold Implementation in SIP/SDP > > Hi Paul, > > Lets say user A sends an invite to user B with a = > send only .User B responds with a = recv only... > Won't that mean setting up a call with one way audio? > Why would that be taken as a case of call HOLD??? > [ABN] in this case it has to be considered as a call hold. If you want to put MUSIC on hold, then the caller "a=" attribute should have been set as recvonly instead of sendonly so that MUSIC server can start send media on that IP and post... If some entity set the media direction as sendonly, you can't play anything to that user... even if you do so, it may not serve the intended purpose (of playing MUSIC to that user...), it may reach that user endpoint and may not be played to user actually... because its been marked as sendonly on that IP:port... > Also, in MUSIC oh hold, lets say u have put the user > on HOLD by using c= 0.0.0.0... > Then you would like to play music to the caller...so > caller and streaming server would establish a one way > audio channel..( from streaming server a = send only > and from caller a =recv only)... > > So in which case a = send only would be taken as an > indication of call on hold and not opening of a one > way audio channel?? > > Please let me know. > > Thanks > Varun > --- Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > > > > > varun wrote: > > > Hi, > > > How does sending a = sendonly put the other guy on > > > hold( and the other end responding with a = recv > > > only). > > > > I think this is a legacy of Music on Hold. Namely, > > you may still want to > > play music to the guy you have held, but you don't > > want to hear anything > > back from him. > > > > It is the recommended way to "put on hold", but it > > is neither the only > > thing one might do, nor is it the only situation in > > which this mechanism > > is used. So a recipient does not know that it has > > been "put on hold" > > when it receives this. All it knows is that it > > should not transmit. > > > > > What if its a invite and not a re-invite. In case > > of > > > invite, it would mean a one way audio channel and > > in > > > case of re-invite would mean a call hold.Is tha > > right? > > > > No. > > > > In the invite case, it could mean that it has been > > invited by someone > > that wants to start the call on hold. In the > > reinvite case it might mean > > that there is a desire to switch to one way media > > that is unrelated to > > call hold. > > > > There is no way to know these things by examining > > the signaling. It is > > all a matter of *intent* which is not signaled. > > > > > Also, if two end supports different codecs ( no > > common > > > codec) is there a way to still establish a call > > > between two ends? > > > > Depends on what you mean, and what you want. > > > > It is valid for the callee to answer with port=0, > > rejecting the media > > because there are no codecs in common, but accepting > > the call without > > any working media. Then you have "established the > > call" but cannot > > exchange media. Its probably not useful, unless its > > followed with some > > other action, such as another offer. Note that afaik > > this is not a > > common way to proceed. > > > > If you are asking how to get a transcoder involved, > > sure there are a > > number of ways to do that. One way is for the UAS to > > act as a 3PCC > > controller and invite a transcoder. But there are > > lots of ways. > > > > Paul > > > > > Please let me know. > > > > > > Thanks > > > Naven > > > > > > --- Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > > > >> > > >> gaurav wrote: > > >>> Hi All, > > >>> > > >>> I have following doubts regaridng the Call Hold > > >> implementation in SIP/SDP: > > >> > > >> First, you must understand that SIP doesn't > > actually > > >> have a way to > > >> signal Call Hold. What it has is a way to signal > > >> changes in the handling > > >> of media that may be useful to a UAC implementing > > a > > >> call hold feature. > > >> The difference is that the signaling thats useful > > >> for call hold is also > > >> useful for other things as well. The UAS has no > > way > > >> to be certain that > > >> the UAC is specifying the start of a hold, or > > >> something else that uses > > >> the same mechanisms. > > >> > > >>> 1.. What is the behavior of UAC and UAS in > > case > > >> the Call Hold using Re-Invite. > > >> > > >> The usual approach is to send an offer with > > >> a=sendonly, to which the > > >> answer is normally a=recvonly. Another > > possibility > > >> is to offer > > >> a=inactive, to which the response should also be > > >> a=inactive. > > >> > > >> An older approach is to offer c=0.0.0.0. > > >> > > >>> 2.. How can UAS reject the Call Hold request, > > as > > >> the control of the call hold is with the UAC. > > >> > > >> You can't reject call hold because it isn't > > >> signaled. (See above.) > > >> > > >> I don't believe there is a valid way to reject > > >> a=sendonly or a=recvonly > > >> either. If you understand them, then to be > > compliant > > >> you must respond in > > >> a compatible way. > > >> > > >> You could pretend not to understand, and just not > > >> return a matching a= > > >> line for the a=sendonly. But I don't recommend > > that. > > >> > > >> I don't understand why you want to do this. If > > the > > >> other side doesn't > > >> want you to send it stuff, you can' force it to > > do > > >> so. At best you might > > >> still be able to send media, but the other end > > will > > >> be ignoring it. If > > >> the user on the other side has pushed the HOLD > > >> button on the phone, what > > >> do you want to happen? Do you want the button to > > pop > > >> back up? > > >> > > >>> 3.. If UAS rejects with 488 Not Acceptable > > Here, > > >> then what should be the ideal behavior of UAC, if > > it > > >> still want the call to be put on Hold. > > >> > > >> If you are lucky, it will try to cope. It could > > try > > >> an alternative > > >> mechanism, such as offering c=0.0.0.0, or it > > might > > >> just send your media > > >> to the bit bucket. But it also may decide that > > you > > >> are a problem and > > >> just send you a BYE. > > >> > > >>> 4.. Can a reuqest to put the call on hold be > > >> rejected by UAS, if yes, then what is the call > > Flow. > > >>> We are testing the Call Hold Flow through eBean > > >> Soft Phone and we are rejecting the request to > > put > > >> the call on hold by 488 to re-invite request, but > > >> the eBean Soft phone is not releasing the call > > hold > > >> when it receives the 488 response to re-invite. > > >>> Where could be the problem? Please help in > > >> understanding the porblem and arriving at a > > >> solution. > > >> > > >> Stop trying to prevent the other end from doing > > what > > >> it wants to do. > > >> > > >> Paul > > >> > > >>> regards > > >>> Gaurav > > >>> _______________________________________________ > > >>> Sip-implementors mailing list > > >>> [email protected] > > >>> > > > > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > >> _______________________________________________ > > >> Sip-implementors mailing list > > >> [email protected] > > >> > > > > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
