The problem is the timing - all I
know is that it's ringing, then the moment I hear audio (in my
test case, when I call a number with an answering machine and it
picks up) - it goes to hold and never comes of unless I toggle
hold on the phone I'm calling from -- and note that it requires
me to push hold key _twice_. While it starts, phone shows "Held"
but I'm still hearing audio. If I then push Hold, it really goes
on hold. Pushing it again, and the audio is back to normal.
Is the "being answered sendonly"
something that is typical? I've still got open communication
with our provider, so can easily point out more if it's doing
something unusual.
Would it help to get a combined sip
trace showing both legs in one timeline?
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>
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.
_________________________________________________________________________
Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com
Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com