Re: [OpenSIPS-Devel] [opensips] [1.11] Crash on TCP read (#813)

[Saúl Ibarra Corretgé]

Thanks Razvan!

On Fri, Mar 4, 2016 at 3:43 PM, Răzvan Crainea 
wrote:

> Closed #813 .
>
> —
> Reply to this email directly or view it on GitHub
> .
>
> ___
> Devel mailing list
> Devel@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>


-- 
/Saúl
bettercallsaghul.com
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] [1.11] Crash on TCP read (#813)

[Saúl Ibarra Corretgé]

Yep, good old `malloc` :-)

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/813#issuecomment-192299774___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] [1.11] Crash on TCP read (#813)

[Saúl Ibarra Corretgé]

There you go:


(gdb) bt
#0  tcp_read_req (con=con@entry=0xa773e948,
bytes_read=bytes_read@entry=0xbfb3b8cc)
at tcp_read.c:711
#1  0x080e08a2 in handle_io (fm=0x99015c8, idx=idx@entry=-1,
event_type=event_type@entry=1) at tcp_read.c:1036
#2  0x080e271c in io_wait_loop_epoll (repeat=, h=, t=) at io_wait.h:867
#3  tcp_receive_loop (unix_sock=72) at tcp_read.c:1144
#4  0x080dc690 in tcp_init_children (chd_rank=chd_rank@entry=0x81e362c,
startup_done=startup_done@entry=0x0) at tcp_main.c:2378
#5  0x0805db02 in main_loop () at main.c:1011
#6  main (argc=11, argv=0xbfb3bbf4) at main.c:1612
(gdb) print req
$1 = (struct tcp_req *) 0x995eaf8
(gdb) print cur
cur_lock curr_dir current_dlg_pointer  current_req
(gdb) print current_req
$2 = {next = 0x0,
  buf = "\r\n\r\n2.0 200 OK\r\nVia: SIP/2.0/TLS
81.23.228.129:443;received=81.23.228.129;branch=z9hG4bK5a46.32065967.0\r\nVia:
SIP/2.0/UDP 81.23.228.150:5060;branch=z9hG4bK5a46.b782e725.0\r\nRecord-Route:

wrote:

> What allocator are you using? Could you print the req variable in gdb and
> paste the output here?
>
> —
> Reply to this email directly or view it on GitHub
> .
>
> ___
> Devel mailing list
> Devel@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>


-- 
/Saúl
bettercallsaghul.com
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] [1.11] Crash on TCP read (#813)

[Saúl Ibarra Corretgé]

@razvancrainea it crashed here: 
https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L711 My guess is that 
it accesses freed memory, hence the crash. It might work sometimes, but if a 
hardened system memory allocator is used it will.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/813#issuecomment-192265551___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] [1.11] Crash on TCP read (#813)

[Saúl Ibarra Corretgé]

I found a crashed OpenSIPS process with the following backtrace:


(gdb) bt
#0  tcp_read_req (con=con@entry=0xa773e948, 
bytes_read=bytes_read@entry=0xbfb3b8cc) at tcp_read.c:711
#1  0x080e08a2 in handle_io (fm=0x99015c8, idx=idx@entry=-1, 
event_type=event_type@entry=1) at tcp_read.c:1036
#2  0x080e271c in io_wait_loop_epoll (repeat=, h=, t=)
at io_wait.h:867
#3  tcp_receive_loop (unix_sock=72) at tcp_read.c:1144
#4  0x080dc690 in tcp_init_children (chd_rank=chd_rank@entry=0x81e362c, 
startup_done=startup_done@entry=0x0)
at tcp_main.c:2378
#5  0x0805db02 in main_loop () at main.c:1011
#6  main (argc=11, argv=0xbfb3bbf4) at main.c:1612


I inspected the code and found a path which leads to the problem. If the code 
entered [this 
if](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L704) `req` 
points to freed memory, so 
[this](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L711) causes 
the crash.

I think we need to jump to `end_req` right after freeing the request, but I'm 
not that familiar with the code to provide a patch.

Something does look a bit strange to me: if `size` was 0 (which is the case), 
then 
[this](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L678-L695) 
code path was followed, which means `release_tcpconn` was called. But when 
`tcp_read_req` returns (if it does so with an error) [this 
code](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L1036-L1045) 
will call `release_tcpconn` again.

As a side note, `release_tcpconn` shoudl probably set the `fd` attribute on the 
connection to -1 after closing it 
[here](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L451).

Unfortunately I cannot reproduce the issue, it's the first time I've seen it, 
and we've been running 1.11 in production on sip2sip.info for quite a while, 
always with async TCP enabled.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/813___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Proposed fix for erratic nat_traversal keepalives (#751)

[Saúl Ibarra Corretgé]

Hey @bogdan-iancu, thanks for chiming in :-)

> that may simplify your patch a lot - the nat_helper timer routing is 
> registered with "TIMER_FLAG_DELAY_ON_DELAY" - this guarantees that (even 
> executed in various processes) the handler will not be run in parallel (all 
> its executions will be serial). So you do not need locking at all. Also, the 
> counter itself can shm allocated and its pointer can be passed to the timer 
> handler (more elegant versus a global var).

This sounds like a better approach to me, can you adjust to it @aerringer? 
Thanks a lot!

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/751#issuecomment-171261698___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Proposed fix for erratic nat_traversal keepalives (#751)

[Saúl Ibarra Corretgé]

