Giter Club home page Giter Club logo

Comments (52)

davehorton avatar davehorton commented on July 28, 2024

Yes, I've noticed this before. Its an issue with how Freeswitch deals with SRTP connections. I've taken to using rtpengine to handle SRTP as a front end so I have not worked out to date how to fix this.

The issue is that this dialplan

    <extension name="socket">
      <condition field="${sip_user_agent}" expression="^drachtio-fsmrf:(.*)$">
        <action application="answer"/>
        <action application="socket" data="${sip_h_X-esl-outbound} async full"/>
      </condition>
    </extension>

Behaves differently when the INVITE is using SRTP -- specifically, the answer command does not complete, and thus the socket command never executes. Thus the timeout on the application side.

So I'm not sure at the moment why answer never completes in this scenario....if you have any thoughts they would be welcome

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

It might be useful to get a freeswitch log after turning log levels up to debug

fsctl loglevel debug

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

Oops sorry about that.

Here is some new logs.

https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take2/drachtio.log
https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take2/freewswitch.log

Thanks, i'll play around more on the Freeswitch side now, I recall this was working half a year ago. So maybe its the recent version of Freeswitch?

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

It may well be a change that I made. Not sure.

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

I don't see any additional logging in that freeswitch log. Did you turn log levels to debug? Since you copied in your dialplan, what does it look like?

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

Sorry again

https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take3/freeswitch.log

let me get that dial plan

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

dialplan

https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/freeswitch/dialplan/mrf.xml

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

Its strange that the freeswitch logging is not showing the execution of the dialplan

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

maybe try 'console loglevel debug' as well

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

okay ill try that, and i'll get a working non srtp log too

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

the notworking one originate from webrtc client
the working one originate from linphone

https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take4/notworking-freeswitch.log
https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take4/working-freeswitch.log

gonna just prepare and leave for work wont be responsive until a bit later

thanks for everything again

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

Okay if i made this configuration changes to freeswitch conf I can connect to it directly and play some sound...

https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/freeswitch/sip_profiles/mrf.xml#L15-L16

https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/freeswitch/dialplan/mrf.xml

freeswitch log: https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take5/freeswitchdirect.log

using fsmrf log: https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take5/drachtioproxied.log

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

I mean if I enable their websocket binding and connect to it directly SRTP works..

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

and and it looked liked debug is working now

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

Yes, looks like the difference is the handshake gets completed in your working example. These lines, after the 200 OK is generated, we do not see in the non-working example

2019-07-24 12:09:20.548776 [INFO] switch_rtp.c:3192 Changing audio DTLS state from HANDSHAKE to SETUP
2019-07-24 12:09:20.568817 [INFO] switch_rtp.c:3101 audio Fingerprint Verified.
2019-07-24 12:09:20.568817 [INFO] switch_rtp.c:3941 Activating audio Secure RTP SEND
2019-07-24 12:09:20.568817 [INFO] switch_rtp.c:3919 Activating audio Secure RTP RECV
2019-07-24 12:09:20.568817 [DEBUG] switch_core_sqldb.c:2617 Secure Type: srtp:dtls:AES_CM_128_HMAC_SHA1_80
2019-07-24 12:09:20.568817 [INFO] switch_rtp.c:3141 Changing audio DTLS state from SETUP to READY
2019-07-24 12:09:20.568817 [DEBUG] switch_core_sqldb.c:2617 Secure Type: srtp:dtls:AES_CM_128_HMAC_SHA1_80
2019-07-24 12:09:20.568817 [NOTICE] mod_dptools.c:1312 Channel [sofia/drachtio_mrf/[email protected]] has been answered
2019-07-24 12:09:20.568817 [DEBUG] switch_channel.c:3773 (sofia/drachtio_mrf/[email protected]) Callstate Change EARLY -> ACTIVE

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

one difference -- in the non-working example the 200 OK looks to have an IP that is behind a nat:

v=0
   o=FreeSWITCH 1563963375 1563963376 IN IP4 192.168.50.127
   s=FreeSWITCH
   c=IN IP4 192.168.50.127

whereas in the working example the freeswitch address looks directly reachable by the client?

   v=0
   o=FreeSWITCH 1563973308 1563973309 IN IP4 175.25.50.122
   s=FreeSWITCH
   c=IN IP4 175.25.50.122

I think to finish the DTLS handshake the client receiving the 200 OK needs to be able to reach the freeswitch at that address.....can it?

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

can you post the drachtio logs that goes with the latest non-working freeswitch log?

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

192.168.50.127

that address looks wrong .. investigating

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

the fact that the handshake succeeds means that it is an address that the freeswitch is recivinbg on, because the handshake takes place over the UDP transport

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

175.25.50.x is my routers network is inside a NAT the lab environment.
192.168 shouldn't be in there unless i accidentally configured something wrong hmm

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

not working drachtio https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take6/drachtio-notworking.log

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

OK I see the whole problem now...its a kind of deadlock

  • drachtio-fsmrf is waiting for the socket connection from freeswitch before sending the 200 OK back to the client (at which point the handshake would take place)
  • freeswitch is waiting for the handshake to complete before proceeding to the making the socket connection.

OK, hmm, at least we know what it is. Need to think about this...

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

as an experiment, change the dialplan so the socket command comes first, then the answer.

Might not work but I would be interested to see logs

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

swapped
https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take7/swappeddrachtio.log

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

i think it works..

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

webrtc client now get 200 OK back

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

here is the freeswitch log https://github.com/andrewvmail/drachtio-webrtc-conference/blob/master/take7/freeswitch.log

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

nevermind does not work but client now gets 200 back

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

I think so.

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

Yeah just double checked the ip in the C=IN line in the body of the 200 OK the webrtc client receive has the correct ip but handshake did not complete

from drachtio-fsmrf.

andrewvmail avatar andrewvmail commented on July 28, 2024

Hi Dave, touching back on this issue this might be of interest https://www.ietf.org/proceedings/70/slides/mmusic-9.pdf can attempt fixing this with some directions. would rec #2 be ideal?

from drachtio-fsmrf.

guy032 avatar guy032 commented on July 28, 2024

So I'm assuming that the Dratchio framework is currently not capable of dealing with its much needed companion SIP.js or any other javascript communication platform which is using WebRTC. I was spending the last few days dealing with AWS containers and instances looking through the logs and trying to figure out where the problem lies but I'm not comming from the VoIP area so I guess I won't be ahead of you guys anytime soon. Let me know if I can be any help for you.

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

drachtio can work fine with WebRTC. Dealing with WebRTC implies two things:

  1. handling SIP over (secure) websockets
  2. handling SRTP; typically transcoding to RTP

drachtio, being only a SIP signaling/application platform handles the first. You can configure your drachtio server to handle SIP over ws or wss.

The second, being media handling, is not something the drachtio server will handle, it will be up to your media server. This particular issue was about trying to get this to work with Freeswitch, and so if that is your configuration there will most probably be an issue (until I have time to look into this further).

However, I use rtpengine as my media server in WebRTC configurations and it is simple, more efficient than freeswitch, and works fine.

As far as SIP.js <==> drachtio that works fine. This is purely a SIP interface between them, and I have developed applications with both SIP.js and jsSIp.

Having said all that, @guy032 if you want to describe your intended scenario and what you are trying to accomplish I may be able to offer suggestions

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

I saw this problem earlier this week.
It took me lot of time to understand why the connectCaller fail with timeout.

I think that the simple solution will be to change the connectCaller function so it will do it like this:

  1. create endpoint in freeswitch without remoteSdp
  2. after we have an active endpoint, modify the remoteSdp to the sdp from webrtc
  3. send the localSdp to the client as usual

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

My scenario is to be able to do conference between webrtc (and maybe pstn) users.
rtpengine cannot do conference, so i need freeswitch.

Currently what i did is put rtpengine in the middle between freeswitch and the web client, it is working but if freeswitch knows how to talk with webrtc, why add the rtpengine in the middle?

I tried to do direct connection between the web client and freeswitch (freeswitch is from your docker image) using the method that i wrote above, and it did not success.

  1. Create endpoint without remoteSdp
  2. Modify the active endpoint to use the remoteSdp from the webrtc
  3. Send the localSdp from freeswitch to the web client
    The webclient cannot connect to freeswitch using the received sdp, ICE negotiation problem.

When i checked it in the In the about:webrtc of firefox,
In the working scenario (using rtpengine in the middle) i see 5 rows, the first row is the public ip of the client.
In the non-working scenario (connect freeswitch directly) i did not see the this row.

Any idea why?

from drachtio-fsmrf.

guy032 avatar guy032 commented on July 28, 2024

rtpengine cannot do conference - yes exactly my scenario also!
we know rtpengine is only for one to one endpoints. this world became much more about one to many endpoints. I think we should agree this will take Drachtio framework to the next level of an all capable framework once we figure out what is going on with this issue. in the meantime I would love to see a code example of how to put rtpengine in the middle as you suggest @akalter
and of course if you got a clue on this issue @davehorton, deadlock as you mentioned earlier
what are your thoughts about solving this issue? Is it going to be from the client side or the server side of drachtio/freeswitch?

