creytiv / re Goto Github PK

Does http_request support HTTP keep-alive? How to implement it ?

Thank you.

Hello!

Can you provide basic example of RTP stream capture?

Library looks very promising, but have no documentation) Although code is very well-written, reading sources more and more required to figure out how to do basic steps)

Why dnsc->srvc is null. It complain invalid argument in query

Configuring baresip in tls.
The SIP infrastructure adds some route headers.
If one of this route has a "sips" scheme, the call can't be established (error in sending the ack).
"function not implemented"

Here is a proposed patch:

------------------------------ src/sip/request.c ------------------------------
index aca2935..9e4dd6c 100644
@@ -606,7 +606,7 @@ int sip_request(struct sip_request **reqp, struct sip *sip, bool stateful,
if (!sip || !met || !uri || !route || !mb)
return EINVAL;

• if (pl_strcasecmp(&route->scheme, "sip"))

• if (pl_strcasecmp(&route->scheme, "sip") && pl_strcasecmp(&route->scheme, "sips"))
  return ENOSYS;

When trying to compile the project on an AlpineLinux (musl-lib) system, it fails with

src/net/posix/pif.c:65:16: error: storage size of 'ifrr' isn't known

This can be solved by using --std=gnu99 for the compiler. In my oppinion, this could be added to the Makefile by

CFLAGS  += --std=gnu99

This issue is only valid when using OpenSSL 1.1.0

it appears that a TLS connection is still accessing the TLS context object,
even after the TLS context object has been destroyed. This is because the
the TLS object has a BIO which is using BIO_METHOD to send/receive packets.
The OpenSSL BIO only has a pointer to BIO_METHOD, and is not using reference count.
The BIO_METHOD is owned by the TLS context:

struct tls {
        SSL_CTX *ctx;
        X509 *cert;
        char *pass;  /* password for private key */
#ifdef TLS_BIO_OPAQUE
        BIO_METHOD *method_tcp;
        BIO_METHOD *method_udp;
#endif
};

One way to reproduce the bug, is to run restund on Linux with OpenSSL 1.1.0

1. Start restund with TLS transport enabled
2. Create a TURN allocation to the server, using TLS
3. Press Ctrl-C on restund while the allocation is still active

Running with valgrind we can see that OpenSSL is accessing invalid data:

==6558== Invalid read of size 8
==6558==    at 0x55D662A: BIO_write (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==6558==    by 0x52D895B: ??? (in /usr/lib/x86_64-linux-gnu/libssl.so.1.1)
==6558==    by 0x52D8BF6: ??? (in /usr/lib/x86_64-linux-gnu/libssl.so.1.1)
==6558==    by 0x52E15C0: ??? (in /usr/lib/x86_64-linux-gnu/libssl.so.1.1)
==6558==    by 0x52DFA04: ??? (in /usr/lib/x86_64-linux-gnu/libssl.so.1.1)
==6558==    by 0x52E9CEE: SSL_shutdown (in /usr/lib/x86_64-linux-gnu/libssl.so.1.1)
==6558==    by 0x4E8B884: destructor (tls_tcp.c:44)
==6558==    by 0x4E95E74: mem_deref (mem.c:318)
==6558==    by 0x10C609: conn_destructor (tcp.c:52)
==6558==    by 0x4E95E74: mem_deref (mem.c:318)
==6558==    by 0x4E8D636: list_flush (list.c:51)
==6558==    by 0x10D03E: restund_tcp_close (tcp.c:355)
==6558==  Address 0x621bf90 is 16 bytes inside a block of size 80 free'd
==6558==    at 0x4C2CE1B: free (vg_replace_malloc.c:530)
==6558==    by 0x4E8A46D: destructor (tls.c:58)
==6558==    by 0x4E95E74: mem_deref (mem.c:318)
==6558==    by 0x10CCF7: lstnr_destructor (tcp.c:241)
==6558==    by 0x4E95E74: mem_deref (mem.c:318)
==6558==    by 0x4E8D636: list_flush (list.c:51)
==6558==    by 0x10D032: restund_tcp_close (tcp.c:354)
==6558==    by 0x10BF49: main (main.c:283)
==6558==  Block was alloc'd at
==6558==    at 0x4C2BBEF: malloc (vg_replace_malloc.c:299)
==6558==    by 0x56922C8: CRYPTO_zalloc (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==6558==    by 0x55D7060: BIO_meth_new (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==6558==    by 0x4E8C08E: tls_method_tcp (tls_tcp.c:406)
==6558==    by 0x4E8A753: tls_alloc (tls.c:204)
==6558==    by 0x10CE25: listen_handler (tcp.c:274)
==6558==    by 0x4E9882C: conf_apply (conf.c:285)
==6558==    by 0x10CFFC: restund_tcp_init (tcp.c:339)
==6558==    by 0x10BDF3: main (main.c:235)

OS: Debian Testing
OpenSSL 1.1.0g 2 Nov 2017

NOTE: libre with older OpenSSL versions allows the user to destroy
struct tls and struct tls_conn in any order. Do we still want to keep this
functionality also with OpenSSL 1.1.0 ?

Contact
Please join our subscription-only mailing-list for discussions and updates.

The server http://lists.creytiv.com/mailman/listinfo/re-devel disappeared.

$ ping lists.creytiv.com
ping: lists.creytiv.com: Name or service not known

Hi all,

I'm running baresip on iOS 11.0.2 (on iPhone6) and there seems to be some problems when choosing the default network interface in libre for the SIP-stack.

No specific network interface has been set in baresip config. If both mobile network and wifi are up, then mobile network is chosen over wifi. To make baresip use wifi network, then mobile network has to be disabled in phone settings.

This is different from how it is working on android, where wifi is chosen as the preferred network over mobile network automatically by the baresip net_change monitor.

Is this a bug or 'feature' ? :)

Br,
Per Enstedt - wx3 telecom

Hi, we are using baresip/rem/re combo on Windows, and we are facing the following issue.
If the client left in registered state for some time, the following warning starts to appear:
main: fd_listen: fd=2056 flags=0x01 - Max 2048 fds

Here's the callstack

ourlib.dll!fd_listen(int fd, int flags, void(*)(int, void *) fh, void * arg) Line 584	C
ourlib.dll!udp_thread_attach(udp_sock * us) Line 696	C
ourlib.dll!udp_listen(udp_sock * * usp, const sa * local, void(*)(const sa *, mbuf *, void *) rh, void * arg) Line 376	C
ourlib.dll!udp_range_listen(rtp_sock * rs, const sa * ip, unsigned short min_port, unsigned short max_port) Line 241	C
ourlib.dll!rtp_listen(rtp_sock * * rsp, int proto, const sa * ip, unsigned short min_port, unsigned short max_port, char enable_rtcp, void(*)(const sa *, const rtp_header *, mbuf *, void *) recvh, void(*)(const sa *, rtcp_msg *, void *) rtcph, void * arg) Line 330	C
ourlib.dll!stream_sock_alloc(stream * s, int af) Line 254	C
ourlib.dll!stream_alloc(stream * * sp, const config_avt * cfg, call * call, sdp_session * sdp_sess, const char * name, int label, const mnat * mnat, mnat_sess * mnat_sess, const menc * menc, menc_sess * menc_sess, const char * cname, void(*)(const rtp_header *, mbuf *, void *) rtph, void(*)(rtcp_msg *, void *) rtcph, void * arg) Line 302	C
ourlib.dll!audio_alloc(audio * * ap, const config * cfg, call * call, sdp_session * sdp_sess, int label, const mnat * mnat, mnat_sess * mnat_sess, const menc * menc, menc_sess * menc_sess, unsigned int ptime, const list * aucodecl, void(*)(int, char, void *) eventh, void(*)(int, const char *, void *) errh, void * arg) Line 703	C
ourlib.dll!call_alloc(call * * callp, const config * cfg, list * lst, const char * local_name, const char * local_uri, account * acc, ua * ua, const call_prm * prm, const sip_msg * msg, call * xcall, dnsc * dnsc, void(*)(call *, call_event, const char *, void *) eh, void * arg) Line 593	C
ourlib.dll!ua_call_alloc(call * * callp, ua * ua, vidmode vidmode, const sip_msg * msg, call * xcall, const char * local_uri) Line 447	C
ourlib.dll!handle_options(ua * ua, const sip_msg * msg) Line 473	C
ourlib.dll!request_handler(const sip_msg * msg, void * arg) Line 553	C
ourlib.dll!sip_recv(sip * sip, const sip_msg * msg) Line 266	C
ourlib.dll!udp_recv_handler(const sa * src, mbuf * mb, void * arg) Line 339	C
ourlib.dll!udp_read(udp_sock * us, int fd) Line 219	C
ourlib.dll!udp_read_handler(int flags, void * arg) Line 232	C
ourlib.dll!fd_handler(re * re, int fd, int flags) Line 240	C
ourlib.dll!fd_poll(re * re) Line 843	C
ourlib.dll!re_main(void(*)(int) signalh) Line 979	C
ourlib.dll!ReMainThreadFunc(void * lpThreadParameter) Line 237	C

While investigating the issue, we have discovered the following two things.

First, minor thing, is that this problem happens when handling OPTIONS message, and to handle it it opens a new call, which in case calls audio_alloc() to handle RTP sessions which seem to be completely redundant.

Second, major issue, an actual cause of the problem we are facing is the way libre works with sockets. See

re\src\udp\udp.c, line 319, int udp_listen():

		fd = SOK_CAST socket(r->ai_family, SOCK_DGRAM, IPPROTO_UDP);
		if (fd < 0) {
			err = errno;
			continue;
		}

and following
re\src\main\main.c, line 582, int fd_listen():

	if (fd >= re->maxfds) {
		if (flags) {
			DEBUG_WARNING("fd_listen: fd=%d flags=0x%02x"
				      " - Max %d fds\n",
				      fd, flags, re->maxfds);
		}
		return EMFILE;
	}

	/* Update fh set */
	if (re->fhs) {
		re->fhs[fd].flags = flags;
		re->fhs[fd].fh    = fh;
		re->fhs[fd].arg   = arg;
	}

	re->nfds = max(re->nfds, fd+1);

The problem with this code is that under Windows result of socket() function is not a fd, and is not bound to be between 0 and FD_SETSIZE. See here:

In Winsock applications, a socket descriptor is not a file descriptor

Windows Sockets handles have no restrictions, other than that the value INVALID_SOCKET is not a valid socket. Socket handles may take any value in the range 0 to INVALID_SOCKET–1.

So it seems that using sockets as ints to index some reasonable-sized array would not work under Windows at all, and some other approach should be used, like keeping list of active sockets.

Hi,

I was initially put off by a broken link to Subversion on the libre homepage:
http://www.creytiv.com/re.html

Then I found the Github repo :)

Good to update the homepage to point to Github

nick.

Hi,

We see there is a build failure of re on the non GNU Linux ports provided by Debian, kFreeBSD and GNU Hurd. It would be good if upstream can provide support for building on these platform.

Here is build logs on these platform https://buildd.debian.org/status/package.php?p=libre

You have broken link in README docuemnt
Link http://creytiv.com/pub/redemo-0.4.1.tar.gz no more exists.

Hey, I noticed that FreeBSD 11 spits out a warning when compiling re:

  CC      build-x86_64/tls/openssl/tls.o
src/tls/openssl/tls.c: In function 'tls_srtp_keyinfo':
src/tls/openssl/tls.c:736:2: warning: implicit declaration of function 'SSL_get_selected_srtp_profile' [-Wimplicit-function-declaration]
  sel = SSL_get_selected_srtp_profile(tc->ssl);
  ^
src/tls/openssl/tls.c:736:2: warning: nested extern declaration of 'SSL_get_selected_srtp_profile' [-Wnested-externs]
src/tls/openssl/tls.c:736:6: warning: assignment makes pointer from integer without a cast
  sel = SSL_get_selected_srtp_profile(tc->ssl);
      ^

OpenSSL version: OpenSSL 1.0.2j-freebsd 26 Sep 2016

In my re application, I've just been tracking down an ETIMEDOUT error - which I wrongly assumed was a TCP connection timeout, until I realised it actually represented a SIP transaction timeout (from https://github.com/creytiv/re/blob/master/src/sip/ctrans.c#L174).

I'd like to make this easier to diagnose, including viewing the Call-ID etc. of the message I tried to send, but I'm not sure how:

• some kind of logging callback infrastructure, so I can register an error log handler with re?
• just printing the error to stderr?
• using the DEBUG_WARNING macro?
• implementing re-specific error codes, and an re_strerror, so I can return E_RE_SIPCXNTIMEOUT instead of ETIMEDOUT?

I'm using libre together with libcurl, and I discover a strange issue: I catch segfault if I call libre_close() before curl_cleanup(), and no segfault on reverse order.

Worrying about using libre on iOS and Android -- which new side-effects will be discovered?

// Segfault minimal sample.
// gcc -std=c99 -pedantic -I./re/include re_curl_segfault.c -L./re -l:libre.a -lpthread -lssl -lcrypto -pthread -lcurl -o ./re_curl_segfault

#define HAVE_INTTYPES_H
#include <stdio.h>
#include <curl/curl.h>
#include <re.h>

int main()
{
	printf("init curl\n");
	if (0 != curl_global_init(CURL_GLOBAL_ALL))
		goto out;

	printf("init libre\n");
	if (0 != libre_init())
		goto out;

	printf("cleanup: \n");

	printf("  close libre\n");
	libre_close();

	printf("  close curl\n");
	curl_global_cleanup();
out:
	return 0;
}

The same codes can run on Ubuntu(x86_64) and openwrt(ARM), but it can't run on CentOS6.8(x86_64).

Segmentation fault happen on:

Program received signal SIGSEGV, Segmentation fault.
fd_handler (re=Cannot access memory at address 0xffffffffffffffe8
) at src/main/main.c:242
242	G_WARNING("1 event on fd=%d (flags=0x%02x)...\n", fd, flags);

static void fd_handler(struct re *re, int fd, int flags)
{
        const uint64_t tick = tmr_jiffies();
        uint32_t diff;

        DEBUG_INFO("event on fd=%d (flags=0x%02x)...\n", fd, flags);

        DEBUG_WARNING("0 event on fd=%d (flags=0x%02x)...\n", fd, flags);
        re->fhs[fd].fh(flags, re->fhs[fd].arg);
        DEBUG_WARNING("1 event on fd=%d (flags=0x%02x)...\n", fd, flags);

        diff = (uint32_t)(tmr_jiffies() - tick);

        if (diff > MAX_BLOCKING) {
                DEBUG_WARNING("long async blocking: %u>%u ms (h=%p arg=%p)\n",
                              diff, MAX_BLOCKING,
                              re->fhs[fd].fh, re->fhs[fd].arg);
        }
}

Before Segmentation fault, the call stack is:

Breakpoint 1, http_resp_handler_get_flv_file (err=0, msg=0x674660, arg=0x66c890) at /root/lix/rawrtc-terminal-demo/c/src/rawrtc-terminal.c:314
314	    struct http_arg* h_arg = (struct http_arg*)arg;
(gdb) bt
#0  http_resp_handler_get_flv_file (err=0, msg=0x674660, arg=0x66c890) at /root/lix/rawrtc-terminal-demo/c/src/rawrtc-terminal.c:314
#1  0x000000000040fe7c in req_close (req=0x6782e0, err=0, msg=0x674660) at src/http/client.c:165
#2  0x0000000000410564 in recv_handler (mb=0x676cc0, arg=0x6730b0) at src/http/client.c:373
#3  0x000000000041a4bb in tcp_recv_handler (flags=1, arg=0x673260) at src/tcp/tcp.c:434
#4  0x0000000000423b9e in fd_handler (re=Cannot access memory at address 0xffffffffffffffe8
) at src/main/main.c:241

The codes is:

//TODO not use malloc
        struct http_arg *arg = (struct http_arg*)malloc(sizeof(struct http_arg));             
        arg->flvname = agent->latest_time;                                                    
        arg->agent = agent;
        
        //TODO need check
        http_client_get(agent->flv_http_client, flv_buf, http_resp_handler_get_flv_file, arg);

/*
 * success return 0, or return -1.
 * */
static int http_client_get(struct http_cli * const cli, const char* url, http_resp_h *h_resph, void *arg)
{
        //struct http_cli *cli = agent->conf_http_client;
        struct http_req *req = NULL;
        int err = 0;

        err = http_request(&req, cli, "GET", url, h_resph, NULL, arg, NULL);
        if (err) {
                DEBUG_WARNING("http_request fail, errno:%d, url:%s\n", err, url);
                return -1;
        }

        return 0;
}

static void http_resp_handler_get_flv_file(int err, const struct http_msg *msg, void *arg)
{
    struct http_arg* h_arg = (struct http_arg*)arg;
    struct peer_group* const agent = h_arg->agent;
    int flvname = h_arg->flvname;

        // TODO: http timeout. CONN_TIMEOUT = 30000
        if (err) {
                DEBUG_WARNING("get flv file fail. %d\n", err);
                free(h_arg);
                return;
        }

This is why? And how to debug it?
Thank you.

I want to print log with current time in this way:

uint64_t now = tmr_seconds();
DEBUG_WARNING("time:%llu, statistics  ok\n");

 static uint64_t tmr_seconds(void)
 {
     struct timeval now;
     uint64_t usec;
 
     if (0 != gettimeofday(&now, NULL)) {
         DEBUG_WARNING("jiffies: gettimeofday() failed (%m)\n", errno);
         return 0;
     }
 
     usec  = (uint64_t)now.tv_sec;
 
     return usec;
 }

Are there other more elegant ways?
Thank you

In case a format specifier is not known, re's re_vhprintf function simply ignores it. This can lead to segfaults because the argument provided for that format specifier will then be applied on the following format specifier. That doesn't seem ideal to me. The function already returns an error but maybe it's better to fail the function once it finds an unknown format specifier? What do you think?

In May 2014, Alfred mentioned that you don't want a configuration file to detect which features have been enabled in re at compile time and would rather have the application do runtime checks (see this mail). And I'm mostly fine with that. However, there are quite a couple of issues with that approach when including the public headers of re in an application as I will explain in the following.

HAVE_INTTYPES_H

As an application depending on re, it makes sense to include re_types.h pretty much everywhere instead of inttypes.h because it is a useful abstraction. However, at the moment the application needs to define HAVE_INTTYPES_H itself or it will trigger unintended behaviour/compile errors in most of the cases (e.g. defining all of those types instead of simply including inttypes.h).

Suggested solution: -DHAVE_INTTYPES_H could be added to the Cflags of libre.pc depending on whether inttypes.h has been detected on the system. I'm not sure if we would also have to include -D__ssize_t_defined for Windows but it does fall into the same category.

RELEASE

The RELEASE definition triggers different behaviour when using re_mbuf. The application will most likely use mbuf structures but its build system may or may not define RELEASE.

Suggested solution: Same as for HAVE_INTTYPES_H but expose -DMBUF_DEBUG=1 (if RELEASE was set) in the Cflags.

WIN32-related

There a lot of WIN32-related definition checks in headers. This results in...

• different definitions for MOD_PRE, MOD_EXT and EXPORT_SYM in re_mod.h,
• different includes in re_net.h and re_sa.h, and
• different type definitions in re_types.h.

IIRC, an application building on Windows pretty much has to define WIN32 to get anything working.

Suggested solution: Expose -DWIN32 in the Cflags if set. That might clash with other projects, though.

USE_ZLIB

crc32 would be redefined if USE_ZLIB is not set and zlib is being used.

Suggested solution: Expose -DUSE_ZLIB if set.

HAVE_GAI_STRERROR

While it will work fine for the library itself, gai_strerror will be overridden with a stub function when including re_net.h after having included all the necessary headers for working with gai_strerror.

Suggested solution: Adding -DHAVE_GAI_STRERROR (if set) to Cflags should do.

HAVE_INET6

The NET_ADDRSTRLEN definition depends on HAVE_INET6. It would be incorrect for the application if HAVE_INET6 is not set.

Suggested solution: Expose -DHAVE_INET6 if set.

USE_OPENSSL

A couple of OpenSSL functions and structs will be redefined when including re_sha.h without setting USE_OPENSSL.
In addition, tls_openssl_context is not defined if USE_OPENSSL is not defined.

Suggested solution: Expose -DUSE_OPENSSL if set.

VERSION, ARCH and OS

All of those will be redefined if not set. However, it doesn't really matter much since the sys_* functions exists. As such it doesn't make much sense to leave them in the public header.

Suggested solution: Move them into a private header file.

SOLARIS and HAVE_STDBOOL_H

SOLARIS and HAVE_STDBOOL_H trigger different behaviour in re_types.h.

Suggested solution: Expose them if they are set.

If we go with the suggested solutions, then we are really not far away from a (much more convenient) configuration header. So, it might make sense to reconsider it.

I'm returning to the old issue of adding support for receiving UPDATE requests. I read RFC 3311 and here is my summary on what would need to be done:

• add UPDATE in Allow header of INVITE and 2xx response (in baresip)

• if UPDATE is received and dialog (early or confirmed) has not been
  established yet, or, if dialog has been established but reply has not
  yet been received to in-dialog INVITE, 491 Request Pending response is
  generated

• if UPDATE is received before response is sent to earlier UPDATE or
  INVITE request, 500 response is generated to the UPDATE with Retry-After
  between 0 and 10 sec

• when UPDATE is received and the previous two conditions don't exist:

  • UAS must update session parameters and generate 2xx response or, if
    session parameters are not acceptable, generate 488 response

  • UAS must update remote target based on Contact header of UPDATE

The above does not look too complicated, but I'm not any re expert. Can it happen that processing of received requests from the same peer overlap or are they handled sequentially?

Hi!

I have openssl and zlib enabled. In theory, with this enabled, it should not compile sha and crc32.
The problem is that you seem to be trying to compile these modules when you don't need to.

make[1]: Entering directory `/home//work/build-target/libre-0.5.8'
CC build-arm/md5/md5.o
CC build-arm/crc32/crc32.o
src/crc32/crc32.c:117:1: fatal error: opening dependency file build-arm/crc32/crc32.d: No such file or directory
}
^
compilation terminated.

Edit: Solve.
It was a mistake of mine that I forgot to indicate the compilation options in the install stage.
I'm sorry about the noise.

I use re in openwrt(ARM Architecture， 32bit). The test codes is:

When I run in ubuntu (x86_64), It's Ok.

But when I cross-compiler and run it in openwrt(ARM 32bit), It's wrong.

How to solve it?
Thank you.

While compiling baresip gzrtp module for Android, I got two conflicting definitions (below). I got rid of them with the following re_types.h diff:

*** include/re_types.h 2017-05-09 18:44:45.000000000 +0300
--- /usr/src/baresip-android/re/include/re_types.h 2018-04-29 15:31:56.435082491 +0300

*** 48,62 ****
--- 48,66 ----

#endif /* __int8_t_defined */
#ifndef __ssize_t_defined

• #ifndef ANDROID
  typedef long ssize_t;

• #endif
  #define __ssize_t_defined
  #endif

  #ifndef WIN32

• #ifndef ANDROID
  typedef uint32_t socklen_t;
  #endif
  #endif

• #endif

Would it be OK to make a corresponding pull request or is there a better solution?

In file included from ../re/include/re.h:15:0,
from modules/gzrtp/gzrtp.cpp:8:
../re/include/re_types.h:52:18: error: conflicting declaration 'typedef long int ssize_t'
typedef long ssize_t;
^
In file included from ../re/include/re_types.h:7:0,
from ../re/include/re.h:15,
from modules/gzrtp/gzrtp.cpp:8:
/usr/local/Android/Sdk/ndk-bundle/sysroot/usr/include/sys/types.h:127:26: note: previous declaration as 'typedef __kernel_ssize_t ssize_t'
typedef __kernel_ssize_t ssize_t;
^
In file included from ../re/include/re.h:15:0,
from modules/gzrtp/gzrtp.cpp:8:
../re/include/re_types.h:59:18: error: conflicting declaration 'typedef uint32_t socklen_t'
typedef uint32_t socklen_t;
^
In file included from ../re/include/re_types.h:7:0,
from ../re/include/re.h:15,
from modules/gzrtp/gzrtp.cpp:8:
/usr/local/Android/Sdk/ndk-bundle/sysroot/usr/include/sys/types.h:116:21: note: previous declaration as 'typedef __socklen_t socklen_t'
typedef __socklen_t socklen_t;
^

I build libre with MINGW using next command:

make -C $(libre_src_dir) \
		BUILD=$(libre_build_dir) \
		PREFIX= DESTDIR=$(install_dir) \
		CROSS_COMPILE= \
		all install

All works fine but there are some issues:

• Though all temporary files go to the libre_build_dir, resulted libre.a, libre.dll and libre.pc stay in original directory libre_src_dir which makes it dirty when checking with git status. Is there any way to put them in the libre_build_dir too?
• libre.dll is installed in the $(DESTDIR)$(LIBDIR) instead of $(DESTDIR)/bin which is correct place for it under MINGW. I think it is a bug because all other open source libraries put their dlls in bin directory.

re.mk has a makefile rule called release that will create a tarball
from a Subversion repo.

we should add a similar rule for GIT repo, example:

git_release:
       git archive --format=tar --prefix=$(PROJECT)-$(VERSION)/ HEAD \
               | gzip > ../$(PROJECT)-$(VERSION).tar.gz

either to make the release from HEAD or from a named tag.

Hello, I receive SDP body with

v=0
o=- 185880834 185880834 IN IP4 192.168.0.150
s=Asterisk
c=IN IP4 192.168.0.150
t=0 0
m=audio 16104 RTP/AVP 0 8 3 9 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=video 16024 RTP/AVP 99
a=rtpmap:99 H264/90000
a=sendrecv

Your example sip_ua.c stop with error: "unable to decode SDP offer: Invalid argument".

Could you provide more detail about this problem ...

Pulling commit traviscross/libre@37e7252

When I tried to build libre with 64-bit Mingw script mk/re.mk didn't detect that it is a WIN32 platform and build failed. As I checked mk/re.mk I found that it check output of gcc -dumpmachine. For 64-bit Mingw it gives x86_64-w64-mingw32

So, after I added this value to check in mk/re.mk libre compiles successfuly. Please consider to add support for 64-bit Mingw to the build scripts. Here is diff with my fix:

--- re.mk.orign 2018-04-15 15:56:52.531056000 +0400
+++ re.mk       2018-04-15 15:57:02.312273200 +0400
@@ -205,7 +205,7 @@


 ifneq ($(strip $(filter i386-mingw32 i486-mingw32 i586-mingw32msvc \
-       i686-w64-mingw32 mingw32, \
+       i686-w64-mingw32 x86_64-w64-mingw32 mingw32, \
        $(MACHINE))),)
        OS   := win32
 ifeq ($(MACHINE), mingw32)

Obviously, OpenSSL 1.1.0 support is currently being implemented. But what is the minimum OpenSSL version we should support?

This is vital information for PRs such as #15 and an upcoming PR to set Diffie-Hellman parameters. I need to know which functions I can use.

Hello,

I'm trying to use this library on Windows. Is there any documents to build and use this library on Windows?

I faced FD limit problem and found #61. However, the patch 49834b7 is not merged into master. (And actually, the patch contains a slight compile error.)

I found #55, and baresip/baresip#235 describe the compile environment of re/rem/baresip. #119, and baresip/baresip#464 show some prerequisite libraries can be omitted. So, what is the current prerequisite libraries?

Thank you.

I created a .pem file merging the
-certificate
-key
-ca

The TLS check is every time successful, also then when I use a wrong CA file.

It looks like the reason for this is that openSSL 1.1.0 does not set the verification methode by default.

The link on the website doesn't work anymore: http://www.creytiv.com/doxygen/re-dox/html

How is SIP over DTLS transport supported? Or did I misunderstood the feature set in the README.md

/** SIP Transport */
enum sip_transp {
SIP_TRANSP_NONE = -1,
SIP_TRANSP_UDP = 0,
SIP_TRANSP_TCP,
SIP_TRANSP_TLS,
SIP_TRANSPC,
};

I use mbuf_printf in this way:

  {    
       struct odict* result_dict;
       struct mbuf* mb_ref = NULL;
       int64_t result = 0; 
       mb_ref = mbuf_alloc(1024);
       if (!mb_ref) {
           DEBUG_WARNING("ENOMEM.\n");
       }    

       char *flvname = "512aaaa";
       EOR(odict_alloc(&result_dict, 16));
       EOR(odict_entry_add(result_dict, "name", ODICT_STRING, flvname));

       mbuf_printf(mb_ref, "%H", json_encode_odict, result_dict);

       char buf[1024];
       re_snprintf(buf, sizeof(buf), "%H", json_encode_odict, result_dict);

       DEBUG_WARNING("mbuf:%s\nbuf:%s\n", mbuf_buf(mb_ref), buf);   
   }  

I run it on ubuntu(x86_64), the result is:

buf has the right value, the mb_ref don't have the right value. I have check mbuf_printf example in reTest.
This is why? Thank you.

I know websock_send support send a JSON data like this:
EOR(websock_send(client->ws_connection, WEBSOCK_TEXT, "%H", json_encode_odict, dict));

So I want use http_request send a JSON data in this way:

 {
            (void)re_snprintf(url, sizeof(url),"http://101.69.114.92:%u/report/", 80); 
       
            struct odict* post_dict;
            EOR(odict_alloc(&post_dict, 16));

            char type[16] = "play-interval"; 
            char customid[128] = "google.cn";
     
            EOR(odict_entry_add(post_dict, "0017", ODICT_STRING, type));
            EOR(odict_entry_add(post_dict, "0009", ODICT_STRING, customid));

            //Test POST 
            err = http_request(&req, cli, "POST", url, http_resp_handler, NULL, &t, "%H", json_encode_odict, post_dict);
            if (err) {
                DEBUG_PRINTF("exit\n");
                goto out; 
            }
        }

This produce a wrong tcp packet.

Does I use the wrong method of http_request ?

Thank you.

btw: I can't find example of http_request(POST) in retest, rawrtc and libre,

Release libre 0.5.7

Platform: Debian 8.6
Compiler: mingw32-gcc 4.9.1

src/tls/openssl/tls.c: In function ‘tls_set_selfsigned’:
src/tls/openssl/tls.c:251:13: error: ‘subj’ undeclared (first use in this function)
  X509_NAME *subj = NULL;
             ^
src/tls/openssl/tls.c:251:13: note: each undeclared identifier is reported only once for each function it appears in
src/tls/openssl/tls.c:252:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  EVP_PKEY *key = NULL;
  ^
make[1]: *** [build-i686/tls/openssl/tls.o] Error 1
make: *** [libre.a] Error 2

hi all:

int http_request(struct http_req **reqp, struct http_cli *cli, const char *met,
		 const char *uri, http_resp_h *resph, http_data_h *datah,
		 void *arg, const char *fmt, ...)

question 1
I think *reqp will allocate memory in the http_request, but we don't free *reqp after call http_request, for http_request is async IO. So we should start a timer which free *reqp.
In this way, we can handle two issus:
1.Http request timeout
2.free *reqp

This is right?

question 2
I find call http_request twice, Tcp connection wil build twice,
So how to let http_request support keep-alive?

Thank you.

First of all, thanks for finally migrating to Git 👍

It would be awesome if you could also push the release tags as Git tags so people can get these releases from a Git clone.

Release libre v0.5.0

• test on supported platforms
• update documentation

Testing:

• Android NDK r13 (arm)
• CentOS 7.2 (x86_64) retest@1ae43f24fd602e3a529acae73d85800ba62c9a2f
• Debian 8.6 (i386)
• Fedora 24
• Mingw32 gcc 3.4.5 with OpenSSL 1.1.0c and WINE
• OpenWRT 15.05 Chaos Calmer (mips) with baresip
• OSX 10.12 (x86_64)
• Ubuntu 14.04 (x86_64)

Hey there,
I'm currently working on a custom re-based UA implementation. I'm also trying to wrap my head around the SIP RFC and I noticed that the re library does not seem to support the OPTIONS request, which RFC 3261 declares as a MUST for UAs:

All UAs MUST support the OPTIONS method.

Now, I was wondering whether there is a specific reason for why it hasn't been implemented in re ? (Note that, for my specific use case, I don't need to support the OPTIONS request but want to assure compatibility to the SIP RFC)

First of all, this library is great, I am using it to get familiar with RTP/RTCP protocols. During that, I have run into couple minor issues related to including re_* header files, so I thought it would be worth sharing:

1. The standard types uint32_t, etc, conflicts with stdint.h, which does not seem to be reflected anywhere in the library. Perhaps adding something like HAVE_STDINT_H would help?.

2. Again a bit related, for C++ code the bool, true, false and inline keywords are all redefined, but that does not seem to be a good idea (and some compilers such as Visual Studio 2017 evaluate this as an error).

3. (just a suggestion) The library relies heavily on importing just "re.h" (otherwise there are issues like missing include guards, etc), but since other includes are available as well, you can be sure people will include them. It might be worth considering either moving them out of API, or making them safe to include separately...

Apart from these I was able to use the library and it works well! (Well for now I have only simple RTP requirements, will be using it more thoroughly later).

Hello could you explain how to make high-level architicture for registrar service and handle incoming register?

I want to print call stack, when a SIGSEGV happen.

void handle_signal_handler(int sig) {
 243     DEBUG_INFO("get signal: %d\n", sig);
 244     if (sig == SIGSEGV) {
 245         dump_trace();
 246     }                
 247      
 248     re_cancel();
 249 }   

In main function:
2889 EOR(re_main(handle_signal_handler));

I think handle_signal_handler will be call by signal 2(SIGINT), not signal 11(SIGSEGV).

This is why? Thank you.

How can we build re library for Android?

Following approach described here
https://developer.android.com/ndk/guides/standalone_toolchain.html

we're running such script on mac OS:

#!/bin/bash

# Get re library
BUILDROOT=re
if [ ! -e re ]; then
  wget https://github.com/creytiv/re/archive/v0.5.5.zip
  unzip v0.5.5.zip && mv re-0.5.5 re && rm v0.5.5.zip
fi
cd ${BUILDROOT}

# Mac OS paths for NDK
NDK_ROOT=${HOME}/Library/Android/sdk/ndk-bundle
NDK_TOOLS=${HOME}/Library/Android/sdk/ndk-bundle/build/tools

# Android toolchain config
ANDROID_PLATFORM=android-24
ANDROID_TOOLCHAIN=/tmp/android/toolchain/arm
if [ ! -e ${ANDROID_TOOLCHAIN} ]; then
  ${NDK_TOOLS}/make-standalone-toolchain.sh \
    --verbose \
    --arch=arm \
    --platform=${ANDROID_PLATFORM} \
    --install-dir=${ANDROID_TOOLCHAIN}
fi

export PATH=${ANDROID_TOOLCHAIN}/bin:${PATH}

# export CC=clang
export CC=arm-linux-androideabi-gcc

make RELEASE=1

And get the following errors:

In file included from src/sip/addr.c:7:0:
include/re_types.h:51:18: error: conflicting types for 'ssize_t'
 typedef long     ssize_t;
                  ^
In file included from /private/tmp/android/toolchain/arm/sysroot/usr/include/bits/strcasecmp.h:33:0,
                 from /private/tmp/android/toolchain/arm/sysroot/usr/include/string.h:36,
                 from src/sip/addr.c:6:
/private/tmp/android/toolchain/arm/sysroot/usr/include/sys/types.h:127:26: note: previous declaration of 'ssize_t' was here
 typedef __kernel_ssize_t ssize_t;
                          ^

There are 2 main issues:

• Many structures are forward declared now in openssl (hmac_ctx_st, bio_st...) and libre is trying to create them in the stack and/or access their fields.
• All the threading APIs (CRYPTO_num_locks, CRYPTO_LOCK ....) have been removed because now threading support is implemented internally in openssl.

Latest debian/changelog entry has wrong month syntax. Sept should be changed to Sep. Otherwise building of Debian package complains:

dpkg-buildpackage: warning: debian/changelog(l5): invalid abbreviated month name 'Sept'
LINE: -- Alfred E. Heggestad [email protected] Tue, 5 Sept 2017 12:00:00 +0200
dpkg-buildpackage: warning: debian/changelog(l5): cannot parse non-comformant date '5 Sept 2017 12:00:00 +0200'
LINE: -- Alfred E. Heggestad [email protected] Tue, 5 Sept 2017 12:00:00 +0200

Due to changes affecting privacy in android 8 trying to access the net.dns properties will result in the following:

E/libc: Access denied finding property "net.dns1"
E/libc: Access denied finding property "net.dns2"
E/libc: Access denied finding property "net.dns3"
E/libc: Access denied finding property "net.dns4"

Therefore for android versions >= 8 the following function will no longer work.

Hi,

For embedded systems, mbedtls is easier to integrate. is it possible to consider supporting it in future releases.

regards
Haithem.

during a security audit it has been pointed out that the decoding of
JSON with a very large exponent can take a very long time, blocking the
process for several minutes.

example JSON strings:

{
  "test" : "0E999999999999999999999999"
}