Hi, thanks for the patch! Can you please elaborate / link some documentation on 
why this is needed? According to the [development 
guide](http://www.opensips.org/Documentation/Development-Manual#toc23) 
`register_timer` works on some "global timer process" which doesn't appear to 
be the case anymore.

I see that the problem was introduced in 
https://github.com/OpenSIPS/opensips/commit/caabbe53229bde6c1d939da2e5380e805b94b983.
 If timers are ran on all processes now, the change to nat_traversal is 
incorrect, because we depend on global data, so I'd rather revert back to using 
a dedicated timer process for our purposes, as before.

@bogdan-iancu can you please shed some light here?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/751#issuecomment-170879130___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] OpenSIPS accepts broken Contact header, then fails to start (#729)

[Saúl Ibarra Corretgé]

Tested it, works just fine, thanks @ionutrazvanionita!

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/729#issuecomment-166567951___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] OpenSIPS accepts broken Contact header, then fails to start (#729)

[Saúl Ibarra Corretgé]

Actually, I was wrong. We are using a bit of custom logic to set the 
received_uri AVP manually. So it is set.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/729#issuecomment-166305988___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] OpenSIPS accepts broken Contact header, then fails to start (#729)

[Saúl Ibarra Corretgé]

Nice, thanks! I'll make a new build and test it out.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/729#issuecomment-166312303___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] OpenSIPS accepts broken Contact header, then fails to start (#729)

[Saúl Ibarra Corretgé]

Hi @ionutrazvanionita,

You're right, I was using nat_traversal, so I guess the same applies.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/729#issuecomment-166280193___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] OpenSIPS accepts broken Contact header, then fails to start (#729)

[Saúl Ibarra Corretgé]

Hi Razvan!

Thanks for the tip!

As for the fix, I think OpenSIPS should make sure the data is correct
before putting it on the DB, so that REGISTER should have been rejected.

Now, data might end up bogus on the DB due to bugs, so ignoring the broken
records on startup sounds like a sensible thing to do IMHO.
On Dec 18, 2015 6:09 PM, "Răzvan Crainea"  wrote:

> Hi Saul!
>
> Not sure whether the problem is that opensips accepts the bogus Contact
> header, or it does not start if the contact in the DB is bogus. Probably
> both?
> The first problem can be solved by using the sipmsg_validate() function.
> Not sure if we should explicitly validate the contact before inserting it
> in the database.
> However, the second problem seems more serious, since OpenSIPS does not
> start, no matter where that Contact header ended up in the database.
>
> Will look into this next week.
>
> Best regards,
> Răzvan
>
> —
> Reply to this email directly or view it on GitHub
> .
>


---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/729#issuecomment-165923461___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] OpenSIPS accepts broken Contact header, then fails to start (#729)

[Saúl Ibarra Corretgé]

(Tested on OpenSIPS 1.11 as of commit 95f5f79)

OpenSIPS accepts a registration with a broken Contact header and saves it in 
the location table. Example REGISTER:


REGISTER sip:sip2sip.info SIP/2.0
Via: SIP/2.0/UDP 127.0.1.1:5060;branch=z9hG4bK-1605-1-0
Max-Forwards: 70
From: "sipp" ;tag=1
To: "sipp" 
Call-ID: reg///1-1605@127.0.1.1
CSeq: 7 REGISTER
Contact: 
Expires: 3600
Content-Length: 0
User-Agent: SIPp


After this, if OpenSIPS is restarted, it fails to start with the following log:


DBG:core:parse_uri: bad host in uri (error at char ; in state 4) parsed: 
(XX) / (XX)
ERROR:usrloc:compute_next_hop: failed to parse URI of next hop: '   
   '
ERROR:usrloc:new_ucontact: failed to resolve next hop
ERROR:usrloc:mem_insert_ucontact: failed to create new contact
ERROR:usrloc:preload_udomain: inserting contact failed


---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/729___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] xcap: make the 'doc' column a LONGBLOB on MySQL (#634)

[Saúl Ibarra Corretgé]

A normal-sized XCAP document with external references easily exceedes
the default column size, leading to all sorts of problems.
You can view, comment on, or merge this pull request online at:

  https://github.com/OpenSIPS/opensips/pull/634

-- Commit Summary --

  * xcap: make the 'doc' column a LONGBLOB on MySQL

-- File Changes --

M db/schema/pr_xcap.xml (1)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/634.patch
https://github.com/OpenSIPS/opensips/pull/634.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/634
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] xcap: make the 'doc' column a LONGBLOB on MySQL (#634)

[Saúl Ibarra Corretgé]

@OpenSIPS/contributors please review.

Once it lands, mind if I backport it to 1.11?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/634#issuecomment-140046585___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] xcap: make the 'doc' column a LONGBLOB on MySQL (#634)

[Saúl Ibarra Corretgé]

Thanks, Razvan!

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/634#issuecomment-140103647___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Fix setting LIBDIR (#626)

[Saúl Ibarra Corretgé]

Guys, can you also merge this into the 1.11 branch? Thanks!

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/626#issuecomment-139573746___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] Fix setting LIBDIR (#626)

[Saúl Ibarra Corretgé]

Should fix #624 

(untested)
You can view, comment on, or merge this pull request online at:

  https://github.com/OpenSIPS/opensips/pull/626

-- Commit Summary --

  * build: fix setting HOST_ARCH on Solaris
  * build: fix setting LIBDIR correctly

-- File Changes --

M Makefile.defs (263)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/626.patch
https://github.com/OpenSIPS/opensips/pull/626.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/626
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Fix setting LIBDIR (#626)

[Saúl Ibarra Corretgé]

@etamme tested it and it works!

Gotta go now, so can you merge it @razvancrainea or @bogdan-iancu? Otherwise I 
will when I get back. Thanks.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/626#issuecomment-135828316___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] makefile: detect target architecture using the compiler (#603)

[Saúl Ibarra Corretgé]

Closed #603.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/603#event-386477257___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] makefile: detect target architecture using the compiler (#605)

[Saúl Ibarra Corretgé]

/cc @razvancrainea 

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/605#issuecomment-132588268___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] makefile: detect target architecture using the compiler (#605)

[Saúl Ibarra Corretgé]

Fixes producing a 32bit build in a 64bit system.

Original patch by Andrei Pelinescu-Onciul:
https://github.com/kamailio/kamailio/commit/c46e79709216c4975abc83869fbce9fa696eac74
You can view, comment on, or merge this pull request online at:

  https://github.com/OpenSIPS/opensips/pull/605

-- Commit Summary --

  * makefile: detect target architecture using the compiler

-- File Changes --

M Makefile.defs (92)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/605.patch
https://github.com/OpenSIPS/opensips/pull/605.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/605
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] makefile: detect target architecture using the compiler (#603)

[Saúl Ibarra Corretgé]

Fixes producing a 32bit build in a 64bit system.

Original patch by Andrei Pelinescu-Onciul:
https://github.com/kamailio/kamailio/commit/c46e79709216c4975abc83869fbce9fa696eac74
You can view, comment on, or merge this pull request online at:

  https://github.com/OpenSIPS/opensips/pull/603

-- Commit Summary --

  * makefile: detect target architecture using the compiler

-- File Changes --

M Makefile.defs (92)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/603.patch
https://github.com/OpenSIPS/opensips/pull/603.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/603
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] makefile: detect target architecture using the compiler (#603)

[Saúl Ibarra Corretgé]

/cc @bogdan-iancu 

If you're fine with the change let me know to what branches you want me to 
apply it.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/603#issuecomment-132199170___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] New Transport Interface

[Saúl Ibarra Corretgé]

Hi Razvan!

I understand it’s just the beginning, hence my comments, targeted at 
(hopefully) improving things :-)

 - If TLS is taken out of the core it would be best to rewrite it without 
 looking at the current code. If we want to get OpenSIPS as an official 
 Debian package, the TLS code needs to be a separate module, with a different 
 license (GPL with the OpenSSL exception thing), but in order to relicense it 
 all developers have to agree, doing it from scratch would avoid this.
 I'm not sure how rewriting the whole module will solve this. Even though it's 
 a different code, it will still have the OpenSSL exception so it can't be 
 part of a Debian package. However, this time we will be able to add the 
 OpenSIPS core in the Debian repo.

It would solve the problem. Having the exception if fine, but if TLS is in the 
core, OpenSIPS would need to be relicensed in its entirety, but having it as a 
module, the exception would only apply to that module.

 
 - If TLS is a module now, has there been any thought on supporting 
 implementations other than OpenSSL? gnuTLS and libreSSL come to mind.
 Since the new interface will be very modular, having a different TLS 
 implementation will be very simple. All they have to do is to implement the 
 Transport Interface functions.
 

Awesome!

 - I see that the send / receive API is not designed with scatter / gather 
 I/O in mind. It might be beneficial in the long run to support sending or 
 receiving an array of buffers, and use readv / writev underneath.
 This would be a nice feature, but the current code is not yet ready to 
 support this. But we should keep track of this for further releases.
 

While the current code might not *use* it, I think allowing for it at the API 
level would be nice to have, it basically revolves around using the vectored 
functions if the number of buffers is  1.

 - sockaddr_union is defined by OpenSIPS with no real purpose these days, 
 since we can use sockaddr_storage for allocating space and sockaddr for 
 passing around pointers.
 Currently sockaddr_union is not only used for storage, but is also allows you 
 to access the structure as sockaddr or sockaddr_in without doing any explicit 
 casts.

So? Is casting to struct sockaddr* in a few places necessarily wrong?

 
 - At what level are the TLS settings considered? Network or transport? 
 Either way, all init functions get void, but where will the config be taken 
 from, if it’s different per domain?
 The TLS settings will be considered at the transport level. We could 
 implement the domain logic in the mod_init() function, that is not part of 
 the Transport Interface but of the general Modules Interface.
 

Ok.

 - The transport API has some inconsistencies in what parameters it takes: 
 connect gets a sockaddr, but bind gets host and port.
 Well, this is not the final version of the API, and most likely during 
 development some of those signatures will change. What we have there is a 
 roughly design we think should be used to implement this interface.But 
 indeed, during development we'll pay attention to these inconsitencies and 
 try to avoid them.
 
 - Where do DNS lookups happen? If the transport API only knows about IPs and 
 ports then all functions should take sockaddr structures and the app would 
 do the lookup.
 The DNS lookup is already done on a higher level, by the OpenSIPS Core. At 
 this level we have the IP and ports already resolved.
 

Cool. In that case I suggest the transport API just gets sockaddr parameters 
and the conversion be done elsewhere. consistency++ :-)

 - Any thoughts on using “connected” UDP sockets, so the kernel does the 
 filtering for incoming traffic?
 We haven't considered this and I am not sure how this would should work. 
 Currently OpenSIPS only has a single socket per UDP listening interface. 
 Using connected UDP sockets would require having multiple sockets, each 
 connected to an authorized client. Therefore we'd have to implement a 
 socket management logic in the UDP transport interface to handle this. This 
 will increase the complexity of the UDP communication and most likely 
 decrease it's performance.
 

I didn’t think this all the way through, but the advantage would be that the 
kernel does the filtering. It’s not a big deal anyway, just checking if you 
folks gave the idea any thought.


Keep up the good work!

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] New Transport Interface

[Saúl Ibarra Corretgé]

Hi Razvan (and all!),

On 12 Jan 2015, at 14:52, Răzvan Crainea raz...@opensips.org wrote:

 Hi, All!
 
 You can find here[2] the APIs that are going to be deeveloped for the 
 Transport Interface.
 Please take a look and let us know what you think. Any feedback is welcome!
 
 [1] http://www.opensips.org/Development/TransportInterfaceAPI
 

Sorry for not having participated earlier. Hopefully I can do that more now!

I had a look at the API, and while the layer separation sounds good, I have 
some questions / concerns of different nature. Here is a brain-dump, in no 
particular order:

- If TLS is taken out of the core it would be best to rewrite it without 
looking at the current code. If we want to get OpenSIPS as an official Debian 
package, the TLS code needs to be a separate module, with a different license 
(GPL with the OpenSSL exception thing), but in order to relicense it all 
developers have to agree, doing it from scratch would avoid this.

- If TLS is a module now, has there been any thought on supporting 
implementations other than OpenSSL? gnuTLS and libreSSL come to mind.

- I see that the send / receive API is not designed with scatter / gather I/O 
in mind. It might be beneficial in the long run to support sending or receiving 
an array of buffers, and use readv / writev underneath.

- sockaddr_union is defined by OpenSIPS with no real purpose these days, since 
we can use sockaddr_storage for allocating space and sockaddr for passing 
around pointers.

