Hi, How does sending a = sendonly put the other guy on hold( and the other end responding with a = recv only). 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?
Also, if two end supports different codecs ( no common codec) is there a way to still establish a call between two ends? 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 > __________________________________________________ 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
