Hi Roman,

Thank you for your response.

We are using FreeSWITCH as a SIP and RTP media server to connect the caller (leg a) to the callee (leg b), the caller is expecting the media state sendrecv but this is influenced by the 3rd party.

The call flow is as follows.

-> = generated by FreeSWITCH (caller)

<- = generated by 3rd party (callee)

-> 0.000000s INVITE with SDP 'codec list'

<- 0.012557s 100 Trying

<- 0.083254s 200 OK with SDP 'codec list'

-> 0.085348s ACK

<- 0.071315s INVITE with-out SDP 'RE-INVITE for existing session'

-> 0.086461s 100 Trying

-> 0.087391s 200 OK with SDP 'codec list'

<- 0.154249s ACK with SDP 'codec list and a=sendonly'

<- 0.155111s INVITE with-out SDP 'RE-INVITE for existing session'

-> 0.166856s 100 Trying

-> 0.167631s 200 OK with SDP 'codec list and a=sendonly'

<- 0.202331s ACK with SDP 'codec list and a=recvonly'

<- 0.337532s INVITE with-out SDP 'RE-INVITE for existing session'

-> 0.346448s 100 Trying

-> 0.347170s 200 OK with SDP 'codec list and a=sendonly'

<- 0.390116s ACK with SDP 'codec list and a=recvonly'

FreeSWITCH currently interprets a RE-INVITE with-out SDP for an existing session as 'no change' for the hold state so it's carrying 'a=sendonly' over from the existing session as it was in the ACK SDP generated by the 3rd party. Based on your explanation I believe this is wrong and we should be responding with-out 'a=sendonly' (default behaviour) or with 'a=sendrecv'.

Thanks,

Shaun

---

From: Roman Shpount <roman@telurix.com>

Sent: 07 September 2020 08:44

To: Shaun Stokes <shaun@sysconfig.cloud>

Cc: sip-implementors@lists.cs.columbia.edu <sip-implementors@lists.cs.columbia.edu>

Subject: Re: [Sip-implementors] RFC 3261 section 14.2 - "brand new call" does not specify whether the SDP should modify media attributes of an existing session containing a=sendonly or a=recvonly

 

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