- At what level are the TLS settings considered? Network or transport? Either 
way, all init functions get void, but where will the config be taken from, if 
it’s different per domain?

- The transport API has some inconsistencies in what parameters it takes: 
connect gets a sockaddr, but bind gets host and port.

- Where do DNS lookups happen? If the transport API only knows about IPs and 
ports then all functions should take sockaddr structures and the app would do 
the lookup. 

- Any thoughts on using “connected” UDP sockets, so the kernel does the 
filtering for incoming traffic?


I hope this helps.


Cheers,

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] fix for RFC5245 15.1 compliant candidate injection (#264)

[Saúl Ibarra Corretgé]

LGTM :+1: 

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/264#issuecomment-68852110___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [OpenSIPS/opensips] 4642e3: Revert Changes to stop keepalives on unregisters

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.11
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 4642e3232d5fc5bb662c75d81caac23f604885a5
  
https://github.com/OpenSIPS/opensips/commit/4642e3232d5fc5bb662c75d81caac23f604885a5
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2014-11-27 (Thu, 27 Nov 2014)

  Changed paths:
M modules/nat_traversal/nat_traversal.c

  Log Message:
  ---
  Revert Changes to stop keepalives on unregisters

This reverts commit 36ad430f0bf50bb20fcdfd1180c9262348e41f79.


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

[OpenSIPS-Devel] [OpenSIPS/opensips] e41c5e: Revert Changes to stop keepalives on unregisters

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.10
  Home:   https://github.com/OpenSIPS/opensips
  Commit: e41c5e37a8a82f0400c3bf3e81b4cb442a60e7d8
  
https://github.com/OpenSIPS/opensips/commit/e41c5e37a8a82f0400c3bf3e81b4cb442a60e7d8
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2014-11-27 (Thu, 27 Nov 2014)

  Changed paths:
M modules/nat_traversal/nat_traversal.c

  Log Message:
  ---
  Revert Changes to stop keepalives on unregisters

This reverts commit 8187a92d48abe24643f8ea2f1b0988857f0ccb1b.


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

Re: [OpenSIPS-Devel] [opensips] Changes to stop keepalives on unregisters (#366)

[Saúl Ibarra Corretgé]

This fix is incorrect and I will revert it. The provided patch solves the 
problem in 2 cases, but fails to do so in others such as when the Contact 
header has a *.

But most importantly, it breaks when a single user agent registers multiple 
accounts from the same IP and port. In this case nat_traversal will create a 
single NAT_Contact structure, and when one of the accounts unregisters we'd 
stop pinging, even if others are still registered. This problem is known, but 
it never seemed worth fixing because it would involve keeping track of the 
registered AoR for NAT_Contact. It can be fixed, but the proposed fix in this 
PR doesn't do so.

Also, I'd appreciate a heads up (by @-ing me or @danpascu) next time one of the 
modules we maintain is modified, this PR got merged in 4 days, we happned to be 
on vacation and this wasn't urgent whatsoever.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/366#issuecomment-64173566___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] TLS: remove support for SSLv2 and SSLv3 (#367)

[Saúl Ibarra Corretgé]

 Since support for the old SSL (both v2 and v3) is completely disabled, should 
 we obsolete the SSLv23 keyword and add a different one, something like TLSany?

Lots of software took that from OpenSSL, even if it doesn't necessarily mean 
SSLv2 or SSLv3 are used. I will add an alias for that config option as you 
suggested, looks much nicer in the eyes :-)

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/367#issuecomment-60198661___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] TLS: remove support for SSLv2 and SSLv3 (#367)

[Saúl Ibarra Corretgé]

@razvancrainea added TLSAny alias for tls_method config option.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/367#issuecomment-60202463___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] TLS: remove support for SSLv2 and SSLv3 (#367)

[Saúl Ibarra Corretgé]

@bogdan-iancu @razvancrainea any comment on this?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/367#issuecomment-60128079___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [opensips] TLS: disable support for SSLv2 and SSLv3 (#367)

[Saúl Ibarra Corretgé]

Time to support crypto built this century only :-)

I know POODLE doesn#39;t affect SIP, but who knows what else is broken in 
SSLv2 / SSLv3 that we don#39;t know about.
You can merge this Pull Request by running:

  git pull https://github.com/saghul/opensips crypto_fixes

Or you can view, comment on it, or merge it online at:

  https://github.com/OpenSIPS/opensips/pull/367

-- Commit Summary --

  * tls: removed code to support OpenSSL lt;= 0.9.7
  * tls: removed SSLv2 and SSLv3 support

-- File Changes --

M cfg.lex (4)
M cfg.y (57)
M modules/identity/identity.c (14)
M tls/README (16)
M tls/tls_config.h (6)
M tls/tls_init.c (43)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/367.patch
https://github.com/OpenSIPS/opensips/pull/367.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/367
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] opensipsctl compatibility (#322)

[Saúl Ibarra Corretgé]

Please stop opening duplicated pull requests.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/322#issuecomment-54958178___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] opensipsctl compatibility (#322)

[Saúl Ibarra Corretgé]

Closed #322.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/322#event-163025696___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] store registration problem (#325)

[Saúl Ibarra Corretgé]

Closed #325.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/325#event-163026144___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] store registration problem (#323)

[Saúl Ibarra Corretgé]

Closed #323.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/323#event-163026056___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] store registration problem (#324)

[Saúl Ibarra Corretgé]

Closed #324.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/324#event-163026111___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] store registration problem (#326)

[Saúl Ibarra Corretgé]

Closed #326.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/326#event-163026219___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] opensipsctl compatibility (#328)

[Saúl Ibarra Corretgé]

Closed #328.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/328#event-163026274___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] opensipsctl compatibility (#330)

[Saúl Ibarra Corretgé]

Closed #330.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/330#event-163026347___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] opensipsctl compatibility (#329)

[Saúl Ibarra Corretgé]

Closed #329.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/329#event-163026301___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] opensipsctl compatibility (#322)

[Saúl Ibarra Corretgé]

You don't need to open the PR multiple times, the commit can be cherry picked.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/322#issuecomment-54960885___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [FYI] OpenSIPS Social networks

[Saúl Ibarra Corretgé]

On 03 Sep 2014, at 11:44, Bogdan-Andrei Iancu bog...@opensips.org wrote:

 Hi,
 
 FYI, we put together a web page with all social networks where OpenSIPS 
 project is present and active, so people know where to find us:
 
http://www.opensips.org/Community/Networking
 

Hi Bogdan,

The Facebook page seems to be a person called “Opensips Server, not an actual 
page people can “like”. That was common practice before Facebook introduced 
“Pages”, but not anymore.


Regards,

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12

[Saúl Ibarra Corretgé]

On 03 Sep 2014, at 11:59, Bogdan-Andrei Iancu bog...@opensips.org wrote:

 On 03.09.2014 12:06, Saúl Ibarra Corretgé wrote:
 On 02 Sep 2014, at 18:26, Răzvan Crainea raz...@opensips.org wrote:
 
 Hi all,
 
 Among the last discussion of the last IRC meeting[1] was related to 
 Asynchronous processing in OpenSIPS script - we want to add a new mechanism 
 that allows you to perform asynchronous operations (such as DB , REST or 
 exec operations) directly from the script. Using this feature will increase 
 the throughput of OpenSIPS, since the SIP processes will no longer be stuck 
 waiting for I/O responses.
 
 When reaching an asynchronous operation, the SIP message processing will be 
 stopped, and resumed in a different script route. In the script, this 
 should be reflected something like this:
 
 route {
...
# other non I/O operations
async(my_resume_route) {
avp_db_query(SELECT setid from subscribers where username = '$fU', 
 $avp(setid));
}
# we never get here.
exit;
 }
 
 route[my_resume_route] {
xlog(The set used by the callee is $avp(setid)\n);
# continue message processing
 }
 
 Only the functions that are used in an async block will be ran 
 asynchronously. If the function does not support async processing, it will 
 block waiting for the response and resume in the route indicated by the 
 async block - so the scripting experience will be the same even if the 
 async OP could not be done.
 I find this quite problematic. How does John Doe know a function supports 
 async or not? Maybe the configuration checker can know this and not let 
 OpenSIPS start if you are doing it wrong? Alternatively, blocking functions 
 could be ran in a thread pool thus giving the illusion of them being async.
 First of all, the function will be documented as supporting Async and the 
 script parser may check it (we will export some extra flags for the function 
 to say it can do async).
 
 Secondly, the script will allow you to use any combination of functions and 
 script macro - I mean the script will allow you to use an async function in a 
 non-async way (and the function will act as sync) or to use a non-async 
 function in an async way (the function will act as async and with a jump to 
 resume route).
 

My concern is with that last part: if a function which doesn’t support async is 
called within an async block it will block but then make the jump thus 
deceiving the user into believing it was async when it isn’t. We need to fail 
loudly and tell users they are doing it wrong, iMHO.


Regards,

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12

[Saúl Ibarra Corretgé]

 
 My concern is with that last part: if a function which doesn’t support async 
 is called within an async block it will block but then make the jump thus 
 deceiving the user into believing it was async when it isn’t. We need to 
 fail loudly and tell users they are doing it wrong, iMHO.
 Of course, we can detect that at script parsing and decide how to handle it:
- ignore and do it blocking
- warning and do it blocking
- error and do not start.
 

I’d say we shouldn’t start :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS Public Meetings

[Saúl Ibarra Corretgé]

On 22 Aug 2014, at 10:16, Bogdan-Andrei Iancu bog...@opensips.org wrote:

 Hi,
 
 I'm really looking forward for this meeting - so far we came up with really 
 great ideas for 1.12, but as usual, the input/feedback from community is 
 really important for us. Recently there were several discussions (on 
 different threads on the mailing lists) where people expressed their need for 
 new features in OpenSIPSSo, here we go for it :).
 
 Please look at the big topic we suggested, come up with your own ideas and 
 let's talk ! See you on Wednesday !!
 

