Git Product home page Git Product logo

rtpengine's Introduction

Code Testing Debian Package CI Coverity

What is rtpengine?

The Sipwise NGCP rtpengine is a proxy for RTP traffic and other UDP based media traffic. It's meant to be used with the Kamailio SIP proxy and forms a drop-in replacement for any of the other available RTP and media proxies.

Currently the only supported platform is GNU/Linux.

Mailing List

For general questions, discussion, requests for support, and community chat, join our mailing list. Please do not use the Github issue tracker for this purpose.

Features

  • Media traffic running over either IPv4 or IPv6
  • Bridging between IPv4 and IPv6 user agents
  • Bridging between different IP networks or interfaces
  • TOS/QoS field setting
  • Customizable port range
  • Multi-threaded
  • Advertising different addresses for operation behind NAT
  • In-kernel packet forwarding for low-latency and low-CPU performance
  • Automatic fallback to normal userspace operation if kernel module is unavailable
  • Support for Kamailio's rtpproxy module
  • Legacy support for old OpenSER mediaproxy module
  • HTTP, HTTPS, and WebSocket (WS and WSS) interfaces

When used through the rtpengine module (or its older counterpart called rtpproxy-ng), the following additional features are available:

  • Full SDP parsing and rewriting
  • Supports non-standard RTCP ports (RFC 3605)
  • ICE (RFC 5245) support:
    • Bridging between ICE-enabled and ICE-unaware user agents
    • Optionally acting only as additional ICE relay/candidate
    • Optionally forcing relay of media streams by removing other ICE candidates
    • Optionally act as an "ICE lite" peer only
  • SRTP (RFC 3711) support:
    • Support for SDES (RFC 4568) and DTLS-SRTP (RFC 5764)
    • AES-CM and AES-F8 ciphers, both in userspace and in kernel
    • HMAC-SHA1 packet authentication
    • Bridging between RTP and SRTP user agents
    • Opportunistic SRTP (RFC 8643)
    • Legacy non-RFC (dual m= line) best-effort SRTP
    • AES-GCM Authenticated Encryption (AEAD) (RFC 7714)
    • a=tls-id as per RFC 8842
  • Support for RTCP profile with feedback extensions (RTP/AVPF, RFC 4585 and 5124)
  • Arbitrary bridging between any of the supported RTP profiles (RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF)
  • RTP/RTCP multiplexing (RFC 5761) and demultiplexing
  • Breaking of BUNDLE'd media streams (draft-ietf-mmusic-sdp-bundle-negotiation)
  • Recording of media streams, decrypted if possible
  • Transcoding and repacketization
  • Transcoding between RFC 2833/4733 DTMF event packets and in-band DTMF tones (and vice versa)
  • Injection of DTMF events or PCM DTMF tones into running audio streams
  • Playback of pre-recorded streams/announcements
  • Transcoding between T.38 and PCM (G.711 or other audio codecs)
  • Silence detection and comfort noise (RFC 3389) payloads
  • Media forking
  • Publish/subscribe mechanism for N-to-N media forwarding

There is also limited support for rtpengine to be used as a drop-in replacement for Janus using the native Janus control protocol (see below).

Rtpengine does not (yet) support:

  • ZRTP, although ZRTP passes through rtpengine just fine

Documentation

Check our general documentation here:

For quick access, documentation for usage:

For quick access, documentation for development:

Contribution

Every bit matters. Join us. Make the rtpengine community stronger.

rtpengine's People

Contributors

aalba6675 avatar attermann avatar avoylenko avatar balajee-plivo avatar camilleoudot avatar den4t avatar dilyanpalauzov avatar egreenmachine avatar enreached avatar guillemj avatar hdikme avatar inf265 avatar jchavanton avatar juha-h avatar khoegh avatar khorsmann avatar lbalaceanu avatar lemenkov avatar linuxmaniac avatar mika avatar netaskd avatar pkuzak avatar rfuchs avatar sipwise-jenkins avatar slavrov avatar smititelu avatar space88man avatar taurus-forever avatar tombriden avatar zenichev avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rtpengine's Issues

Installing rtpengine on Centos 6.5

Hi guys, I have installed rtpengine on centos 6.5, and I now keep getting the error;

rtpengine: error while loading shared libraries: libxmlrpc_xmlparse.so.3: cannot open shared object file: No such file or directory

However I look in /usr/lib/ directories and I see it there.

Which version of xmlrpc should I be using, I have tried with xmlrpc-c-1.25.27 and .28.

Any help appreciated.

Thanks

Jon

Interop Feature Request: Ignore crypto lifetime flag

Would it be possible to add the functionality to disable the validation of the crypto lifetime attribute if present?

In order to get various phones to work (notably the grandstream 2130) i have had to comment out the error checking between lines 485 - 500 of sdp.c, as the devices in question (incorrectly in my opinion) force the crypto lifetime attribute

After a quite puzzling debugging session, where no errors were reported in the syslog output of the grandstream phone where the call was dropped without reason when the called party answered, i finally saw that the solution was staring me in the face in the rtpengine logs, Jan 8 13:18:23 kambox rtpengine[16719]: Failed to parse a=crypto attribute: invalid key lifetime

This is the same as this asterisk issue: https://issues.asterisk.org/jira/browse/ASTERISK-17899
Grandstream even have an FAQ entry advising you to patch your environment around their stubbornness to make this configurable on the phone... http://www.grandstream.com/support/faq/gxp-enterprise-phone-series#25

Although i don't like disabling validations, i think for the sake of interop with less standards compliant devices and systems it would be beneficial if this behavior could be switched off if required, ideally as a flag in the kamailio module/control protocol or as a make flag.

Extra c= line in media section

Hi,
i'm testing a very simple call flow involving re-INVITE (call on hold). I'm using the interface-bridging branch:

  • Alice is in the "internal" zone (127.0.0.1)
  • Bob is in the "external" zone (10.193.x.x)
  • Kamailio + rtpengine act as SIP and RTP relays

Alice invites Bob, Bob picks up, everything OK

Bob hits the "on hold" button

Bob's phone sends a re-INVITE to Alice with the following SDP

v=0
o=bob 1201 3427 IN IP4 10.193.13.216
s=Talk
c=IN IP4 0.0.0.0
t=0 0
m=audio 7078 RTP/AVP 111 110 0 8 101
c=IN IP4 10.193.13.216
a=rtpmap:111 speex/16000
(...)
a=sendonly

rtpengine rewrites the SDP

v=0
o=bob 1201 3427 IN IP4 10.193.13.216
s=Talk
c=IN IP4 0.0.0.0
t=0 0
a=ice-lite
m=audio 30114 RTP/AVP 111 110 0 8 101
c=IN IP4 127.0.0.1
a=rtpmap:111 speex/16000
(...)
a=sendonly
a=rtcp:30115
(... ice stuff)

there is now an extra c=line in the media section. Is this done intentionally? If yes, in what case is it added and in what case is it not? This re-INVITE message is the only one where i saw an extra c= line.

How to bridge IP4 to IP4

Apologies if this not the right place to discuss this, but i see that the interface bridging branch has been integrated into master. My understanding is that this would allow me to use rtpengine in a bridging mode like i could with rtpproxy. My question is how would i go about enabling this functionality, and would its use from kamailio differ from the IE/EI flag combination on rtpproxy_manage calls from my kamailio.cfg?

If there is a more appropriate place to discuss this please point me in that direction

Use -O2 in CFLAGS?

Any reason why we shouldn't be using the recommended optimization (-O2)?
CFLAGS= -g -O2 -Wall -pthread -fno-strict-aliasing
I'll be conducting a more thorough test with our call center on Monday but initially it seems that it has a decent impact reducing the CPU load.

no IP / Port in answer to kamailio when using "old" udp Port

While trying to get the old way running (for a drop in replacement) we try to get rtpengine just like rtpproxy running.
Since we had some segfault issues this is the actual newest version you have in github

while doing this the rtpengine behaves different and i cannot see any cause why. The differences look like causing no way audio. Maybe you can help.

what happens
Request
kamailio ---> RTPengine
3970_10 U 3448e253ca69-f2cy7erszaem 192.168.178.24 55374 6lvbmtw4eo;1

Answer
kamailio <--- RTPengine
3970_10

Log from rtpengine
Aug 6 17:28:08 kaltz rtpengine[22216]: Got valid command from udp:217.116.124.22:55226: 3967_11 U 8849e2538127-7q4v2k6sgby6 192.168.178.24 59984 uywo40m916;1
Aug 6 17:28:08 kaltz rtpengine[22216]: [8849e2538127-7q4v2k6sgby6] Creating new call
Aug 6 17:28:08 kaltz rtpengine[22216]: [8849e2538127-7q4v2k6sgby6] Returning to SIP proxy: 3967_11

If i compare this with old rtpproxy in the answer port and IP are missing
here it looks like:

Request
kamailio ---> RTPengine
3990_18 U fd48e25382ec-1hzdqelr0pc8 192.168.178.24 58396 yu58b2pcux;1

Answer
kamailio <--- RTPengine
3990_18 51334 217.116.124.22

What did i miss in config since there is no content in the answer?

many thanks!

RTP goes to the address in =o attribute or the address that the sip invite was sent to in some calls

Hi All

We are experiencing an odd problem with 1 way audio in about %6-%8 of our calls.

It seems to me that what is happening is that our kamailio installation (using rtpengine) is some times ignoring the c= attribute that the carrier is sending us, and sending our audio instead to either address in the carriers o= attribute, or just to the same address we sent our sip invite too.

We have looked at hundreds of calls and haven't found a reliable pattern why this happens some times and not others. It really happens in a lot of different scenarios with lots of different carriers and differently formatted SDP packets.

I was wondering if you had an advice as to where to start for a solution, or a way to make rtpengine always send audio to the ip in the c= attribute we are receiving from the carrier.

My best theory is that maybe rtpengine falls back to the addresses held in these other attributes if it can't reach the addresses found in c=. Perhaps it first tries: c= address then o= address and then the one that the invite was sent to.

I have tried to read through the c code a bit but am having a hard time finding the answer I am looking for.

Thank you much for any assistance.

All the best.

Will Ferrer
Switchsoft Inc

Segmentation fault

Since updating from mediaproxy-ng to rtpengine (we had to because of Chrome Update). We experience segmentation faults, normaly on in two weeks. Sometimes at night with zero load, sometimes, under load. This week after update to last commit from July 2nd, Thursday and Friday under Heavy Load: No Problem, today with a few clients: 4 segmention faults in one day. Log from Kamailio:

RTP/AVP", "call-id": "62c60772-ca0e-5a0e-2ade-75139d3d0391", "received-from": [ "IP4", "94.220.217.63" ], "from-tag": "uMNSTxXhA5xLpVFGCDVV", "command": "delete" } Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] Deleting full call Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] Final packet stats:
Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] --- Tag 'as3a1098b8', created 122:10 ago, in dialogue with 'uMNSTxXhA5xLpVFGCDVV'
Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] ------ Media #1, port 30334 <> 94.220.217.63:55463, 381275 p, 64611108 b, 0 e
Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] ------ Media #1, port 30335 <> 94.220.217.63:55463 (RTCP), 16601 p, 1751640 b, 0 e
Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] --- Tag 'uMNSTxXhA5xLpVFGCDVV', created 122:10 ago, in dialogue with 'as3a1098b8'
Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] ------ Media #1, port 30332 <> 172.16.16.104:11116, 366484 p, 64500728 b, 0 e
Jun 25 19:08:48 konfwebrtc1 rtpengine[25185]: [62c60772-ca0e-5a0e-2ade-75139d3d0391] ------ Media #1, port 30333 <> 172.16.16.104:11117 (RTCP), 1465 p, 114270 b, 0 e
Jun 25 19:08:48 konfwebrtc1 kernel: [4922154.524970] rtpengine[25190]:
segfault at 18c7d50 ip 00000000018c7d50 sp 00007fa78ffd7498 error 15

If you are interested in a core dump, i can deliver one.