from drachtio-fsmrf.

guy032 avatar guy032 commented on July 28, 2024

Made these changes to createEndpoint at mediaserver.js by your suggestion @akalter:

this.srf.createUAC(uri, {headers: opts.headers})

endpoint.once('ready', () => {
    endpoint.modify(opts.remoteSdp);
    callback(null, endpoint);
});

Now my web application based on SIP.js return:
Failed to set remote answer sdp: Called with SDP without DTLS fingerprint.

After investigating the logs I can see the following (excluded some SDP paramters):

recv 7303 bytes from wss/[77.139.36.12]:52742 at 15:36:27.012049:

    INVITE sip:[email protected] SIP/2.0
    Via: SIP/2.0/WSS 9ctdeavrhc2e.invalid;branch=z9hG4bK5934954
    To: <sip:[email protected]>
    From: <sip:[email protected]>;tag=100ngnrc5e
    CSeq: 2 INVITE
    Call-ID: biek1ccu5pku1i3lmckr
    Max-Forwards: 70
    Authorization: Digest algorithm=MD5, username="123", realm="sip.xxxxxxxxx.com", nonce="158575538688000", uri="sip:[email protected]", response="a378effc049ab621f07ef719f8209d59", qop=auth, cnonce="mmo4g439qri9", nc=00000001
    Contact: <sip:[email protected];transport=ws;ob>
    Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
    Supported: outbound
    User-Agent: SIP.js/0.15.10
    Content-Type: application/sdp
    Content-Length: 6593

    m=audio 54719 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
    m=video 54721 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116

2020-04-01 15:36:27.134774 send 465 bytes to udp/[172.31.27.248]:5080 at 15:36:27.134689:

    INVITE sip:[email protected]:5080 SIP/2.0
    Via: SIP/2.0/UDP 172.31.36.242:5080;rport;branch=z9hG4bKUaateragN25DB
    Max-Forwards: 70
    From: <sip:172.17.0.1:5080>;tag=07Bym5v14FZDK
    To: <sip:[email protected]:5080>
    Call-ID: 6461924c-eed1-1238-69a0-0a7d01e9ec20
    CSeq: 18323901 INVITE
    User-Agent: drachtio-fsmrf:f4cf1933-3bf4-4ae6-aa41-21fb14f4c87b
    Content-Length: 0
    X-esl-outbound: 172.31.36.242:42243
    Contact: <sip:172.31.36.242:5080;transport=udp>

2020-04-01 15:36:27.136877 recv 1220 bytes from udp/[172.31.27.248]:5080 at 15:36:27.136802:

    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 172.31.36.242:5080;rport=5080;branch=z9hG4bKUaateragN25DB
    From: <sip:172.17.0.1:5080>;tag=07Bym5v14FZDK
    To: <sip:[email protected]:5080>;tag=FaQmjS1ap4Sgc
    Call-ID: 6461924c-eed1-1238-69a0-0a7d01e9ec20
    CSeq: 18323901 INVITE
    Contact: <sip:[email protected]:5080;transport=udp>
    User-Agent: drachtio MRF
    Accept: application/sdp
    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
    Supported: path, replaces
    Allow-Events: talk, hold, conference, refer
    Content-Type: application/sdp
    Content-Disposition: session
    Content-Length: 599

    m=audio 29416 RTP/AVP 102 0 8 104 101
    m=video 27272 RTP/AVP 103

2020-04-01 15:36:27.563467 send 7022 bytes to udp/[172.31.27.248]:5080 at 15:36:27.563236:

    INVITE sip:[email protected]:5080;transport=udp SIP/2.0
    Via: SIP/2.0/UDP 172.31.36.242:5080;rport;branch=z9hG4bKXvvBjecQFmjKj
    Max-Forwards: 70
    From: <sip:172.17.0.1:5080>;tag=07Bym5v14FZDK
    To: <sip:[email protected]:5080>;tag=FaQmjS1ap4Sgc
    Call-ID: 6461924c-eed1-1238-69a0-0a7d01e9ec20
    CSeq: 18323902 INVITE
    Contact: <sip:172.31.36.242:5080;transport=udp>
    Content-Type: application/sdp
    Content-Length: 6593

    m=audio 54719 UDP/TLS/RTP/SAVPF 111 126 104 9 0 8 103 105 13 110 112 113 106
    m=video 54721 UDP/TLS/RTP/SAVPF 125 96 98 99 100 101 102 122 127 121 97 107 108 109 124 120 123 119 114 115 116

2020-04-01 15:36:27.583376 recv 747 bytes from udp/[172.31.27.248]:5080 at 15:36:27.583299:

    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 172.31.36.242:5080;rport=5080;branch=z9hG4bKXvvBjecQFmjKj
    From: <sip:172.17.0.1:5080>;tag=07Bym5v14FZDK
    To: <sip:[email protected]:5080>;tag=FaQmjS1ap4Sgc
    Call-ID: 6461924c-eed1-1238-69a0-0a7d01e9ec20
    CSeq: 18323902 INVITE
    Contact: <sip:[email protected]:5080;transport=udp>
    User-Agent: drachtio MRF
    Accept: application/sdp
    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
    Supported: path, replaces
    Content-Type: application/sdp
    Content-Disposition: session
    Content-Length: 171

    m=audio 0 UDP/TLS/RTP/SAVPF 19
    m=video 0 UDP/TLS/RTP/SAVPF 19

2020-04-01 15:36:27.583408 tport.c:3051 tport_deliver() tport_deliver(0xc42e80): msg 0xca1180 (747 bytes) from udp/172.31.27.248:5080 next=(nil)
2020-04-01 15:36:27.583423 nta.c:3448 agent_recv_response() nta: received 200 OK for INVITE (18323902)
2020-04-01 15:36:27.583444 nta.c:3515 agent_recv_response() nta: 200 OK is going to a transaction
2020-04-01 15:36:27.583463 nta.c:9734 outgoing_estimate_delay() nta_outgoing: RTT is 20.276 ms
2020-04-01 15:36:27.583476 tport.c:4261 tport_release() tport_release(0xc42e80): 0xca16f0 by 0xca1aa0 with 0xca1180
2020-04-01 15:36:27.583490 SipDialogController::processResponseInsideDialog:
2020-04-01 15:36:27.583504 SipDialogController::findRIPByOrq orq 0xca1aa0
2020-04-01 15:36:27.583516 SipDialogController::processResponseInsideDialog: found request for response
2020-04-01 15:36:27.583537 ClientController::removeAppTransaction: transactionId a6c5fb73-e71b-4bf0-8788-3e872f17b438; size: 0
2020-04-01 15:36:27.583556 timerD: Adding entry to go off in 32500ms
2020-04-01 15:36:27.583570 timerD: Adding entry to the tail of the queue: length 2
2020-04-01 15:36:27.583583 TimerDHandler::addInvite 0xca1aa0, 6461924c-eed1-1238-69a0-0a7d01e9ec2018323902
2020-04-01 15:36:27.583595 SipDialogController::clearRIP clearing orq 0xca1aa0
2020-04-01 15:36:27.585186 Client::write_handler - wrote 7218 bytes: system:0
2020-04-01 15:36:27.585220 Client::write_handler - wrote 942 bytes: system:0
2020-04-01 15:36:27.603272 Client::read_handler read: c912d19f-f75f-4533-9ae2-26345cb7edfa|sip|e97dfc6f-e48a-4b4e-82c4-cac0b55f9639|
SIP/2.0 200 OK
Call-ID: biek1ccu5pku1i3lmckr
cseq: 2 INVITE
from: <sip:[email protected]>;tag=100ngnrc5e
to: <sip:[email protected]>
Content-Length: 623

m=audio 29416 RTP/AVP 102 0 8 104 101
m=video 27272 RTP/AVP 103

send 985 bytes to wss/[77.139.36.12]:52742 at 15:36:27.603961:

    SIP/2.0 200 OK
    Via: SIP/2.0/WSS 9ctdeavrhc2e.invalid;branch=z9hG4bK5934954;received=77.139.36.12;rport=52742
    From: <sip:[email protected]>;tag=100ngnrc5e
    To: <sip:[email protected]>;tag=1g5pp0D51rN0e
    Call-ID: biek1ccu5pku1i3lmckr
    CSeq: 2 INVITE
    Contact: <sips:172.31.36.242:443;transport=wss>
    Content-Type: application/sdp
    Content-Length: 623
    
    m=audio 29416 RTP/AVP 102 0 8 104 101
    m=video 27272 RTP/AVP 103

but the response should be with UDP/TLS/RTP/SAVPF instead.

It seems to me that the first request to Freeswitch with X-esl-outbound is sent without SDP parameters (because of removing localSdp when creating the endpoint) and then the second request to Freeswitch is sent with UDP/TLS/RTP/SAVPF but the response to the web application comes from the first request which by default is RTP/AVP
@davehorton can you tell why?

