I agree with you with regards to the mode of the connection. Basically it should return what it can support based on its own state not the state it was driven to because of a Re-invite (send-only in the example). For example if the Application Server initially answered the call from an UA-A and later put it on hold while establishing the call towards a remote user UA-B. After the call with the remote user is answered, the AS initiates a Re-Invite with No SDP towards UA-A. In this case if the UA-A returns recv-only (instead of send-recv), the AS forwards it to UA-B which will result in a Held call between UA-A and UA-B. You may recommend that AS shld remove the call from Hold before sending the Re-invite with "No-SDP".
Also my question was with regards to other capabilities as well. Like for example if Video is supported by an UA and initially it got an invite with audio media only and later if it gets a Re-invite with "No SDP" should it not return the Video Capability as well in the 200 ok so that Video also can be re-negotiated if possible. But your conclusion answers all the above questions 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" > Kasturi -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 9:35 AM To: Kasturi Narayanan Cc: kaojohnny; Sip-implementors Subject: Re: [Sip-implementors] INV without sdp Kasturi Narayanan wrote: > 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. I'm not sure I understand you, but as best I do I think I disagree. The 3pcc use cases are one of the compelling reasons for using this approach, because it makes extensive use of offerless INVITEs. In the 3pcc case the controller is likely not to know the state of either UA. Having the UA respond with what it "wants" at the time (a reflection of *its* state) will do the right thing in all the cases I am aware of. If a user has pushed the hold button on their phone and walked away, and then the phone receives an offerless invite, what good thing will result by it responding with "sendrecv"? The user of the phone expects it to stay on hold until he does something to take it out of that state. > Yes this needs to be clarified addressing all the requiremets. Yes, i agree. The fuzzy part in my approach is how to determine what a UA "wants". Paul > 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