Hi i get problem implementing 'https://github.com/caruizdiaz/kamailio-ws' The log returned by kamailio is

Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6819]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6821]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6826]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6828]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6829]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6832]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6835]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6824]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6824]: INFO: ctl [io_listener.c:225]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config)
Oct 14 15:59:17 TN02028 /usr/local/sbin/kamailio[6834]: INFO: rtpengine [rtpengine.c:1547]: rtpp_test(): rtp proxy udp:127.0.0.1:22222 found, support for it enabled
Oct 14 15:59:20 TN02028 /usr/local/sbin/kamailio[6828]: INFO: <script>: HTTP Request Received
Oct 14 15:59:38 TN02028 /usr/local/sbin/kamailio[6829]: INFO: <script>: Request coming from WS
Oct 14 15:59:38 TN02028 /usr/local/sbin/kamailio[6817]: INFO: <script>: Reply from softphone: 100
Oct 14 15:59:38 TN02028 /usr/local/sbin/kamailio[6816]: INFO: <script>: Reply from softphone: 180
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: ERROR: <script>: ==> duri=[sip:10.0.2.120:15066;transport=ws]
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: INFO: <script>: Request going to WS
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: WARNING: [msg_translator.c:2756]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be f$
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: ERROR: [msg_translator.c:1984]: build_req_buf_from_sip_req(): could not create Via header
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: ERROR: tm [t_fwd.c:527]: prepare_new_uac(): could not build request
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: ERROR: tm [t_fwd.c:1778]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: ERROR: sl [sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used: No error (2/SL)
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6815]: ERROR: <script>: ==> duri=[sip:10.0.2.120:15066;transport=ws]
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6817]: ERROR: <script>: ==> duri=[sip:10.0.2.120:15066;transport=ws]
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6816]: ERROR: <script>: ==> duri=[sip:10.0.2.120:15066;transport=ws]
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6816]: WARNING: [msg_translator.c:2756]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be f$
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6816]: ERROR: [msg_translator.c:1984]: build_req_buf_from_sip_req(): could not create Via header
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6816]: ERROR: [forward.c:584]: forward_request(): building failed
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6816]: ERROR: sl [sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used: I'm terribly sorry, server error occu$
Oct 14 15:59:42 TN02028 /usr/local/sbin/kamailio[6818]: INFO: <script>: Reply from softphone: 200
Oct 14 15:59:43 TN02028 /usr/local/sbin/kamailio[6829]: ERROR: <script>: ==> duri=[]

Oct 14 15:59:47 TN02028 /usr/local/sbin/kamailio[6815]: ERROR: <script>: ==> duri=[sip:10.0.2.120:15173;transport=ws]

Strange issue which prevents audio

We have successfully been running rtpengine for a couple days (daemon only without kernel module) as a replacement for WebRTC2Sip which was having issues with a "double free". We had a strange problem this afternoon where all of a sudden there was no audio on our calls anymore (actually, I believe that existing calls were ok but new calls failed). Looking in the logs we found the below errors reported. We rebooted rtpengine and all agents were able to connect again.

Openssl 1.0.1j

ERR: [[email protected]:5050 port 31956] DTLS error: 1 (read timeout expired)
ERR: [[email protected]:5050 port 31956] DTLS error on local port 31956
WARNING: [[email protected]:5050 port 31956] Error parsing RTP header: invalid header version
ERR: [[email protected]:5050 port 31957] DTLS error: 1 (read timeout expired)
ERR: [[email protected]:5050 port 31957] DTLS error on local port 31957
WARNING: [[email protected]:5050 port 31957] Error parsing RTCP header: invalid header version

WARNING: [[email protected]:5050 port 33670] Error parsing RTP header: invalid header version
WARNING: [[email protected]:5050 port 33671] Error parsing RTCP header: invalid header version
WARNING: Unknown flag encountered: 'force'
ERR: [[email protected]:5050] DTLS error: 1 (read timeout expired)
ERR: [[email protected]:5050] DTLS error on local port 34193
ERR: [[email protected]:5050] DTLS error: 1 (read timeout expired)
ERR: [[email protected]:5050] DTLS error on local port 34192
WARNING: [[email protected]:5050 port 33057] Error parsing RTCP header: invalid header version
WARNING: [[email protected]:5050 port 33056] Error parsing RTP header: invalid header version
ERR: [[email protected]:5050 port 34245] DTLS error: 1 (read timeout expired)
ERR: [[email protected]:5050 port 34245] DTLS error on local port 34245
ERR: [[email protected]:5050 port 34244] DTLS error: 1 (read timeout expired)
ERR: [[email protected]:5050 port 34244] DTLS error on local port 34244
WARNING: [[email protected]:5050 port 33670] Error parsing RTP header: invalid header version
WARNING: [[email protected]:5050 port 33671] Error parsing RTCP header: invalid header version
WARNING: [[email protected]:5050 port 33057] Error parsing RTCP header: invalid header version
WARNING: [[email protected]:5050 port 33056] Error parsing RTP header: invalid header version

I would also note that we had a similar issue with webrtc2sip at one point so this may be some bad handling in the OpenSSL libraries which is possibly causing OpenSSL to get into a bad state:

***ERROR: function: "tnet_dtls_socket_do_handshake()"
file: "src/tls/tnet_dtls.c"
line: "510"
MSG: DTLS handshake failed [error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type]
***ERROR: function: "tnet_dtls_socket_do_handshake()"
file: "src/tls/tnet_dtls.c"
line: "510"
MSG: DTLS handshake failed [error:141023F2:SSL routines:DTLS1_READ_BYTES:sslv3 alert unexpected message]
***ERROR: function: "tsk_params_get_param_value()"
file: "src/tsk_params.c"
line: "219"
MSG: Invalid parameter  
***ERROR: function: "tsk_params_get_param_value()"
file: "src/tsk_params.c"
line: "219"
MSG: Invalid parameter  
warning: The VAD has been replaced by a hack pending a complete rewrite
warning: The VAD has been replaced by a hack pending a complete rewrite
***ERROR: function: "tnet_dtls_socket_do_handshake()"
file: "src/tls/tnet_dtls.c"
line: "510"
MSG: DTLS handshake failed [error:1413C138:SSL routines:DTLS1_CHECK_TIMEOUT_NUM:read timeout expired]
***ERROR: function: "tnet_dtls_socket_do_handshake()"

segfault in rtpengine 3.3.0.0 mr 3.7.0

We've got another segfault in rtpengine. Might be related to dtls but i'm not sure

This is how rtpengine is running:
/usr/sbin/rtpengine --interface=1.2.3.4 --listen-udp=1.2.3.4:9000 --listen-ng=1.2.3.4:9001 --timeout=120 --silent-timeout=3600 --pidfile=/var/run/ngcp-rtpengine-daemon.pid --port-min=15000 --port-max=30000 --no-fallback --table=0 --log-level=7 --log-facility=local7 --dtls-passive

GDB says:
gdb /usr/lib/debug/usr/sbin/rtpengine /core

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/debug/usr/sbin/rtpengine...done.
[New LWP 3438]
[New LWP 3441]
[New LWP 3434]
[New LWP 3440]
[New LWP 3435]
[New LWP 3439]
[New LWP 3436]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/rtpengine --interface=217.10.77.242 --listen-udp=217.10.77.242:9000 -'.
Program terminated with signal 6, Aborted.
#0  0x00007f0af15ab165 in raise () from /lib/x86_64-linux-gnu/libc.so.6



(gdb) thread apply all bt

Thread 7 (Thread 0x7f0aee5bd700 (LWP 3436)):
#0  0x00007f0af16252bd in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f0af164f9d4 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x000000000040e8f4 in poller_timers_wait_run (p=0xeebfb0, max=100000) at poller.c:500
#3  0x0000000054916120 in ?? ()
#4  0x0000000000031132 in ?? ()
#5  0x0000000000eebfb0 in ?? ()
#6  0x0000000000ef43b0 in ?? ()
#7  0x00007f0aee5bd700 in ?? ()
#8  0x00007f0aee5bd9c0 in ?? ()
#9  0x00007f0af4028040 in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x000000000040865d in timer_loop (d=0x186a0) at main.c:618
#11 0x0000000000eee330 in ?? ()
#12 0x000000000040e9ff in thread_detach_func (d=0x186a0) at aux.c:160
#13 0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7f0aed5bb700 (LWP 3439)):
#0  0x00007f0af1655e13 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000040df8b in poller_poll (p=0xeebfb0, timeout=100) at poller.c:308
#2  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7f0aeedbe700 (LWP 3435)):
#0  0x00007f0af15abe8b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f0af15abf33 in sigtimedwait () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00000000004086eb in sighandler (x=<optimized out>) at main.c:123
#3  0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7f0aecdba700 (LWP 3440)):
#0  0x00007f0af16497d0 in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f0af15e6253 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f0af15efa16 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f0af15f47bc in free () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f0af2aada4d in CRYPTO_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#5  0x00007f0af2816e69 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#6  0x000000000042462b in dtls_connection_init (ps=0x7f0ae00a6e00, active=0, cert=0xeef010) at dtls.c:448
#7  0x00007f0ae00a6e00 in ?? ()
#8  0x0000000000faba40 in ?? ()
#9  0x0000000000fb28f0 in ?? ()
#10 0x0000000001064c30 in ?? ()
#11 0x00007f0ae00a6e00 in ?? ()
#12 0x0000000000410430 in __init_stream (ps=0xfb28f0) at call.c:1748
#13 0x00007f0ae0011700 in ?? ()
#14 0x00007f0ae00a8a20 in ?? ()
#15 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f0af400e720 (LWP 3434)):
#0  0x00007f0af16252bd in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f0af164f9d4 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00000000004083f2 in main (argc=1, argv=0x7fff5e6bfc18) at main.c:654

Thread 2 (Thread 0x7f0ae7fff700 (LWP 3441)):
#0  0x00007f0af1655e13 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000040df8b in poller_poll (p=0xeebfb0, timeout=100) at poller.c:308
#2  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f0aeddbc700 (LWP 3438)):
#0  0x00007f0af15ab165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
---Type <return> to continue, or q <return> to quit---
#1  0x00007f0af15ae3e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f0af15e61cb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f0af15efa16 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f0af15f47bc in free () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007f0af2aada4d in CRYPTO_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#6  0x00007f0af2ae6e20 in BN_clear_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#7  0x00007f0af2b1893d in RSA_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#8  0x00007f0af2b42a3b in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#9  0x00007f0af2b431c8 in EVP_PKEY_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#10 0x00007f0af2816e69 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#11 0x000000000042462b in dtls_connection_init (ps=0x7f0ae802d000, active=0, cert=0xeef010) at dtls.c:448
#12 0x00007f0ae802d000 in ?? ()
#13 0x00007f0ae00b7090 in ?? ()
#14 0x00007f0ae004b4e0 in ?? ()
#15 0x00007f0ae8072cb0 in ?? ()
#16 0x00007f0ae802d000 in ?? ()
#17 0x0000000000410430 in __init_stream (ps=0x7f0ae004b4e0) at call.c:1748
#18 0x00007f0ae001cc40 in ?? ()
#19 0x0000000000f0be60 in ?? ()
#20 0x0000000000000000 in ?? ()




(gdb) bt full
#0  0x00007f0af15ab165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f0af15ae3e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007f0af15e61cb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00007f0af15efa16 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00007f0af15f47bc in free () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x00007f0af2aada4d in CRYPTO_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#6  0x00007f0af2ae6e20 in BN_clear_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#7  0x00007f0af2b1893d in RSA_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#8  0x00007f0af2b42a3b in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#9  0x00007f0af2b431c8 in EVP_PKEY_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#10 0x00007f0af2816e69 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#11 0x000000000042462b in dtls_connection_init (ps=0x7f0ae802d000, active=0, cert=0xeef010) at dtls.c:448
        d = 0x7f0ae004b5a0
        err = <optimized out>
#12 0x00007f0ae802d000 in ?? ()
No symbol table info available.
#13 0x00007f0ae00b7090 in ?? ()
No symbol table info available.
#14 0x00007f0ae004b4e0 in ?? ()
No symbol table info available.
#15 0x00007f0ae8072cb0 in ?? ()
No symbol table info available.
#16 0x00007f0ae802d000 in ?? ()
No symbol table info available.
#17 0x0000000000410430 in __init_stream (ps=0x7f0ae004b4e0) at call.c:1748
        media = 0x7f0ae802d000
        call = 0x7f0ae004b5a0
        active = <optimized out>
#18 0x00007f0ae001cc40 in ?? ()
No symbol table info available.
#19 0x0000000000f0be60 in ?? ()
No symbol table info available.
#20 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) 

If needed, i can send you the logs via Mail

thanks

forgot dtls during build process?

Hi, aktual version of rtpengine ends after few seconds of running with some segmentation fault. Seems we forgot something about dtls during build.

could you please help?

gdb /usr/lib/debug/usr/sbin/rtpengine core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/debug/usr/sbin/rtpengine...done.
[New LWP 3622]
[New LWP 3612]
[New LWP 3616]
[New LWP 3617]
[New LWP 3608]
[New LWP 3615]
[New LWP 3620]
[New LWP 3613]
[New LWP 3618]
[New LWP 3609]
[New LWP 3614]
[New LWP 3610]
[New LWP 3619]
[New LWP 3623]
[New LWP 3621]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/rtpengine --interface=212.9.44.243 --listen-udp=212.9.44.243:9000 --l'.
Program terminated with signal 11, Segmentation fault.
#0  dtls_shutdown (ps=0x2532e00) at dtls.c:675
675 dtls.c: No such file or directory.
(gdb) 

do we need to adapt our build process or do we need to build something else? Didn't find anything in docu.

many thanks

rtpengine crash looks like issue in libcrypto

One of our RTPengine systems stopped working. It looks like there is some issue with libcrypto. Maybe you want to take a look. So far this is the first time it crashes like this.

(gdb) bt full

#0  0x00007f9a7cf32aed in X509_get_pubkey () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
No symbol table info available.
#1  0x00007f9a7d234ceb in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
No symbol table info available.
#2  0x0000000000421772 in dtls_connection_init (ps=ps@entry=0x1773e00, active=0, cert=0x1731680) at dtls.c:441
        d = 0x7f9a70007770
        err = <optimized out>
#3  0x000000000040e33a in __init_stream (ps=ps@entry=0x1773e00) at call.c:1700
        media = 0x1801d20
        call = 0x7f9a680f4090
        active = <optimized out>
#4  0x000000000040e6ad in __init_streams (A=A@entry=0x1801d20, B=B@entry=0x7f9a6811a690, sp=sp@entry=0x0) at call.c:1739
        la = 0x7f9a700c4b40
        lb = 0x17fba40
        a = 0x1773e00
        ax = <optimized out>
        b = 0x1757540
        port_off = <optimized out>
        __PRETTY_FUNCTION__ = "__init_streams"
#5  0x00000000004109c8 in monologue_offer_answer (other_ml=other_ml@entry=0x18af050, streams=streams@entry=0x7f9a77194550, 
    flags=flags@entry=0x7f9a77194570) at call.c:2157
        sp = 0x18b99e0
        media_iter = 0x7f9a701142c0
        ml_media = 0x7f9a70113c40
        other_ml_media = 0x7f9a7005e880
        media = 0x1801d20
        other_media = 0x7f9a6811a690
        num_ports = 2
        monologue = 0x7f9a700ee000
        em = <optimized out>
#6  0x000000000041e43c in call_offer_answer_ng (input=<optimized out>, m=0x1732000, output=output@entry=0x7f9a700bf018, 
    opmode=opmode@entry=OP_OFFER) at call_interfaces.c:605
        sdp = {
          s = 0x7f9a77194816 "v=0\r\no=root 1087808729 1087808730 IN IP4 217.10.77.117\r\ns=sipgate VoIP GW\r\nc=IN IP4 217.10.77.117\r\nt=0 0\r\nm=audio 17578 RTP/AVP 8 0 3 97 18 112 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpma"..., len = 403}
        fromtag = {s = 0x7f9a77194a59 "as5c6bf20a7:command5:offere", len = 10}
        totag = {s = 0x0, len = 0}
        callid = {
          s = 0x7f9a771949fa "[email protected]:received-froml3:IP413:217.10.68.147e8:from-tag10:as5c6bf20a7:command5:offere", len = 43}
        errstr = 0x4261c8 "Invalid dialogue association"
        parsed = {head = 0x7f9a700bbb00, tail = 0x7f9a700bbb00, length = 1}
        streams = {head = 0x7f9a701142c0, tail = 0x7f9a701142c0, length = 1}
        call = 0x7f9a680f4090
        monologue = 0x18af050
        ret = <optimized out>
        flags = {opmode = OP_OFFER, received_from_family = {
            s = 0x7f9a77194a38 "IP413:217.10.68.147e8:from-tag10:as5c6bf20a7:command5:offere", len = 3}, received_from_address = {
            s = 0x7f9a77194a3e "217.10.68.147e8:from-tag10:as5c6bf20a7:command5:offere", len = 13}, media_address = {s = 0x0, 
            len = 0}, transport_protocol_str = {
            s = 0x7f9a771949e6 "RTP/SAVP7:call-id43:[email protected]:received-froml3:IP413:217.10.68.147e8:from-tag10:as5c6bf20a7:command5:offere", len = 8}, address_family_str = {s = 0x0, len = 0}, transport_protocol = 0x423b38, 
          parsed_received_from = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, 
              __u6_addr32 = {0, 0, 0, 0}}}, parsed_media_address = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, 
              __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, directions = {DIR_UNKNOWN, DIR_UNKNOWN}, 
          address_family = 0, tos = 256, asymmetric = 0, trust_address = -1, replace_origin = 0, replace_sess_conn = 0, 
---Type <return> to continue, or q <return> to quit---
          ice_remove = -1, ice_force = 0, ice_force_relay = 0, rtcp_mux_offer = 0, rtcp_mux_demux = 0, rtcp_mux_accept = 0, 
          rtcp_mux_reject = 0, strict_source = 0, media_handover = 0}
        chopper = 0x7f9a70049cf0
