date:20160131

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

2016-01-31 Thread Nabeel

sevpal,

Thanks for the suggestions. I didn't have the domain in the domain table of
the database. However, I have added this and the problem is not solved.
The calls otherwise work without it, so I'm not sure why the domain table
is necessary.

I'm still working on the theory that the TURN server behaves differently
with TCP, UDP and TLS.  It is very strange behaviour, but Linphone
definitely shows this discrepancy with TCP using the Coturn TURN server.

On 31 January 2016 at 17:11, sevpal  wrote:

> It’s just a configuration issue you are having, start by:
>
> 1. In windows, do an “nslookup your.domain.net”
> if the returned IP’s are not what you expect, then correct this. You
> may also want to do a reverse lookup “nslookup xxx.xxx.xxx.xxx” to return
> its domain name.
>
> 2. Configure your Opensips to listen on these IP’s
>
> 3. Add “your.domain.net” in your domain table (these are the domains your
> sips is responsible for, IP’s can go in this table but not recommended if
> you are strictly using domain names in the clients for authentication)
>
> By the way, TCP works with Linphone very well.
>
>
> *From:* Nabeel 
> *Sent:* Sunday, January 31, 2016 9:28 AM
> *To:* OpenSIPS users mailling list 
> *Subject:* Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP
>
> Without using alias=domain.com, TCP still does not work.  My initial
> request for someone to test this using Linphone remains. Please test and
> let me know if you can call using TCP with OpenSIPS listening on an IP
> address.
>
> On 31 January 2016 at 09:28, Nabeel  wrote:
>
>> On further testing, using the IP address instead of the domain name in
>> the URI setting of Linphone works with TCP, so I think this might be to do
>> with SRV/NAPTR records associated with the domain.
>>
>> On 31 January 2016 at 08:29, Nabeel  wrote:
>>
>>> Hello,
>>>
>>> There seems to be a problem with calls over TCP using Linphone, and
>>> since Linphone is a popular open source application, I would like someone
>>> to please verify this problem. Calls work fine with Linphone over UDP, but
>>> after registering with TCP using the same credentials, calls do not connect
>>> at all and lead to a request timeout.  A request timeout does not say much
>>> about the cause, but in this case I suspect there is something wrong with
>>> TCP on the server side. I would like someone to please install Linphone on
>>> your phone and connect to your OpenSIPS server using UDP and TCP.  Please
>>> report here if the calls work over both transports.
>>>
>>
>>
>
>
> --
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] B2B Call-ID GUID generation scheme

2016-01-31 Thread Alex Balashov


Hello,

I am using the "top hiding" B2B scenario and am a bit puzzled as to the 
thinking that led to the current scheme for the generation of GUIDs on 
the B-leg of B2BUA entities.


In b2b_entities/dlg.c:b2b_generate_key(), the use of this format:

   ..

leads to very short Call-IDs like this:

   Call-ID: B2B.27572.17705

This is impractically short, and is certain to lead to collisions in a 
high-volume environment with millions of calls daily. There are many 
database systems etc. that rely on all calls being identifiable by a 
unique GUID. I don't think it conforms to the RFC 3261 prescription that 
GUIDs be good GUIDs.


Unfortunately, it's not possible to simply append additional random data 
to the key string, since the Call-ID has specific meaning that is 
extracted in sequential requests, as per 
b2b_entities/dlg.c:b2b_parse_key(). This function also foresees the 
length of the GUID and the positioning of the delimiters to be rather 
static in nature.


Furthermore, the only way I can see to lengthen the GUID is to increase 
the B2B entity hash size. I have it set to 2^16, but it doesn't seem 
practical or worthwhile to set it to much more than that. Even 
increasing it to millions of buckets will only produce a gain of another 
3-4 [0-9] digits, which isn't the combinatoric explosion I'm looking 
for. :-)


For the moment, I have "solved" this problem by:

1) Setting a static

modparam("b2b_entities", "b2b_key_prefix", "ABCDEFGIJKLMNOP")

of 15 characters in length.

1) Removing the code in b2b_parse_key() that compares the prefix to the 
value of the `b2b_key_prefix` modparam, so that this portion of the 
Call-ID can be any 15-character string.


2) Modifying b2b_generate_key() to generate a random 15-character string 
in place of the `b2b_key_prefix`:


---
static char *ever_so_random(int len)
{
static char buf[20];
int i = 0;
struct timeval tv;

memset(, 0, sizeof(buf));

gettimeofday(, NULL);
srand(tv.tv_usec);

for(i = 0; i < len; i ++) {
srand(rand());

buf[i] = (char) ((int) 'A' + (rand() % 26));
}

return buf;
}

...

str* b2b_generate_key(unsigned int hash_index, unsigned int local_index)
{
...
len = sprintf(buf, "%s.%d.%d", 
ever_so_random(b2b_key_prefix.len), hash_index, local_index);

...
}
---