after this SIP.js sends BYE with the following reason:
SIP;cause=488;text="Not Acceptable Here"

If anyone have idea what can be the reason please help.

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

I have the code that i tested with it, but i cannot run it now.
Looks like he endpoint.modify returns promise, and after it resolves - the endpoint.local.sdp is UDP/TLS/RTP/SAVPF

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

I've checked in a beta fix that should allow Mediaserver#connectCaller to handle SRTP being offered from webrtc clients. To test it, could you please install as follows:

npm install — save drachtio-fsmrf@beta.

There are no special or additional options you need to pass in the call to connectCaller -- it will inspect the sdp you pass in req.body and if SRTP will do the right thing.

Please re-run your tests and let me know the results.

Also, note two things:

  1. You should not (and you will now get an assert if you try) call MediaServer#createEndpoint with a remote sdp offering SRTP - you have to use Mediaserver#connectCaller. The reason is that part of creating the endpoint in this scenario is doing the TLS handshake with the sender, which only connectCaller is in a position to do since it has the res object.
  2. This is only a solution for connecting inbound SRTP calls to freeswitch. Generating an outbound call from freeswitch is trickier because we need to get freeswitch to offer SRTP outside of the context of having an incoming offer with SRTP. I am still looking into possible solutions for this.

If your simple test does not work, please run it with DEBUG=drachtio:fsmrf env var set and provide logs

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

I tested it with the beta version and i still have the timeout problem, same as before.

The error:
drachtio:fsmrf MediaServer#createEndpoint - connection timeout for 3e29153d-90e9-4862-a9d3-86e55645e124

Should i modify the freeswitch configuration?
The current freeswitch configuration is:
<extension name="socket"> <condition field="${sip_user_agent}" expression="^drachtio-fsmrf:(.*)$"> <action application="answer"/> <action application="log" data="INFO ***** before connect to socket "/> <action application="socket" data="${sip_h_X-esl-outbound} async full"/> <action application="log" data="INFO ***** after connect to socket "/> </condition>

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

the normal configuration should be fine. Could you run with DEBUG as I requested, then send me both the node.js logs as well as the drachtio server logs

from drachtio-fsmrf.

guy032 avatar guy032 commented on July 28, 2024

Interesting... there are new findings now!

I suspect the problem below is with Freeswitch getting invite message with SRTP but deliver it to classic sip endpoint without transforming the SDP from SRTP to RTP.

Also Chrome reports:
[Deprecation] Your partner is negotiating an obsolete (D)TLS version. Support for this will be removed in M81, around March 2020. Please check with your partner to have this fixed.
Probably because of Freeswitch?

Also: It seems to be possible now to have a conversation between 2 WebRTC endpoints but it's not stable yet. I was not able to see video and hear sound from the remote party after initiating the call before doing restart to the Node.js application (during the call).

When using demo-1 from SIP.js I can hear the IVR voice message from drachtio-fsmrf with the following SDP message in the invitation sent to Freeswitch:

v=0
o=- 2046822851891369810 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS ZwJfPBxjASsCVKqG8YCRPnFX4qJghpx4qMFL
m=audio 51983 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 77.139.36.12
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:202810205 1 udp 2113937151 4eecf1cb-2932-412b-b51c-d7055a338a3c.local 51983 typ host generation 0 network-cost 999
a=candidate:2064909898 1 udp 2113939711 66b8d9c7-28e6-4a76-861d-e3eda29d984f.local 51984 typ host generation 0 network-cost 999
a=candidate:842163049 1 udp 1677729535 77.139.36.12 51983 typ srflx raddr 0.0.0.0 rport 0 generation 0 network-cost 999
a=ice-ufrag:B6wU
a=ice-pwd:I6pfjuTjkEg6SE6C7IsmfGcX
a=ice-options:trickle
a=fingerprint:sha-256 4C:DD:15:00:8E:BE:6E:B3:B3:F5:FF:35:E1:8F:40:D8:54:FE:86:03:A3:72:7A:88:96:89:35:FC:7F:DB:02:B3
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:ZwJfPBxjASsCVKqG8YCRPnFX4qJghpx4qMFL 4a6ecb5d-757e-49fb-a92c-f02e82fa5a33
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:1954271339 cname:a/QCz2g+vZsVG3+d
a=ssrc:1954271339 msid:ZwJfPBxjASsCVKqG8YCRPnFX4qJghpx4qMFL 4a6ecb5d-757e-49fb-a92c-f02e82fa5a33
a=ssrc:1954271339 mslabel:ZwJfPBxjASsCVKqG8YCRPnFX4qJghpx4qMFL
a=ssrc:1954271339 label:4a6ecb5d-757e-49fb-a92c-f02e82fa5a33

and these logs on node.js:

"123" <sip:[email protected]>;tag=itrs3njgec
got attempt record from network at 04:13:35.299751: pvgjq79d5dat1thbcvmt
got stop record from application at 04:13:35.442995 with reason call-rejected: pvgjq79d5dat1thbcvmt
"123" <sip:[email protected]>;tag=itrs3njgec
got attempt record from network at 04:13:35.583809: pvgjq79d5dat1thbcvmt
invited
{"level":30,"time":1586924016082,"pid":19672,"hostname":"ip-172-31-36-242.eu-west-1.compute.internal","Call-ID":"pvgjq79d5dat1thbcvmt","family":"ipv4","scheme":"sip","user":"216548489848","host":"sip.xxxxxxxxx.com","port":null,"params":{},"headers":{},"msg":"received INVITE from tcp/77.139.36.12:62764","v":1}
got attempt record from application at 04:13:36.099270: 51862d92-f972-1238-6d8f-0a7d01e9ec20
  drachtio:fsmrf MediaServer#connectCaller - createUAC (srtp scenario) produced dialog for 0ec98c8c-a100-4256-9ffc-b6f8911f41f9: {"id":"51862d92-f972-1238-6d8f-0a7d01e9ec20;from-tag=QQDBBDcSjQHyH","type":"uac","sip":{"callId":"51862d92-f972-1238-6d8f-0a7d01e9ec20","remoteTag":"S1HZNXtQa9Njm","localTag":"QQDBBDcSjQHyH"},"local":{"uri":"sip:[email protected]:5080","sdp":"v=0\r\no=- 3345497715259109555 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0\r\na=msid-semantic: WMS 5xJ9e4MS3KNyoTQBqIDdfuMPpIYMiwQggYXO\r\nm=audio 51365 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126\r\nc=IN IP4 77.139.36.12\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=candidate:202810205 1 udp 2113937151 4eecf1cb-2932-412b-b51c-d7055a338a3c.local 51365 typ host generation 0 network-cost 999\r\na=candidate:2064909898 1 udp 2113939711 66b8d9c7-28e6-4a76-861d-e3eda29d984f.local 51366 typ host generation 0 network-cost 999\r\na=candidate:842163049 1 udp 1677729535 77.139.36.12 51365 typ srflx raddr 0.0.0.0 rport 0 generation 0 network-cost 999\r\na=ice-ufrag:YXGI\r\na=ice-pwd:1b1lG2leOyBFqf54KyEFpaPe\r\na=ice-options:trickle\r\na=fingerprint:sha-256 B6:98:2E:47:62:63:1D:00:7E:70:DC:4C:48:D1:46:D9:42:EE:07:FA:52:5F:4A:B0:F6:92:3C:1D:1D:0C:BA:16\r\na=setup:actpass\r\na=mid:0\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=sendrecv\r\na=msid:5xJ9e4MS3KNyoTQBqIDdfuMPpIYMiwQggYXO f781d4fa-72b8-4d5e-9bfd-fc0c1e2ee3a7\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=rtcp-fb:111 transport-cc\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:110 telephone-event/48000\r\na=rtpmap:112 telephone-event/32000\r\na=rtpmap:113 telephone-event/16000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:1649915407 cname:rU8S4MsviOOAbf9s\r\na=ssrc:1649915407 msid:5xJ9e4MS3KNyoTQBqIDdfuMPpIYMiwQggYXO f781d4fa-72b8-4d5e-9bfd-fc0c1e2ee3a7\r\na=ssrc:1649915407 mslabel:5xJ9e4MS3KNyoTQBqIDdfuMPpIYMiwQggYXO\r\na=ssrc:1649915407 label:f781d4fa-72b8-4d5e-9bfd-fc0c1e2ee3a7\r\n","contact":"<sip:xx.xxx.xx.xxx:5060>"},"remote":{"uri":"sip:[email protected]:5080;transport=udp","sdp":"v=0\r\no=FreeSWITCH 1586895886 1586895887 IN IP4 xx.xx.xxx.xx\r\ns=FreeSWITCH\r\nc=IN IP4 xx.xx.xxx.xx\r\nt=0 0\r\na=msid-semantic: WMS B2M62ClAsrUVucaEUHsDX6awM9D5sG5T\r\nm=audio 28130 UDP/TLS/RTP/SAVPF 111 110\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 useinbandfec=1; minptime=10\r\na=rtpmap:110 telephone-event/48000\r\na=ptime:20\r\na=fingerprint:sha-256 2D:15:DC:8E:4C:37:14:B8:E8:94:11:A5:D9:39:C1:F5:ED:1A:BD:1A:50:1E:9D:5D:A4:7F:7A:B0:74:84:E8:76\r\na=setup:active\r\na=rtcp-mux\r\na=rtcp:28130 IN IP4 xx.xx.xxx.xx\r\na=ice-ufrag:MpRAmSWYRpU9WPSl\r\na=ice-pwd:nyCopjHyKM0eRYsud9UqSGez\r\na=candidate:9735191008 1 udp 659136 xx.xx.xxx.xx 28130 typ host generation 0\r\na=end-of-candidates\r\na=ssrc:2198349304 cname:yIPra1RtiBeCDf7n\r\na=ssrc:2198349304 msid:B2M62ClAsrUVucaEUHsDX6awM9D5sG5T a0\r\na=ssrc:2198349304 mslabel:B2M62ClAsrUVucaEUHsDX6awM9D5sG5T\r\na=ssrc:2198349304 label:B2M62ClAsrUVucaEUHsDX6awM9D5sG5Ta0\r\n"},"onHold":false} +7s