#7  0x000000000041f967 in call_offer_ng (input=<optimized out>, m=<optimized out>, output=output@entry=0x7f9a700bf018)
    at call_interfaces.c:630
No locals.
#8  0x0000000000415b35 in control_ng_incoming (obj=0x1736000, buf=<optimized out>, sin=0x7f9a771947a0, 
    addr=0x7f9a771947c0 "217.10.68.174:36212") at control_ng.c:113
        c = 0x1736000
        bencbuf = {pieces = 0x7f9a70109e00, free_list = 0x7f9a70109fb0, error = 0}
        dict = 0x0
        resp = 0x7f9a700bf018
        cmd = {s = 0x7f9a77194a6e "offere", len = <optimized out>}
        cookie = {s = 0x7f9a77194800 "13479_19282", len = 11}
        data = {
          s = 0x7f9a7719480c "d3:sdp403:v=0\r\no=root 1087808729 1087808730 IN IP4 217.10.77.117\r\ns=sipgate VoIP GW\r\nc=IN IP4 217.10.77.117\r\nt=0 0\r\nm=audio 17578 RTP/AVP 8 0 3 97 18 112 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/800"..., len = 616}
        reply = {s = 0x3000000028 <Address 0x3000000028 out of bounds>, len = 1998145392}
        to_send = <optimized out>
        errstr = 0x0
        mh = {msg_name = 0x7f9a771947a0, msg_namelen = 28, msg_iov = 0x7f9a771946c0, msg_iovlen = 3, msg_control = 0x0, 
          msg_controllen = 0, msg_flags = 0}
        iov = {{iov_base = 0x4077194800, iov_len = 140301399836608}, {iov_base = 0x8d74, iov_len = 18374404125135744311}, {
            iov_base = 0x7f9a700c9518, iov_len = 533}}
        log_str = 0x7f9a700e9900
#9  0x000000000041527d in udp_listener_incoming (fd=7, p=0x1734ca0, x=<optimized out>) at udp_listener.c:52
        cb = 0x1734ca0
        sin = {sin6_family = 10, sin6_port = 29837, sin6_flowinfo = 0, sin6_addr = {__in6_u = {
              __u6_addr8 = "\000\000\000\000\000\000\000\000\000\000\377\377\331\nD\256", __u6_addr16 = {0, 0, 0, 0, 0, 65535, 2777, 
                44612}, __u6_addr32 = {0, 0, 4294901760, 2923694809}}}, sin6_scope_id = 0}
        sin_len = 28
        len = 628
        buf = "13479_19282\000d3:sdp403:v=0\r\no=root 1087808729 1087808730 IN IP4 217.10.77.117\r\ns=sipgate VoIP GW\r\nc=IN IP4 217.10.77.117\r\nt=0 0\r\nm=audio 17578 RTP/AVP 8 0 3 97 18 112 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpma"...
        addr = "217.10.68.174:36212", '\000' <repeats 44 times>
        str = {s = 0x7f9a77194800 "13479_19282", len = 628}
#10 0x000000000040bc56 in poller_poll (p=p@entry=0x172dd20, timeout=timeout@entry=100) at poller.c:354
        ret = 1
        i = <optimized out>
        it = 0x1734640
        evs = {{events = 1, data = {ptr = 0x7, fd = 7, u32 = 7, u64 = 7}}, {events = 1, data = {ptr = 0x2f6, fd = 758, u32 = 758, 
              u64 = 758}}, {events = 1, data = {ptr = 0x1e6, fd = 486, u32 = 486, u64 = 486}}, {events = 1, data = {ptr = 0x335, 
              fd = 821, u32 = 821, u64 = 821}}, {events = 1, data = {ptr = 0x34c, fd = 844, u32 = 844, u64 = 844}}, {events = 1, 
            data = {ptr = 0x376, fd = 886, u32 = 886, u64 = 886}}, {events = 1, data = {ptr = 0x28a, fd = 650, u32 = 650, 
              u64 = 650}}, {events = 1, data = {ptr = 0xf2, fd = 242, u32 = 242, u64 = 242}}, {events = 1, data = {ptr = 0x132, 
              fd = 306, u32 = 306, u64 = 306}}, {events = 1, data = {ptr = 0xaa, fd = 170, u32 = 170, u64 = 170}}, {events = 1, 
            data = {ptr = 0x362, fd = 866, u32 = 866, u64 = 866}}, {events = 1, data = {ptr = 0x95, fd = 149, u32 = 149, 
              u64 = 149}}, {events = 1, data = {ptr = 0x13e, fd = 318, u32 = 318, u64 = 318}}, {events = 1, data = {ptr = 0xb9, 
              fd = 185, u32 = 185, u64 = 185}}, {events = 1, data = {ptr = 0x1b2, fd = 434, u32 = 434, u64 = 434}}, {events = 1, 
            data = {ptr = 0x350, fd = 848, u32 = 848, u64 = 848}}, {events = 1, data = {ptr = 0x3f5, fd = 1013, u32 = 1013, 
              u64 = 1013}}, {events = 1, data = {ptr = 0x6a9, fd = 1705, u32 = 1705, u64 = 1705}}, {events = 1, data = {ptr = 0x17d, 
              fd = 381, u32 = 381, u64 = 381}}, {events = 1, data = {ptr = 0x42b, fd = 1067, u32 = 1067, u64 = 1067}}, {events = 1, 
            data = {ptr = 0x2d, fd = 45, u32 = 45, u64 = 45}}, {events = 1, data = {ptr = 0x183, fd = 387, u32 = 387, u64 = 387}}, {
            events = 1, data = {ptr = 0x555, fd = 1365, u32 = 1365, u64 = 1365}}, {events = 1, data = {ptr = 0x35d, fd = 861, 
              u32 = 861, u64 = 861}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}} <repeats 73 times>, {events = 0, 
            data = {ptr = 0x430, fd = 1072, u32 = 1072, u64 = 1072}}, {events = 1879048312, data = {ptr = 0x7000008800007f9a, 
---Type <return> to continue, or q <return> to quit---
              fd = 32666, u32 = 32666, u64 = 8070451116363513754}}, {events = 32666, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {
            events = 1056, data = {ptr = 0x7000007800000000, fd = 0, u32 = 0, u64 = 8070451047644004352}}, {events = 64, data = {
              ptr = 0x1000, fd = 4096, u32 = 4096, u64 = 4096}}, {events = 131072, data = {ptr = 0x22000000000, fd = 0, u32 = 0, 
              u64 = 2336462209024}}, {events = 0, data = {ptr = 0x200, fd = 512, u32 = 512, u64 = 512}}, {events = 1879048224, 
            data = {ptr = 0x20000007f9a, fd = 32666, u32 = 32666, u64 = 2199023288218}}, {events = 0, data = {ptr = 0x1f0, fd = 496, 
              u32 = 496, u64 = 496}}, {events = 512, data = {ptr = 0x7000360000000000, fd = 0, u32 = 0, u64 = 8070509905875828736}}, 
          {events = 32666, data = {ptr = 0x7f9a7b9dd6f4, fd = 2073941748, u32 = 2073941748, u64 = 140301475632884}}, {events = 240, 
            data = {ptr = 0x20000000000, fd = 0, u32 = 0, u64 = 2199023255552}}, {events = 0, data = {ptr = 0x7f9a70000020, 
              fd = 1879048224, u32 = 1879048224, u64 = 140301280739360}}, {events = 512, data = {ptr = 0x1f000000000, fd = 0, 
              u32 = 0, u64 = 2130303778816}}, {events = 0, data = {ptr = 0x2c, fd = 44, u32 = 44, u64 = 44}}, {events = 32, data = {
              ptr = 0x7b9deec600000000, fd = 0, u32 = 0, u64 = 8907538172179644416}}, {events = 32666, data = {ptr = 0x7f9a771a4df8, 
              fd = 1998212600, u32 = 1998212600, u64 = 140301399903736}}, {events = 8, data = {ptr = 0x20000000000, fd = 0, u32 = 0, 
              u64 = 2199023255552}}, {events = 0, data = {ptr = 0x10, fd = 16, u32 = 16, u64 = 16}}, {events = 44, data = {
              ptr = 0x7b9df17900000000, fd = 0, u32 = 0, u64 = 8907541140002045952}}, {events = 32666, data = {ptr = 0x20, fd = 32, 
              u32 = 32, u64 = 32}}, {events = 2108227022, data = {ptr = 0x2d00007f9a, fd = 32666, u32 = 32666, u64 = 193273560986}}, 
          {events = 0, data = {ptr = 0x7f9a70003600, fd = 1879062016, u32 = 1879062016, u64 = 140301280753152}}, {
            events = 1879055360, data = {ptr = 0x70001c2000007f9a, fd = 32666, u32 = 32666, u64 = 8070481456012492698}}, {
            events = 32666, data = {ptr = 0x18, fd = 24, u32 = 24, u64 = 24}}, {events = 2108658769, data = {ptr = 0x1000007f9a, 
              fd = 32666, u32 = 32666, u64 = 68719509402}}, {events = 0, data = {ptr = 0x7f9a7dad7847, fd = 2108520519, 
              u32 = 2108520519, u64 = 140301510211655}}, {events = 8, data = {ptr = 0x173ad8000000000, fd = 0, u32 = 0, 
              u64 = 104617981627072512}}, {events = 0, data = {ptr = 0x7f9a700036a0, fd = 1879062176, u32 = 1879062176, 
              u64 = 140301280753312}}, {events = 51, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {
              ptr = 0x7f9a70002a60, fd = 1879059040, u32 = 1879059040, u64 = 140301280750176}}}
        ev = 0x7f9a771a4860
        e = {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}
#11 0x000000000040821d in poller_loop (d=0x172dd20) at main.c:553
        p = 0x172dd20
#12 0x000000000040c53f in thread_detach_func (d=0x1730270) at aux.c:160
        dt = 0x1730270
        t = 0x173a670
#13 0x00007f9a7bcf4b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#14 0x00007f9a7ba3ee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#15 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) 

(gdb) thread apply all bt

Thread 7 (Thread 0x7f9a789a8700 (LWP 30597)):
#0  0x00007f9a7ba0f33d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f9a7ba39084 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x000000000040c434 in poller_timers_wait_run (p=p@entry=0x172dd20, max=100000, max@entry=100) at poller.c:500
#3  0x000000000040824d in timer_loop (d=0x172dd20) at main.c:546
#4  0x000000000040c53f in thread_detach_func (d=0x1730230) at aux.c:160
#5  0x00007f9a7bcf4b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007f9a7ba3ee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7f9a6ffff700 (LWP 30599)):
#0  0x00007f9a7ba3f4c3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000040bacb in poller_poll (p=p@entry=0x172dd20, timeout=timeout@entry=100) at poller.c:308
#2  0x000000000040821d in poller_loop (d=0x172dd20) at main.c:553
#3  0x000000000040c53f in thread_detach_func (d=0x1730250) at aux.c:160
#4  0x00007f9a7bcf4b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007f9a7ba3ee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7f9a7e3f7720 (LWP 30594)):
#0  0x00007f9a7ba0f33d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f9a7ba39084 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000000000408002 in main (argc=1, argv=0x7fff0a528598) at main.c:573

Thread 4 (Thread 0x7f9a791a9700 (LWP 30595)):
#0  0x00007f9a7b995ecb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f9a7b995f73 in sigtimedwait () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00000000004082db in sighandler (x=<optimized out>) at main.c:119
#3  0x000000000040c53f in thread_detach_func (d=0x1730220) at aux.c:160
#4  0x00007f9a7bcf4b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007f9a7ba3ee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f9a781a7700 (LWP 30598)):
#0  0x00007f9a7ba3f4c3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000040bacb in poller_poll (p=p@entry=0x172dd20, timeout=timeout@entry=100) at poller.c:308
#2  0x000000000040821d in poller_loop (d=0x172dd20) at main.c:553
#3  0x000000000040c53f in thread_detach_func (d=0x1730240) at aux.c:160
#4  0x00007f9a7bcf4b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007f9a7ba3ee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f9a779a6700 (LWP 30600)):
#0  0x00007f9a7ba3f4c3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000040bacb in poller_poll (p=p@entry=0x172dd20, timeout=timeout@entry=100) at poller.c:308
#2  0x000000000040821d in poller_loop (d=0x172dd20) at main.c:553
#3  0x000000000040c53f in thread_detach_func (d=0x1730260) at aux.c:160
#4  0x00007f9a7bcf4b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007f9a7ba3ee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f9a771a5700 (LWP 30602)):
#0  0x00007f9a7cf32aed in X509_get_pubkey () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1  0x00007f9a7d234ceb in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#2  0x0000000000421772 in dtls_connection_init (ps=ps@entry=0x1773e00, active=0, cert=0x1731680) at dtls.c:441
---Type <return> to continue, or q <return> to quit---
#3  0x000000000040e33a in __init_stream (ps=ps@entry=0x1773e00) at call.c:1700
#4  0x000000000040e6ad in __init_streams (A=A@entry=0x1801d20, B=B@entry=0x7f9a6811a690, sp=sp@entry=0x0) at call.c:1739
#5  0x00000000004109c8 in monologue_offer_answer (other_ml=other_ml@entry=0x18af050, streams=streams@entry=0x7f9a77194550, 
    flags=flags@entry=0x7f9a77194570) at call.c:2157
#6  0x000000000041e43c in call_offer_answer_ng (input=<optimized out>, m=0x1732000, output=output@entry=0x7f9a700bf018, 
    opmode=opmode@entry=OP_OFFER) at call_interfaces.c:605
#7  0x000000000041f967 in call_offer_ng (input=<optimized out>, m=<optimized out>, output=output@entry=0x7f9a700bf018)
    at call_interfaces.c:630
#8  0x0000000000415b35 in control_ng_incoming (obj=0x1736000, buf=<optimized out>, sin=0x7f9a771947a0, 
    addr=0x7f9a771947c0 "217.10.68.174:36212") at control_ng.c:113
#9  0x000000000041527d in udp_listener_incoming (fd=7, p=0x1734ca0, x=<optimized out>) at udp_listener.c:52
#10 0x000000000040bc56 in poller_poll (p=p@entry=0x172dd20, timeout=timeout@entry=100) at poller.c:354
#11 0x000000000040821d in poller_loop (d=0x172dd20) at main.c:553
#12 0x000000000040c53f in thread_detach_func (d=0x1730270) at aux.c:160
#13 0x00007f9a7bcf4b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00007f9a7ba3ee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#15 0x0000000000000000 in ?? ()

rtpengine terminates on websocket connection

Hi,

When i make SIP call from webrtc to any other end point. The rtpengine service seems to crash and has to be started again, following is what i see in syslog:

kernel: [4222780.657197] traps: rtpengine[10188] general protection ip:418f33 sp:7f88520c3438 error:0 in rtpengine[400000+28000]

I am relatively new to this thing, How can i get rtpengine to work? (same thing happens with mediapoxy-ng).

Regards

rtpengine fails while calling from public network.

It works well when the caller and callee are from private network but doesnot work if they are from public network or behind NAT.