This is a rather naive and unsophisticated approach to generating random 
data, just the first thing that popped into my head. Together with an 
augmented HASH_SIZE constant of 1 << 23, passed to core_hash(), it 
generates Call-IDs like:


Call-ID: LGHJRYMWFKMRIMP.55196.78746776
Call-ID: GIUSLMQJLSWSJVW.42081.639158452
Call-ID: DNDAINOIOZXCEDB.9209.1278194624

Better than nothing, but not ultimately where happiness lies. :-)

My real questions are:

1) Am I missing any key design decisions that led to the generation of 
such short Call-IDs on the B leg, seemingly in flagrant violation of RFC 
3261's prescription (Section 8.1.1.4 "Call-ID") that ...


   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA.

2) Is there some way to override this that I don't realise, e.g. using a 
minimalistic scenario file for topology hiding?


Many thanks in advance!

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

2016-01-31 Thread Nabeel

I now believe this may be a discrepancy in the way my TURN server (Coturn)
is used over different protocols, as follows:

Using UDP, all calls use Coturn correctly and can establish calls without
problems.

Using TLS, calls within 15 minutes of clients' registration use Coturn
correctly and the calls can connect, but after 15 minutes of registration,
Coturn cannot establish the calls.

Using TCP, Coturn cannot establish the calls at all.

Please let me know if these are known issues with OpenSIPS+TURN server, and
if anything can be done on the OpenSIPS side to fix this.  I have contacted
the Coturn forum regarding this.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

2016-01-31 Thread sevpal

It’s just a configuration issue you are having, start by:

1. In windows, do an “nslookup your.domain.net”
if the returned IP’s are not what you expect, then correct this. You may 
also want to do a reverse lookup “nslookup xxx.xxx.xxx.xxx” to return its 
domain name.

2. Configure your Opensips to listen on these IP’s

3. Add “your.domain.net” in your domain table (these are the domains your sips 
is responsible for, IP’s can go in this table but not recommended if you are 
strictly using domain names in the clients for authentication)

By the way, TCP works with Linphone very well.


From: Nabeel 
Sent: Sunday, January 31, 2016 9:28 AM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

Without using alias=domain.com, TCP still does not work.  My initial request 
for someone to test this using Linphone remains. Please test and let me know if 
you can call using TCP with OpenSIPS listening on an IP address.

On 31 January 2016 at 09:28, Nabeel  wrote:

  On further testing, using the IP address instead of the domain name in the 
URI setting of Linphone works with TCP, so I think this might be to do with 
SRV/NAPTR records associated with the domain.

  On 31 January 2016 at 08:29, Nabeel  wrote:

Hello, 

There seems to be a problem with calls over TCP using Linphone, and since 
Linphone is a popular open source application, I would like someone to please 
verify this problem. Calls work fine with Linphone over UDP, but after 
registering with TCP using the same credentials, calls do not connect at all 
and lead to a request timeout.  A request timeout does not say much about the 
cause, but in this case I suspect there is something wrong with TCP on the 
server side. I would like someone to please install Linphone on your phone and 
connect to your OpenSIPS server using UDP and TCP.  Please report here if the 
calls work over both transports.  





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips 2.1.1 tm-utimer Segmentation Fault

2016-01-31 Thread Hamid Hashmi

What is the reason of the crash ? how it can be reproduced ?
Jan 31 16:17:00 prod-siplb SIPLB[24724]: WARNING:core:utimer_ticker: utimer 
task  already schedualed for 5216416740 ms (now 5216416840 ms), it 
may overlap..
Jan 31 16:17:00 prod-siplb SIPLB[24728]: [udp:keepalive@192.168.26.237:7000]: 
Receive request OPTIONS from local server [192.168.26.237] 
Jan 31 16:17:00 prod-siplb SIPLB[24724]: WARNING:core:utimer_ticker: utimer 
task  already schedualed for 5216416840 ms (now 5216416940 ms), it 
may overlap..
Jan 31 16:17:00 prod-siplb SIPLB[24721]: INFO:core:handle_sigs: child process 
24725 exited by a signal 11
Jan 31 16:17:00 prod-siplb SIPLB[24721]: INFO:core:handle_sigs: core was 
generated
Jan 31 16:17:00 prod-siplb SIPLB[24721]: INFO:core:handle_sigs: terminating due 
to SIGCHLD
Jan 31 16:17:00 prod-siplb SIPLB[24726]: INFO:core:sig_usr: signal 15 received
Jan 31 16:17:00 prod-siplb SIPLB[24722]: INFO:core:sig_usr: signal 15 received
Jan 31 16:17:00 prod-siplb SIPLB[24727]: INFO:core:sig_usr: signal 15 received
Jan 31 16:17:00 prod-siplb SIPLB[24724]: INFO:core:sig_usr: signal 15 received
Jan 31 16:17:00 prod-siplb SIPLB[24723]: INFO:core:sig_usr: signal 15 received
Jan 31 16:17:00 prod-siplb SIPLB[24728]: INFO:core:sig_usr: signal 15 received
Jan 31 16:17:00 prod-siplb SIPLB[24721]: INFO:core:cleanup: cleanup