This is a great initiative folks, kudos! I’ll try to make it to the meeting.

Can I get “Asynchronous TLS” added to the list? :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] Supported RFCs

[Saúl Ibarra Corretgé]

On 23 Jul 2014, at 17:02, Conners, James james.conn...@aspect.com wrote:

 RFCs: 3262, 3311, 3515, 3581, 3891, 3966, 4028
 

AFAIK all those are supported.

 -Original Message-
 From: devel-boun...@lists.opensips.org 
 [mailto:devel-boun...@lists.opensips.org] On Behalf Of Saúl Ibarra Corretgé
 Sent: Friday, July 18, 2014 7:59 AM
 To: OpenSIPS devel mailling list
 Subject: Re: [OpenSIPS-Devel] Supported RFCs
 
 Too many to keep a list, I guess :-)
 
 Which one are you particularly interested in?
 
 On 17 Jul 2014, at 16:59, Conners, James james.conn...@aspect.com wrote:
 
 What RFCs are supported by OpenSIPS?
 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
 
 --
 Saúl Ibarra Corretgé
 AG Projects
 
 
 
 This email (including any attachments) is proprietary to Aspect Software, 
 Inc. and may contain information that is confidential. If you have received 
 this message in error, please do not read, copy or forward this message. 
 Please notify the sender immediately, delete it from your system and destroy 
 any copies. You may not further disclose or distribute this email or its 
 attachments.
 
 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] Supported RFCs

[Saúl Ibarra Corretgé]

Too many to keep a list, I guess :-)

Which one are you particularly interested in?

On 17 Jul 2014, at 16:59, Conners, James james.conn...@aspect.com wrote:

 What RFCs are supported by OpenSIPS?
  
 JIM CONNERS
 SENIOR PRINCIPAL SOFTWARE ENGINEER
 +1 (978) 250.7579 WORK
 +1 (978) 244.7405 FAX
 300 APOLLO DRIVE
 CHELMSFORD, MA 01824-3626
 UNITED STATES
 james.conn...@aspect.com
 aspect.com
  
 image001.jpg
  
  
 This email (including any attachments) is proprietary to Aspect Software, 
 Inc. and may contain information that is confidential. If you have received 
 this message in error, please do not read, copy or forward this message. 
 Please notify the sender immediately, delete it from your system and destroy 
 any copies. You may not further disclose or distribute this email or its 
 attachments. ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

--
Saúl Ibarra Corretgé
AG Projects





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

In-dialog requests (re-INVITEs) would also have the CSeq modified if dialog 
pinging is enabled. We need to get the updated CSeq for both requests and 
responses, is this handled?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-47639697___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

@bogdan-iancu what we need is a way to fetch the actual cseq for a given 
request or reply. Regardless of cseq mangling happening or not. Otherwise 
MediaProxy could get confused because it relies on incrementing cseqs.The code 
there was written before dialog pinging was a thing, so it may need adjustments.

I don't know the transaction internals so well, but looks to me like we still 
would not get the right cseq in case of an in-dialog request after the cseq was 
mangled by OpenSIPS.

Since other modules could need the same, it would be nice to have a utility 
function somewhere, which does exactly that: return the cseq for the given SIP 
message, looking in the transaction if necessary.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-47644872___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [OpenSIPS-Users] Fwd: RTPproxy project

[Saúl Ibarra Corretgé]

On May 27, 2014, at 4:29 PM, Bogdan-Andrei Iancu wrote:

 Brett, you put the finger on the wound :)
 
 I looked around to other alternatives (to avoid re-inventing the wheel) - 
 like mediaproxy or rtpengine - and I saw no carrier-grade features in the 
 there  - please correct me if I'm wrong.
 
 I'm looking to see if the problem is correctly identified and if there is a 
 large consent in the community about this need. As we would like to through 
 some resources into this (hopefully other parties too), as ideally we should 
 be going in the right direction :)
 

What carrier grade features are those?

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [opensips] One Way or No Audio/Video Opensips 1.9.1 , Mediaproxy 2.5.2 and iptables 1.4.16.2 (#171)

[Saúl Ibarra Corretgé]

Hi @jalung. Thanks for comment. Do you have any links/docs regarding NOTRACK vs 
CT targets and supported versions?

As for why we need it, we first create those NOTRACK entries in the PREROUTING 
(table raw), then, after the conntrack rule has been created they are removed. 

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/171#issuecomment-37382340___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] GEtting the proper CSeq value from a module

[Saúl Ibarra Corretgé]

Hi all,

I'm trying to find the proper way to fix 
https://github.com/OpenSIPS/opensips/issues/165 since we are close to a 
release. I need to obtain the CSeq value for a request/response, but get_cseq 
is not going to cut it. If dialog ping is used it could be internally mangled, 
so I want the mangled value.

I thought I could get the cseq_n value from the transaction as in 
https://github.com/OpenSIPS/opensips/blob/master/modules/tm/h_table.h#L235-L240 
but unfortunately the docs disagree with the real world. cseq_n contains 
doesn't contain the number but the header itself.

The aforementioned issue raises because the header is something like CSeq:42 
(note the lack of a space). So it looks like I'd need to manually parse the 
CSeq header here?!

So, TLDR, how is a module supposed to get the CSeq for a request/response, even 
in the case OpenSIPS modifies it?


Thanks,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [opensips] xcap_client: Fix two mem corruptions. (#176)

[Saúl Ibarra Corretgé]

LGTM.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/176#issuecomment-37389015___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] GEtting the proper CSeq value from a module

[Saúl Ibarra Corretgé]

Hi Vlad,

On Mar 12, 2014, at 11:47 AM, Vlad Paiu wrote:

 Hello,
 
 Indeed in the case of the in-dialog pinging, the cseq might change and 
 get_cseq is not going to be accurate for such cases.
 
 What we can do is to have the dialog module change the number pointer in the 
 actual cseq parsed structure to point to the lump added by the dialog module 
 in case of pinging ( very similar to what fix_nated_contact is doing when 
 fixing the contact header ).
 

That would be nice.

 Alternatively, if you're using the TM module to get the actual CSEQ header, 
 you can use parse_cseq() from parser/parse_cseq.h to extract the actual CSEQ 
 number.
 

Actually, I'm not sure what I'm doing is correct, if the cseq_n from the 
transaction supposed to be updated already in case dialog ping is enabled?


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] 618546: update ChangeLog file for 1.9.2

[Saúl Ibarra Corretgé]

I think it's time we dump Debian lenny, at least on master :-)

On Mar 12, 2014, at 5:13 PM, Razvan Crainea wrote:

  Branch: refs/heads/1.9
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 6185467474cfb78b8974694313d11f5d2e548bbd
  
 https://github.com/OpenSIPS/opensips/commit/6185467474cfb78b8974694313d11f5d2e548bbd
  Author: Razvan Crainea raz...@opensips.org
  Date:   2014-03-12 (Wed, 12 Mar 2014)
 
  Changed paths:
M ChangeLog
 
  Log Message:
  ---
  update ChangeLog file for 1.9.2
 
 
  Commit: 19c03db7b0f4e07a35b158e9dbc357fab4d6af3d
  
 https://github.com/OpenSIPS/opensips/commit/19c03db7b0f4e07a35b158e9dbc357fab4d6af3d
  Author: Razvan Crainea raz...@opensips.org
  Date:   2014-03-12 (Wed, 12 Mar 2014)
 
  Changed paths:
M Makefile.defs
 
  Log Message:
  ---
  update Makefile for 1.9.2
 
 
  Commit: 8fd8407c5078c2933ab942fa6e89165d88b95a42
  
 https://github.com/OpenSIPS/opensips/commit/8fd8407c5078c2933ab942fa6e89165d88b95a42
  Author: Razvan Crainea raz...@opensips.org
  Date:   2014-03-12 (Wed, 12 Mar 2014)
 
  Changed paths:
M packaging/debian-lenny/changelog
M packaging/debian/changelog
M packaging/fedora/opensips.spec
R packaging/gentoo/opensips-1.9.1.ebuild
A packaging/gentoo/opensips-1.9.2.ebuild
M packaging/netbsd/Makefile
M packaging/openbsd/Makefile
M packaging/rpm/opensips.spec.CentOS
M packaging/rpm/opensips.spec.SuSE
M packaging/solaris/base-pkginfo
M packaging/solaris/berkeley-pkginfo
M packaging/solaris/carrierroute-pkginfo
M packaging/solaris/identity-pkginfo
M packaging/solaris/ldap-pkginfo
M packaging/solaris/mmgeoip-pkginfo
M packaging/solaris/mysql-pkginfo
M packaging/solaris/perl-pkginfo
M packaging/solaris/pgsql-pkginfo
M packaging/solaris/regex-pkginfo
M packaging/solaris/snmp-pkginfo
M packaging/solaris/tls-pkginfo
M packaging/solaris/xmlrpc-pkginfo
 
  Log Message:
  ---
  update specs for 1.9.2
 
 
 Compare: 
 https://github.com/OpenSIPS/opensips/compare/0ae9a468f301...8fd8407c5078___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [opensips] Fix examples, some presence settings have moved (#76)

[Saúl Ibarra Corretgé]

Ah, sorry about that! Thanks Liviu!

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/76#issuecomment-37323061___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Fix examples, some presence settings have moved (#76)

[Saúl Ibarra Corretgé]

I think I did fix the examples, but please do doublecheck :-)

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/76#issuecomment-37233880___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] call_control: Passthrough sip_application (#170)