this is how i start rtpengine
./rtpengine --interface=private IP --listen-ng=127.0.0.1:22222 -m 30000 -M 35000

The log is:
Nov 12 17:10:01 l rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="7667" x-info="http://www.rsyslog.com"] start
Nov 12 17:10:01 l rsyslogd: rsyslogd's groupid changed to 104
Nov 12 17:10:01 l rsyslogd: rsyslogd's userid changed to 101
Nov 12 17:10:01 l rsyslogd-2039: Could no open output pipe '/dev/xconsole': No such file or directory [try http://www.rsyslog.com/e/2039 ]
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:44533: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:53622: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:37934: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:40131: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:50314: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:42393: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:56231: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:50907: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:36101: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:59100: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:44747: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:44106: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:53098: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:40266: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:57617: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:10 l rtpengine[7001]: Got valid command from 127.0.0.1:57855: ping - { "command": "ping" }
Nov 12 17:10:10 l rtpengine[7001]: Returning to SIP proxy: d6:result4:ponge
Nov 12 17:10:23 l rtpengine[7001]: Got valid command from 127.0.0.1:50907: offer - { "sdp": "v=0#015#012o=doubango 1983 678901 IN IP4 192.168.10.104#015#012s=-#15#012$
Nov 12 17:10:23 l rtpengine[7001]: ... ap:3 GSM/8000/1#015#012a=rtpmap:18 g729/8000/1#015#012a=fmtp:18 annexb=no#015#012a=rtpmap:101 telephone-event/8000/1#015#012a=fm$
Nov 12 17:10:23 l rtpengine[7001]: ... 553 label:doubango@audio#015#012a=ice-ufrag:tkVPESvaWcc1f7O#015#012a=ice-pwd:hAFM5UmwNx42DAuly4uCi#015#012a=candidate:8rZ3LPfjt $Nov 12 17:10:23 l rtpengine[7001]: ... ap:3 GSM/8000/1#015#012a=rtpmap:18 g729/8000/1#015#012a=fmtp:18 annexb=no#015#012a=rtpmap:101 telephone-event/8000/1#015#012a=fm$
Nov 12 17:10:23 l rtpengine[7001]: ... 553 label:doubango@audio#015#012a=ice-ufrag:tkVPESvaWcc1f7O#015#012a=ice-pwd:hAFM5UmwNx42DAuly4uCi#015#012a=candidate:8rZ3LPfjt $
Nov 12 17:10:23 l rtpengine[7001]: ... 92.168.10.104#015#012a=rtpmap:103 H263-1998/90000#015#012a=fmtp:103 CIF=2;QCIF=2;SQCIF=2#015#012a=rtpmap:102 H263-2000/90000#015$
Nov 12 17:10:23 l rtpengine[7001]: ... 8/90000#015#012a=imageattr:100 recv [x=[128:16:352],y=[96:16:288]] send [x=[128:16:352],y=[96:16:288]]#15#012a=rtpmap:121 MP4V-$
Nov 12 17:10:23 l rtpengine[7001]: ... 28_HMAC_SHA1_80 inline:5d3g4tjv3lcuFAgxm9+Aj01XT00MhxXgENkImKGv#015#012a=acap:2 crypto:2 AES_CM_128_HMAC_SHA1_32 inline:PsEZtS0t$
Nov 12 17:10:23 l rtpengine[7001]: ... 1642 typ host#015#012a=candidate:XHGYxFLYE 2 udp 2130706174 192.168.10.104 41643 typ host#015#012a=candidate:srflxXHGY 1 udp 169$
Nov 12 17:10:23 l rtpengine[7001]: ... "202.52.254.226" ], "from-tag": "1806497783", "command": "offer" }
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] Creating new call
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] Returning to SIP proxy: d3:sdp3223:v=0#015#012o=doubango 1983 678901 IN IP4 10.0.3.112#015#01$
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] ... pmap:18 g729/8000/1#015#012a=fmtp:18 annexb=no#015#012a=rtpmap:101 telephone-event/8000/1$
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] ... 30477#015#012a=rtcp-mux#015#012a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3m2d70SUYN3ZFmTE$
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] ... 263-1998/90000#015#012a=fmtp:103 CIF=2;QCIF=2;SQCIF=2#015#012a=rtpmap:102 H263-2000/90000$
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] ... [x=[128:16:352],y=[96:16:288]] send [x=[128:16:352],y=[96:16:288]]#15#012a=rtpmap:121 M$
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] ... jv3lcuFAgxm9+Aj01XT00MhxXgENkImKGv#015#012a=acap:2 crypto:2 AES_CM_128_HMAC_SHA1_32 inlin$
Nov 12 17:10:23 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] ... :F1:C8:A9:1C:C1:39:34:D0:24:1C:D5:0B:21:0F:8C:FE#015#012a=ice-ufrag:Iy2gj6ox#015#012a=ice$
Nov 12 17:10:33 l rtpengine[7001]: Got valid command from 127.0.0.1:57617: answer - { "sdp": "v=0#015#012o=Mozilla-SIPUA-32.0.3 18228 1 IN IP4 0.0.0.0#015#012s=Doubang$
Nov 12 17:10:33 l rtpengine[7001]: ... =candidate:0 1 UDP 2122252543 117.121.237.11 43500 typ host#015#012a=candidate:0 2 UDP 2122252542 117.121.237.11 58813 typ host#$
Nov 12 17:10:33 l rtpengine[7001]: ... l": "RTP/AVP", "call-id": "e8af2436-dd8f-bf8c-2334-fdcebbaecf89", "received-from": [ "IP4", "117.121.237.11" ], "from-tag": "180$
Nov 12 17:10:33 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89] Returning to SIP proxy: d3:sdp361:v=0#015#012o=Mozilla-SIPUA-32.0.3 18228 1 IN IP4 0.0.0.0#01$
Nov 12 17:10:37 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89 port 30490] Confirmed peer address as 202.52.254.226:48824
Nov 12 17:15:51 l rtpengine[7001]: [e8af2436-dd8f-bf8c-2334-fdcebbaecf89 port 30490] Error parsing RTCP header: invalid packet type

what might be the problem...

Can't renegotiate DTLS

Hi,

My setup is: -RTP/SAVPF- -RTP/AVP-

I want to move a call from one browser instance to another by sending reINVITE with new SDP. DTLS/ice/ports - everything changed.

reINVITE is rejected with this warning:

WARNING: [[email protected]] DTLS: Peer certificate rejected - fingerprint mismatch

Here is the log:

(gdb)
Continuing.
INFO: [[email protected]] Returning to SIP proxy: d3:sdp540:v=0
o=Sippy 46812552 1 IN IP4 194.6.238.86
s=SIP Call
t=0 0
a=ice-lite
m=audio 30000 RTP/SAVPF 8 101
c=IN IP4 46.51.202.63
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:30001
a=setup:passive
a=fingerprint:sha-1 EA:3B:3B:4C:0D:A7:41:D4:BB:30:60:99:40:05:D8:40:EA:B6:90:90
a=ice-ufrag:0supYCeH
a=ice-pwd:qadMMRxB0cYdgrUOd9AHtYXtorRn
a=candidate:pbAWB1o4xvnzeF4E 1 UDP 2130706431 46.51.202.63 30000 typ host
a ...
INFO: [[email protected]] ... =candidate:pbAWB1o4xvnzeF4E 2 UDP 2130706430 46.51.202.63 30001 typ host
6:result2:oke
INFO: Got valid command from 10.2.48.106:50183: answer - { "sdp": "v=0
o=Sippy 46812552 1 IN IP4 194.6.238.86
s=SIP Call
t=0 0
m=audio 55796 RTP/AVP 8 101
c=IN IP4 194.6.238.86
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
", "ICE": "force", "direction": [ "external", "internal" ], "transport-protocol": "RTP/SAVPF", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.18.109" ], "from-tag": "33ad245d", "to-tag": "jcouhebyldpy ...
INFO: ... iyfi.o", "command": "answer" }

Breakpoint 1, sdp_replace (chop=chop@entry=0x7fffe00064d0, sessions=sessions@entry=0x7fffeb7ed530,
monologue=0x7fffdc005050, flags=flags@entry=0x7fffeb7ed570) at sdp.c:1632
1632 {
(gdb)
Continuing.
INFO: [[email protected]] Returning to SIP proxy: d3:sdp540:v=0
o=Sippy 46812552 1 IN IP4 194.6.238.86
s=SIP Call
t=0 0
a=ice-lite
m=audio 30000 RTP/SAVPF 8 101
c=IN IP4 46.51.202.63
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:30001
a=setup:passive
a=fingerprint:sha-1 EA:3B:3B:4C:0D:A7:41:D4:BB:30:60:99:40:05:D8:40:EA:B6:90:90
a=ice-ufrag:0supYCeH
a=ice-pwd:qadMMRxB0cYdgrUOd9AHtYXtorRn
a=candidate:pbAWB1o4xvnzeF4E 1 UDP 2130706431 46.51.202.63 30000 typ host
a ...
INFO: [[email protected]] ... =candidate:pbAWB1o4xvnzeF4E 2 UDP 2130706430 46.51.202.63 30001 typ host
6:result2:oke
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30014] Confirmed peer address as 194.6.238.86:55796
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Confirmed peer address as 54.76.44.12:57279
INFO: [[email protected] port 30015] Confirmed peer address as 194.6.238.86:55797
INFO: Got valid command from 10.2.48.106:57720: answer - { "sdp": "v=0
o=Sippy 46812552 1 IN IP4 194.6.238.86
s=SIP Call
t=0 0
m=audio 55796 RTP/AVP 8 101
c=IN IP4 194.6.238.86
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
", "ICE": "force", "direction": [ "external", "internal" ], "transport-protocol": "RTP/SAVPF", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.18.109" ], "from-tag": "33ad245d", "to-tag": "jcouhebyldpy ...
INFO: ... iyfi.o", "command": "answer" }
[Switching to Thread 0x7fffeaffd700 (LWP 6734)]

