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???
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