[Saúl Ibarra Corretgé]

 @@ -228,6 +232,7 @@ struct module_exports exports = {
  str call_token;
  char* prepaid_account;
  int call_limit;
 +str sip_application;

Please move this after call_token.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/170/files#r9901510___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] call_control: Passthrough sip_application (#170)

[Saúl Ibarra Corretgé]

 @@ -177,6 +180,7 @@
  {call_token_avp,  STR_PARAM, (call_token_avp.spec.s)},
  {prepaid_account_flag,STR_PARAM, prepaid_account_str},
  {prepaid_account_flag,INT_PARAM, prepaid_account_flag},
 +{sip_application_avp, STR_PARAM, (sip_application_avp.spec.s)},

Please move this before the flags, so that all avps are grouped together.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/170/files#r9851647___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] call_control: Passthrough sip_application (#170)

[Saúl Ibarra Corretgé]

 @@ -640,6 +662,7 @@ struct module_exports exports = {
 prepaid: %s\r\n
 call_limit: %d\r\n
 call_token: %.*s\r\n
 +   application: %.*s\r\n

sip_application

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/170/files#r9851689___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] call_control: Passthrough sip_application (#170)

[Saúl Ibarra Corretgé]

 @@ -406,6 +411,22 @@ struct module_exports exports = {
  return value.s;
  }
  
 +// Get SIP application type
 +static str
 +get_sip_application(struct sip_msg* msg)
 +{
 +int_str value;
 +
 +if (!search_first_avp(sip_application_avp.type | AVP_VAL_STR,
 +  sip_application_avp.name, value, NULL) ||
 +!value.s.s || value.s.len==0) {
 +
 +value.s.s = audio;

Lets use  as the default value. It's easy enough for anybody to set it in the 
config script.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/170/files#r9851713___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

Ah, I see. The fun fact here is that, that field should contain just the number 
(according to the comments in the code), yet it doesn't. In the initial version 
of the code I advanced the pointer by CSEQ_LEN, which is defined as the length 
of CSeq:  (note the space after the colon).

I think what we need to do here is to find the ':' there and trim the result.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-35073164___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

Hum, something feels wrong here. I did some git archeolgy and looks like I 
modified that code to look the way it does now in order for it to work with 
dialog pings: 
https://github.com/OpenSIPS/opensips/commit/80511207e9acec1bfabed7807a83329a8adebbce

When dialog ping is used OpenSIPS needs to modify the CSeq numbers because it 
injects traffic in between. Are you using dialog ping? Also, can you share a 
SIP trace for the call? (you may mail that to me privately if you want)

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-35021825___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

Here is another patch: https://gist.github.com/saghul/8983424 can you please 
try it out?
 @vladpaiu, IIRC you wrote the dialog ping logic, does what I did there look 
good to you?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-35023680___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

@adrien-martin can you please test if it works after applying the following 
patch? https://gist.github.com/saghul/8952340

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34851588___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

Thanks for confirming, I'll commit the changes later today.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34868870___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

Hum, I'll look into it, thanks for the test!

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34614574___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] CSeq header handling in mediaproxy (#165)

[Saúl Ibarra Corretgé]

I just checked and we don't really parse the packet but use the provided 
functions to extract the value. Does pseudo-variable which extracts the CSeq 
work for you?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34481460___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [OpenSIPS/opensips] 359db7: mediaproxy: always parse To header

[Saúl Ibarra Corretgé]

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 359db7f8713921042d14beffd83b5b07e40536fe
  
https://github.com/OpenSIPS/opensips/commit/359db7f8713921042d14beffd83b5b07e40536fe
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-12-20 (Fri, 20 Dec 2013)

  Changed paths:
M modules/mediaproxy/mediaproxy.c

  Log Message:
  ---
  mediaproxy: always parse To header


  Commit: e4a334eaba6e7f402fd26a9e354428b066fc6835
  
https://github.com/OpenSIPS/opensips/commit/e4a334eaba6e7f402fd26a9e354428b066fc6835
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-12-20 (Fri, 20 Dec 2013)

  Changed paths:
M modules/mediaproxy/mediaproxy.c

  Log Message:
  ---
  mediaproxy: fixed detecting messages without a body


Compare: 
https://github.com/OpenSIPS/opensips/compare/54a22de28833...e4a334eaba6e___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [OpenSIPS/opensips] 3b1761: mediaproxy: always parse To header

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.10
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 3b1761a303f93a0fae7209e0577c8fcdb12bddbe
  
https://github.com/OpenSIPS/opensips/commit/3b1761a303f93a0fae7209e0577c8fcdb12bddbe
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-12-20 (Fri, 20 Dec 2013)

  Changed paths:
M modules/mediaproxy/mediaproxy.c

  Log Message:
  ---
  mediaproxy: always parse To header

(cherry picked from 359db7f8713921042d14beffd83b5b07e40536fe)


  Commit: 15f435e1edc30d6e98915514c7ebb01948393438
  
https://github.com/OpenSIPS/opensips/commit/15f435e1edc30d6e98915514c7ebb01948393438
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-12-20 (Fri, 20 Dec 2013)

  Changed paths:
M modules/mediaproxy/mediaproxy.c

  Log Message:
  ---
  mediaproxy: fixed detecting messages without a body

(cherry picked from e4a334eaba6e7f402fd26a9e354428b066fc6835)


Compare: 
https://github.com/OpenSIPS/opensips/compare/f2d32ec4e5f2...15f435e1edc3___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [OpenSIPS/opensips] c3931c: mediaproxy: always parse To header

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.9
  Home:   https://github.com/OpenSIPS/opensips
  Commit: c3931c5800c61cd31e746f95bd65f11c2fa7625c
  
https://github.com/OpenSIPS/opensips/commit/c3931c5800c61cd31e746f95bd65f11c2fa7625c
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-12-20 (Fri, 20 Dec 2013)

  Changed paths:
M modules/mediaproxy/mediaproxy.c

  Log Message:
  ---
  mediaproxy: always parse To header

(cherry picked from 359db7f8713921042d14beffd83b5b07e40536fe)


  Commit: a2a234e52b960182cdee25befc658dd24083d37f
  
https://github.com/OpenSIPS/opensips/commit/a2a234e52b960182cdee25befc658dd24083d37f
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-12-20 (Fri, 20 Dec 2013)

  Changed paths:
M modules/mediaproxy/mediaproxy.c

  Log Message:
  ---
  mediaproxy: fixed detecting messages without a body

(cherry picked from e4a334eaba6e7f402fd26a9e354428b066fc6835)


Compare: 
https://github.com/OpenSIPS/opensips/compare/9ee282898fd0...a2a234e52b96___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Via branch non RFC 3261 compliant (#145)

[Saúl Ibarra Corretgé]

I have not tested the code, but looks good to me :-)

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/145#issuecomment-30035248___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Via branch non RFC 3261 compliant (#145)

[Saúl Ibarra Corretgé]

FWIW, I think nat_traversal does the same. @ibc shouldn't OverSIP be gentle in 
what it accepts? ;-)

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/145#issuecomment-29925741___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

Re: [OpenSIPS-Devel] [opensips] Feature request #77 fulfilled (#138)

[Saúl Ibarra Corretgé]

 @@ -346,6 +420,11 @@ int verify_callback(int pre_verify_ok, X509_STORE_CTX 
 *ctx) {
   ssl_methods[TLS_USE_SSLv23_cli - 1] = SSLv23_client_method();
   ssl_methods[TLS_USE_SSLv23_srv - 1] = SSLv23_server_method();
   ssl_methods[TLS_USE_SSLv23 - 1] = SSLv23_method();
 + 
 + ssl_methods[TLS_USE_TLSv1_2_cli - 1] = TLSv1_2_client_method();

Should these be ifdefed in case the OpenSSL version is too old?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/138/files#r7923384___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [OpenSIPS/opensips] 9b786a: Fixed residential example when using presence

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.10
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 9b786aac8c18e908516932a98c19e94202d220ef
  
https://github.com/OpenSIPS/opensips/commit/9b786aac8c18e908516932a98c19e94202d220ef
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-11-24 (Sun, 24 Nov 2013)

  Changed paths:
M menuconfig/configs/opensips_residential.m4

  Log Message:
  ---
  Fixed residential example when using presence



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

[OpenSIPS-Devel] [OpenSIPS/opensips] 7d2387: Fixed residential example when using presence

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.9
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 7d2387013ebaf3cfd1f9ac95f19bccd38e481004
  
https://github.com/OpenSIPS/opensips/commit/7d2387013ebaf3cfd1f9ac95f19bccd38e481004
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-11-24 (Sun, 24 Nov 2013)

  Changed paths:
M menuconfig/configs/opensips_residential.m4

  Log Message:
  ---
  Fixed residential example when using presence



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

[OpenSIPS-Devel] [OpenSIPS/opensips] a80248: Load xcap module, presence_xml depends on it

[Saúl Ibarra Corretgé]

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: a802488848e9f28701ede84cac16b762ad97d9c8
  
https://github.com/OpenSIPS/opensips/commit/a802488848e9f28701ede84cac16b762ad97d9c8
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-11-24 (Sun, 24 Nov 2013)

  Changed paths:
M menuconfig/configs/opensips_residential.m4

  Log Message:
  ---
  Load xcap module, presence_xml depends on it



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

[OpenSIPS-Devel] [OpenSIPS/opensips] 8d93a2: Load xcap module, presence_xml depends on it

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.9
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 8d93a219a142269af21e1e7bcb336efd3a0c8251
  
https://github.com/OpenSIPS/opensips/commit/8d93a219a142269af21e1e7bcb336efd3a0c8251
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-11-24 (Sun, 24 Nov 2013)

  Changed paths:
M menuconfig/configs/opensips_residential.m4

  Log Message:
  ---
  Load xcap module, presence_xml depends on it



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

[OpenSIPS-Devel] [OpenSIPS/opensips] 669efa: Load xcap module, presence_xml depends on it

[Saúl Ibarra Corretgé]

  Branch: refs/heads/1.10
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 669efafb150caae9ed757051adff65284c14a8be
  
https://github.com/OpenSIPS/opensips/commit/669efafb150caae9ed757051adff65284c14a8be
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-11-24 (Sun, 24 Nov 2013)

  Changed paths:
M menuconfig/configs/opensips_residential.m4

  Log Message:
  ---
  Load xcap module, presence_xml depends on it



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

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.11.0 major release

[Saúl Ibarra Corretgé]

Hi Bogdan,

Can we have async TLS added to the list?

Nice list for Santa, btw :-P

On Nov 4, 2013, at 6:58 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote:

 Hi all,
 
 I would like to start a discussion about the next OpenSIPS major release
 - and in this discussion anyone is welcomed with options, ideas, critics
 and other. Your feedback is important to drive the project into a
 direction that reflects the user's needs!.
 
 So, I will list here the starting points, for both release planing and
 release content.
 
 
 Content
 ---
 What was done:
http://www.opensips.org/About/Version-1-11-0#toc2
 What is planned:
http://www.opensips.org/About/Version-1-11-0#toc9
 Planned items have priorities (for being addressed); it is a must to
 have all items done for the next release, as we need to fit into a time
 frame. Whatever is not done, will be left for the next release (1.12 ?)
 
 Additional thinks (not listed on web) we are considering are:
- new call queuing module
- new SMPP module
- async operations at script level (doing async db ops, exec, rest
 queries)
- dropping avpops module (and replacing with dbops module)
- simplify scripting/logic by dropping the usage of AVPs (defined as
 module params) in favor of explicit func. params
- better handling of UAC transactions (being able to set failure
 routes for them, to fire new requests from script)
- Quality routing in Dynamic Routing
 Also we target so work in the RTPProxy area (still under heavy planing)
 like restart persistence, replication and statistics .
 
 
 Planing
 ---
 Release candidate:
second half of January 2014, depending on the progress with the
 items to be done.
 Testing phase:
1 month allocated (it may be extended if critical problems show up)
 Stable release:
second half of February (after the testing phase is done).
 
 
 Once again, your feedback on these matters is important to us.
 
 
 Best regards,
 
 -- 
 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developer
 http://www.opensips-solutions.com
 
 
 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] eyeBeam NAT ping packets

[Saúl Ibarra Corretgé]

On Oct 16, 2013, at 12:22 PM, Ovidiu Sas o...@voipembedded.com wrote:

 eyeBeam (release 1105z stamp 59030) is sending small packets to keep
 the NAP pinhole open.
 Those packets are short (4 bytes) with the following content: 0d0a0d0a.
 In the logs, we have:
 INFO:core:parse_first_line: empty  or bad first line
 INFO:core:parse_first_line: bad message
 ERROR:core:parse_msg: message=
 ERROR:core:receive_msg: parse_msg failed
 
 We should add some parameters to the config that will allow to
 silently drop these kind of packets.
 We should be able to configure several patterns with length and hex content.
 Comments?
 

That looks like the double CRLF technique used in SIP outbound 
(http://tools.ietf.org/html/rfc5626#section-3.5.1), so I guess the right thing 
to do here would be to reply with CRLF.


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] eyeBeam NAT ping packets

[Saúl Ibarra Corretgé]

On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote:

 I forgot to mention in my previous e-mail that those ping packets are
 over UDP, which seems like a bug in eyeBeam.
 Anyway, the end result is that opensips logs are polluted.
 Over TCP, it seems that those packets are properly handled by opensips.
 It's UDP that is having issues.
 

Oh. I guess OpenSIPS should reply with CRLF like if it was TCP. Be gentle in 
what you accept… :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

[OpenSIPS-Devel] [OpenSIPS/opensips] 6e3b16: Fixed crash if send_subscribe fails early

[Saúl Ibarra Corretgé]

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 6e3b16ec6d3fe59b5a1b415b548394be401e69af
  
https://github.com/OpenSIPS/opensips/commit/6e3b16ec6d3fe59b5a1b415b548394be401e69af
  Author: Saúl Ibarra Corretgé sag...@gmail.com
  Date:   2013-08-07 (Wed, 07 Aug 2013)

  Changed paths:
M modules/pua/send_subscribe.c

  Log Message:
  ---
  Fixed crash if send_subscribe fails early

In that case presentity is still NULL, check for it



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

Re: [OpenSIPS-Devel] OpenSIPS Tracker Migration on GitHub

[Saúl Ibarra Corretgé]

On Jun 4, 2013, at 3:18 PM, Răzvan Crainea raz...@opensips.org wrote:

 Hello all!
 
 After migrating all the OpenSIPS repositories from SourceForge to GitHub[1], 
 the next step is to proceed with the tracker migration. We wrote down two 
 options here:
 
 1. Move all tickets (patches, feature requests, bugs) to the GitHub tracker. 
 There are several problems with this approach: first is that we won't be able 
 to preserve the submitter information, therefore it will no longer be updated 
 about further updates (comments, fixes, etc). Moreover this has to be done 
 manually, so it requires a lot of time and effort.
 
 2. Keep all the tickets already opened on SourceForge, but open new tickets 
 on GitHub. In this case you will no longer be able to open tickets (this will 
 be blocked from SourceForge), but only to update the new ones (comment, 
 close, etc). All new tickets will have to be opened on the GitHub tracker.
 
 We prefer the second option because it overcomes all the issues of the first 
 one. The downside is that for a certain period of time we will have to follow 
 two different tracks (both SourceForge and GitHub). However, we believe that 
 this is an acceptable compromise.
 

I think it's a good thing to do, this will probably also help in removing old 
tickets that have been lingering around for too long ;-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS.org web site REFURBISH - FIRST PHASE - Completed

[Saúl Ibarra Corretgé]

Hi Alex!

On May 14, 2013, at 2:11 PM, Alex Ionescu wrote:

 Hi all,
 
 We are happy to announce that we have re-organized the web site 
 (www.opensips.org) as grouping, menus etc.
 This is just the first step of a more complex process of refurbishing. We 
 would like to ask you to report any broken links or other issues that you may 
 found.
 Also, your suggestions and opinions are very much welcome.
 

Good work, the new layout looks much nicer! A small nit: the GO button is 
taller than the textbox next to it.

As for the content, the news seem to be repeated: they are displayed as 
headlines at the top of the page and also on the bar to the right. I'd leave 
only the bar on the right, so the first thing newcomers see on the website is 
What OpenSIPS is.

My 2 cents :-)

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] 1.9 Major Release becomes stable GA today!