Breakpoint 1, sdp_replace (chop=chop@entry=0x7fffd4005070, sessions=sessions@entry=0x7fffeafec530,
monologue=0x7fffdc005050, flags=flags@entry=0x7fffeafec570) at sdp.c:1632
1632 {
(gdb)
Continuing.
INFO: [[email protected]] Returning to SIP proxy: d3:sdp540:v=0
o=Sippy 46812552 1 IN IP4 194.6.238.86
s=SIP Call
t=0 0
a=ice-lite
m=audio 30000 RTP/SAVPF 8 101
c=IN IP4 46.51.202.63
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:30001
a=setup:passive
a=fingerprint:sha-1 EA:3B:3B:4C:0D:A7:41:D4:BB:30:60:99:40:05:D8:40:EA:B6:90:90
a=ice-ufrag:0supYCeH
a=ice-pwd:qadMMRxB0cYdgrUOd9AHtYXtorRn
a=candidate:pbAWB1o4xvnzeF4E 1 UDP 2130706431 46.51.202.63 30000 typ host
a ...
INFO: [[email protected]] ... =candidate:pbAWB1o4xvnzeF4E 2 UDP 2130706430 46.51.202.63 30001 typ host
6:result2:oke
INFO: [[email protected] port 30001] DTLS: Peer certificate accepted
DEBUG: [[email protected] port 30001] DTLS handshake successful
INFO: [[email protected] port 30001] DTLS-SRTP successfully negotiated
INFO: [[email protected] port 30000] DTLS: Peer certificate accepted
DEBUG: [[email protected] port 30000] DTLS handshake successful
INFO: [[email protected] port 30000] DTLS-SRTP successfully negotiated
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: Got valid command from 10.2.48.106:48031: answer - { "sdp": "v=0
o=Sippy 46812552 1 IN IP4 194.6.238.86
s=SIP Call
t=0 0
m=audio 55796 RTP/AVP 8 101
c=IN IP4 194.6.238.86
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
", "ICE": "force", "direction": [ "external", "internal" ], "transport-protocol": "RTP/SAVPF", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.18.109" ], "from-tag": "33ad245d", "to-tag": "jcouhebyldpy ...
INFO: ... iyfi.o", "command": "answer" }

Breakpoint 1, sdp_replace (chop=chop@entry=0x7fffd40050d0, sessions=sessions@entry=0x7fffeafec530,
monologue=0x7fffdc005050, flags=flags@entry=0x7fffeafec570) at sdp.c:1632
1632 {
(gdb)
Continuing.
INFO: [[email protected]] Returning to SIP proxy: d3:sdp540:v=0
o=Sippy 46812552 1 IN IP4 194.6.238.86
s=SIP Call
t=0 0
a=ice-lite
m=audio 30000 RTP/SAVPF 8 101
c=IN IP4 46.51.202.63
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:30001
a=setup:passive
a=fingerprint:sha-1 EA:3B:3B:4C:0D:A7:41:D4:BB:30:60:99:40:05:D8:40:EA:B6:90:90
a=ice-ufrag:0supYCeH
a=ice-pwd:qadMMRxB0cYdgrUOd9AHtYXtorRn
a=candidate:pbAWB1o4xvnzeF4E 1 UDP 2130706431 46.51.202.63 30000 typ host
a ...
INFO: [[email protected]] ... =candidate:pbAWB1o4xvnzeF4E 2 UDP 2130706430 46.51.202.63 30001 typ host
6:result2:oke
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
I
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: [[email protected] port 30000] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30001] Successful STUN binding request from 54.76.44.12:57279
INFO: [[email protected] port 30001] STUN: using this candidate
INFO: [[email protected] port 30000] Successful STUN binding request from 54.76.44.12:54049
INFO: Got valid command from 10.2.48.106:50183: offer - { "sdp": "v=0
o=- 389709017273804394 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic:WMS 4Fbui50mgZLhtcAG2cr3MeRJ4ARTgZC7XbLF
m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 1.1.1.1
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:u1x8gauuhul8/DSB
a=ice-pwd:xtwKmXc3JJOQ7wzEKSur3C8e
a=ice-options:google-ice
a=fingerprint:sha-256 39:D0:0A:99:E0:CD:3F:8A:81:BD:55:76:88:96:88:46:B3:66:32:DA:20:B9:A1:26:57:63:D7:DC:CD:C8:0 ...
INFO: ... 5:15
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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:126 telephone-event/8000
a=maxptime:60
a=ssrc:122036720 cname:RKeq4UdFnH/S2SBj
a=ssrc:122 ...
INFO: ... 036720 msid:4Fbui50mgZLhtcAG2cr3MeRJ4ARTgZC7XbLF dd3ccf59-0d2c-4a5b-a9e7-ce331818ac9e
a=ssrc:122036720 mslabel:4Fbui50mgZLhtcAG2cr3MeRJ4ARTgZC7XbLF
a=ssrc:122036720 label:dd3ccf59-0d2c-4a5b-a9e7-ce331818ac9e
a=candidate:2246292373 1 udp 2122260223 172.16.10.234 58239 typ host generation 0
", "ICE": "remove", "direction": [ "internal", "external" ], "replace": [ "session-connection" ], "transport-protocol": "RTP/AVP", "call-id": "[email protected]", "received-f ...
INFO: ... rom": [ "IP4", "10.2.19.67" ], "from-tag": "33ad245d", "to-tag": "jcouhebyldpyiyfi.o", "command": "offer" }
WARNING: [[email protected]] DTLS: Peer certificate rejected - fingerprint mismatch
WARNING: [[email protected]] Protocol error in packet from 10.2.48.106:50183: Error rewriting SDP [d3:sdp1234:v=0
o=- 389709017273804394 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic:WMS 4Fbui50mgZLhtcAG2cr3MeRJ4ARTgZC7XbLF
m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 1.1.1.1
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:u1x8gauuhul8/DSB
a=ice-pwd:xtwKmXc3JJOQ7wzEKSur3C8e
a=ice-options:google-ice
a=fingerprint:sha-256 39:D0:0A:99:E0:CD:3F:8A:81:BD:55:76:88:96:88:46:B3:66:32:DA:20:B9:A1:2 ...
WARNING: [[email protected]] ... 6:57:63:D7:DC:CD:C8:05:15
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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:126 telephone-event/8000
a=maxptime:60
a=ssrc:122036720 cname:RKeq4Ud ...
WARNING: [[email protected]] ... FnH/S2SBj
a=ssrc:122036720 msid:4Fbui50mgZLhtcAG2cr3MeRJ4ARTgZC7XbLF dd3ccf59-0d2c-4a5b-a9e7-ce331818ac9e
a=ssrc:122036720 mslabel:4Fbui50mgZLhtcAG2cr3MeRJ4ARTgZC7XbLF
a=ssrc:122036720 label:dd3ccf59-0d2c-4a5b-a9e7-ce331818ac9e
a=candidate:2246292373 1 udp 2122260223 172.16.10.234 58239 typ host generation 0
3:ICE6:remove9:directionl8:internal8:externale7:replacel18:session-connectione18:transport-protocol7:RTP/AVP7:call-id49:[email protected]:received-from ...
WARNING: [[email protected]] ... l3:IP410:10.2.19.67e8:from-tag8:33ad245d6:to-tag18:jcouhebyldpyiyfi.o7:command5:offere]
INFO: [[email protected]] Returning to SIP proxy: d6:result5:error12:error-reason19:Error rewriting SDP

Segmentation Fault on SDP parsing

For some reason, when rtpengine receives an offer from FS, it crashes. The INVITE goes like this:

UA1 -> Kamailio (no rtpengine engagement)  -> FS -> (rtpengine engaged + crash) Kamailio -> UA2

Below is the output of "bt full":

Program terminated with signal 11, Segmentation fault.
#0  0x000000000041b713 in is_addr_unspecified (a=0x510050ad) at aux.h:380
380     if (a->s6_addr32[2] == 0 || a->s6_addr32[2] == htonl(0xffff))
(gdb) bt full
#0  0x000000000041b713 in is_addr_unspecified (a=0x510050ad) at aux.h:380
No locals.
#1  fill_endpoint (ep=0x7fb007b5a8a7, ep=0x7fb007b5a8a7, port=8, address=0x5100507d, flags=0x20, media=0x11c1818) at sdp.c:947
        session = 0x7fb007b5a8ba
#2  sdp_streams (sessions=, streams=0x11c1800, flags=0x20) at sdp.c:1068
        session = 
        media = 0x11c1818
        sp = 0x7fb007b5a87b
        l = 0x9
        k = 0x1
        errstr = 0x4284d8 "Invalid RTCP attribute"
        num = 18627584
        __PRETTY_FUNCTION__ = "sdp_streams"
#3  0x00007faffc001620 in ?? ()
No symbol table info available.
#4  0x00007faffc001620 in ?? ()
No symbol table info available.
#5  0x0000006e00000001 in ?? ()
No symbol table info available.
#6  0x00007faffc0010c0 in ?? ()
No symbol table info available.
#7  0x00007faffc001740 in ?? ()
No symbol table info available.
#8  0x00007faffc001740 in ?? ()
No symbol table info available.
#9  0x0000000000000001 in ?? ()
No symbol table info available.
#10 0x00007fb007b5a914 in ?? ()
No symbol table info available.
#11 0x0000000000000000 in ?? ()
No symbol table info available.

SDP offer by CSipSimple:

Content-Length:   320.
.
v=0.
o=- 3621017196 3621017196 IN IP4 192.168.3.103.
s=pjmedia.
c=IN IP4 192.168.3.103.
t=0 0.
m=audio 4024 RTP/AVP 103 0 8 101.
c=IN IP4 192.168.3.103.
a=rtcp:4025 IN IP4 192.168.3.103.
a=sendrecv.
a=rtpmap:103 ISAC/16000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.

SDP offer by FS

v=0.
o=FreeSWITCH 1412001408 1412001409 IN IP4 x.x.x.x.
s=FreeSWITCH.
c=IN IP4 x.x.x.x.
t=0 0.
m=audio 26986 RTP/AVP 8 101 13.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.

Versions

FS: 1.2.24+git~20140513T183205Z~9af707ed20~64bit
Kamailio: 4.2.0-pre1
rtpengine: git-master-c1d7a52

parse_attribute_crypto

Hi All,
I think c->lifetime = 1 << c->lifetime should be c->lifetime = 1ULL << c->lifetime otherwise for a lifetime of say 2^31 the c->lifetime is populated with a negative value, presumably 1 is interpreted as signed by default.

Thanks
Ed James

test ipv4 to ipv4 rtp proxy ie without bridginig

I want to use rtpengine but not with ipv4 ipv6 bridging ie i want the media to relay from the same ipv4 to ipv4 , differentiated by ports , I have made few changes in class of debian folder , basically omitted some code . My problem is that i dont know how to test it and the test classes present give an error of uuid : command not found .
Is there a way to test media relay for my situation ?
Ps : im using it in userspace mode with No kernel forwarding

Random audio loss after browsers update

After FF (33.1.1) and Chrome (39.0.2171.71) updates, rtpengine behaves erratically in the sense of audio flow establishment. Sometimes, it works, sometimes, it doesn't.

I originally identified this behavior after Chrome mobile update, to 39.0.2171.59, and I thought it was a bug with the browser since it didn't happen with the desktop version which remained v38 until a couple of days ago. After this event, the two major browsers I mentioned, started to show this symptom.

Another interesting thing is that the problem appears only with browser to browser calls. With browser to softphone (csipsimple) it works properly.

I rolled rtpengine back to commit "19e02817447d430c596208e1a3cb3a0acb79b413", and everything went back to normal. I believe some of the changes with the DTLS management introduced some kind of bug.

Regards,
Carlos

Crypto Tag Default

Hi All,
I've got an INVITE containing an SDP offer with a crypto attribute "a=crypto:0 AES..." (added using rtpproxy_manage) so the crypto attribute tag field is defaulting to zero. Looking at the code in call.c the 'sdes_out.tag' variable is commented to default to zero for the offer case (although I can't see where it actually defaults to zero). The 'insert_crypto' function then writes this default into the crypto attribute.

I've got a TLS/SRTP client which expects the crypto tags to start at 1 and which is throwing an error saying that it failed to select a crypto key from sdp in the INVITE. RFC4568 would seem to confirm that the tag should be in the range 1-9 ( http://tools.ietf.org/html/rfc4568#section-9.1 ).

Any comments are suggestions are welcome.

Thanks
Ed James

SDP missing = sign

Just come accross a bit of a strange issue when i try and place a call to holly ivr with the rtp streams transiting through rtpengine. The initial invite is ok, but when the 200 ok reply from holly hits rtpengine i get the following error:

Dec 18 18:40:28 vs-kam-prod02 rtpengine[9856]: Error parsing SDP at offset 262: Missing '=' sign

I have picked apart the sdp body and its well formed with the exception that it seems to have an extra blank line at the end. Having had a cursory look at sdp.c it seems that their isnt a check that the line is > 0 chars in length before its parsed?

What if any impact would skipping blank lines in the sdp body cause? As this system used to work fine before i put it behind kamailio and rtpengine...

udp6 ports been created and leading to port and memory starvation

Continuing from Issue #21 and possibly related to issue #20

After a lot of testing, I can consistently see that there is a linear increase in udp6 ports been opened with RTP Engine. This appears to either saturate memory or port availability.

When traffic is removed there is no increase or decrease in the amount of udp6 ports which appear to be open and listening.

I have tried to disable ipv6 networking, however this issue continues to happen.

Below is the tail for the result for netstat -tulpn

udp6       0      0 :::52371                :::*                                27257/rtpengine
udp6       0      0 :::51859                :::*                                27257/rtpengine
udp6       0      0 :::51091                :::*                                27257/rtpengine
udp6       0      0 :::49299                :::*                                27257/rtpengine
udp6       0      0 :::49043                :::*                                27257/rtpengine
udp6       0      0 :::48019                :::*                                27257/rtpengine
udp6       0      0 :::47763                :::*                                27257/rtpengine
udp6       0      0 :::44179                :::*                                27257/rtpengine
udp6       0      0 :::43667                :::*                                27257/rtpengine
udp6       0      0 :::43411                :::*                                27257/rtpengine
udp6       0      0 :::38803                :::*                                27257/rtpengine
udp6       0      0 :::38291                :::*                                27257/rtpengine
udp6       0      0 :::31635                :::*                                27257/rtpengine
udp6       0      0 :::31123                :::*                                27257/rtpengine
udp6       0      0 :::29331                :::*                                27257/rtpengine
udp6       0      0 :::26771                :::*                                27257/rtpengine
udp6       0      0 :::56979                :::*                                27257/rtpengine
udp6       0      0 :::56467                :::*                                27257/rtpengine
root@rtp-lon-1:~# netstat -tulpn | grep udp | wc -l
32046

This is after I removed all traffic from the server 5 minutes prior, there is 30,000 udp6 ports here. I am not 100% sure of the exact relevance, but it seems a bit strange. I have IP6 addresses on my server, but they are not in use, I am utilizing IPv4 only.

RTP Packets but no audio

I dont know if this is connected with Issue #8.
We had that every few weeks / few days.
Now with Version from 10th of July everything went fine, until yesterday.
Every connected client didnt receive or transmit audio.

First i was searching on one client i was configuring, i was seeing rtp data between client and rtpengine, but it looked more like a general keepalive (i dont know how to explain it better, for my experience there werent sufficient packets for speach). rtpenginge was running and working, but without audio. After a rtpengine restart everything was fine.

The Problem is, the segmentation fault was easy to monitor, this isnt. If you tell me, which data you need, i will deliver.

Enhancement: Ability to specify DTLS cert/key (or print it at startup)

We would like to be able to capture and analyze the traffic between rtpengine and the WebRTC endpoints that we are connecting. Unfortunately, since the negotiation is in the media plane and we don't have access to the DTLS key since it gets generated at startup we are unable to do any capturing.

Two possible options that would be nice would be:
a) The ability to specify a DTLS cert/key that would be used.
b) Have an option to make rtpengine print the DTLS cert/key at startup.

Thanks,
Jarrod

No Audio on FF34

When trying to interconnect FF34 to Chrome, or even FF to FF, the audio establishment fails always.

In the logs I see:

Jan 11 15:51:45 carucloud1 rtpengine[5094]: [mlupa19ri25b4lq7099e port 32644] Successful STUN binding request from 201.141.129.19:53464
Jan 11 15:51:45 carucloud1 rtpengine[5094]: [mlupa19ri25b4lq7099e port 32644] STUN: using this candidate
Jan 11 15:51:45 carucloud1 rtpengine[5094]: [mlupa19ri25b4lq7099e port 32644] DTLS: Peer certificate accepted
Jan 11 15:51:45 carucloud1 rtpengine[5094]: [mlupa19ri25b4lq7099e port 32644] DTLS-SRTP successfully negotiated
Jan 11 15:51:45 carucloud1 rtpengine[5094]: [mlupa19ri25b4lq7099e port 32644] DTLS-SRTP successfully negotiated
Jan 11 15:51:49 carucloud1 rtpengine[5094]: [mlupa19ri25b4lq7099e port 32644] Confirmed peer address as 201.141.129.19:53464

But, comparing to Chrome logs, the multiple "Successful STUN binding" like the following ...

Jan 11 15:46:31 carucloud1 rtpengine[5094]: [3bkc0oqbsobnvqqk0j63 port 32510] Successful STUN binding request from 201.141.129.19:33457
Jan 11 15:46:31 carucloud1 rtpengine[5094]: [3bkc0oqbsobnvqqk0j63 port 32510] STUN: using this candidate
Jan 11 15:46:31 carucloud1 rtpengine[5094]: [3bkc0oqbsobnvqqk0j63 port 32498] Successful STUN binding request from 201.141.129.19:45243
Jan 11 15:46:31 carucloud1 rtpengine[5094]: [3bkc0oqbsobnvqqk0j63 port 32498] STUN: using this candidate

... does not appear.

This happens browser to browser, and browser to regular UA.

Failure in Phone makes rtpengine spam syslog

When there is a malfunktion in an SIP Phone and it offers an SAVP without an Key it results in one way audio and a full log.

rtpengine is logging something like this:
Sep 29 13:58:35 hostname rtpengine[47020]: [[email protected] port 41848] SRTP output wanted, but no crypto suite was negotiated
for each RTP Packet.

unfortunately it's an error if this would be debug or only reprorted once you could just drop it or keep the singel message.

Rtpengine forwards SSL trafic on RTP on call hold

Hi,

I'm using 3.3.0.0+0~mr3.4.2.1 and kamailio 4.2.0-pre1 (x86_64/linux) 44e298

When Sipml client presses on hold asterisk receives SSL traffic on RTP instance:
[Oct 3 12:41:47] ERROR[4493][C-00000059]: res_rtp_asterisk.c:1936 __rtp_recvfrom: Received SSL traffic on RTP instance '0x7f9cfc4aa6e8' without an SSL session
[Oct 3 12:41:47] ERROR[4493][C-00000059]: res_rtp_asterisk.c:1936 __rtp_recvfrom: Received SSL traffic on RTP instance '0x7f9cfc4aa6e8' without an SSL session
[Oct 3 12:41:47] WARNING[4493][C-00000059]: res_rtp_asterisk.c:4197 ast_rtp_read: RTP Read error: Unspecified. Hanging up.
[Oct 3 12:41:47] WARNING[4493][C-00000059]: res_rtp_asterisk.c:4197 ast_rtp_read: RTP Read error: Unspecified. Hanging up.