got start record from network at 04:13:36.118252 with role uac: 51862d92-f972-1238-6d8f-0a7d01e9ec20
got start record from application at 04:13:36.179529 with role uas: pvgjq79d5dat1thbcvmt
  drachtio:fsmrf MediaServer#_onNewCall: xx.xx.xxx.xx received new call with tracking uuid: 0ec98c8c-a100-4256-9ffc-b6f8911f41f9 +1s
  drachtio:fsmrf MediaServer#connectCaller - (srtp scenario) produceEndpoint for 0ec98c8c-a100-4256-9ffc-b6f8911f41f9 +0ms
  drachtio:fsmrf Endpoint#ctor creating endpoint with uuid db58396a-cff8-4020-90f9-353acf4f6a11, is3pcc: undefined +0ms
  drachtio:fsmrf Endpoint#api uuid_set_media_stats db58396a-cff8-4020-90f9-353acf4f6a11 +1ms
  drachtio:fsmrf Endpoint#api response: [{"headers":[{"name":"Content-Type","value":"api/response"},{"name":"Content-Length","value":5}],"hPtr":null,"body":"+OK:\n"},{"Content-Type":"api/response","Content-Length":5},"+OK:\n"] +62ms
  drachtio:fsmrf Endpoint#api uuid_dump db58396a-cff8-4020-90f9-353acf4f6a11 +1ms
  drachtio:fsmrf Endpoint#api response: [{"headers":[{"name":"Content-Type","value":"api/response"},{"name":"Content-Length","value":10696}],"hPtr":null,"body":"Event-Name: CHANNEL_DATA\nCore-UUID: ca2b1398-721f-4acc-a626-0a891aa3326b\nFreeSWITCH-Hostname: ip-172-31-27-248\nFreeSWITCH-Switchname: ip-172-31-27-248\nFreeSWITCH-IPv4: 172.31.27.248\nFreeSWITCH-IPv6: %3A%3A1\nEvent-Date-Local: 2020-04-15%2004%3A13%3A37\nEvent-Date-GMT: Wed,%2015%20Apr%202020%2004%3A13%3A37%20GMT\nEvent-Date-Timestamp: 1586924017709736\nEvent-Calling-File: mod_commands +60ms
  drachtio:fsmrf MediaServer#createEndpoint - (srtp scenario) returning endpoint for uuid 0ec98c8c-a100-4256-9ffc-b6f8911f41f9 +1ms
  drachtio:fsmrf Endpoint#execute play_and_get_digits 1 1 1 5000 # https://xxxxxxxxx.com/audio/ivr.wav silence_stream://250 myDigitBuffer \d+ 8000 +1ms
  drachtio:fsmrf Endpoint#execute playback silence_stream://500 +1ms
DTMF SIP info: 1
1

I tested with 3 different targets and got different errors after routing the call to its destination:

1. Bria:

{"level":30,"time":1586924019422,"pid":19672,"hostname":"ip-172-31-36-242.eu-west-1.compute.internal","msg":"Registrar#query: sip:[email protected] returned {\"Protocol\":\"udp\",\"ID\":\"216548489848\",\"Contact\":\"sip:[email protected]:62890;rinstance=277ebb273d880d0c\"}","v":1}
{"level":30,"time":1586924019422,"pid":19672,"hostname":"ip-172-31-36-242.eu-west-1.compute.internal","Call-ID":"pvgjq79d5dat1thbcvmt","msg":"call to a registered sip client at uri sip:[email protected]:62890;rinstance=277ebb273d880d0c","v":1}
  drachtio:fsmrf Endpoint#execute playback https://www.thesoundarchive.com/ringtones/jenny.wav +2s

SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP xx.xxx.xx.xxx;rport=5060;branch=z9hG4bKp428323yaSr4B
To: <sip:[email protected]:62890>;tag=e8359f2f;rinstance=277ebb273d880d0c
From: "123" <sip:[email protected]>;tag=itrs3njgec
Call-ID: 5383c761-f972-1238-6d8f-0a7d01e9ec20
CSeq: 18908217 INVITE
User-Agent: Bria release 6.1.0 stamp 103104
Warning: 305 devnull "SDP: Incompatible media format: no common codec"
Content-Length: 0

2. Zoiper:

{"level":30,"time":1586924932120,"pid":21649,"hostname":"ip-172-31-36-242.eu-west-1.compute.internal","msg":"Registrar#query: sip:[email protected] returned {\"Protocol\":\"udp\",\"ID\":\"+97252xxxxxxx\",\"Contact\":\"sip:[email protected]:3548;transport=UDP;rinstance=64c4222e2e6bc476\"}","v":1}
{"level":30,"time":1586924932120,"pid":21649,"hostname":"ip-172-31-36-242.eu-west-1.compute.internal","Call-ID":"5hs5q3jangpbpt82sh00","msg":"call to a registered sip client at uri sip:[email protected]:3548;transport=UDP;rinstance=64c4222e2e6bc476","v":1}
  drachtio:fsmrf Endpoint#execute playback https://www.thesoundarchive.com/ringtones/jenny.wav +4s

SIP/2.0 484 Address Incomplete
Via: SIP/2.0/UDP xx.xxx.xx.xxx;rport=5060;branch=z9hG4bKcBFaBppcBX2Za
To: <sip:[email protected]:3548>;tag=79e4ae08;transport=UDP;rinstance=64c4222e2e6bc476
From: "123" <sip:[email protected]>;tag=98bvd6v7mv
Call-ID: 73845899-f974-1238-6d8f-0a7d01e9ec20
CSeq: 18908674 INVITE
User-Agent: Zoiper rv2.10.8.2
Content-Length: 0

3. Twilio sip trunk:

{"level":30,"time":1586925156443,"pid":21649,"hostname":"ip-172-31-36-242.eu-west-1.compute.internal","msg":"Registrar#query: sip:[email protected] returned undefined","v":1}
{"level":30,"time":1586925156443,"pid":21649,"hostname":"ip-172-31-36-242.eu-west-1.compute.internal","Call-ID":"5hs5q3jangpbpt82sh00","Call-ID":"qthrm9onnno0jbc4o8g5","msg":"call to a pstn number sip:[email protected]:5060","v":1}
  drachtio:fsmrf Endpoint#execute playback https://www.thesoundarchive.com/ringtones/jenny.wav +2s

SIP/2.0 488 Not Acceptable here
CSeq: 18908787 INVITE
Call-ID: f93afde7-f974-1238-6d8f-0a7d01e9ec20
From: <sip:[email protected]:5060>;tag=Na8Q3ZH69pH8Q
To: <sip:[email protected]:5060>;tag=57869687_6772d868_402c0d80-8a07-411e-a437-73a3f63905b7
Via: SIP/2.0/UDP xx.xxx.xx.xxx;received=xx.xxx.xx.xxx;rport=5060;branch=z9hG4bKHrD6KXayv9HXm
Server: Twilio
Contact: <sip:172.21.0.248:5060>
X-Twilio-Error: 32102 The SDP is not correctly formatted.
Warning: 305 Twilio "Incompatible media format"
Content-Length: 0

On the drachtio server these are the logs:

2020-04-15 05:20:44.531107 Client::read_handler read: baa6c2cc-d404-4d17-a08b-42a14c15a3b4|sip||
INVITE sip:[email protected]:62890;rinstance=277ebb273d880d0c SIP/2.0
from: "123" <sip:[email protected]>;tag=cj5meg03bo
Content-Length: 2038