(gdb) bt full
#0  0x7f19bf834a47 in check_and_split_time_list (uticks=521641670, 
set=) at timer.c:805
tl = 0x7f19b9f57538
end = 0x7f19b9efbc70
ret = 
#1  utimer_routine (uticks=521641670, set=) at 
timer.c:1070
tl = 
tmp_tl = 
id = 
__FUNCTION__ = "utimer_routine"
#2  0x004c4974 in handle_timer_job () at timer.c:557
t = 0x7f19b9efbd38
l = 
__FUNCTION__ = "handle_timer_job"
#3  0x0056c87a in handle_io (si=) at 
net/net_udp.c:265
read = 0
#4  io_wait_loop_epoll (si=) at net/../io_wait_loop.h:190
e = 
ret = 
n = 1
r = 1
#5  udp_rcv_loop (si=) at net/net_udp.c:308
__FUNCTION__ = "udp_rcv_loop"
#6  0x0056d47a in udp_start_processes (chd_rank=, 
startup_done=0x0) at net/net_udp.c:448
si = 0x7f19bfe92f68
load_p = 0x7f19b9f22a90
pid = 
i = 
__FUNCTION__ = "udp_start_processes"
#7  0x0043b91a in main_loop (argc=, argv=) at main.c:722
startup_done = 0x0
chd_rank = 1
#8  main (argc=, argv=) at main.c:1259
cfg_log_stderr = 0
cfg_stream = 
c = 
r = 
tmp = 0x7fff18cfe8d3 ""
tmp_len = 
port = 0
proto = 5801077
options = 0x58feb8 "f:cCm:M:b:l:n:N:rRvdDFETSVhw:t:u:g:P:G:W:o:"
seed = 3755833260
rfd = 
__FUNCTION__ = "main"
(gdb) quit

RegardsHamid R. HashmiSoftware Engineer - VoIPVopium A/S
  ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Interpreting the debug memory dump.

2016-01-31 Thread surya

Hi All,

I don't really understand how to interpret the dump because it's huge and I
really don't believe all those entries are memory leaks in the system. 

I deliberately created some leaks and took the memory dump and compared it
with the dump without leak. Obviously, I didn't compare line by line but I
found that in the memory leak dump the file name of the leaking code was
mentioned while it was not present in the none leaking dump.

*So, I want to confirm that do I see only those files in the dump from which
memory is not freed?*

Appreciate help.

Thanks,
Surya



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Interpreting-the-debug-memory-dump-tp7601138.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Linphone and OpenSIPS over TCP

2016-01-31 Thread Nabeel

Hello,

There seems to be a problem with calls over TCP using Linphone, and since
Linphone is a popular open source application, I would like someone to
please verify this problem. Calls work fine with Linphone over UDP, but
after registering with TCP using the same credentials, calls do not connect
at all and lead to a request timeout.  A request timeout does not say much
about the cause, but in this case I suspect there is something wrong with
TCP on the server side. I would like someone to please install Linphone on
your phone and connect to your OpenSIPS server using UDP and TCP.  Please
report here if the calls work over both transports.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

2016-01-31 Thread Nabeel

Without using alias=domain.com, TCP still does not work.  My initial
request for someone to test this using Linphone remains. Please test and
let me know if you can call using TCP with OpenSIPS listening on an IP
address.

On 31 January 2016 at 09:28, Nabeel  wrote:

> On further testing, using the IP address instead of the domain name in the
> URI setting of Linphone works with TCP, so I think this might be to do with
> SRV/NAPTR records associated with the domain.
>
> On 31 January 2016 at 08:29, Nabeel  wrote:
>
>> Hello,
>>
>> There seems to be a problem with calls over TCP using Linphone, and since
>> Linphone is a popular open source application, I would like someone to
>> please verify this problem. Calls work fine with Linphone over UDP, but
>> after registering with TCP using the same credentials, calls do not connect
>> at all and lead to a request timeout.  A request timeout does not say much
>> about the cause, but in this case I suspect there is something wrong with
>> TCP on the server side. I would like someone to please install Linphone on
>> your phone and connect to your OpenSIPS server using UDP and TCP.  Please
>> report here if the calls work over both transports.
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

[OpenSIPS-Users] B2B Call-ID GUID generation scheme

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

[OpenSIPS-Users] Opensips 2.1.1 tm-utimer Segmentation Fault

[OpenSIPS-Users] Interpreting the debug memory dump.

[OpenSIPS-Users] Linphone and OpenSIPS over TCP

Re: [OpenSIPS-Users] Linphone and OpenSIPS over TCP

8 matches

Site Navigation

Mail list logo

Footer information