rtpengine log shows:
Oct 3 12:41:47 localhost rtpengine[3772]: Got valid command from 127.0.0.1:41616: offer - { "sdp": "v=0#015#012o=- 3161846126406615600 3 IN IP4 127.0.0.1#015#012s=Doubango Telecom - chrome#015#012t=0 0#015#012a=msid-semantic: WMS pGwX5Qn9NlVMDtJYyEwwQQ6pvQj9ZiqLDG6x#015#012m=audio 55508 UDP/TLS/RTP/SAVPF 0#015#012c=IN IP4 10.15.38.22#015#012a=rtcp:62638 IN IP4 10.15.38.22#015#012a=candidate:852255240 1 udp 2122260223 10.15.38.22 55508 typ host generation 0#015#012a=candidate:852255240 2 udp 2122260222 10.15.38.22 62638 typ host generation 0#015#012a=ice-ufrag:WNYhlfivFdT+aRoo#015#012a=ice-pwd:gPQbOMQScANKN+22dpskNBeH#015#012a=fingerprint:sha-256 1E:74:90:87:9B:DF:F9:EF:F4:B0:F8:4E:CB:35:B3:AF:44:DB:D2:BB:31:EF:5B:5F:03:B0:3B:F5:34:6B:DF:BE#015#012a=setup:active#015#012a=mid:audio#015#012a=sendonly#015#012a=rtpmap:0 PCMU/8000#015#012a=ssrc:3600308564 cname:/HlU0tr3/SI8jof1#015#012a=ssrc:3600308564 msid:pGwX5Qn9NlVMDtJYyEwwQQ6pvQj9ZiqLDG6x 5059faa4-c28d-498d-a37f-4a99ae4471cd#015#012a=ssrc:3600308564 mslabel:pGwX5Qn9NlVMDtJYyEwwQQ6pvQj9ZiqLDG6x#015#012a=ssrc:3600308564 label:5059faa4-c28d-498d-a37f-4a99ae4471cd#015#012", "ICE": "remove", "flags": [ "force", "trust-address" ], "replace": [ "origin", "session-connection" ], "transport-protocol": "RTP/AVP", "call-id": "[email protected]:5060", "received-from": [ "IP4", "10.15.38.22" ], "from-tag": "zIaE6fQu094GLubHaDmv", "to-tag": "as365a4e0c", "command": "offer" }
Oct 3 12:41:47 localhost rtpengine[3772]: Unknown flag encountered: 'force'
Oct 3 12:41:47 localhost rtpengine[3772]: [[email protected]:5060] Returning to SIP proxy: d3:sdp522:v=0#015#012o=- 3161846126406615600 3 IN IP4 10.15.26.112#015#012s=Doubango Telecom - chrome#015#012t=0 0#015#012a=msid-semantic: WMS pGwX5Qn9NlVMDtJYyEwwQQ6pvQj9ZiqLDG6x#015#012m=audio 30010 RTP/AVP 0#015#012c=IN IP4 10.15.26.112#015#012a=mid:audio#015#012a=rtpmap:0 PCMU/8000#015#012a=ssrc:3600308564 cname:/HlU0tr3/SI8jof1#015#012a=ssrc:3600308564 msid:pGwX5Qn9NlVMDtJYyEwwQQ6pvQj9ZiqLDG6x 5059faa4-c28d-498d-a37f-4a99ae4471cd#015#012a=ssrc:3600308564 mslabel:pGwX5Qn9NlVMDtJYyEwwQQ6pvQj9ZiqLDG6x#015#012a=ssrc:3600308564 label:5059faa4-c28d-498d-a37f-4a99ae4471cd#015#012a=sendonly#015#012a=rtcp:30011#015#0126:result2:oke

rtcp-mux changing on re-INVITE

I'm testing standalone rtpengine with webRTC client (RTP/SAVPF) and legacy devices (RTP/AVP) and see a problem in the following scenario:

  1. Offer from webRTC (RTP/SAVPF) client send to rtpengine with offer[rtcp-mux] = demux, offer[ICE] = remove, offer[transport-protocol] = RTP/AVP
  2. SDP received from engine and sent to legacy client
  3. Answer received from legacy client and sent to engine with answer[ICE]=force (optional), answer[transport-protocol]=RTP/SAVPF (optional), answer[rtcp-mux]=reject, offer
  4. rtpengine return correct SDP for answer where the same port used for RTP and RTCP and with single candidate for that addres:port:

m=audio 30074 RTP/SAVPF 0
a=rtcp:30074
a=rtcp-mux
a=candidate ... 30074 typ host

Now, when I receive re-INVITE from legacy client (ie, the other side of the session) and send it to rtpengine as an offer with swapped from-tag and to-tag, engine return SDP with additional port allocated for RTPC and two candidates for RTP and RTCP each, ie:

m=audio 30074 RTP/SAVPF 0
a=rtcp:30075
a=rtcp-mux
a=candidate ... 30074 typ host
a=candidate ... 30075 typ host

I tried different parameters / no parameters for rtcp-mux without lack - result is always the same.

DTLS negotiation fails

Incoming call from SIP w/ RTP/AVP to Webrtc w/ SRTP/AVPF - no audio.

Browser does not say "ICE connected" on webrtc-internals and kept saying "Received non-DTLS packet before DTLS complete"

From tcpdump I can see client(browser) keeps sending its certificate w/o any response from rtpengine.

Worth to mention: first DTLS packet from client comes before "answer" is processed by rtpengine. Sometimes I dont see this issue so it is racy.

", "ICE": "force", "direction": [ "external", "internal" ], "transport-protocol": "RTP/SAVPF", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.18.109" ], "from-tag": "tmf7mepnchgx4gf2.o", "command": "offer" }
NOTICE: [[email protected]] Creating new call
DEBUG: [[email protected]] Opened ports 32116..32117 for media relay
DEBUG: [[email protected]] Opened ports 32130..32131 for media relay
INFO: [[email protected]] Returning to SIP proxy: d3:sdp697:v=0
o=Sippy 790073928 0 IN IP4 194.6.238.84
s=SIP Call
t=0 0
a=ice-lite
m=audio 32116 RTP/SAVPF 8 0 18 101
c=IN IP4 46.51.202.63
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:32117
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:YEviGbqC/pJAlKDSs/3fqeGVqkiRDm6dyvgao7hs
a=setup:actpass
a=fingerprint:sha-1 AB:B6:8A:6F:4F:50:32:2E:13:B9:6E:54:2F:B9:CE:60:5F:B8:D1:88
a=ice-ufrag:9gVR2bxi
a=ice-pwd:7eew5h2Pg6vA0MLAITjEHPiQ3bF6
a=candidate:DWVERZrcf4ciJmzG 1 UDP 2130706431 46.51.202.63 32116 typ host
a=candidate:DWVERZrcf4ciJmzG 2 UDP 2130706430 46.51.202.63 32117 typ host
6:result2:oke
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: Got valid command from 10.2.48.106:51486: answer - { "sdp": "v=0
o=- 187397460986484946 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic:WMS PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
m=audio 9 RTP/SAVPF 8 0 101
c=IN IP4 1.1.1.1
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Ni7uWzSBZiwFDsaQ
a=ice-pwd:iaTe7M3ny7H3zaVeTrnje0jZ
a=fingerprint:sha-256 6C:EC:A8:34:B8:34:1B:09:6B:DF:05:D1:7E:F5:66:B0:87:FC:46:24:8C:9F:48:08:A5:63:07:2C:49:E3:F4:47
a=setup:active
a=mid:audio
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:3121243410 cname:UscVNj+UJudcbTAw
a=ssrc:3121243410 msid:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=ssrc:3121243410 mslabel:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
a=ssrc:3121243410 label:fdef30b1-1cb4-45ac-8b40-38ca39671ee9
", "ICE": "remove", "direction": [ "internal", "external" ], "replace": [ "session-connection" ], "transport-protocol": "RTP/AVP", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.19.134" ], "from-tag": "tmf7mepnchgx4gf2.o", "to-tag": "1b3f50c2", "command": "answer" }
INFO: [[email protected]] Returning to SIP proxy: d3:sdp556:v=0
o=- 187397460986484946 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic:WMS PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
m=audio 32130 RTP/AVP 8 0 101
c=IN IP4 46.51.202.63
a=mid:audio
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:3121243410 cname:UscVNj+UJudcbTAw
a=ssrc:3121243410 msid:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=ssrc:3121243410 mslabel:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
a=ssrc:3121243410 label:fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=sendrecv
a=rtcp:32131
6:result2:oke
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
WARNING: [[email protected] port 32117] Error parsing RTCP header: invalid header version
INFO: Got valid command from 10.2.48.106:49650: offer - { "sdp": "v=0
o=- 187397460986484946 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic:WMS PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
m=audio 9 RTP/SAVPF 8 0 101
c=IN IP4 1.1.1.1
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Ni7uWzSBZiwFDsaQ
a=ice-pwd:iaTe7M3ny7H3zaVeTrnje0jZ
a=fingerprint:sha-256 6C:EC:A8:34:B8:34:1B:09:6B:DF:05:D1:7E:F5:66:B0:87:FC:46:24:8C:9F:48:08:A5:63:07:2C:49:E3:F4:47
a=setup:active
a=mid:audio
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:3121243410 cname:UscVNj+UJudcbTAw
a=ssrc:3121243410 msid:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=ssrc:3121243410 mslabel:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
a=ssrc:3121243410 label:fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=candidate:1682511864 1 udp 2122194687 10.6.5.18 56223 typ host generation 0
a=candidate:1682511864 2 udp 2122194686 10.6.5.18 57628 typ host generation 0
", "ICE": "remove", "direction": [ "internal", "external" ], "replace": [ "session-connection" ], "transport-protocol": "RTP/AVP", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.19.134" ], "from-tag": "1b3f50c2", "to-tag": "tmf7mepnchgx4gf2.o", "command": "offer" }
INFO: [[email protected]] Returning to SIP proxy: d3:sdp568:v=0
o=- 187397460986484946 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic:WMS PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
m=audio 32130 RTP/AVP 8 0 101
c=IN IP4 46.51.202.63
a=mid:audio
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:3121243410 cname:UscVNj+UJudcbTAw
a=ssrc:3121243410 msid:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=ssrc:3121243410 mslabel:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
a=ssrc:3121243410 label:fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=sendrecv
a=rtcp:32131
a=rtcp-mux
6:result2:oke
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: Got valid command from 10.2.48.106:51486: answer - { "sdp": "v=0
o=Sippy 790073928 1 IN IP4 194.6.238.84
s=SIP Call
t=0 0
m=audio 51144 RTP/AVP 8 101
c=IN IP4 194.6.238.84
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
", "ICE": "force", "direction": [ "external", "internal" ], "transport-protocol": "RTP/SAVPF", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.18.109" ], "from-tag": "1b3f50c2", "to-tag": "tmf7mepnchgx4gf2.o", "command": "answer" }
INFO: [[email protected]] Returning to SIP proxy: d3:sdp541:v=0
o=Sippy 790073928 1 IN IP4 194.6.238.84
s=SIP Call
t=0 0
a=ice-lite
m=audio 32116 RTP/SAVPF 8 101
c=IN IP4 46.51.202.63
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:32117
a=setup:passive
a=fingerprint:sha-1 AB:B6:8A:6F:4F:50:32:2E:13:B9:6E:54:2F:B9:CE:60:5F:B8:D1:88
a=ice-ufrag:9gVR2bxi
a=ice-pwd:7eew5h2Pg6vA0MLAITjEHPiQ3bF6
a=candidate:DWVERZrcf4ciJmzG 1 UDP 2130706431 46.51.202.63 32116 typ host
a=candidate:DWVERZrcf4ciJmzG 2 UDP 2130706430 46.51.202.63 32117 typ host
6:result2:oke
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: Got valid command from 10.2.48.106:49650: offer - { "sdp": "v=0
o=- 187397460986484946 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic:WMS PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
m=audio 9 RTP/SAVPF 8 0 101
c=IN IP4 1.1.1.1
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Ni7uWzSBZiwFDsaQ
a=ice-pwd:iaTe7M3ny7H3zaVeTrnje0jZ
a=fingerprint:sha-256 6C:EC:A8:34:B8:34:1B:09:6B:DF:05:D1:7E:F5:66:B0:87:FC:46:24:8C:9F:48:08:A5:63:07:2C:49:E3:F4:47
a=setup:active
a=mid:audio
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:3121243410 cname:UscVNj+UJudcbTAw
a=ssrc:3121243410 msid:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=ssrc:3121243410 mslabel:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
a=ssrc:3121243410 label:fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=candidate:1682511864 1 udp 2122194687 10.6.5.18 56223 typ host generation 0
a=candidate:1682511864 2 udp 2122194686 10.6.5.18 57628 typ host generation 0
a=candidate:717941512 1 tcp 1518214911 10.6.5.18 0 typ host tcptype active generation 0
a=candidate:717941512 2 tcp 1518214910 10.6.5.18 0 typ host tcptype active generation 0
", "ICE": "remove", "direction": [ "internal", "external" ], "replace": [ "session-connection" ], "transport-protocol": "RTP/AVP", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.19.134" ], "from-tag": "1b3f50c2", "to-tag": "tmf7mepnchgx4gf2.o", "command": "offer" }
INFO: [[email protected]] Returning to SIP proxy: d3:sdp568:v=0
o=- 187397460986484946 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic:WMS PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
m=audio 32130 RTP/AVP 8 0 101
c=IN IP4 46.51.202.63
a=mid:audio
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:3121243410 cname:UscVNj+UJudcbTAw
a=ssrc:3121243410 msid:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=ssrc:3121243410 mslabel:PQXgiu2jplzhtnbxWq7FKDPeYPqzMllKeSKU
a=ssrc:3121243410 label:fdef30b1-1cb4-45ac-8b40-38ca39671ee9
a=sendrecv
a=rtcp:32131
a=rtcp-mux
6:result2:oke
INFO: Got valid command from 10.2.48.106:52994: answer - { "sdp": "v=0
o=Sippy 790073928 1 IN IP4 194.6.238.84
s=SIP Call
t=0 0
m=audio 51144 RTP/AVP 8 101
c=IN IP4 194.6.238.84
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
", "ICE": "force", "direction": [ "external", "internal" ], "transport-protocol": "RTP/SAVPF", "call-id": "[email protected]", "received-from": [ "IP4", "10.2.18.109" ], "from-tag": "1b3f50c2", "to-tag": "tmf7mepnchgx4gf2.o", "command": "answer" }
INFO: [[email protected]] Returning to SIP proxy: d3:sdp541:v=0
o=Sippy 790073928 1 IN IP4 194.6.238.84
s=SIP Call
t=0 0
a=ice-lite
m=audio 32116 RTP/SAVPF 8 101
c=IN IP4 46.51.202.63
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:32117
a=setup:passive
a=fingerprint:sha-1 AB:B6:8A:6F:4F:50:32:2E:13:B9:6E:54:2F:B9:CE:60:5F:B8:D1:88
a=ice-ufrag:9gVR2bxi
a=ice-pwd:7eew5h2Pg6vA0MLAITjEHPiQ3bF6
a=candidate:DWVERZrcf4ciJmzG 1 UDP 2130706431 46.51.202.63 32116 typ host
a=candidate:DWVERZrcf4ciJmzG 2 UDP 2130706430 46.51.202.63 32117 typ host
6:result2:oke
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected] port 32130] Confirmed peer address as 194.6.238.84:51144
INFO: [[email protected] port 32116] Successful STUN binding request from 148.122.175.42:56223
INFO: [[email protected] port 32116] STUN: using this candidate
INFO: [[email protected] port 32116] Confirmed peer address as 148.122.175.42:56223
INFO: [[email protected] port 32117] Successful STUN binding request from 148.122.175.42:57628
INFO: [[email protected] port 32117] STUN: using this candidate
INFO: [[email protected]] Closing call due to timeout
INFO: [[email protected]] Final packet stats:
INFO: [[email protected]] --- Tag '1b3f50c2', created 10:59 ago, in dialogue with 'tmf7mepnchgx4gf2.o'
INFO: [[email protected]] ------ Media #1, port 32116 <> 148.122.175.42:56223, 1188 p, 128304 b, 0 e
INFO: [[email protected]] ------ Media #1, port 32117 <> 148.122.175.42:57628 (RTCP), 1238 p, 134441 b, 0 e
INFO: [[email protected]] --- Tag 'tmf7mepnchgx4gf2.o', created 10:59 ago, in dialogue with '1b3f50c2'
INFO: [[email protected]] ------ Media #1, port 32130 <> 194.6.238.84:51144, 29771 p, 5418322 b, 0 e
INFO: [[email protected]] ------ Media #1, port 32131 <> 194.6.238.84:51145 (RTCP), 31 p, 3162 b, 0