v=0
o=- 8867341143521405018 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS 5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw
m=audio 53632 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 77.139.36.12
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:202810205 1 udp 2113937151 4eecf1cb-2932-412b-b51c-d7055a338a3c.local 53632 typ host generation 0 network-cost 999
a=candidate:2064909898 1 udp 2113939711 66b8d9c7-28e6-4a76-861d-e3eda29d984f.local 53633 typ host generation 0 network-cost 999
a=candidate:842163049 1 udp 1677729535 77.139.36.12 53632 typ srflx raddr 0.0.0.0 rport 0 generation 0 network-cost 999
a=ice-ufrag:+51O
a=ice-pwd:CIMlosOn/Am6jB3s2h6NjGhm
a=ice-options:trickle
a=fingerprint:sha-256 40:01:EC:99:E5:04:81:79:52:F1:D9:1E:ED:10:74:52:8C:D0:2D:DE:28:5D:48:D2:65:74:75:23:47:2E:41:ED
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw edf6f799-64f8-4462-8a37-5b1bb50dbc05
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:557316648 cname:mWYNlW4qEMX6CC0Z
a=ssrc:557316648 msid:5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw edf6f799-64f8-4462-8a37-5b1bb50dbc05
a=ssrc:557316648 mslabel:5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw
a=ssrc:557316648 label:edf6f799-64f8-4462-8a37-5b1bb50dbc05


2020-04-15 05:20:44.531243 Client::processMessage - got request with 4 tokens
2020-04-15 05:20:44.531263 Client::processMessage - request id baa6c2cc-d404-4d17-a08b-42a14c15a3b4, request type: sip transaction id: , dialog id:
2020-04-15 05:20:44.531282 Client::processMessage - sending a request outside of a dialog
2020-04-15 05:20:44.531307 ClientController::addAppTransaction: transactionId 71f63706-4bcb-41b2-9cd0-8fc6d5628bbd; size: 1
2020-04-15 05:20:44.531321 ClientController::addApiRequest: clientMsgId baa6c2cc-d404-4d17-a08b-42a14c15a3b4; size: 1
2020-04-15 05:20:44.531464 DrachtioController::findTportForSubscription: no transport found for [email protected]
2020-04-15 05:20:44.531867 SipTransport::findAppropriateTransport: searching for a transport to reach udp/sip:[email protected]:62890;rinstance=277ebb273d880d0c
2020-04-15 05:20:44.531894 SipTransport::findAppropriateTransport - after filtering for transport we have 10 candidates
2020-04-15 05:20:44.531909 SipTransport::findAppropriateTransport - after filtering for protocol we have 2 candidates
2020-04-15 05:20:44.531924 SipTransport::findAppropriateTransport: - returning the best match 0x1343de0: udp/127.0.0.1:5060
2020-04-15 05:20:44.531939 SipTransport::getContactUri - created Contact header: sip:xx.xxx.xx.xxx:5060
2020-04-15 05:20:44.531951 SipDialogController::doSendRequestOutsideDialog selected transport 0x1343de0udp/127.0.0.1:5060
2020-04-15 05:20:44.532012 makeTags - using external IP as replacement for 'localhost': xx.xxx.xx.xxx
2020-04-15 05:20:44.532033 makeTags - Adding well-known header 'from' with value '"123" <sip:[email protected]>;tag=cj5meg03bo'
2020-04-15 05:20:44.532051 SipDialogController::doSendRequestOutsideDialog - from: "123" <sip:[email protected]>;tag=cj5meg03bo
2020-04-15 05:20:44.532064 SipDialogController::doSendRequestOutsideDialog - to: sip:[email protected]:62890;rinstance=277ebb273d880d0c
2020-04-15 05:20:44.532076 SipDialogController::doSendRequestOutsideDialog - contact: <sip:xx.xxx.xx.xxx:5060>
2020-04-15 05:20:44.532090 SipDialogController::doSendRequestOutsideDialog - automatically detecting content-type as application/sdp
2020-04-15 05:20:44.532107 isLocalSipUri: checking to see if this is one of mine: sip:[email protected]:62890;rinstance=277ebb273d880d0c
2020-04-15 05:20:44.532153 nta.c:4566 nta_leg_tcreate() nta_leg_tcreate(0x16e4fa0)
2020-04-15 05:20:44.532202 nta.c:2813 nta_tpn_by_url() nta: selecting scheme sip
2020-04-15 05:20:44.532242 tport.c:3285 tport_tsend() tport_tsend(0x1342fc0) tpn = */77.139.36.12:62890
2020-04-15 05:20:44.532263 tport.c:4085 tport_resolve() tport_resolve addrinfo = 77.139.36.12:62890
2020-04-15 05:20:44.532313 tport.c:3531 tport_send_msg() tport_vsend returned 2500
2020-04-15 05:20:44.532399 send 2500 bytes to udp/[77.139.36.12]:62890 at 05:20:44.532288:
INVITE sip:[email protected]:62890;rinstance=277ebb273d880d0c SIP/2.0
Via: SIP/2.0/UDP xx.xxx.xx.xxx;rport;branch=z9hG4bK181jgerperp8D
Max-Forwards: 70
From: "123" <sip:[email protected]>;tag=cj5meg03bo
To: <sip:[email protected]:62890>;rinstance=277ebb273d880d0c
Call-ID: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20
CSeq: 18910230 INVITE
Contact: <sip:xx.xxx.xx.xxx:5060>
Content-Type: application/sdp
Content-Length: 2038

v=0
o=- 8867341143521405018 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS 5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw
m=audio 53632 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 77.139.36.12
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:202810205 1 udp 2113937151 4eecf1cb-2932-412b-b51c-d7055a338a3c.local 53632 typ host generation 0 network-cost 999
a=candidate:2064909898 1 udp 2113939711 66b8d9c7-28e6-4a76-861d-e3eda29d984f.local 53633 typ host generation 0 network-cost 999
a=candidate:842163049 1 udp 1677729535 77.139.36.12 53632 typ srflx raddr 0.0.0.0 rport 0 generation 0 network-cost 999
a=ice-ufrag:+51O
a=ice-pwd:CIMlosOn/Am6jB3s2h6NjGhm
a=ice-options:trickle
a=fingerprint:sha-256 40:01:EC:99:E5:04:81:79:52:F1:D9:1E:ED:10:74:52:8C:D0:2D:DE:28:5D:48:D2:65:74:75:23:47:2E:41:ED
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw edf6f799-64f8-4462-8a37-5b1bb50dbc05
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:557316648 cname:mWYNlW4qEMX6CC0Z
a=ssrc:557316648 msid:5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw edf6f799-64f8-4462-8a37-5b1bb50dbc05
a=ssrc:557316648 mslabel:5dim5eeCGmRJZ4BOpz0ystCF5gsFijQTE5uw
a=ssrc:557316648 label:edf6f799-64f8-4462-8a37-5b1bb50dbc05
2020-04-15 05:20:44.532462 nta.c:8470 outgoing_send() nta: sent INVITE (18910230) to */77.139.36.12:62890
2020-04-15 05:20:44.532478 tport.c:4199 tport_pend() tport_pend(0x1342fc0): pending 0x16e3990 for udp/172.31.36.242:5060 (already 0)
2020-04-15 05:20:44.532502 SipDialog::SipDialog - creating dialog for outbound INVITE sent from udp/172.31.36.242:5060 to 77.139.36.12:62890
2020-04-15 05:20:44.532519 SipDialogController::addOutgoingInviteTransaction:  adding leg 0x16e4fa0
2020-04-15 05:20:44.532544 ClientController::selectClientForRequestOutsideDialog - there are 1 possible clients, we are starting with offset 0
2020-04-15 05:20:44.532559 ClientController::route_request_outside_dialog - Selected client at offset 0
2020-04-15 05:20:44.532589 ClientController::removeApiRequest: clientMsgId baa6c2cc-d404-4d17-a08b-42a14c15a3b4; size: 0
2020-04-15 05:20:44.532818 Client::write_handler - wrote 2583 bytes: system:0
2020-04-15 05:20:44.532850 Client::write_handler - wrote 2696 bytes: system:0
2020-04-15 05:20:44.778442 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x1342fc0): events IN
2020-04-15 05:20:44.778542 tport.c:2892 tport_recv_event() tport_recv_event(0x1342fc0)
2020-04-15 05:20:44.778571 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1342fc0) msg 0x1705d60 from (udp/172.31.36.242:5060) has 321 bytes, veclen = 1
2020-04-15 05:20:44.778656 recv 321 bytes from udp/[77.139.36.12]:62890 at 05:20:44.778595:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP xx.xxx.xx.xxx;rport=5060;branch=z9hG4bK181jgerperp8D
To: <sip:[email protected]:62890>;rinstance=277ebb273d880d0c
From: "123" <sip:[email protected]>;tag=cj5meg03bo
Call-ID: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20
CSeq: 18910230 INVITE
Content-Length: 0

