No audio after hold/unhold on incoming calls
575 views
Skip to first unread message
Alex Balashov
Mar 7, 2021, 4:45:03 PM3/7/21
to js...@googlegroups.com
Hi!
Using the latest stable release of JsSIP, the JsSIP endpoint ceases to
transmit audio when JsSIP.RTCSession.hold() is engaged, and does not
resume doing so when JsSIP.RTCSession.unhold() is called.
(Because the SIP-WS/RTP gateway on the other side performs strict
server-side NAT traversal and RTP latching, no RTP frames from JsSIP
means no incoming frames show up, either, leading to no audio in either
direction.)
This only happens:
1) on incoming calls--that is, calls that have been answer()d. If an
outbound call() is made and JsSIP places the remote user on hold, it
continues to transmit RTP while in that state, as well as when it comes
out of that state;
2) in Chrome (tested on Linux with 83.0.4103.61 and 89.0.4389.82 on OSX)
and Safari (14.0.3); Firefox (86.0/Linux) continues to send audio
throughout the hold cycle as on outbound calls.
I'm not sure if this is a novel quirk in Webkit-based browsers, or some
API instrumentation problem on our side.
...
How I put the session on hold:
if(!session.isEstablished() || session.isOnHold().local)
return;
session.hold();
...
And off hold:
if(!session.isEstablished() || !session.isOnHold().local)
return;
session.unhold();
...
To play out audio, we have an Audio element that is not attached to the
DOM and is initialised on startup. When we call() or answer(), we add an
event handler like this:
session.connection.addEventListener('track', t => {
this._audio.srcObject = t.streams[0];
this._audio.play();
});
Not that I think it makes a difference, since everything works fine on
outgoing calls, but the server side is always DTLS-passive, offers /
answers RTCP-MUX, and otherwise generates identical SDP answers in the
200 OKs to JsSIP's re-invites when taking calls on/off hold. I've
scrutinised the SDP answers for reinvites in outgoing vs incoming calls
for any differences with a fine-toothed comb, and there aren't any apart
from call/transaction/dialog-specific SIP fields.
Thank you very much in advance for any light you may be able to shed!
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Iñaki Baz Castillo
Mar 8, 2021, 6:33:54 AM3/8/21
to jssip
When we call `session.hold()` in JsSIP, we are not really preventing
RTP from JsSIP to the remote. However such a RTP just contains audio
silence samples or black video frames. If the `a=sendonly` attribute
produces an undesired behavior due the remote endpoint (a SIP media
server or whatever) this is not a bug in JsSIP for sure.
> --
> You received this message because you are subscribed to the Google Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jssip+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/0864ac39-1985-83aa-e70f-3c9a8fb668e5%40evaristesys.com.
--
Iñaki Baz Castillo
<i...@aliax.net>
RTP from JsSIP to the remote. However such a RTP just contains audio
silence samples or black video frames. If the `a=sendonly` attribute
produces an undesired behavior due the remote endpoint (a SIP media
server or whatever) this is not a bug in JsSIP for sure.
> You received this message because you are subscribed to the Google Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jssip+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/0864ac39-1985-83aa-e70f-3c9a8fb668e5%40evaristesys.com.
--
Iñaki Baz Castillo
<i...@aliax.net>
Alex Balashov
Mar 8, 2021, 8:09:56 AM3/8/21
to js...@googlegroups.com
Okay, but it’s JsSIP’s on-hold / post-hold behaviour that differs, depending on whether it’s an outbound call or an inbound call.
I don’t mean to insinuate it’s a bug. It’s very possibly something wrong I’m doing with API instrumentation. I just can’t figure out what it is.
—
Sent from mobile, with due apologies for brevity and errors.
> On Mar 8, 2021, at 6:33 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
>
> When we call `session.hold()` in JsSIP, we are not really preventing
> To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/CALiegfn0YcO4iaMTzCiDKYxh%2B76ykK-mLjcbWzoPtfhcaRMmuA%40mail.gmail.com.
I don’t mean to insinuate it’s a bug. It’s very possibly something wrong I’m doing with API instrumentation. I just can’t figure out what it is.
—
Sent from mobile, with due apologies for brevity and errors.
> On Mar 8, 2021, at 6:33 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
>
> When we call `session.hold()` in JsSIP, we are not really preventing
Iñaki Baz Castillo
Mar 8, 2021, 8:16:36 AM3/8/21
to jssip
JsSIP just changes the `a=` direction attribute of the muted section
in the SDP and pauses the local audio/video track. Whether the remote
endpoint behaves different depending on who the call initiator is is
another story.
You may want to monitor RTP traffic from JsSIP to the server (and
vice-versa) after calling `hold()` and `resume()`. You'll see that
there is RTP anyway in both cases.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/07BE7341-F4F6-4411-A698-2DAAAADB34B2%40evaristesys.com.
in the SDP and pauses the local audio/video track. Whether the remote
endpoint behaves different depending on who the call initiator is is
another story.
You may want to monitor RTP traffic from JsSIP to the server (and
vice-versa) after calling `hold()` and `resume()`. You'll see that
there is RTP anyway in both cases.
Alex Balashov
Mar 8, 2021, 8:19:37 AM3/8/21
to js...@googlegroups.com
I did exactly as you suggest before filing this report, and observed in a wire packet capture that there is definitely no RTP in the inbound call case.
—
Sent from mobile, with due apologies for brevity and errors.
> On Mar 8, 2021, at 8:16 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
>
> JsSIP just changes the `a=` direction attribute of the muted section
> To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/CALiegfmKFEsK-6%3DZTbN6kpOdm%2BUNVs5j%2Beb5yQ0tkgzjjt8xTg%40mail.gmail.com.
—
Sent from mobile, with due apologies for brevity and errors.
>
> JsSIP just changes the `a=` direction attribute of the muted section
Iñaki Baz Castillo
Mar 8, 2021, 8:22:18 AM3/8/21
to jssip
On Mon, 8 Mar 2021 at 14:19, Alex Balashov <abal...@evaristesys.com> wrote:
>
> I did exactly as you suggest before filing this report, and observed in a wire packet capture that there is definitely no RTP in the inbound call case.
No RTP in which direction? and how different are the remote SDPs in
>
> I did exactly as you suggest before filing this report, and observed in a wire packet capture that there is definitely no RTP in the inbound call case.
both cases (inbound and outbound calls)?
Alex Balashov
Mar 8, 2021, 8:27:01 AM3/8/21
to js...@googlegroups.com
No RTP from JsSIP to remote endpoint after going on hold, or coming off of hold thereafter.
No inbound RTP either, but I already explained why this is the case—it is due to server-side RTP latching waiting for WS endpoint to send an RTP frame first.
SDP absolutely identical. I went through any possible differences forensically. No difference apart from exactly those differences which you would expect (dialog/transaction-specific).
—
Sent from mobile, with due apologies for brevity and errors.
> On Mar 8, 2021, at 8:22 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
No inbound RTP either, but I already explained why this is the case—it is due to server-side RTP latching waiting for WS endpoint to send an RTP frame first.
SDP absolutely identical. I went through any possible differences forensically. No difference apart from exactly those differences which you would expect (dialog/transaction-specific).
—
Sent from mobile, with due apologies for brevity and errors.
> --
> You received this message because you are subscribed to the Google Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jssip+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/CALiegf%3DOMb%2B-o-GtQJYK94SJLguv%3DB3iiT2HCeYq8XP2%3D_FTrg%40mail.gmail.com.
> You received this message because you are subscribed to the Google Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jssip+un...@googlegroups.com.
Iñaki Baz Castillo
Mar 8, 2021, 8:41:12 AM3/8/21
to js...@googlegroups.com
Try it in tryit.jssip.net (no media server but just a SIP proxy between caller and callee) and you'll see that there is bidirectional rtp
To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/2101BC82-F707-4B08-B655-DA982D00DCE3%40evaristesys.com.
Alex Balashov
Mar 8, 2021, 8:44:28 AM3/8/21
to js...@googlegroups.com
I believe that this is true for others, which is why I wonder if I’m doing something in the calling application.
—
Sent from mobile, with due apologies for brevity and errors.
On Mar 8, 2021, at 8:41 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/CALiegf%3D74b2EvBx%2BMu_X4RnGjK%3D4WbgA_1hkWy%2Bc%3DOKuESgS3g%40mail.gmail.com.
Iñaki Baz Castillo
Mar 8, 2021, 9:05:21 AM3/8/21
to js...@googlegroups.com
I don't see how no RTP at all on hold() can be triggered by using JsSIP API.
To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/EC31EE8F-539F-4721-A9A2-28A3AE8342AD%40evaristesys.com.
Alex Balashov
Mar 8, 2021, 9:23:01 AM3/8/21
to js...@googlegroups.com
I hear you, and agree with you. That’s why I saw the SDP from the far end as the appropriate place to look. But they’re literally identical. I can fish them out and post them if need be. Maybe a second pair of eyes can help.
—
Sent from mobile, with due apologies for brevity and errors.
On Mar 8, 2021, at 9:05 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/CALiegfk-MWoPAAcprT4uN-dN_pYjadqrm0Rp9c3D0fXNXHHq3Q%40mail.gmail.com.
Alex Balashov
May 6, 2021, 3:40:45 AM5/6/21
to js...@googlegroups.com
Hi,
Some months have passed since I raised this thread, and investigations
have continued, but without success.
I have reproduced this scenario on a variety of platforms and browsers,
and with modern versions of Asterisk as well as EOL ones (like in
"production"). Each time the behaviour is consistent; an incoming call
placed on hold causes JsSIP to cease transmitting audio, and it never
resumes.
The SDP has been re-combed at a microscopic level and DTLS roles have
been examined. The on-hold / off-hold reinvite flows are exquisitely
identical for both incoming and outgoing calls, with the difference that
putting an outgoing call on hold works, but putting an incoming call on
hold causes a cessation of audio.
I have introspected a wide variety of JsSIP and W3C data structures,
including RTCPeerConnection.RTCConfiguration, and I have used Chrome's
webrtc-internals to try to spot any differences. There are none that I
can see.
Unfortunately, I do not know what else to try to get to the bottom of
it. If there are any diagnostic suggestions, I am open.
-- Alex
On 3/8/21 9:22 AM, Alex Balashov wrote:
> I hear you, and agree with you. That’s why I saw the SDP from the far
> end as the appropriate place to look. But they’re literally identical. I
> can fish them out and post them if need be. Maybe a second pair of eyes
> can help.
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
>> On Mar 8, 2021, at 9:05 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
>>
>>
>> I don't see how no RTP at all on hold() can be triggered by using
>> JsSIP API.
>>
>> El El lun, 8 mar 2021 a las 14:44, Alex Balashov
>> <abal...@evaristesys.com <mailto:abal...@evaristesys.com>> escribió:
>>>
>>>
>>> Try it in tryit.jssip.net <http://tryit.jssip.net> (no media
>>> <https://groups.google.com/d/msgid/jssip/2101BC82-F707-4B08-B655-DA982D00DCE3%40evaristesys.com>.
>>>
>>> --
>>> Iñaki Baz Castillo
>>> <i...@aliax.net <mailto:i...@aliax.net>>
>>> <https://groups.google.com/d/msgid/jssip/CALiegf%3D74b2EvBx%2BMu_X4RnGjK%3D4WbgA_1hkWy%2Bc%3DOKuESgS3g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> <https://groups.google.com/d/msgid/jssip/EC31EE8F-539F-4721-A9A2-28A3AE8342AD%40evaristesys.com?utm_medium=email&utm_source=footer>.
>>
>> --
>> Iñaki Baz Castillo
>> <i...@aliax.net <mailto:i...@aliax.net>>
>> <https://groups.google.com/d/msgid/jssip/CALiegfk-MWoPAAcprT4uN-dN_pYjadqrm0Rp9c3D0fXNXHHq3Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> <https://groups.google.com/d/msgid/jssip/AC216814-A5F8-48C7-8F83-07504365180D%40evaristesys.com?utm_medium=email&utm_source=footer>.
Some months have passed since I raised this thread, and investigations
have continued, but without success.
I have reproduced this scenario on a variety of platforms and browsers,
and with modern versions of Asterisk as well as EOL ones (like in
"production"). Each time the behaviour is consistent; an incoming call
placed on hold causes JsSIP to cease transmitting audio, and it never
resumes.
The SDP has been re-combed at a microscopic level and DTLS roles have
been examined. The on-hold / off-hold reinvite flows are exquisitely
identical for both incoming and outgoing calls, with the difference that
putting an outgoing call on hold works, but putting an incoming call on
hold causes a cessation of audio.
I have introspected a wide variety of JsSIP and W3C data structures,
including RTCPeerConnection.RTCConfiguration, and I have used Chrome's
webrtc-internals to try to spot any differences. There are none that I
can see.
Unfortunately, I do not know what else to try to get to the bottom of
it. If there are any diagnostic suggestions, I am open.
-- Alex
On 3/8/21 9:22 AM, Alex Balashov wrote:
> I hear you, and agree with you. That’s why I saw the SDP from the far
> end as the appropriate place to look. But they’re literally identical. I
> can fish them out and post them if need be. Maybe a second pair of eyes
> can help.
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
>> On Mar 8, 2021, at 9:05 AM, Iñaki Baz Castillo <i...@aliax.net> wrote:
>>
>>
>> I don't see how no RTP at all on hold() can be triggered by using
>> JsSIP API.
>>
>> El El lun, 8 mar 2021 a las 14:44, Alex Balashov
>>
>> I believe that this is true for others, which is why I wonder if
>> I’m doing something in the calling application.
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>>> On Mar 8, 2021, at 8:41 AM, Iñaki Baz Castillo <i...@aliax.net
>>> <mailto:i...@aliax.net>> wrote:
>> I believe that this is true for others, which is why I wonder if
>> I’m doing something in the calling application.
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>>> On Mar 8, 2021, at 8:41 AM, Iñaki Baz Castillo <i...@aliax.net
>>>
>>>
>>> Try it in tryit.jssip.net <http://tryit.jssip.net> (no media
>>> server but just a SIP proxy between caller and callee) and you'll
>>> see that there is bidirectional rtp
>>>
>>> El El lun, 8 mar 2021 a las 14:27, Alex Balashov
>>> <abal...@evaristesys.com <mailto:abal...@evaristesys.com>>
>>> see that there is bidirectional rtp
>>>
>>> El El lun, 8 mar 2021 a las 14:27, Alex Balashov
>>> escribió:
>>>
>>> No RTP from JsSIP to remote endpoint after going on hold, or
>>> coming off of hold thereafter.
>>>
>>> No inbound RTP either, but I already explained why this is
>>> the case—it is due to server-side RTP latching waiting for WS
>>> endpoint to send an RTP frame first.
>>>
>>> SDP absolutely identical. I went through any possible
>>> differences forensically. No difference apart from exactly
>>> those differences which you would expect
>>> (dialog/transaction-specific).
>>>
>>> —
>>> Sent from mobile, with due apologies for brevity and errors.
>>>
>>> > On Mar 8, 2021, at 8:22 AM, Iñaki Baz Castillo
>>>
>>> No RTP from JsSIP to remote endpoint after going on hold, or
>>> coming off of hold thereafter.
>>>
>>> No inbound RTP either, but I already explained why this is
>>> the case—it is due to server-side RTP latching waiting for WS
>>> endpoint to send an RTP frame first.
>>>
>>> SDP absolutely identical. I went through any possible
>>> differences forensically. No difference apart from exactly
>>> those differences which you would expect
>>> (dialog/transaction-specific).
>>>
>>> —
>>> Sent from mobile, with due apologies for brevity and errors.
>>>
>>> > On Mar 8, 2021, at 8:22 AM, Iñaki Baz Castillo
>>> <i...@aliax.net <mailto:i...@aliax.net>> wrote:
>>> >
>>> > On Mon, 8 Mar 2021 at 14:19, Alex Balashov
>>> <abal...@evaristesys.com
>>> >
>>> > On Mon, 8 Mar 2021 at 14:19, Alex Balashov
>>> <abal...@evaristesys.com
>>> <mailto:abal...@evaristesys.com>> wrote:
>>> >>
>>> >> I did exactly as you suggest before filing this report,
>>> and observed in a wire packet capture that there is
>>> definitely no RTP in the inbound call case.
>>> >
>>> > No RTP in which direction? and how different are the remote
>>> SDPs in
>>> > both cases (inbound and outbound calls)?
>>> >
>>> > --
>>> > Iñaki Baz Castillo
>>> > <i...@aliax.net <mailto:i...@aliax.net>>
>>> >>
>>> >> I did exactly as you suggest before filing this report,
>>> and observed in a wire packet capture that there is
>>> definitely no RTP in the inbound call case.
>>> >
>>> > No RTP in which direction? and how different are the remote
>>> SDPs in
>>> > both cases (inbound and outbound calls)?
>>> >
>>> > --
>>> > Iñaki Baz Castillo
>>> >
>>> > --
>>> > You received this message because you are subscribed to the
>>> Google Groups "JsSIP" group.
>>> > To unsubscribe from this group and stop receiving emails
>>> from it, send an email to jssip+un...@googlegroups.com
>>> <mailto:jssip%2Bunsu...@googlegroups.com>.
>>> > --
>>> > You received this message because you are subscribed to the
>>> Google Groups "JsSIP" group.
>>> > To unsubscribe from this group and stop receiving emails
>>> from it, send an email to jssip+un...@googlegroups.com
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jssip/CALiegf%3DOMb%2B-o-GtQJYK94SJLguv%3DB3iiT2HCeYq8XP2%3D_FTrg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jssip/CALiegf%3DOMb%2B-o-GtQJYK94SJLguv%3DB3iiT2HCeYq8XP2%3D_FTrg%40mail.gmail.com>.
>>> https://groups.google.com/d/msgid/jssip/CALiegf%3DOMb%2B-o-GtQJYK94SJLguv%3DB3iiT2HCeYq8XP2%3D_FTrg%40mail.gmail.com
>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "JsSIP" group.
>>> To unsubscribe from this group and stop receiving emails from
>>> it, send an email to jssip+un...@googlegroups.com
>>> <mailto:jssip%2Bunsu...@googlegroups.com>.
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "JsSIP" group.
>>> To unsubscribe from this group and stop receiving emails from
>>> it, send an email to jssip+un...@googlegroups.com
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jssip/2101BC82-F707-4B08-B655-DA982D00DCE3%40evaristesys.com
>>> <https://groups.google.com/d/msgid/jssip/2101BC82-F707-4B08-B655-DA982D00DCE3%40evaristesys.com>.
>>>
>>> --
>>> Iñaki Baz Castillo
>>> <i...@aliax.net <mailto:i...@aliax.net>>
>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "JsSIP" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to jssip+un...@googlegroups.com
>>> <mailto:jssip+un...@googlegroups.com>.
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "JsSIP" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to jssip+un...@googlegroups.com
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jssip/CALiegf%3D74b2EvBx%2BMu_X4RnGjK%3D4WbgA_1hkWy%2Bc%3DOKuESgS3g%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jssip/CALiegf%3D74b2EvBx%2BMu_X4RnGjK%3D4WbgA_1hkWy%2Bc%3DOKuESgS3g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "JsSIP" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to jssip+un...@googlegroups.com
>> <mailto:jssip+un...@googlegroups.com>.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "JsSIP" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to jssip+un...@googlegroups.com
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jssip/EC31EE8F-539F-4721-A9A2-28A3AE8342AD%40evaristesys.com
>> <https://groups.google.com/d/msgid/jssip/EC31EE8F-539F-4721-A9A2-28A3AE8342AD%40evaristesys.com?utm_medium=email&utm_source=footer>.
>>
>> --
>> Iñaki Baz Castillo
>> <i...@aliax.net <mailto:i...@aliax.net>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "JsSIP" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to jssip+un...@googlegroups.com
>> <mailto:jssip+un...@googlegroups.com>.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "JsSIP" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to jssip+un...@googlegroups.com
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jssip/CALiegfk-MWoPAAcprT4uN-dN_pYjadqrm0Rp9c3D0fXNXHHq3Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jssip/CALiegfk-MWoPAAcprT4uN-dN_pYjadqrm0Rp9c3D0fXNXHHq3Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jssip+un...@googlegroups.com
> <mailto:jssip+un...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jssip+un...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jssip/AC216814-A5F8-48C7-8F83-07504365180D%40evaristesys.com
> <https://groups.google.com/d/msgid/jssip/AC216814-A5F8-48C7-8F83-07504365180D%40evaristesys.com?utm_medium=email&utm_source=footer>.
Juha Heinanen
May 6, 2021, 3:48:29 AM5/6/21
to js...@googlegroups.com
Alex Balashov writes:
> The SDP has been re-combed at a microscopic level and DTLS roles have
> been examined. The on-hold / off-hold reinvite flows are exquisitely
> identical for both incoming and outgoing calls, with the difference that
> putting an outgoing call on hold works, but putting an incoming call on
> hold causes a cessation of audio.
Is it now so that JsSIP also supports re-INVITEs? Last time I asked
> The SDP has been re-combed at a microscopic level and DTLS roles have
> been examined. The on-hold / off-hold reinvite flows are exquisitely
> identical for both incoming and outgoing calls, with the difference that
> putting an outgoing call on hold works, but putting an incoming call on
> hold causes a cessation of audio.
about it the answer was that only UPDATEs are supported and that the
policy will not change,
-- Juha
Alex Balashov
May 6, 2021, 9:22:54 AM5/6/21
to js...@googlegroups.com
It does, it does indeed.
Sent from mobile, with due apologies for brevity and errors.
On May 6, 2021, at 3:48 AM, 'Juha Heinanen' via JsSIP <js...@googlegroups.com> wrote:
--
You received this message because you are subscribed to the Google Groups "JsSIP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jssip+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/24723.40777.114850.263583%40tutpro.com.
Juha Heinanen
May 6, 2021, 9:49:39 AM5/6/21
to js...@googlegroups.com
Alex Balashov writes:
> It does, it does indeed.
>
> https://jssip.net/documentation/3.7.x/api/session/#method_hold
>
I rechecked the old thread and indeed re-INVITE was supported. The
> It does, it does indeed.
>
> https://jssip.net/documentation/3.7.x/api/session/#method_hold
>
issue was that JsSIP didn't check if UPDATE was includes in Allow header
of the other party and was not able to choose the method based on that.
I'll try if I can reproduce the hold/unhold issue in my environment.
-- Juha
Alex Balashov
May 6, 2021, 9:52:26 AM5/6/21
to js...@googlegroups.com
Thanks, Juha, I really appreciate that. I’m at the limit of what I can ascertain for myself.
—
—
Sent from mobile, with due apologies for brevity and errors.
> On May 6, 2021, at 9:49 AM, 'Juha Heinanen' via JsSIP <js...@googlegroups.com> wrote:
> --
> You received this message because you are subscribed to the Google Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jssip+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jssip/24723.62444.936685.163294%40tutpro.com.
> You received this message because you are subscribed to the Google Groups "JsSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jssip+un...@googlegroups.com.
j...@tutpro.com
May 6, 2021, 12:01:28 PM5/6/21
to JsSIP
Alex,
Was this the same kind of test you made and had the issue? If not, how should I change my test?
-- Juha
Reply all
Reply to author
Forward
0 new messages