Hi This is the case when UA2 has previously been "placed on hold" by UA1, via receipt of "a=sendonly", then it may initiate its own hold by sending a new offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will answer with "a=inactive" because that is the only valid answer that reflects its desire not to receive media.
For more details please refer to section 5.3 Hold and Resume of media of draft-ietf-sipping-sip-offeranswer-08 which states :- RFC 3264 [4] specifies (non-normatively) that "hold" should be indicated in an established session by sending a new offer containing "a=sendonly" for each media stream to be held. An answerer is then to respond with "a=recvonly" to acknowledge that the hold request has been understood. Note that the use of sendonly/recvonly is not limited to hold. These may be used for other reasons, such as devices that are only capable of sending or receiving. So receiving an offer with "a=sendonly" must not be treated as a certain indication that the offerer has placed the media stream on hold. This model is based on an assumption that the UA initiating the hold will want to play Music on Hold, which is not always the case. A UA may, if desired, initiate hold by offering "a=inactive" if it does not intend to transmit any media while in hold status. The rules of RFC 3264 [4] constrain what may be in an answer when the offer contains "sendonly", "recvonly", or "inactive" in an a= line. But they do not constrain what must be in a subsequent offer. The General Principle for Constructing Offers and Answers (section 5.1. ) is important here. The initiation of "hold" is a local action. It should reflect the desired state of the UA. It then affects what the UA includes in offers and answers until the local state is reset. The receipt of an offer containing "a=sendonly" or "a=inactive" and the sending of a compatible answer should not change the desired state of the recipient. However, a UA that has been "placed on hold" may itself desire to initiate its own hold status, based on local input. If UA2 has previously been "placed on hold" by UA1, via receipt of "a=sendonly", then it may initiate its own hold by sending a new offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will answer with "a=inactive" because that is the only valid answer that reflects its desire not to receive media. regards Abhishek Dhammawat Aricent ________________________________________ From: [email protected] [[email protected]] On Behalf Of kaiduan xie [[email protected]] Sent: Saturday, February 21, 2009 2:38 AM To: Dale Worley Cc: [email protected] Subject: Re: [Sip-implementors] in-active in answer with sendonly in offer The case is that the a basic call is established, A and B are talking. A puts B on hold by sending offer with sendonly first, but B responds with inactive. B did not put A on hold first before receiving sendonly from A. This is kind weird, but rfc3264 says that it is valid. kaiduan ----- Original Message ---- From: Dale Worley <[email protected]> To: kaiduan xie <[email protected]> Cc: [email protected] Sent: Friday, February 20, 2009 3:57:58 PM Subject: Re: [Sip-implementors] in-active in answer with sendonly in offer On Fri, 2009-02-20 at 11:42 -0800, kaiduan xie wrote: > Hi, all, > > What is the purpose of putting inactive in answer when receiving a > sendonly offer? Rfc3264 Section 6.1 says, > > "If a stream is offered as sendonly, the corresponding stream MUST be > marked as recvonly or inactive in the answer." > > In rfc5359, recvonly is returned in hold case. "inactive" means the answerer does not desire to receive either. This case will happen if both phones have put the call on hold. Dale __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