2020-04-15 05:20:44.778684 tport.c:3051 tport_deliver() tport_deliver(0x1342fc0): msg 0x1705d60 (321 bytes) from udp/77.139.36.12:5060 next=(nil)
2020-04-15 05:20:44.778700 nta.c:3448 agent_recv_response() nta: received 100 Trying for INVITE (18910230)
2020-04-15 05:20:44.778718 nta.c:3515 agent_recv_response() nta: 100 Trying is going to a transaction
2020-04-15 05:20:44.778737 nta.c:9734 outgoing_estimate_delay() nta_outgoing: RTT is 246.492 ms
2020-04-15 05:20:44.778752 tport.c:4261 tport_release() tport_release(0x1342fc0): 0x16e3990 by 0x1706da0 with 0x1705d60 (preliminary)
2020-04-15 05:20:45.015802 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x1342fc0): events IN
2020-04-15 05:20:45.015912 tport.c:2892 tport_recv_event() tport_recv_event(0x1342fc0)
2020-04-15 05:20:45.015941 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1342fc0) msg 0x1705d60 from (udp/172.31.36.242:5060) has 493 bytes, veclen = 1
2020-04-15 05:20:45.016038 recv 493 bytes from udp/[77.139.36.12]:62890 at 05:20:45.015965:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP xx.xxx.xx.xxx;rport=5060;branch=z9hG4bK181jgerperp8D
Contact: <sip:[email protected]:62890;rinstance=277ebb273d880d0c>
To: <sip:[email protected]:62890>;tag=0ba6622e;rinstance=277ebb273d880d0c
From: "123" <sip:[email protected]>;tag=cj5meg03bo
Call-ID: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20
CSeq: 18910230 INVITE
User-Agent: Bria release 6.1.0 stamp 103104
Allow-Events: talk, hold, talk, hold
Content-Length: 0

2020-04-15 05:20:45.016068 tport.c:3051 tport_deliver() tport_deliver(0x1342fc0): msg 0x1705d60 (493 bytes) from udp/77.139.36.12:5060 next=(nil)
2020-04-15 05:20:45.016084 nta.c:3448 agent_recv_response() nta: received 180 Ringing for INVITE (18910230)
2020-04-15 05:20:45.016100 nta.c:3515 agent_recv_response() nta: 180 Ringing is going to a transaction
2020-04-15 05:20:45.016115 tport.c:4261 tport_release() tport_release(0x1342fc0): 0x16e3990 by 0x1706da0 with 0x1705d60 (preliminary)
2020-04-15 05:20:45.016130 SipDialogController::processResponseOutsideDialog
2020-04-15 05:20:45.016239 Client::write_handler - wrote 685 bytes: system:0
2020-04-15 05:20:45.473720 nta.c:7281 _nta_incoming_timer() nta: timer I fired, terminate 200 response
2020-04-15 05:20:45.473827 nta.c:5973 incoming_reclaim_queued() incoming_reclaim_all((nil), (nil), 0x7fffc2c876f0)
2020-04-15 05:20:45.473860 nta.c:7335 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 1/4 term, 1/22 free
2020-04-15 05:20:45.473875 nta.c:1357 agent_timer() nta: timer set next to 11799 ms
2020-04-15 05:20:47.534503 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x1342fc0): events IN
2020-04-15 05:20:47.534602 tport.c:2892 tport_recv_event() tport_recv_event(0x1342fc0)
2020-04-15 05:20:47.534632 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1342fc0) msg 0x1378430 from (udp/172.31.36.242:5060) has 464 bytes, veclen = 1
2020-04-15 05:20:47.534725 recv 464 bytes from udp/[77.139.36.12]:62890 at 05:20:47.534657:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP xx.xxx.xx.xxx;rport=5060;branch=z9hG4bK181jgerperp8D
To: <sip:[email protected]:62890>;tag=0ba6622e;rinstance=277ebb273d880d0c
From: "123" <sip:[email protected]>;tag=cj5meg03bo
Call-ID: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20
CSeq: 18910230 INVITE
User-Agent: Bria release 6.1.0 stamp 103104
Warning: 305 devnull "SDP: Incompatible media format: no common codec"
Content-Length: 0

2020-04-15 05:20:47.534758 tport.c:3051 tport_deliver() tport_deliver(0x1342fc0): msg 0x1378430 (464 bytes) from udp/77.139.36.12:5060 next=(nil)
2020-04-15 05:20:47.534775 nta.c:3448 agent_recv_response() nta: received 488 Not Acceptable Here for INVITE (18910230)
2020-04-15 05:20:47.534792 nta.c:3515 agent_recv_response() nta: 488 Not Acceptable Here is going to a transaction
2020-04-15 05:20:47.534806 tport.c:4261 tport_release() tport_release(0x1342fc0): 0x16e3990 by 0x1706da0 with 0x1378430
2020-04-15 05:20:47.534860 tport.c:3285 tport_tsend() tport_tsend(0x1342fc0) tpn = UDP/77.139.36.12:62890
2020-04-15 05:20:47.534885 tport.c:4085 tport_resolve() tport_resolve addrinfo = 77.139.36.12:62890
2020-04-15 05:20:47.534937 tport.c:3531 tport_send_msg() tport_vsend returned 400
2020-04-15 05:20:47.534974 send 400 bytes to udp/[77.139.36.12]:62890 at 05:20:47.534909:
ACK sip:[email protected]:62890;rinstance=277ebb273d880d0c SIP/2.0
Via: SIP/2.0/UDP xx.xxx.xx.xxx;rport;branch=z9hG4bK181jgerperp8D
Max-Forwards: 70
From: "123" <sip:[email protected]>;tag=cj5meg03bo
To: <sip:[email protected]:62890>;tag=0ba6622e;rinstance=277ebb273d880d0c
Call-ID: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20
CSeq: 18910230 ACK
Content-Length: 0

2020-04-15 05:20:47.535011 nta.c:8470 outgoing_send() nta: sent ACK (18910230) to UDP/77.139.36.12:62890
2020-04-15 05:20:47.535029 nta.c:8888 outgoing_free() nta: outgoing_free(0x1690de0)
2020-04-15 05:20:47.535050 SipDialogController::processResponseOutsideDialog
2020-04-15 05:20:47.535073 SipDialogController::clearIIP:  clearing leg 0x16e4fa0, irq: 0, orq: 0x1706da0, rel: 0
2020-04-15 05:20:47.535088 SipDialogController::clearIIP:  clearing m_mapOrq2IIP for leg 0x16e4fa0
2020-04-15 05:20:47.535121 ClientController::removeAppTransaction: transactionId 71f63706-4bcb-41b2-9cd0-8fc6d5628bbd; size: 0
2020-04-15 05:20:47.535144 ClientController::selectClientForRequestOutsideDialog - there are 1 possible clients, we are starting with offset 0
2020-04-15 05:20:47.535159 ClientController::route_request_outside_dialog - Selected client at offset 0
2020-04-15 05:20:47.535176 ClientController::removeDialog - dialog not found: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20;from-tag=cj5meg03bo
2020-04-15 05:20:47.535191 SipDialog::~SipDialog - destroying sip dialog with call-id b2a850dc-f97b-1238-6d8f-0a7d01e9ec20
2020-04-15 05:20:47.535206 nta.c:4619 nta_leg_destroy() nta_leg_destroy(0x16e4fa0)
2020-04-15 05:20:47.535220 SipDialog::~SipDialog - destroying orq from original (uac) INVITE 0
2020-04-15 05:20:47.535309 Client::write_handler - wrote 656 bytes: system:0
2020-04-15 05:20:47.535336 Client::write_handler - wrote 553 bytes: system:0
2020-04-15 05:20:47.537714 Client::read_handler read: 93c70be5-3495-4fc6-89e3-e006387a1b4c|sip||b2a850dc-f97b-1238-6d8f-0a7d01e9ec20;from-tag=cj5meg03bo
ACK sip:[email protected]:62890;rinstance=277ebb273d880d0c SIP/2.0
Content-Length: 0



2020-04-15 05:20:47.537757 Client::processMessage - got request with 4 tokens
2020-04-15 05:20:47.537774 Client::processMessage - request id 93c70be5-3495-4fc6-89e3-e006387a1b4c, request type: sip transaction id: , dialog id: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20;from-tag=cj5meg03bo
2020-04-15 05:20:47.537788 Client::processMessage - sending a request inside a dialog (dialogId provided)
2020-04-15 05:20:47.537807 ClientController::addApiRequest: clientMsgId 93c70be5-3495-4fc6-89e3-e006387a1b4c; size: 1
2020-04-15 05:20:47.537997 SipDialogController::doSendRequestInsideDialog dialog id: b2a850dc-f97b-1238-6d8f-0a7d01e9ec20;from-tag=cj5meg03bo
2020-04-15 05:20:47.538029 Can't send ACK for dialog id b2a850dc-f97b-1238-6d8f-0a7d01e9ec20;from-tag=cj5meg03bo; likely because stack already ACK'ed non-success final response
2020-04-15 05:20:47.538061 SipDialogController::doSendRequestInsideDialog - Error: ACK for non-success final response is automatically generated by server
2020-04-15 05:20:47.538077 ClientController::removeApiRequest: clientMsgId 93c70be5-3495-4fc6-89e3-e006387a1b4c; size: 0
2020-04-15 05:20:47.538094 ClientController::removeAppTransaction: transactionId f1fd18ac-1525-4b6a-9520-074835ae6a2d; size: 0
2020-04-15 05:20:47.538187 Client::write_handler - wrote 176 bytes: system:0
2020-04-15 05:20:47.583701 Client::read_handler read: c27193cb-98ca-49ed-8b3b-61506c261860|sip|71f63706-4bcb-41b2-9cd0-8fc6d5628bbd|
CANCEL sip:[email protected]:62890;rinstance=277ebb273d880d0c SIP/2.0
Content-Length: 0



