Some notes here… if there is none of the inactive/sendonly/recvonly/sendrecv its the same as if it was sendrecv In the going on to on-hold immediately (leg w/ provider) case… the call is being answered sendonly, essentially they are answering the call on hold, then sending us a re-invite to take us off hold. Its correct that the call should start on hold, but it should come back off hold, can you confirm that it is? In the going on to on-hold immediately (leg w/ device) case… the call is being answered off hold, and then we are getting an update with sendonly (putting us on hold)…. I would expect it to be on hold after that.
On Sep 6, 2018, at 11:48 PM, Nathan Neulinger <nneul@mst.edu> wrote:
Finally managed to get a reproducible failure on this, but don't understand SIP enough to know where it's going wrong. I have two local numbers that I can call via my local telco over a SIP trunk (MetaSwitch) - one reliably demonstrates the behavior, the other reliably works normal:
The call that is working normally (leg w/ provider): INVITE w/ neither sendonly nor sendrecv 100 Trying 183 Progress w/ a=sendrecv 200 OK w/ a=sendrecv
The call that is going into on-hold immediately (leg w/ provider): INVITE w/ neither sendonly nor sendrecv 100 Trying 180 Ringing 200 OK w/ a=sendonly INVITE w/ a=sendrecv 100 Trying 200 OK w/ neither sendonly nor sendrecv
Call that goes into on hold immediately (leg w/ device): INVITE w/ neither, but has sdp 407 INVITE w/ neither, but has sdp 100 183 w/ neither 200 w/ neither UPDATE w/ sendonly (which is after the second 200 OK above) 200 OK w/ recvonly
I'm going to try and do some more digging on this tomorrow, but if someone has any insights here on what the proper/expected behavior is, I sure would love to hear it.
It seems like this may be somewhat related to FS-9765 - however there is no invite w/o an SDP. Also similar sounding to FS-11234. I'm happy to take this forward to provider (I'm inquiring with them as well) but would be helpful to have some more details on which piece is behaving incorrectly.
-- Nathan
-------- Original Message -------- From: Nathan Neulinger Sent: Tue, Sep 4, 2018 2:45 PM CDT To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Phone spontaneously going into Hold when a call is established?
I had seen this symptom a few times randomly, and just got a couple of reports from users where a call to an outside number was going immediately to 'On Hold' when the person answered.
Is there anything in the SIP/RTP stream that could be expected to trigger that sort of behavior? I've seen it from a polycom, and I believe one of the user reports today was with a yealink. User report was with a recently upgraded 1.6 -> 1.8 deployment. I believe the previous times I've seen it would have been on git builds of 1.8, but not certain.