Paul, Your examples are very specific to the Hold Scenario. But in the case of Third-party call flow using Re-Invites, the Application Server prefers a full capability to be returned so that it can pass it along to the other party. This enables the remote users to re-negotiate the Media based on their capabilities.
Yes this needs to be clarified addressing all the requiremets. Thanks Kasturi -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 1:46 PM To: Kasturi Narayanan Cc: kaojohnny; Sip-implementors Subject: Re: [Sip-implementors] INV without sdp Kasturi Narayanan wrote: > Two interpretations are around for Re-invite without SDP. > 1) Return the Currently Negotiated SDP which is recv only > 2) Treat that as a new SDP negotiation and return the full capabilities > (with send-recv etc). > > I think the second option is more generic. You don't want to return "full capabilities" if you don't *want* that. In particular consider a variation on your scenario: After Caller A and Callee B construct a dialog, A sends a re-invite request with sdp indicates "sendonly" to hold B. B responses 200 OK with sdp indicated "recvonly" correctly. If at this moment, *B* sends a re-invite again but without sdp, how does *A* response in sdp? sendreccv? recvonly? In this case, A should respond not with its "full capabilities", but rather with "its desired state". It had previously wanted to have the call held, so it presumably should offer sendonly again. However, it is possible that it was just toggled off hold but received the reinvite before it could send its own. In that case it can offer sendrecv. The general rule that always works if for the offerer to always offer the state *it* desires, without regard for what it thinks the answerer might prefer. This preserves the options for the answerer. Consider yet another case: - A and B have a dialog - A reinvites with offer of sendonly to establish hold - B answers with recvonly to acknowledge the hold - B also decides to hold the call, so reinvites with offer of sendonly. (What it wants.) - A still wishes hold on its end, so doesn't want to answer recvonly. The only valid answer consistent with what it wants to do and with the offer is inactive, so it answers that. - For some reason, B later sends an offerless reinvite to A. A still wants a hold initiated by its end, but doesn't care that call is held from other end. So it offers sendonly. If B still wants the call held from its end as well, it will answer with inactive. So the state stays as it was. - Later A wants to go off hold. So it sends a reinvite with an offer of sendrecv. - B still wants the call held, so it answers with sendonly. - Later, B wants to go off hold too, so it sends reinvite with offer of sendrecv. - A also wants to be off hold, so it answers with sendrecv. Summarizing: - an offer always contains what the offerer *wants*. - an answer is computed as follows: . select the answers that are consistent with the offer . choose the one of those that is closest to what the answerer *wants" We intend to write something about this in the offeranswer draft, but haven't yet. Paul > Kasturi > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 15, 2006 8:47 PM > To: [email protected] > Subject: [Sip-implementors] INV without sdp > > Hi ALL: > > I'm a newbie of sip implementation. Here is a question about invite > request > without sdp. > > After Caller A and Callee B construct a dialog, A sends a re-invite > request > with sdp indicates "sendony" to hold B. B responses 200 OK with sdp > indicated "receonly" correctly. If at this moment, A sends a re-invite > again but without sdp, how does B response in sdp? sendrece? receonly? > > Is there any sections in any RFCs defines the behavior described here? > > Thanks you all. > > BR, > Johnny > _______________________________________________ > 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