2020-04-15 05:20:47.583806 Client::processMessage - got request with 4 tokens
2020-04-15 05:20:47.583831 Client::processMessage - request id c27193cb-98ca-49ed-8b3b-61506c261860, request type: sip transaction id: 71f63706-4bcb-41b2-9cd0-8fc6d5628bbd, dialog id:
2020-04-15 05:20:47.583847 Client::processMessage - sending a CANCEL request inside a transaction
2020-04-15 05:20:47.583872 ClientController::addApiRequest: clientMsgId c27193cb-98ca-49ed-8b3b-61506c261860; size: 1
2020-04-15 05:20:47.583904 Client::read_handler processing follow-on message in read buffer, remaining bytes to process: 138
2020-04-15 05:20:47.583919 Client::read_handler follow-on message length of 134 bytes
2020-04-15 05:20:47.583932 Client::read_handler read: 62425c6b-148b-4ad0-94ba-0298aa7738a9|sip||8isd5qdqods0p5ask1fk;from-tag=cj5meg03bo
BYE sip:placeholder SIP/2.0
Content-Length: 0



2020-04-15 05:20:47.583959 Client::processMessage - got request with 4 tokens
2020-04-15 05:20:47.583973 Client::processMessage - request id 62425c6b-148b-4ad0-94ba-0298aa7738a9, request type: sip transaction id: , dialog id: 8isd5qdqods0p5ask1fk;from-tag=cj5meg03bo
2020-04-15 05:20:47.583986 Client::processMessage - sending a request inside a dialog (dialogId provided)
2020-04-15 05:20:47.584022 ClientController::addAppTransaction: transactionId 591fddbf-bf8d-4eba-870b-8f39549cb399; size: 1
2020-04-15 05:20:47.584039 ClientController::addApiRequest: clientMsgId 62425c6b-148b-4ad0-94ba-0298aa7738a9; size: 2
2020-04-15 05:20:47.584274 SipDialogController::doSendCancelRequest - unknown transaction id 71f63706-4bcb-41b2-9cd0-8fc6d5628bbd
2020-04-15 05:20:47.584309 ClientController::removeApiRequest: clientMsgId c27193cb-98ca-49ed-8b3b-61506c261860; size: 1
2020-04-15 05:20:47.584329 SipDialogController::doSendRequestInsideDialog dialog id: 8isd5qdqods0p5ask1fk;from-tag=cj5meg03bo
2020-04-15 05:20:47.584421 SipDialogController::doSendRequestInsideDialog - defaulting request uri to sip:[email protected];transport=ws;ob
2020-04-15 05:20:47.584438 DrachtioController::findTportForSubscription: no transport found for [email protected]
2020-04-15 05:20:47.584500 tport.c:3285 tport_tsend() tport_tsend(0x16e5ad0) tpn = wss/77.139.36.12:64788
2020-04-15 05:20:47.584537 tport_type_ws.c:311 tport_send_stream_ws() tport_ws_writevec: vec 0x16e5cc0 0x1691660 339 (339)
2020-04-15 05:20:47.584581 tport.c:3531 tport_send_msg() tport_vsend returned 339
2020-04-15 05:20:47.584624 send 339 bytes to wss/[77.139.36.12]:64788 at 05:20:47.584532:
BYE sip:[email protected];transport=ws;ob SIP/2.0
Via: SIP/2.0/WSS 172.31.36.242:443;branch=z9hG4bK2HUBj98SB1cUS
Max-Forwards: 70
From: <sip:[email protected]>;tag=0pFcpSy49ypyF
To: "123" <sip:[email protected]>;tag=cj5meg03bo
Call-ID: 8isd5qdqods0p5ask1fk
CSeq: 3 BYE
Content-Length: 0

2020-04-15 05:20:47.584647 tport.c:2324 tport_set_secondary_timer() tport(0x16e5ad0): reset timer
2020-04-15 05:20:47.584664 nta.c:8470 outgoing_send() nta: sent BYE (3) to wss/77.139.36.12:64788
2020-04-15 05:20:47.584677 tport.c:4199 tport_pend() tport_pend(0x16e5ad0): pending 0x1489d80 for wss/77.139.36.12:64788 (already 0)
2020-04-15 05:20:47.584693 SipDialogController::doSendRequestInsideDialog - created orq 0x148a130 sending BYE to sip:[email protected];transport=ws;ob
2020-04-15 05:20:47.584716 SipDialogController::addRIP adding orq 0x148a130
2020-04-15 05:20:47.584735 ClientController::selectClientForRequestOutsideDialog - there are 1 possible clients, we are starting with offset 0
2020-04-15 05:20:47.584750 ClientController::route_request_outside_dialog - Selected client at offset 0
2020-04-15 05:20:47.584767 ClientController::removeApiRequest: clientMsgId 62425c6b-148b-4ad0-94ba-0298aa7738a9; size: 0
2020-04-15 05:20:47.584925 Client::write_handler - wrote 167 bytes: system:0
2020-04-15 05:20:47.584951 Client::write_handler - wrote 433 bytes: system:0
2020-04-15 05:20:47.584982 Client::write_handler - wrote 533 bytes: system:0
2020-04-15 05:20:47.717376 tport.c:2801 tport_wakeup() tport_wakeup(0x16e5ad0): events IN
2020-04-15 05:20:47.717475 tport.c:2892 tport_recv_event() tport_recv_event(0x16e5ad0)
2020-04-15 05:20:47.717521 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x16e5ad0) msg 0x167e300 from (wss/77.139.36.12:64788) has 323 bytes, veclen = 1
2020-04-15 05:20:47.717604 recv 323 bytes from wss/[77.139.36.12]:64788 at 05:20:47.717539:
SIP/2.0 200 OK
Via: SIP/2.0/WSS 172.31.36.242:443;branch=z9hG4bK2HUBj98SB1cUS
From: <sip:[email protected]>;tag=0pFcpSy49ypyF
To: "123" <sip:[email protected]>;tag=cj5meg03bo
CSeq: 3 BYE
Call-ID: 8isd5qdqods0p5ask1fk
Supported: outbound
User-Agent: SIP.js/0.15.10
Content-Length: 0

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

I think this is expected. You are saying (I think) that you can connect an inbound call to the media server for IVR (or presumably) a conference. Your outdials though are not working though.

I don't completely understand how your app is constructed, can you provide more details.

Keeping focused on this issue however -- "connectCaller times out with webRTC client" -- I still need to know if this is now fixed

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

I have confirmed in my test that this now works. I'm going to be closing this issue shortly (once I migrate the fix from beta into a latest release).

There is more still to do be done -- specifically, there needs to be some way to call Mediaserver#createEndpoint with no remote sdp and get back SRTP, for when you know you want to offer SRTP on an invite (e.g. you are sending a call to a registered webrtc client). But that is not what this issue is about.

Here is a sample test app that works when I call it from a webrtc client. It

  • connects the call to freeswitch using SRTP
  • plays a prompt
  • allocates a new RTP endpoint and then dials through twilio to a PSTN phone, bridging the webrtc endpoint to the PSTN.

https://gist.github.com/davehorton/ca8a9e3820eddcb8b71c9eb4efd224b9

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

fixed in 2.0.0

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

It still not working, also with v2.0.0, with your sample code.
I just modified the srf and mrf configuration.