[Saúl Ibarra Corretgé]

On Feb 27, 2013, at 7:13 PM, Bogdan-Andrei Iancu wrote:

 After one month of successful beta testing, the 1.9.0 major released turned 
 into a fully stable GA releasesuitable for production usage.
 
 Feel free to download and torture it - it will proudly do the job for you :) !
 
 Once again, many thanks to all people who got involved in the testing, 
 reporting and fixing during the beta stage - it was a great job:

 http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.9/CREDITS
 

This is fantastic! Kudos to the team!

Time to make some new builds :-)


Cheers,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] migration to GIT

[Saúl Ibarra Corretgé]

 
 When comes to SF versus GITHUB - the main problem from my perspective is that 
 SF overs a unified (one account) for tracker, forums, downloads, code 
 repo.If we move code repo to GITHUB, we will force the developer to use 2 
 accounts (on SF for tracker, forum , etc, and one on GITHUB for GIT only)..
 

I guess my original suggestion was not clear then :-) I was suggesting to 
completely move from SF. Just add a pointer to GH.

 For manageability reasons I would prefer to have a place hosting everything.
 

Agreed.

 What options I see:
 
 1) move everything (tracker + GIT and the rest ?) on GITHUB
 

What would the rest be?

 2) keep SF as primary GIT repo and GITHUB can be a secondary. Developers can 
 use the SF accounts for everything and use GITHUB as an interface to the 
 community (changes, pull requests, etc)..
 

