Shaun, I am the person who actually got the language about handing re-INVITE without SDP into RFC 3261 as "a brand new call". The initial intent was to enable a third party call control to initiate a new call by sending a re-INVITE without SDP to an existing call and then place another call to a new party.
If I understand correctly, FreeSwitch is sending a response with "a=recvonly" to a re-INVITE with no SDP? If this is the case, since they are a media server, in this particular situation they are probably wrong, but generally the answer is "it depends". Because of this, you are not going to find an RFC that specifies the one and only correct procedure. The general idea is that sendonly/recvonly in every SDP exchange should reflect the preferences for the user agents, not what was previously negotiated. Imagine that one UA is putting another UA on hold. In this case this phone sends a re-INVITE with a=inactive (or a=sendonly which only makes sense if the UA plans to play the music on hold). The second UA will respond with a=inactive or a=recvonly. If the second UA later sends a re-INVITE without SDP, the first UA will still respond with SDP with a=inactive (or a=sendonly), since it is still on hold. If the UA which is currently on hold sends a re-INVITE with no SDP, then the other UA should respond with a=sendrecv (since it is not on hold), but the first UA should respond with a=inactive (or a=sendonly) in SDP in ACK, since it is still on hold. In other words, re-INVITE does not change the local UA hold status, only a user action does this. Based on the local hold status and the remote direction attribute the UA should respond with an appropriate direction attribute in the answer. If you are using FreeSwitch as a media server, then the local call status is likely not on hold and it should be able to send/recv media, which should be indicated in the response to a re-INVITE with no body. In general case, the local call status is something that depends on the application running on FreeSwitch, which you do not specify. This is why the general answer "it depends". I hope it helps, _____________ Roman Shpount On Mon, Sep 7, 2020 at 2:11 AM Shaun Stokes <shaun@sysconfig.cloud> wrote: > Hi, > > We've been struggling with some of the interpretation used in RFC 3261 > section 14.2 which has created a conflict between the software we use > (FreeSWITCH) and another environment (based on Cisco previously Broadsoft > equipment) both of which claim to be RFC 3261 compliant and claim that the > other is not. > > The problem occurs when the 3rd party sends an SDP with the media > attribute 'a=sendonly' on an existing session then follow with a RE-INVITE > with-out an SDP, they claim that our 2xx offer in response should contain > an SDP with-out 'a=sendonly' (or replace with 'a=sendrecv') based on the > interpretation of a "brand new call" used below. Anthony Minessale II > (FreeSWITCH lead) claims that "brand new call" is only intended to refer to > codecs (not all media attributes) and that the 3rd party (Broadsoft) > invented this concept on their own. > > RFC 3261 > > 14.2 UAS Behavior > A UAS providing an offer in a 2xx (because the INVITE did not contain > an offer) SHOULD construct the offer as if the UAS were making a > brand new call, subject to the constraints of sending an offer that > updates an existing session, as described in [13] in the case of SDP. > Specifically, this means that it SHOULD include as many media formats > and media types that the UA is willing to support. The UAS MUST > ensure that the session description overlaps with its previous > session description in media formats, transports, or other parameters > that require support from the peer. This is to avoid the need for > the peer to reject the session description. If, however, it is > unacceptable to the UAC, the UAC SHOULD generate an answer with a > valid session description, and then send a BYE to terminate the > session. > > Source: https://tools.ietf.org/html/rfc3261#section-14.2 > > > The 3rd party have also stated that this isn't a call going on hold as > it's routing to an ACD group, according to RFC 6337 section 5.3 "the use of > sendonly/recvonly is not limited to hold". > > In the following discussion on this subject involving the authors of RFC > 3261 there is a clear indication that a RE-INVITE with-out an SDP should > not modify 'a=sendonly', unfortunately this isn't enough to support our > argument and our service providers protocol lead have determined that the > 3rd party is acting correctly and have asked for more evidence. > http://marc.info/?t=98738614300001&r=1&w=2 > > We have also pointed out that RFC 3264 section 8 states that the offer MAY > be identical to the last SDP provided but are promptly referred back to > "brand new call" in RFC 3261 section 14.2. > > RFC 3264 > > 8 Modifying the Session > At any point during the session, either participant MAY issue a new > offer to modify characteristics of the session. It is fundamental to > the operation of the offer/answer model that the exact same > offer/answer procedure defined above is used for modifying parameters > of an existing session. > > The offer MAY be identical to the last SDP provided to the other > party (which may have been provided in an offer or an answer), or it > MAY be different. We refer to the last SDP provided as the "previous > SDP". If the offer is the same, the answer MAY be the same as the > previous SDP from the answerer, or it MAY be different. If the > offered SDP is different from the previous SDP, some constraints are > placed on its construction, discussed below. > > Source: https://tools.ietf.org/html/rfc3264#section-8 > > > I've been struggling to find anything more in RFC which can support our > argument, on the contrary I had a response from Paul Kyzivat on IETF > Dispatch who directed me towards RFC 6337. RFC 6337 section 5.1 refers us > back to RFC 3261 in case of a RE-INVITE and "without regard for what the > other party in the call may have indicated previously" would suggest we > should be using 'a=sendrecv' in our offer, Paul's response was a follows. > > As one of the authors of 6337 I will agree that sendrecv is probably > what the UAS should be offering given the circumstances. But it > ultimately comes down to what it "wants" to be doing at that time. > > The folly comes when it offers something less than what *it* wants > because it imagines (based on prior o/a) that the answerer wants less > than it does. This can get you into "stuck on hold" scenarios or other > trouble. > > This contradicts the previous discission on SIP Implementors ( > http://marc.info/?t=98738614300001&r=1&w=2), which behaviour is correct > and does the RFC need to be updated? > > Hope someone here can help. > > Regards, > Shaun > Shaun Stokes - > T : 0800 0489300 > E : shaun@sysconfig.cloud > W : www.sysconfig.cloud > SYSCONFIG is a trading name of ITEC Support LTD which is a limited company > registered in England and Wales. Company Registered Number 06908001. > Registered office: Suite 2, Prospect House, Bath Road Trading Estate, > Stroud, GL5 3QF. VAT Number GB971629981 > > CONFIDENTIALITY NOTICE > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error; please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > WARNING: Although the company has taken reasonable precautions to ensure > no viruses are present in this email, the company cannot accept > responsibility for any loss or damage arising from the use of this email or > attachments. > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