RTPEngine Lockup

Occasionally, I am experiencing issues where CPU goes to maximum utilisation,

The following message is repeated quote a few times

Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible

Even when load is removed completely CPU usage stays locked at 100%.

strace reveals the following information on one of the processes:

rt_sigtimedwait([INT USR1 USR2 TERM], NULL, {0, 100000000}, 8) = -1 EAGAIN (Resource temporarily unavailable)

Segmentation Fault

Crashed with Segmentation Fault

Built on clean install of Ubuntu 14.04.

Tail of Log

Aug 28 06:05:26 rtp-lon-5 rtpengine[30020]: [58cff5ec041c90ee5941828a6f0533a8] Failed to get 2 consecutive UDP ports for relay
Aug 28 06:05:26 rtp-lon-5 rtpengine[30020]: [58cff5ec041c90ee5941828a6f0533a8] Error allocating media ports
Aug 28 06:05:26 rtp-lon-5 rtpengine[30020]: [58cff5ec041c90ee5941828a6f0533a8] Media has no streams
Aug 28 06:05:26 rtp-lon-5 rtpengine[30020]: [58cff5ec041c90ee5941828a6f0533a8] Returning to SIP proxy: 23935_7177
Aug 28 06:05:26 rtp-lon-5 rtpengine[30020]: [4fe1b58b0e730a2d6f4f25e23f901d38] Failed to get 2 consecutive UDP ports for relay
Aug 28 06:05:26 rtp-lon-5 rtpengine[30020]: [4fe1b58b0e730a2d6f4f25e23f901d38] Error allocating media ports
Aug 28 06:05:26 rtp-lon-5 kernel: [72040.955492] show_signal_msg: 12 callbacks suppressed
Aug 28 06:05:26 rtp-lon-5 kernel: [72040.955518] rtpengine[30026]: segfault at 58 ip 000000000040e385 sp 00007f4707808240 error 4 in rtpengine[400000+2a000]

GDB

gdb /usr/sbin/rtpengine CoreDump
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/rtpengine...(no debugging symbols found)...done.
[New LWP 30026]
[New LWP 30020]
[New LWP 30021]
[New LWP 30022]
[New LWP 30023]
[New LWP 30024]
[New LWP 30025]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/rtpengine --ip=178.62.XXX.XXX --listen-tcp=25060 --listen-udp=22222 --l'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000040e385 in ?? ()
(gdb) bt full
#0  0x000000000040e385 in ?? ()
No symbol table info available.
#1  0x00000000004118d6 in call_stream_address ()
No symbol table info available.
#2  0x000000000041d8a6 in ?? ()
No symbol table info available.
#3  0x000000000041db34 in ?? ()
No symbol table info available.
#4  0x000000000041259c in ?? ()
No symbol table info available.
#5  0x0000000000413e21 in ?? ()
No symbol table info available.
#6  0x000000000040b54e in poller_poll ()
No symbol table info available.
#7  0x00000000004076ad in _start ()
No symbol table info available.

(gdb) thread apply all bt

Thread 7 (Thread 0x7f470801a700 (LWP 30025)):
#0  0x00007f470e8aaa23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000000040b3eb in poller_poll ()
#2  0x00000000004076ad in _start ()

Thread 6 (Thread 0x7f470881b700 (LWP 30024)):
#0  0x00007f470e8aaa23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000000040b3eb in poller_poll ()
#2  0x00000000004076ad in _start ()

Thread 5 (Thread 0x7f470901c700 (LWP 30023)):
#0  0x00007f470e8aaa23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000000040b3eb in poller_poll ()
#2  0x00000000004076ad in _start ()

Thread 4 (Thread 0x7f470981d700 (LWP 30022)):
#0  0x00007f470e870d8d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f470e8a23b4 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
#2  0x000000000040b7d4 in poller_timers_wait_run ()
#3  0x00000000004076dd in _start ()

Thread 3 (Thread 0x7f470a01e700 (LWP 30021)):
#0  0x00007f470e7e7050 in do_sigtimedwait (timeout=0x7f470a01de20, info=0x0, set=0x7f470a01de30) at ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigtimedwait.c:53
#1  __GI___sigtimedwait (set=0x7f470a01de30, info=0x0, timeout=0x7f470a01de20) at ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigtimedwait.c:81
#2  0x000000000040776b in _start ()

Thread 2 (Thread 0x7f471085e780 (LWP 30020)):
#0  0x00007f470e870d8d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f470e8a23b4 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
#2  0x0000000000407562 in main ()

Thread 1 (Thread 0x7f4707819700 (LWP 30026)):
#0  0x000000000040e385 in ?? ()
#1  0x00000000004118d6 in call_stream_address ()
#2  0x000000000041d8a6 in ?? ()
#3  0x000000000041db34 in ?? ()
#4  0x000000000041259c in ?? ()
#5  0x0000000000413e21 in ?? ()
#6  0x000000000040b54e in poller_poll ()
#7  0x00000000004076ad in _start ()

Apologies if this is the same as #8 as it looks like that issue has a fix and also sorry that I cant provider more detailed gdb information, I am not too familiar with it, if you can tell me how to setup my environment to correctly provide symbol table info info, I will run again.

Extra crlf added causes invalid sdp

Hi,

I'm not quite sure if this is a bug or not.

I did a configuration error in my kamailio testlab which used both fix_nated_sdp and rtpproxy for the same call. That caused the sdp to look like this:
"a=setup:actpass
a=fingerprint:sha-1 9A:D4:08:93:0F:46:23:3E:3B:58:4D:AF:51:A6:C7:5E:90:2D:BA:CB

a=direction:active"

In this example I use rtpengine to proxy between srtp/rtp, but it's the same with just normal rtp.

The last line is added by kamailio. Kamailio seems to always start a new line with crlf (and none at the end), but rtpengine adds a single line with crlf at the end of the sdp message returned. This could be a problem?

This patch seems to fix it for me, but I don't know if it will break something else.

--- daemon/sdp.c 2014-08-27 09:09:40.649757586 +0200
+++ daemon/sdp.c 2014-08-27 09:26:51.951569589 +0200
@@ -1617,7 +1617,6 @@
chopper_append_c(chop, hf->name);
chopper_append_c(chop, " ");
chopper_append_dup(chop, hexbuf, o - hexbuf);

  • chopper_append_c(chop, "\r\n");
    }