The mrf logs:
Sat, 18 Apr 2020 18:00:15 GMT drachtio:fsmrf MediaServer#connectCaller - createUAC (srtp scenario) produced dialog for 0a91f46c-fba2-49ea-b877-abfbab9cc8f1: {"id":"651c96e6-fc41-1238-f084-001a4a160113;from-tag=7rBH55D38tBXS","type":"uac","sip":{"callId":"651c96e6-fc41-1238-f084-001a4a160113","remoteTag":"mNac6p77cBFeB","localTag":"7rBH55D38tBXS"},"local":{"uri":"sip:drachtio@<SERVERIP>186:5080","sdp":"v=0\r\no=mozilla...THIS_IS_SDPARTA-71.0 9031364223570339508 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=sendrecv\r\na=fingerprint:sha-256 DD:D7:F0:09:63:23:64:70:EE:E7:9E:12:DC:8B:41:EB:37:3D:CA:14:6E:A0:76:17:8A:D4:F4:76:8A:D7:63:47\r\na=group:BUNDLE 0\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=audio 64723 UDP/TLS/RTP/SAVPF 109 9 0 8 101\r\nc=IN IP4 <CLIENTIPv4>\r\na=candidate:0 1 UDP 2122121471 192.168.22.252 44408 typ host\r\na=candidate:2 1 UDP 2121924863 192.168.248.1 55135 typ host\r\na=candidate:4 1 UDP 2121859327 192.168.23.1 37485 typ host\r\na=candidate:6 1 UDP 2121990399 172.17.0.1 44921 typ host\r\na=candidate:8 1 UDP 2122252543 <CLIENTIPv6>::2428 45495 typ host\r\na=candidate:10 1 UDP 2122187007 <CLIENTIPv6>:ebca:45ee:e7ba:acf 55224 typ host\r\na=candidate:12 1 UDP 2122055935 fd00:1002::1 37006 typ host\r\na=candidate:14 1 TCP 2105393407 192.168.22.252 9 typ host tcptype active\r\na=candidate:15 1 TCP 2105196799 192.168.248.1 9 typ host tcptype active\r\na=candidate:16 1 TCP 2105131263 192.168.23.1 9 typ host tcptype active\r\na=candidate:17 1 TCP 2105262335 172.17.0.1 9 typ host tcptype active\r\na=candidate:18 1 TCP 2105524479 <CLIENTIPv6>::2428 9 typ host tcptype active\r\na=candidate:19 1 TCP 2105458943 <CLIENTIPv6>:ebca:45ee:e7ba:acf 9 typ host tcptype active\r\na=candidate:20 1 TCP 2105327871 fd00:1002::1 9 typ host tcptype active\r\na=candidate:0 2 UDP 2122121470 192.168.22.252 37847 typ host\r\na=candidate:2 2 UDP 2121924862 192.168.248.1 43263 typ host\r\na=candidate:4 2 UDP 2121859326 192.168.23.1 60880 typ host\r\na=candidate:6 2 UDP 2121990398 172.17.0.1 48939 typ host\r\na=candidate:8 2 UDP 2122252542 <CLIENTIPv6>::2428 37146 typ host\r\na=candidate:10 2 UDP 2122187006 <CLIENTIPv6>:ebca:45ee:e7ba:acf 34461 typ host\r\na=candidate:12 2 UDP 2122055934 fd00:1002::1 46429 typ host\r\na=candidate:14 2 TCP 2105393406 192.168.22.252 9 typ host tcptype active\r\na=candidate:15 2 TCP 2105196798 192.168.248.1 9 typ host tcptype active\r\na=candidate:16 2 TCP 2105131262 192.168.23.1 9 typ host tcptype active\r\na=candidate:17 2 TCP 2105262334 172.17.0.1 9 typ host tcptype active\r\na=candidate:18 2 TCP 2105524478 <CLIENTIPv6>::2428 9 typ host tcptype active\r\na=candidate:19 2 TCP 2105458942 <CLIENTIPv6>:ebca:45ee:e7ba:acf 9 typ host tcptype active\r\na=candidate:20 2 TCP 2105327870 fd00:1002::1 9 typ host tcptype active\r\na=candidate:1 1 UDP 1685921791 <CLIENTIPv4> 64723 typ srflx raddr 192.168.22.252 rport 44408\r\na=candidate:3 1 UDP 1685725183 <CLIENTIPv4> 12545 typ srflx raddr 192.168.248.1 rport 55135\r\na=candidate:7 1 UDP 1685790719 <CLIENTIPv4> 49793 typ srflx raddr 172.17.0.1 rport 44921\r\na=candidate:1 2 UDP 1685921790 <CLIENTIPv4> 60014 typ srflx raddr 192.168.22.252 rport 37847\r\na=candidate:3 2 UDP 1685725182 <CLIENTIPv4> 5088 typ srflx raddr 192.168.248.1 rport 43263\r\na=candidate:7 2 UDP 1685790718 <CLIENTIPv4> 58190 typ srflx raddr 172.17.0.1 rport 48939\r\na=sendrecv\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1\r\na=fmtp:101 0-15\r\na=ice-pwd:cee3cb0e5228b1304a63414955a5c347\r\na=ice-ufrag:51955d8f\r\na=mid:0\r\na=msid:{b0285756-5f26-4354-a6ac-c3c5c98574c7} {f36a583a-b648-4dee-bc18-d176fa8bae15}\r\na=rtcp:60014 IN IP4 <CLIENTIPv4>\r\na=rtcp-mux\r\na=rtpmap:109 opus/48000/2\r\na=rtpmap:101 telephone-event/8000\r\na=setup:actpass\r\na=ssrc:3878933796 cname:{52dfda70-4069-48de-8c06-43f826463f51}\r\n","contact":"<sip:<SERVERIP>186:5060>"},"remote":{"uri":"sip:drachtio@<SERVERIP>186:5080;transport=udp","sdp":"v=0\r\no=FreeSWITCH 1587222839 1587222840 IN IP4 <SERVERIP>186\r\ns=FreeSWITCH\r\nc=IN IP4 <SERVERIP>186\r\nt=0 0\r\na=msid-semantic: WMS ZwVvnYJx1Wqg9aJZMBg22QEpDUwtQFDG\r\nm=audio 10018 UDP/TLS/RTP/SAVPF 109 101\r\na=rtpmap:109 opus/48000/2\r\na=fmtp:109 useinbandfec=1; stereo=1\r\na=rtpmap:101 telephone-event/8000\r\na=ptime:20\r\na=fingerprint:sha-256 60:4B:1D:EC:EA:38:CA:EB:E0:ED:FE:79:A1:58:EF:7E:E5:75:87:24:F2:69:20:D6:4E:AD:1A:3C:09:CB:69:14\r\na=setup:active\r\na=rtcp-mux\r\na=rtcp:10018 IN IP4 <SERVERIP>186\r\na=ice-ufrag:cjp50UktEGNlcgS4\r\na=ice-pwd:vK9zbCupmwC77Eu9OK4EueYZ\r\na=candidate:3306520019 1 udp 659136 <SERVERIP>186 10018 typ host generation 0\r\na=end-of-candidates\r\na=ssrc:446844481 cname:1o1fdBD5nTbmUKcx\r\na=ssrc:446844481 msid:ZwVvnYJx1Wqg9aJZMBg22QEpDUwtQFDG a0\r\na=ssrc:446844481 mslabel:ZwVvnYJx1Wqg9aJZMBg22QEpDUwtQFDG\r\na=ssrc:446844481 label:ZwVvnYJx1Wqg9aJZMBg22QEpDUwtQFDGa0\r\n"},"onHold":false} Sat, 18 Apr 2020 18:00:19 GMT drachtio:fsmrf MediaServer#createEndpoint - (srtp scenario) connection timeout for 0a91f46c-fba2-49ea-b877-abfbab9cc8f1 Error handling call Error: Connection timeout at MediaServer.timeoutFn (c:\Users\aryek\Desktop\Dev\side\drc\drachtio-app\drachtio-rtpengine-webrtcproxy\node_modules\drachtio-fsmrf\lib\mediaserver.js:445:20) at listOnTimeout (timers.js:327:15) at processTimers (timers.js:271:5) (node:18700) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'destroy' of undefined at forEach (c:\Users\aryek\Desktop\Dev\side\drc\drachtio-app\drachtio-rtpengine-webrtcproxy\app2.js:45:37) at Array.forEach (<anonymous>) at Object.srf.invite [as handle] (c:\Users\aryek\Desktop\Dev\side\drc\drachtio-app\drachtio-rtpengine-webrtcproxy\app2.js:45:20) at processTicksAndRejections (internal/process/next_tick.js:81:5) (node:18700) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:18700) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

This means that freeswitch was not able to establish the outbound esl connection from freeswitch to your application. Most probably a configuration issue on your side having to do with where your app is running , and what IP it is listening on (e.g an IP that is not reachable from the freeswitch).

In my configuration the drachtio app, drachtio server, and freeswitch were all running on the same server, which does simplify things a bit.

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

I tested it now with chrome and it is working as expected, but with firefox it is not working.
Any idea why firefox cannot handle the sdp from freeswitch, but can handle the sdp from rtpengine?

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

Okay, with firefox - it is timeout problem.
I changed it in mediaserver.js from 4000 to 20000 and it is working as expected.
I think that the difference is the a=setup line in the sdp.
In rtpengine it is a=setup:passive
In freeswitch it is a=setup:active

So for now i must stay with rtpengine as bridge to freeswitch, because it is not acceptable for the user to wait too much time

from drachtio-fsmrf.

davehorton avatar davehorton commented on July 28, 2024

That is very strange. It would be good to see what the freeswitch logs (set to debug) look like for the firefox scenario

from drachtio-fsmrf.

akalter avatar akalter commented on July 28, 2024

OK, it is not problem of the a=setup line.
I forced freeswitch to use passive, and it is still took very long time.
Something around 9-10 seconds in either case.

I will try later to check the logs

from drachtio-fsmrf.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.