Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ORACLE SBC + Drachtio + rtpengine - No connected clients found to handle incoming invite request #10

Closed
ivlovric opened this issue Mar 9, 2019 · 14 comments
Closed

ORACLE SBC + Drachtio + rtpengine - No connected clients found to handle incoming invite request #10

ivlovric opened this issue Mar 9, 2019 · 14 comments

Comments

@ivlovric
Copy link

ivlovric commented Mar 9, 2019 •
edited
Loading

Hi Dave and thanks for this unique repo.

I am having this error above in title where my call is not being recorded and hope you can help.

this is complete log:

INVITE sip:10.116.28.171:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.140:5060;branch=z9hG4bKc835p1201oejvmt2e4i0
Max-Forwards: 70
Call-ID: 323d4a19f0eeb1d10283c935f80d0c16@10.116.28.171
To: sip:10.116.28.171:5060;transport=udp
Contact: sip:acmeSrc@192.168.50.140:5060;transport=udp;+sip.src
From: sip:acmeSrc@192.168.50.140:5060;tag=817c6996f978f421a0ca64181959e0c5
CSeq: 100021 INVITE
Require: siprec
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: 1873
MIME-Version: 1.0

--unique-boundary-1
Content-Type: application/sdp

v=0
o=- 1300 112633 IN IP4 192.168.50.140
s=-
c=IN IP4 192.168.50.140
t=0 0
m=audio 20026 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:16777219
a=sendonly
m=audio 20030 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=maxptime:150
a=label:16777220
a=sendonly

--unique-boundary-1
Content-Type: application/rs-metadata+xml
Content-Disposition: recording-session

complete 2019-03-09T11:37:23 9000 KgEqFsw3SW1H4oLaSgPqKA== 2019-03-09T11:37:23 true 1002 O8ImD6Y6SEVHzyLEDisAlw== 2019-03-09T11:37:23 false 16777219 separate 2019-03-09T11:37:23 16777220 separate 2019-03-09T11:37:34 --unique-boundary-1-- 2019-03-09 12:42:11.659057 nta.c:2968 agent_recv_request() nta: received INVITE sip:10.116.28.171:5060 SIP/2.0 (CSeq 100021) 2019-03-09 12:42:11.659106 nta.c:3183 agent_recv_request() nta: INVITE (100021) to message callback 2019-03-09 12:42:11.659127 processMessageStatelessly - incoming message with call-id 323d4a19f0eeb1d10283c935f80d0c16@10.116.28.171 does not match an existing call leg, processed in thread 140133265098880 2019-03-09 12:42:11.659326 send 325 bytes to udp/[192.168.50.140]:5060 at 12:42:11.659262: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.50.140:5060;branch=z9hG4bKc835p1201oejvmt2e4i0;rport=5060 From: ;tag=817c6996f978f421a0ca64181959e0c5 To: Call-ID: 323d4a19f0eeb1d10283c935f80d0c16@10.116.28.171 CSeq: 100021 INVITE Content-Length: 0

2019-03-09 12:42:11.659390 No connected clients found to handle incoming invite request
2019-03-09 12:42:11.659419 processNewRequest - No providers available for INVITE
2019-03-09 12:42:11.659552 send 356 bytes to udp/[192.168.50.140]:5060 at 12:42:11.659516:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 192.168.50.140:5060;branch=z9hG4bKc835p1201oejvmt2e4i0;rport=5060
From: sip:acmeSrc@192.168.50.140:5060;tag=817c6996f978f421a0ca64181959e0c5
To: sip:10.116.28.171:5060;transport=udp;tag=ZSXH7a2t1jNNc
Call-ID: 323d4a19f0eeb1d10283c935f80d0c16@10.116.28.171
CSeq: 100021 INVITE
Content-Length: 0

2019-03-09 12:42:11.660644 recv 361 bytes from udp/[192.168.50.140]:5060 at 12:42:11.660602:
ACK sip:10.116.28.171:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.140:5060;branch=z9hG4bKc835p1201oejvmt2e4i0
CSeq: 100021 ACK
Max-Forwards: 70
Call-ID: 323d4a19f0eeb1d10283c935f80d0c16@10.116.28.171
To: sip:10.116.28.171:5060;transport=udp;tag=ZSXH7a2t1jNNc
From: sip:acmeSrc@192.168.50.140:5060;tag=817c6996f978f421a0ca64181959e0c5
Content-Length: 0

2019-03-09 12:42:11.660687 nta.c:2968 agent_recv_request() nta: received ACK sip:10.116.28.171:5060 SIP/2.0 (CSeq 100021)
2019-03-09 12:42:11.660714 nta.c:3183 agent_recv_request() nta: ACK (100021) to message callback
2019-03-09 12:42:11.660734 processMessageStatelessly - incoming message with call-id 323d4a19f0eeb1d10283c935f80d0c16@10.116.28.171 does not match an existing call leg, processed in thread 140133265098880

Thanks and regards,
I
@ivlovric
Copy link
Author

ivlovric commented Mar 9, 2019