static void insert_crypto(struct call_media *media, struct sdp_chopper *chop) {
@@ -1803,7 +1802,6 @@
chopper_append_str(chop, &call_media->ice_ufrag);
chopper_append_c(chop, "\r\na=ice-pwd:");
chopper_append_str(chop, &call_media->ice_pwd);

  •           chopper_append_c(chop, "\r\n");
        }
    
        if (!flags->ice_remove) {
    

RE-invite support (call hold)

Hello,

I'm trying to implement Re-invite with rtpengine (for call hold/unhold), but I don't clearly see
how to implement the Kamailio script when the Re-invite is sent by callee.

For Re-invite sent by caller:

  • on INVITE receipt, kamailio asks rtpengine for an updated offer (calling again rtpproxy_offer)
  • on 200 Ok receipt, kamailio asks rtpengine for an updated answer (calling again rtpproxy_answer)
    This works for both "call hold" and "call unhold"

For Re-invite sent by the callee:

  • on INVITE receipt, kamailio asks rtpengine for an updated answer (calling again rtpproxy_answer)
  • on 200 Ok receipt, kamailio asks rtpengine for an updated offer (calling again rtpproxy_offer)

This doesn't work, the updated answer on INVITE is not understood by the client (RTP media port is 0 and no crypto parameters).
The caller is a Chrome web page with jssip, the callee is a linphone sip stack (clear RTP). The linphone sip stack (callee) initiates the Re-invite.

The question is: should the "Re-invite sent by the callee" be implemented this way ?

Best regards,
Yoann

SRTP lands on the browser before keying material negotiated

I have sp (RTP/AVP) to SP (RTP/SAVPF) call setup. Browser to SIP. Using DTLS to setup SRTP keys on browser and rtpproxy-ng.

This chain of events causes encrypted RTP played by the browser before it knows SRTP keys. It sounds like a white noise:

  1. INVITE w/o candidates to rtpproxy-ng from Browser side
  2. Ringing w/ SDP from SIP side, (answer is sent to Browser and ICE starts); and RTP comes from SIP side
  3. white noise played for a second then comes ringing tone

rtpproxy-ng on Centos 5.9

Hi Guys,

Just trying to install rtpengine on a server running Centos 5.9, and I can see iptables v1.3.5 is in place.

First question, will rtpengine work on Centos 5.9 (as I normally use 6.5 and it works great), and then also I believe I have to upgrade iptables to minimum version 1.4.3.

Is that correct?

Many thanks

Jon

Problem compiling on 64bit Centos 6.5

uname:
Linux localhost 2.6.32-431.11.2.el6.x86_64 #1 SMP Tue Mar 25 19:59:55 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

make[1]: Entering directory /root/rtpengine/daemon
gcc -g -Wall -pthread -fno-strict-aliasing -std=c99 pkg-config --cflags glib-2.0 pkg-config --cflags gthread-2.0 pkg-config --cflags zlib pkg-config --cflags openssl pcre-config --cflags` -I../kernel-module/ -D_GNU_SOURCE -DMEDIAPROXY_VERSION="""2.3.6""" -DMP_PLUGIN_DIR=""/usr/lib/rtpengine"" -O3 -c -o call.o call.c
In file included from call.c:25:
../kernel-module/xt_MEDIAPROXY.h:23: warning: declaration does not declare anything
call.c: In function âkernelizeâ:
call.c:342: error: âstruct mp_addressâ has no member named âipv4â
call.c:344: error: âstruct mp_addressâ has no member named âipv4â
call.c:348: error: âstruct mp_addressâ has no member named âipv6â
call.c:348: error: âstruct mp_addressâ has no member named âipv6â
call.c:350: error: âstruct mp_addressâ has no member named âipv6â
call.c:350: error: âstruct mp_addressâ has no member named âipv6â
make[1]: *** [call.o] Error 1
make[1]: Leaving directory /root/rtpengine/daemon
make: *** [all] Error 2

parallel fork of calls with same Call-ID

Hello. I try to do parallel fork calls to endpoints that have same username and different destination URI through Kamailio. Logic of my script:

checking location table for rows with needed account
get info from contact at loop

for every step

check technology (sip or ws)
handle call with rtpengine
append_branch with existing destination for this account
rewrite packet with rtpengine to needed technology

after loop
forward packets via t_relay

sql_query("ca", "select contact from location where username='$tU'", "ra");
xlog("rows: $dbr(ra=>rows) cols: $dbr(ra=>cols)\n");

        if($dbr(ra=>rows)>0){
            $var(i)=0;
             while($var(i)<$dbr(ra=>rows)){

                xlog("L_INFO","SQL query return contact {$dbr(ra=>[$var(i),0])} for {$tU} at step {$var(i)}\n");

                if ($dbr(ra=>[$var(i),0])=~"transport=ws"){ 
                    xlog("L_INFO", "This is a Websocket call to endpoint");
                    sql_pvquery("ca", "select received from location where contact='$dbr(ra=>[$var(i),0])'","$var(recieved)");
                    xlog("L_INFO","SQL query return recieved {$var(recieved)} for {$tU}\n");
                    $du=$var(recieved);
                    xlog("L_INFO", "Request going FROM ASTERISK to WS. Destination is {$du}\n");
                    xlog("L_INFO","Websocket Destination URI is {$var(recieved)} for {$tU}\n");
                    rtpproxy_manage("froc+SP");
                    t_on_reply("REPLY_FROM_WS");
                    append_branch("sip:$tU@$du");
                    $var(i) = $var(i) + 1;
                }

                else
                {   
                    xlog("L_INFO", "This is a classic UDP call to endpoint");

                    $du="sip:"+$(dbr(ra=>[$var(i),0]){s.select,1,@});
                    xlog("L_INFO","Classic Destination URI is {$dbr(ra=>[$var(i),0])} for {$tU}\n");
                    rtpproxy_manage("co");
                    t_on_reply("MANAGE_CLASSIC_REPLY");
                    append_branch("sip:$tU@$du");
                    $var(i) = $var(i) + 1;
                }
                #append_branch("sip:$tU@$du");

            }   
        }
        return 1;

So it customised schema of standart example

seturi("sip:[email protected]");
append_branch("sip:[email protected]");
append_branch("sip:[email protected]");
append_branch("sip:[email protected]");

t_relay();

At my test I have 2 endpoints with WS and UDP phones (at fist step ir WS and 2 step it UDP). when I do these steps (at my script) I see packet at TCP dump and saw that sended only one packet to UDP but body of packet is WS. Then I saw log of kamailio. I see that at second step packet changed body to WS body (so strange because other steps before and after goes for UDP (as at logic of script))

All calls going form asterisk via UDP.

I think my problem may be at rtpengine that already handle packetd with this Call-ID and gives same result for other flags to this packet at second step.

Does it right?

query command not returning "streams" element

Hello,

I developed a java client for rtpengine using the ng protocol. Everything went fine until I tried to retrieve channel stats by issuing a 'query' command and passing the call-id of the current streaming as the only parameter. I only got the 'result=ok' and so there was missing the 'streams' element with all channels stats as described in the documentation: https://github.com/sipwise/rtpengine#query-message

Any thoughts? Below the relevant log parts in linux syslog:

Thanks!

Apr 22 02:02:07 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: ping - { "command": "ping" }
Apr 22 02:02:07 bhlangonijr-lap rtpengine[12389]: Returning to SIP proxy: d6:result4:ponge
Apr 22 02:02:08 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: offer - { "call-id": "[email protected]", "command": "offer", "flags": [ "trust address" ], "from-tag": "[email protected]", "sdp": "v=0#015#012o=root 123 123 IN IP4 127.0.0.1#015#012s=stream#015#012c=IN IP4 127.0.0.1#015#012t=0 0#015#012m=audio 20000 RTP/AVP#015#012" }
Apr 22 02:02:08 bhlangonijr-lap rtpengine[12389]: [[email protected]] Creating new call
Apr 22 02:02:08 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d3:sdp342:v=0#015#012o=root 123 123 IN IP4 127.0.0.1#015#012s=stream#015#012c=IN IP4 127.0.0.1#015#012t=0 0#015#012a=ice-lite#015#012m=audio 30060 RTP/AVP#015#012a=sendrecv#015#012a=rtcp:30061#015#012a=ice-ufrag:lQuPNmPc#015#012a=ice-pwd:mQy8MinKorIo1lVmpDJ6ZkbiaD7Y#015#012a=candidate:88bsieY2c5oyVJlM 1 UDP 2130706432 127.0.0.1 30060 typ host#015#012a=candidate:88bsieY2c5oyVJlM 2 UDP 2130706431 127.0.0.1 30061 typ host#015#0126:result2:oke
Apr 22 02:02:08 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: answer - { "call-id": "[email protected]", "command": "answer", "flags": [ "trust address" ], "from-tag": "[email protected]", "sdp": "v=0#015#012o=root 123 123 IN IP4 127.0.0.1#015#012s=stream#015#012c=IN IP4 127.0.0.1#015#012t=0 0#015#012m=audio 20002 RTP/AVP#015#012", "to-tag": "[email protected]" }
Apr 22 02:02:08 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d3:sdp342:v=0#015#012o=root 123 123 IN IP4 127.0.0.1#015#012s=stream#015#012c=IN IP4 127.0.0.1#015#012t=0 0#015#012a=ice-lite#015#012m=audio 30062 RTP/AVP#015#012a=sendrecv#015#012a=rtcp:30063#015#012a=ice-ufrag:XV8kLGqx#015#012a=ice-pwd:WNiidYHejCAJejNbDWrMzxIxsQPd#015#012a=candidate:88bsieY2c5oyVJlM 1 UDP 2130706432 127.0.0.1 30062 typ host#015#012a=candidate:88bsieY2c5oyVJlM 2 UDP 2130706431 127.0.0.1 30063 typ host#015#0126:result2:oke
Apr 22 02:02:13 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:13 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:18 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:18 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:23 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:23 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
^[[AApr 22 02:02:28 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:28 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:33 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:33 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:38 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:38 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:43 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:43 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:47 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: ping - { "command": "ping" }
Apr 22 02:02:47 bhlangonijr-lap rtpengine[12389]: Returning to SIP proxy: d6:result4:ponge
Apr 22 02:02:48 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:48 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:53 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:53 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:02:58 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:02:58 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:03:03 bhlangonijr-lap rtpengine[12389]: Got valid command from 127.0.0.1:18426: query - { "call-id": "[email protected]", "command": "query" }
Apr 22 02:03:03 bhlangonijr-lap rtpengine[12389]: [[email protected]] Returning to SIP proxy: d6:result2:oke
Apr 22 02:03:10 bhlangonijr-lap NetworkManager[1176]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: Closing call branch due to timeout
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: [[email protected]] Final packet stats:
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: [[email protected]] --- Tag '[email protected]', created 2:01 ago, in dialogue with '[email protected]'
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: [[email protected]] ------ Media #1, port 30062 <>       127.0.0.1:6020 , 5992 p, 947940 b, 0 e
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: [[email protected]] ------ Media #1, port 30063 <>       127.0.0.1:6021  (RTCP), 37 p, 2868 b, 0 e
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: [[email protected]] --- Tag '[email protected]', created 2:01 ago, in dialogue with '[email protected]'
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: [[email protected]] ------ Media #1, port 30060 <>       127.0.0.1:6022 , 5991 p, 947904 b, 0 e
Apr 22 02:04:09 bhlangonijr-lap rtpengine[12389]: [[email protected]] ------ Media #1, port 30061 <>       127.0.0.1:6023  (RTCP), 31 p, 2484 b, 0 e

100% Utilisation (lots of sendmsg)

Compiled and deployed on a clean Ubuntu 14.04, I ran traffic for 1 hour, then system went to 100% utilisation.

We were using the old RTP Proxy protocol and configured ipv4 only.

Running strace we got the following message (defiantly starting the exact same) continuously repeating. Failed to respond to service stop, had to kill the process and restart.

sendmsg(279, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(31930), inet_pton(AF_INET6, "::ffff:178.62.XXX.XXX", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\241P\16R\377\331\221\2\253\272?OF>;AWVIHFRjlw\337\336\341kX"..., 172}], msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 172
recvfrom(275, "\200\0\241\335\16SW\371\221\2\253\272,e\260\243\236\233\232\232\233\235\237\247\262\317>+"\36\33\31"..., 8192, 0, {sa_family=AF_INET6, sin6_port=htons(31934), inet_pton(AF_INET6, "::ffff:178.62.XXX.XXX", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 172

RTPENGINE stops answering on control port

We are using rtpengine under load.
So far we are using only "old" control UDP Port since we want to use it as drop in replacement.

Unfortunately after 20h working fine, rtpengine just stops answering on control port udp AND ng
On UDP Ports no message from kamailio where answered and ng port did not react on Ping.

Running calls where not affected.

We switched off the logging, since the heavy load. We will activate logging now and repeat the Test. Maybe we will find the Answer in Logs. (the cpu and disk itself has no load so i guess the logging will not really affect the performance.

Since it does not crash or segfault there was no core dump generated by itself we killed rtpengine with -11 option to generate core dump.

please find here the outcome (hopefully you can see whats going on:
(gdb) thread apply all bt

Thread 7 (Thread 0x7f3d54a96700 (LWP 5652)):
#0  0x00007f3d585eacec in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f3d585e6339 in _L_lock_926 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007f3d585e615b in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#3  0x00000000004116a8 in stream_packet (fsin=0x7f3d54a93400, s=0x7f3d54a93300, sfd=0x8330f0) at call.c:664
#4  stream_fd_readable (fd=<optimized out>, p=0x8330f0, u=<optimized out>) at call.c:851
#5  0x000000000040bc56 in poller_poll (p=p@entry=0x706e20, timeout=timeout@entry=100) at poller.c:354
#6  0x000000000040821d in poller_loop (d=0x706e20) at main.c:548
#7  0x000000000040c53f in thread_detach_func (d=0x70d240) at aux.c:160
#8  0x00007f3d585e3b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007f3d5832e20d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7f3d53293700 (LWP 5656)):
#0  0x00007f3d585eb6bd in sendmsg () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x0000000000411d96 in stream_packet (fsin=<optimized out>, s=0x7f3d53290300, sfd=0x8330f0) at call.c:761
#2  stream_fd_readable (fd=<optimized out>, p=0x8330f0, u=<optimized out>) at call.c:851
#3  0x000000000040bc56 in poller_poll (p=p@entry=0x706e20, timeout=timeout@entry=100) at poller.c:354
#4  0x000000000040821d in poller_loop (d=0x706e20) at main.c:548
#5  0x000000000040c53f in thread_detach_func (d=0x70d270) at aux.c:160
#6  0x00007f3d585e3b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#7  0x00007f3d5832e20d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7f3d55297700 (LWP 5651)):
#0  0x00007f3d585e7abd in pthread_rwlock_wrlock () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x0000000000410d53 in call_destroy (c=c@entry=0x8aeea0) at call.c:2086
#2  0x0000000000412048 in kill_calls_timer (list=0x7c5150, m=m@entry=0x70b000) at call.c:1074
#3  0x0000000000412478 in callmaster_timer (ptr=0x70b000) at call.c:1193
#4  0x000000000040c49a in poller_timers_run (p=0x706e20) at poller.c:282
#5  poller_timers_wait_run (p=p@entry=0x706e20, max=100000, max@entry=100) at poller.c:506
#6  0x000000000040824d in timer_loop (d=0x706e20) at main.c:541
#7  0x000000000040c53f in thread_detach_func (d=0x70d230) at aux.c:160
#8  0x00007f3d585e3b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007f3d5832e20d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7f3d55a98700 (LWP 5650)):
#0  0x00007f3d5828526b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f3d58285313 in sigtimedwait () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00000000004082db in sighandler (x=<optimized out>) at main.c:114
#3  0x000000000040c53f in thread_detach_func (d=0x70d220) at aux.c:160
#4  0x00007f3d585e3b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007f3d5832e20d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f3d54295700 (LWP 5653)):
#0  0x00007f3d585eacec in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f3d585e6339 in _L_lock_926 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007f3d585e615b in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#3  0x00000000004113dc in stream_packet (fsin=0x7f3d54292400, s=0x7f3d54292300, sfd=0x8330f0) at call.c:581
#4  stream_fd_readable (fd=<optimized out>, p=0x8330f0, u=<optimized out>) at call.c:851
#5  0x000000000040bc56 in poller_poll (p=p@entry=0x706e20, timeout=timeout@entry=100) at poller.c:354
#6  0x000000000040821d in poller_loop (d=0x706e20) at main.c:548
#7  0x000000000040c53f in thread_detach_func (d=0x70d250) at aux.c:160
---Type <return> to continue, or q <return> to quit---
#8  0x00007f3d585e3b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007f3d5832e20d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f3d53a94700 (LWP 5655)):
#0  0x00007f3d585eacec in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f3d585e6339 in _L_lock_926 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007f3d585e615b in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#3  0x00000000004113dc in stream_packet (fsin=0x7f3d53a91400, s=0x7f3d53a91300, sfd=0x8330f0) at call.c:581
#4  stream_fd_readable (fd=<optimized out>, p=0x8330f0, u=<optimized out>) at call.c:851
#5  0x000000000040bc56 in poller_poll (p=p@entry=0x706e20, timeout=timeout@entry=100) at poller.c:354
#6  0x000000000040821d in poller_loop (d=0x706e20) at main.c:548
#7  0x000000000040c53f in thread_detach_func (d=0x70d260) at aux.c:160
#8  0x00007f3d585e3b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007f3d5832e20d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f3d5ace6720 (LWP 5649)):
#0  0x00007f3d582fe6dd in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f3d58328424 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000000000408002 in main (argc=1, argv=0x7fff40dd63f8) at main.c:568

SSL role changed on re-INVITE on DTLS

Testing rtpengine with webRTC client (SAVPF) and legacy phone (AVP) I found re-INVITE answer rejected by webRTC when original offer (INVITE) received from legacy (AVP) client and subsequent offer (re-INVITE) received from webRTC (SAVPF) client. It looks that the problem is with a=setup:xxx attribute in an answer from rtpengine, i.e. looking into rtpengine and webRTC (SAVPF) side only:
#1 original offer:

rtpengine offer --------------->
a=setup:actpass

<------------------- webRTC answer
a=setup:active

at this point media is OK, now we send an offer from webRTC for the same media session (hold or adding video)
#2 re-offer from the other side:

<------------------- webRTC re-offer
a=setup:actpass

rtpengine answer --------------->
a=setup:active

webRTC client here (on receiving rtpengine answer) complains that "SSL role" cannot be changed on already established media session

When I tried the same scenario directly between two webRTC clients, everything looks the same with exception that in #2 answering side sends a=setup:passive and media path re-established ok.

I understand we can say that webRTC SHOULD pass a=setup:active in #2 re-offer, but that is what we have with latest webRTC code, so can we do some "stickiness" on established media session, even for actpass re-offer?

ipv4-ipv4 (internal/external) bridging (issue#21 from mediaproxy-ng continuation)

Hi Richard,

I need some clarification on mediaproxy-ng/rtpengine logic specifically around '-i' vs '-I' arguments and meaning of bridging used here.

Looking into the code, it seems to me that if a RTP packet is received from IPv4, it's forwarded from the local IPv4 address (specified using '-i' arg) and if it's received from IPv6, it's forwarded from Iocal IPv6 address (-I arg), regardless of which IP it's received on.

Is the code written in anyway to be intended to take packet received on -i specified address (calling it internal interface) and forward it through -I (external interface) specified address (v4/v6) and vice versa?

My intention is to make the code to be adopted in this bridging between ipv4/v4 or ipv4/v6 internal/external interface bridging, to use it for NAT traversal on an edge server.

One of the earlier projects called 'rtpproxy' used with Kamailio have this feature. I want to adopt that here.

Please let me know whether I'm making myself clear and I'm right/wrong in assessing the current implementation approach. What would be your suggestion in keeping the current functionality intact and add the new functionality, like adding another argument to differentiate between the existing bridging concept and the new, what should I call it, say, nat-bridging.

Thanks,
Dipak

DTLS-SRTP negotiation

Sometimes, maybe the majority of the time, the DTLS-SRTP negotiation can take 5 seconds or even more, and during this time, no audio can be heard on any side.

Is there a way to accelerate the negotiation, or maybe create an event that gets triggered when a SRTP negotiation event happens? This way, we could have a feedback of the audio status and maybe notify the UAs when they are clear to speak, or in case there was an error.

Any ideas how could this be achieved? I can allocate some time to implement it in case this idea is in fact valid.

Thanks!

No RTP/SRTP Sent

Hi All,
I'm trying to integrate Rtpengine into our MS Lync testing estate (so there's a MS Lync SIP client on the SRTP side and our internal media card on the RTP side) and have got to the point where there are RTP/RTCP (from the media card) and SRTP/SRTCP packets (from the MS Lync SIP client) going into the proxy (both IPV4) but no packets being sent by the proxy. Some info:

  1. The sip/sdp messages look fine either side of the rtpproxy, RTP/AVP on the rtp side and RTP/SAVP on the srtp side plus crypto attributes etc.. look ok.
  2. There's no firewall on the kamailio hosting the Rtpengine or the windows 7 prof workstation which is hosting the virtual kamailio.
  3. Wireshark of the RTP and SRTP packets coming into the proxy show healthy looking packets from both the Lync testing client and the media card.
  4. There are no errors seen in the kamailio logs.

Our kamailio script entries:

Loadmodule “rtpproxy-ng.so”
Modparam(“rtpproxy-ng”, “rtpproxy_sock”, “udp:127.0.0.1:2223”)

request_route

For request from RTP to SRTP with sdp body

Rtpproxy_manage(“froc+Sp”)
onreply_route
rtpproxy_answer(“-sp”)

For request from SRTP to RTP with sdp body

Rtpproxy_manage(“froc-sp”)
Onreply_route

Rtpproxy_answer(“froc+Sp”)

Commands we run at startup:

service mysqld start
service kamailio start - - for rtpproxy
modprobe xt_MEDIAPROXY
iptables –I INPUT –p udp –d 10.1.0.127 –j MEDIAPROXY - -id 0
echo ‘del 0’ > /proc/mediaproxy/control
/usr/bin/rtpengine --table=0 - - listen-ng=127.0.0.1:2223 - - tos=184 --pidfile=/var/run/rtpengine.pid - - no-fallback
Service mysqld start

Service kamailio start

Any comments, suggestions etc.. as to why there are no packets being sent by the proxy would be welcome. I suspect it might be something obvious relating to config but if not then some pointers to places in the code I could add extra debugging would be helpful.

Thanks
Ed James

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.