So it crashed again today. Here is the log
Feb 10 18:26:24 RTSIP rtsip-service[10443]: CRITICAL:core:qm_free: freeing
already freed pointer, first free: parser/sdp/sdp.c:
free_cloned_sdp_stream(874) - aborting
Feb 10 18:26:25 RTSIP rtsip-service[10464]: CRITICAL:core:receive_fd: EOF
on 25
On M
Ok so it looks like 1.10 may have been the problem. Things seem to be working
with the same config on 1.9. I'm still getting that funny /304 in the route
header, but now I've discovered that it's the software initiating the call that
is adding that /304 (it only added it when it's in proxy mode,
Guys thank you all for your help. I was able to locate and restart the
mysql instance and was able to restart opensips, thank you so much.
/etc/init.d/opensips start
Starting opensips: [ OK ]
On Sat, Feb 8, 2014 at 3:04 PM, Schneur Rosenberg
wrote:
> I
Hello,
I tested it, and it works.
About the save() return codes, there are a lot of cases, so I would have
sorted it this way:
- no error,
- error codes in parsing SIP,
- server side errors (like manipulating usrloc),
- and service errors (like too many registers).
Here is a patch by way of exam
Hello,
Seems the Solaris sed does not have the -i option ( which is used to
edit some files in place to change the installation path ) -
http://stackoverflow.com/questions/4121711/sed-i-option-is-not-working-on-solaris
, seems that this is just a GNU sed feature.
Will try to do a work around
Hello,
Any updates on this ?
Best Regards,
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com
On 16.01.2014 18:13, Vlad Paiu wrote:
Hello Jeff,
Well then it seems like a bug - if you can, please provide more info
on how you can replicate this and open a ticket on github. Thanks
Hi Max,
Looking in the RTPP module in 1.10, I see it is properly tested for the
"" value (not to be used) - I did not test, but code looks right.
For which version + module have you found the problems ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions
Hello,
The Route header you receive in the original INVITE does contain the IP
of your OpenSIPS (that 85.221.xxx.xxx ) ?
(as I understand the call is rejected as "Attempt to route with
preloaded Route's", right?)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensi
Hello,
No, that is not possible - it has nothing to do with the TCP
implementation, but with the fact that the branches (in parallel
forking) are sequentially processed (built and sent).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.01.2
Hello,
The ACK is sent to the contact URI from the 200 OK. As you found, the
problem is when the 200 OK is processed by your OpenSIPS - the private
IP in the 200 OK Contact header must be replaced with the public one
(take from the network level) by the fix_nated_contact() (or similar
functio
Hello,
In this scenario:
Ast?risk <-- 3 -- OpenSIPS <-- 4 -- UAC
What SIP requests the UAC is sending ? REGISTER ? INVITES ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 20.01.2014 13:05, ? ?? wrote:
Hi!
OpenSIPS version
Hello,
The fact you are changing the interface (actually your are bridging
networks) have nothing to do neither with TO and FROM hdrs (they contain
callee/caller identities, nothing to do with routing), nor with the
Contact hdr (this contains the IP coordinates of the sender of the
package, n
Hello,
I would strongly advice you to use the address table in conjunction with
check_address() or check_source_address(). See:
http://www.opensips.org/html/docs/modules/1.10.x/permissions.html#sec-address-permissions
http://www.opensips.org/html/docs/modules/1.10.x/permissions.html#id294509
I
13 matches
Mail list logo