update:
My drachtio-siprec-recording-server was not running, but here is new output from drachtio-siprec

{"level":30,"time":1552145809169,"msg":"received SIPREC invite: sip:10.116.28.171:5060","pid":5806,"hostname":"siprec-drachtio","callid":"513724f0448795cafb0323fb1ab1cba0@10.116.28.171","v":1}
{"level":50,"time":1552145809173,"msg":"Error connecting call: Error: expected multipart SIPREC body","pid":5806,"hostname":"siprec-drachtio","callid":"513724f0448795cafb0323fb1ab1cba0@10.116.28.171","v":1}

Thanks,
I

@davehorton
Copy link
Collaborator

As you've noted, there are two logs - the drachtio server log and the application log. Would it be possible for you to post a gist of the drachtio server log showing when the SIPREC call arrives? I would like to see what that INVITE looks like because it seems as if there was an error parsing it for some reason.

@ivlovric
Copy link
Author

ivlovric commented Mar 9, 2019 •
edited
Loading

Thanks for reply!
In debugging of payload-parser.js I noticed that in function parseSiprecPayload in "switch" loop, variable req.payload[0].type gets value of "multipart/mixed; boundary=unique-boundary-1" and that whole array is length of 1 instead of 3, so there seems to be the issue.

Please find INVITE attached.

image

SIPREC-INVITE.txt

@davehorton
Copy link
Collaborator

I think I see the problem. I had an issue in a dependent library parsing the Content-Type header with multipart content when there was whitespace before the boundary delimiter. In any case, I've checked in a fix, so can you pull the latest and retest? Make sure to run npm install after getting the latest to install the fixed library

@ivlovric
Copy link
Author

Thanks! Now its parsed correctly. :)
Now whats left for me is to have call recorded in rtpengine, so far directories pcaps and metadata are empty.

@davehorton
Copy link
Collaborator

Hmm, interesting because the app definitely sends the record call: yes instruction to rtpengine.

Are you running rtpengine from a docker image or a native build?

If the latter, I would say to check the rtpengine configuration options to make sure they are set up properly to record.

Here is an example rtpengine systemd file for running rtpengine.

The best way to troubleshoot is to turn log levels for rtpengine up to debug and then watch the syslog on the rtpengine server when you place a call. You should see all of the commands and responses from the drachtio app

@ivlovric
Copy link
Author

I was using custom build on Centos 7, which was not so easy to build and I suspect rtpengine is somewhat broken. Building from ground now up using Debian which seems to be much easier regarding all dependencies. I guess we can close this issue now as it is resolved. Thanks once gain!

@davehorton
Copy link
Collaborator

ok, lets leave open until you are successful with rtpengine on debian.

@ivlovric
Copy link
Author

ivlovric commented Mar 11, 2019 •
edited
Loading

I am able to record calls to pcap format, but as we dont necessarily like to use any post-processing converting pcap to something more friendly, my next task is to record directly to wav/mp3 using rtpengine-recording. :)
Components used (latest drachtio-server, drachtio-siprec-recording-server, latest rtpengine compiled from master).

One question regarding large scale deployment with more control: how is it possible to control what is recorded and what is not as I have ideas to build multi-tenant and controllable call recording solution?

Also, we like to use ansible here and it seems you like it too, so once Ansible role is ready with all components using rtpengine, I can provide it here.

Thanks!

@davehorton
Copy link
Collaborator

davehorton commented Mar 11, 2019 •
edited
Loading

with rtpengine, you can indicate that you want the call to be recorded when you send the 'offer' command (which is what we are doing), or alternatively during the call you can send a start recording command (and later, if you want, send a stop recording command). I don't know, though, if you can start and stop recording multiple times for a single call though.

If you want to change the app to have it be configurable by call whether or not you are recording, then change the setting in the offer command here:

to set the 'record call' property based on a variable in your application.

@rojover
Copy link

rojover commented Oct 8, 2021 •
edited
Loading

Hi there. I'm sorry to post here but i would like to ask a question related to a very similar scenario. In my case there's an oracle SBC which would operate as siprec client. My intention is to use Drachtio siprec server to get the siprec RTP audio stream and instead of actually recording it, buffer and send it to other destinations for real time transcriptions or other actions. I would very much appreciate it if you could just give me your perspective on this idea. Do you think it's doable or see some clear obstacle which would make it not doable or very complex? Many many thanks.

@Mickaelh51
Copy link
Contributor

Mickaelh51 commented Oct 8, 2021 via email

@davehorton
Copy link
Collaborator

Yes, I don't see any reason you could not do that. One option would be to use Freeswitch with my mod_audio_fork to send the audio over a websocket to downstream processing, though you can really handle it any way you want

@rojover
Copy link

rojover commented Oct 9, 2021

Many thanks for that feedback!
I'll be looking at the Oracle SBC -> SIPREC -> Drachtio SIPREC using Freeswitch with the mod_audio_fork scenario first.
Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@davehorton @Mickaelh51 @ivlovric @rojover