Hi all, I think the basic query is
a) that in case UAS does not support call hold feature, what handling in mentioneed in SIP RFC. We have gone thru RFC 3261/3264 but to our understanding, it does not specify this. Is there is a suggested handling? Can UAS reject this message or ignore it, or ignore/reject and clear the call? b) Also, in case UAC sends a call hold request, what handling is prescribed for UAC? Should it wait till 200 Ok before putting call on hold. Regards Sarju # 9810304396 ----- Original Message ----- From: "Agrawal, Vishal" <[EMAIL PROTECTED]> To: "Paul Kyzivat" <[EMAIL PROTECTED]> Cc: "Blasko, John" <[EMAIL PROTECTED]>; <[email protected]> Sent: Friday, October 20, 2006 8:39 PM Subject: Re: [Sip-implementors] Query: Call Hold Implementation in SIP/SDP > Hello Paul, > > Why does SIP not recommend a single way to put the UAS on hold? Has > there ever been any discussion to provide the hold indication in a > separate SIP header in the re-INVITE? > > So far I've not seen two SIP endpoints (different vendors) which offer > or accept the hold and MOH the same way (some expect c=0.0.0.0 (old > way), some respond back with (a=recvonly in response to re-INVITE with > a=sendonly), some respond back with (a=sendrecv), some respond back with > (a=inactive), some can't handle the second re-INVITE with (a=sendonly, > c=MOH server) to connect them to the MOH server. > > Also, the hold is not bidirectional right? If A puts B on hold, A sends > a=sendonly in re-INVITE and B should send a=sendrecv in the response, > right? If true, then B can send a re-INVITE to A with a=sendonly, what > should the response from A now? How should they take the call off-hold? > > -Vishal > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Kyzivat > Sent: Tuesday, October 17, 2006 8:09 AM > To: Retesh > Cc: [email protected]; gaurav > Subject: Re: [Sip-implementors] Query: Call Hold Implementation in > SIP/SDP > > Just to restate the point that I an others are trying to make: > > THE ANSWERER CANNOT TELL WHETHER THE OFFERER INTENDED HOLD OR ONE WAY > MEDIA. > > You must construct your device so that it doesn't care. If you attempt > to distinguish the two you will no doubt encounter interoperability > problems. > > Paul > > Retesh wrote: >> Hi Varun >> If I get your point, you are trying to differentiate call on hold with >> one way audio. >> >> Music on hold implemented is using one way audio (sendonly(in offer) >> and recvonly(in answer)). >> >> Practically, hold (without music) is done by exchanging sdp with >> attribute as inactive. Also, in case it is done with a=sendonly(in >> offer) and a=recvonly(in answer), the UAC may chose not to send any >> RTP data at all. >> >> Also INVITE (sendonly) and reINVITE (sendonly) can be treated as 1 way >> audio and call hold respectively. >> >> Hope this helps. >> > _______________________________________________ > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