The problem I see here is that there would be a split so it could potentially 
be confusing. When a user sends a pull request, and issue is automatically 
created, so there would be two places for issues :-S

Having GitHub not as the primary repo is not so nice because pull requests 
can't be disabled, so people could think that that is the place to contribute 
code :-S

So, I think the two choices become:

- Move everything to GH and have a read-only mirror somewhere (SF, BitBucket, 
self hosted, ...)
- Stick to SF

Personally I'd go for GitHub. In case there is anything I can do to help, 
whatever the choice is, don't hesitate to ask :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] migration to GIT

[Saúl Ibarra Corretgé]

Hi Bogdan,

On Feb 18, 2013, at 5:05 PM, Bogdan-Andrei Iancu wrote:

 Hi all,
 
 I would like to get some suggestions and help on the matter of migrating the 
 code repository from SVN to GIT - the fact that such migration will bring 
 value is for sure :)
 

I'm glad to see this happening. Count me in for helping as much as I can.

 What things need to be sorted out when moving to GIT:
 

First question: would it be a self-hosted Git repository or the GitHub service?

 
 1) for backward compatibility, I would suggest having a Read-Only SVN, so 
 people will be able to update their current SVN checkouts.
 Does any of you have experience in mirroring (GIT to SVN only) data ?
 

If GitHub is chosen it already provides this, so there is nothing to be done: 
https://github.com/blog/1178-collaborating-on-github-with-subversion

 
 2) about the hooks in GIT - we have now the scripts for sending email on each 
 SVN commits - some help in this matter will be highly appreciated.
 

I don't know myself, but shouldn't be too hard to do.

 
 3) we are heavily using the SVN keywords (%id%, etc) - is there a way to keep 
 something similar in GIT ?
 

Ditto. Also, we should keep the svn authors mapped to git authors where 
possible.

 
 I will appreciate any help from any GIT expert around here, just to be sure 
 we get the things in the right way from the beginning :).
 

Not a git super expert, but I have maintained a unofficial OpenSIPS repo for a 
while: https://github.com/saghul/OpenSIPS

Since I'm here, let me elaborate on why I think moving to GitHub is a good idea:

- Pull requests.

That's it. Pull requests are the perfect way to collaborate with the project. 
Only people who actively contribute need commit rights, the rest can send a 
pull request with their changes just fine. Inline commenting is awesome, it's a 
very good way to iterate on a bugfix without sending diffs left and right, 
making code reviews very simple.

GitHub also has an issue tracker, so existing issues can be migrated there. 
This would also help remove all sorts of old issues that have piled up over 
time ;-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] migration to GIT

[Saúl Ibarra Corretgé]

On Feb 18, 2013, at 6:14 PM, Peter Lemenkov wrote:

 2013/2/18 Saúl Ibarra Corretgé s...@ag-projects.com:
 Also I'd like to propose a switch to a new issue tracker at SF.net.
 Just compare that one we have to use now with the newest one:
 
 * http://sourceforge.net/p/sipp/bugs/
 * http://sourceforge.net/p/curl/bugs/
 
 
 Does the new tracker have anything like the pull requests mechanism?
 
 No, it doesn't. But it's still much better than the current one.
 

Right. Personally, the main reason for going with GitHub and having the issue 
tracker there is how simple it is for people to contribute thanks to the 
powerful pull-requests feature. Not to mention that it encourages code reviews, 
which should in turn increase code quality.

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Drafting OpenSIPS 1.10.0 TODO list

[Saúl Ibarra Corretgé]

Hi Bogdan and team,

On Feb 9, 2013, at 7:40 PM, Bogdan-Andrei Iancu wrote:

 Hi all,
 
 According the the release policy 
 (http://www.opensips.org/Development/Development), I would like to call for a 
 brainstorming, ideas, discussion, etc regarding what should be the roadmap 
 for OpenSIPS 1.10 - more or less, what new goodies should be in 1.10 release 
 (next major release).
 
 The page is already ready (http://www.opensips.org/Main/Ver1100) and 
 pre-populated with the pending items from 1.9 release plus some items from my 
 side .
 
 
 I would like to stat the discussion here, on the mailing list first, to get 
 from all community ideas on what should be done in 1.10 - things to improve, 
 supporting new RFC/drafts, new functionalitites, etc.
 
 So, please do not be shy and make your points here ;).
 
 Also we plan a second round of discussion / selection via an IRC meeting 
 (probably in 2 weeks or so).
 

You asked for it :-)

Here are 3 big items I think we should have in OpenSIPS:

1. Non-blocking TCP operations (this is already on the list)
2. Outbound support (RFC5626) - supporting this may affect the design of 
point 1.
3. WebSocket transport

As for bug fixes, there are a few that come to mind:

1. Proper routing of in-dialog messages when GRUU is used. (the dialog should 
remember the path and loose_route should route the message to the right place 
even if an AoR is found in the contact, which happens when GRUU is used. This 
is a problem if a user re-registers while on a call and she chooses a different 
inbound proxy, as the in-dialog requests would now follow a different path).
2. PUA module should refresh outgoing subscriptions until told otherwise
3. presence_xml should validate incoming PIDF documents (validate them against 
the schema, that is). Right now it doesn't, and if a client sends a broken 
document then the aggregated PIDF document will also be broken. Those broken 
docs should not be stored.

I can elaborate on any of the points in case there are any doubts :-)


Thanks for letting us fill-up your TODO list ;-)

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Drafting OpenSIPS 1.10.0 TODO list

[Saúl Ibarra Corretgé]

On Feb 11, 2013, at 12:38 PM, Saúl Ibarra Corretgé wrote:

 Hi Bogdan and team,
 
 On Feb 9, 2013, at 7:40 PM, Bogdan-Andrei Iancu wrote:
 
 Hi all,
 
 According the the release policy 
 (http://www.opensips.org/Development/Development), I would like to call for 
 a brainstorming, ideas, discussion, etc regarding what should be the roadmap 
 for OpenSIPS 1.10 - more or less, what new goodies should be in 1.10 release 
 (next major release).
 
 The page is already ready (http://www.opensips.org/Main/Ver1100) and 
 pre-populated with the pending items from 1.9 release plus some items from 
 my side .
 
 
 I would like to stat the discussion here, on the mailing list first, to get 
 from all community ideas on what should be done in 1.10 - things to improve, 
 supporting new RFC/drafts, new functionalitites, etc.
 
 So, please do not be shy and make your points here ;).
 
 Also we plan a second round of discussion / selection via an IRC meeting 
 (probably in 2 weeks or so).
 
 
 You asked for it :-)
 
 Here are 3 big items I think we should have in OpenSIPS:
 
 1. Non-blocking TCP operations (this is already on the list)
 2. Outbound support (RFC5626) - supporting this may affect the design of 
 point 1.
 3. WebSocket transport
 
 As for bug fixes, there are a few that come to mind:
 
 1. Proper routing of in-dialog messages when GRUU is used. (the dialog should 
 remember the path and loose_route should route the message to the right place 
 even if an AoR is found in the contact, which happens when GRUU is used. This 
 is a problem if a user re-registers while on a call and she chooses a 
 different inbound proxy, as the in-dialog requests would now follow a 
 different path).
 2. PUA module should refresh outgoing subscriptions until told otherwise
 3. presence_xml should validate incoming PIDF documents (validate them 
 against the schema, that is). Right now it doesn't, and if a client sends a 
 broken document then the aggregated PIDF document will also be broken. Those 
 broken docs should not be stored.
 
 I can elaborate on any of the points in case there are any doubts :-)
 

Oh, since I'm here, let me add one more thing:

- Get rid of the lumps or add a way to apply all pending lumps to a message 
manually. This would fix a number of issues that can now happen, like using 
engage_mediaproxy and removing the SDP of a 183 response.


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] SF.net SVN: opensips:[9700] trunk/modules/siptrace/siptrace.c

[Saúl Ibarra Corretgé]

Does this fix the bug with loosing a couple of characters of the source or 
destination IP addresses in the DB?

On Jan 29, 2013, at 5:28 PM, Bogdan-Andrei Iancu wrote:

 Revision: 9700
  http://opensips.svn.sourceforge.net/opensips/?rev=9700view=rev
 Author:   bogdan_iancu
 Date: 2013-01-29 16:28:44 + (Tue, 29 Jan 2013)
 Log Message:
 ---
 - fixed ugly bug in computing the fromIP and toIP (because of some mixture of 
 STRING and STR type at db level).
  Thanks to Vlad Paiu for assisting with the debugging ;)
  Closes bug #3576351
 
 Modified Paths:
 --
trunk/modules/siptrace/siptrace.c
 
 This was sent by the SourceForge.net collaborative development platform, the 
 world's largest Open Source development site.
 
 
 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] SF.net SVN: opensips:[9700] trunk/modules/siptrace/siptrace.c

[Saúl Ibarra Corretgé]

Awesome, thanks!

On Jan 29, 2013, at 7:34 PM, Bogdan-Andrei Iancu wrote:

 yes, indeed - loosing or having extra garbage :)
 
 Regards,
 
 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developer
 http://www.opensips-solutions.com
 
 
 On 01/29/2013 07:33 PM, Saúl Ibarra Corretgé wrote:
 Does this fix the bug with loosing a couple of characters of the source or 
 destination IP addresses in the DB?
 
 On Jan 29, 2013, at 5:28 PM, Bogdan-Andrei Iancu wrote:
 
 Revision: 9700
  http://opensips.svn.sourceforge.net/opensips/?rev=9700view=rev
 Author:   bogdan_iancu
 Date: 2013-01-29 16:28:44 + (Tue, 29 Jan 2013)
 Log Message:
 ---
 - fixed ugly bug in computing the fromIP and toIP (because of some mixture 
 of STRING and STR type at db level).
  Thanks to Vlad Paiu for assisting with the debugging ;)
  Closes bug #3576351
 
 Modified Paths:
 --
trunk/modules/siptrace/siptrace.c
 
 This was sent by the SourceForge.net collaborative development platform, 
 the world's largest Open Source development site.
 
 
 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
 --
 Saúl Ibarra Corretgé
 AG Projects
 
 
 
 
 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
 

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] [RELEASE] OpenSIPS 1.9.0 - a new major release is out

[Saúl Ibarra Corretgé]

On Jan 29, 2013, at 8:11 PM, Bogdan-Andrei Iancu wrote:

 Hi all,
 
 One more major release is out - OpenSIPS 1.9.0 Release Candidate (beta)
 
 *OpenSIPS 1.9.0* comes with several major improvements (scripting, dialog 
 support, TCP, Web Sockets, timers), but also with new functionalities like 
 CacheDB Interface - CouchBase, MongoDB, Cache2SQL DNS caching, nice 
 provisioning tool like PI_HTTP module or great helper on integration, the 
 Event_Route module (combined with a rich set of new events from core and 
 modules).
 
 One of the important goals of this release were scalability (geo and load), 
 integration capabilities and controllability (debugging, tracing, monitoring).
 
 A complete compilation with all the additions and improvements for *OpenSIPS 
 1.9.0 *release is available under:
 http://www.opensips.org/Main/Ver190
 
 A comprehensive migration document is available also:
 http://www.opensips.org/Resources/DocsMigration180to190
 
 Many thanks to all the people who got involved in this release (and in the 
 overall OpenSIPS project) and contributed with code, with testing and 
 debugging, with patches or reports, with support on the lists, help with 
 packaging and documentation. Here is the a fast compiled list:

 http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.9/CREDITS?revision=9708view=markup
 If someone was missed, apologies in advance and let me know ASAP to fix it ;)
 
 I want to thanks you all for out great job and not in my behalf, but in the 
 behalf of people who will find this piece of software a useful tool.
 
 The full Changelog is available  here:
 http://opensips.org/pub/opensips/1.9.0/src/ChangeLog
 
 
 To get the *OpenSIPS 1.9.0* version, see :
 
* website page: http://www.opensips.org/Resources/Downloads
 
* SF project: 
 https://sourceforge.net/projects/opensips/files/OpenSIPS/1.9.0/
 
 
 Note that for the moment only the source tarballs are available. Also DEBs 
 for Debian ans Ubuntu should be ready soon on the official repository.
 

Congrats to the team! See (some of) you in Brussels!

Also, FWIW, I've been running OpenSIPS straight from trunk for a while now 
without major problems, everyone go test!


Cheers,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] Improved socket error messages

[Saúl Ibarra Corretgé]

Hi,

On Jan 27, 2013, at 8:17 PM, Michael Schloh von Bennewitz wrote:

 
 Hello developers,
 
 While trying to debug a difficult to find problem (where ntop,
 tcpdump, and snoop were no help) I finally figured out where
 OpenSIPS was trying to send misdirected messages by hacking
 the sources. It might be useful to always accompany log text
 with network stack information. So instead of:
 
  Jan 02 18:18:02 hostname error opensips[1234]: 
 ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (146) Connection 
 refused
 
 ...we would see:
 
  Jan 02 18:18:02 hostname error opensips[1234]: 
 ERROR:core:tcp_blocking_connect: addr (1.2.3.4) port (98765), failed to 
 retrieve SO_ERROR (146) Connection refused
 
 ...which of course is much more useful.
 
 To integrate the improvement above, I hacked tcp_main.c like this:
 
  $ sed -e 's;\(LM_ERR(\)\(failed to retrieve SO_ERROR (%d) %s\\n,\);\1addr 
 (%s) port (%d), \2 inet_ntoa(((struct sockaddr_in *)servaddr)-sin_addr), 
 ntohs(((struct sockaddr_in *)servaddr)-sin_port),;' tcp_main.c
 
 ...or if you prefer here's a unified diff that does the same thing:
 
 diff -Nau tcp_main.c.orig tcp_main.c
 --- tcp_main.c.orig   2012-10-17 00:09:05.0 +0200
 +++ tcp_main.c2013-01-27 16:44:47.803235857 +0100
 @@ -340,7 +340,7 @@
   getsockopt(fd, SOL_SOCKET, SO_ERROR, err, err_len);
   if ((err==0)  (poll_err==0)) goto end;
   if (err!=EINPROGRESS  err!=EALREADY){
 - LM_ERR(failed to retrieve SO_ERROR (%d) %s\n, 
 err,
 + LM_ERR(addr (%s) port (%d), failed to retrieve 
 SO_ERROR (%d) %s\n, inet_ntoa(((struct sockaddr_in *)servaddr)-sin_addr), 
 ntohs(((struct sockaddr_in *)servaddr)-sin_port), err,
   strerror(err));
   goto error;
   }
 
 This hack applies cleanly to OpenSIPS 1.7.2 and 1.8.2 although I've
 tested only on 1.7.2 (because of the database access bugs in 1.8.*.)
 
 Unfortunately there are other socket related operations which
 write unhelpful log text, so this is not a complete solution.
 

Improved logging messages are of course great :-) I have a few unfinished 
patches in this regard as well, so if you send over partial improvements I'll 
incorporate them. However, the patch you sent is not correct because it doesn't 
deal with IPv6 addresses, you need to check the sa_family field of the sockaddr 
struct before casting it to sockaddr_in or sockaddr_in6.


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] Improved socket error messages

[Saúl Ibarra Corretgé]

On Jan 28, 2013, at 12:10 PM, Bogdan-Andrei Iancu wrote:

 Hi,
 
 Saul, should I fix and upload Michael's patch (to be part of 1.9) or you want 
 to provide a larger patch (to covert this too, still for 1.9) ?
 

You may fix and upload that one, since I won't have time to do it this week. It 
would be nice to have a generic function/macro which would print the given 
error string + IP (port) + error description with the given error severity , 
for example :-) Then we can use it in more places later on.


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

Re: [OpenSIPS-Devel] Please stop retagging versions and releasing new tarballs under the same version number.

[Saúl Ibarra Corretgé]

On Jan 15, 2013, at 4:02 PM, Bogdan-Andrei Iancu wrote:

 Hi Peter,
 
 Indeed, the src tarballs are daily re-generated in order to reflect changes 
 on SVN - we ended up with this procedure as users are constantly asking for 
 up 2 date tarballs for installing. And we are not making a new release for 
 each svn commit :)
 
 Also I understand that you want a stable tarball for the specs.
 
 What should be the solution here ? to have one tarball to reflect the release 
 time (and not to be updated in time) and another dynamic one for download 
 purposes ? I'm open to any suggestions :)
 

Here is a proposal: There could be 2 types of files: releases and svn 
snapshots. Releases look like opensips-1.8.3.tar.gz and svn snapshot like 
opensips-1.8-svn1234.tar.gz


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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