[OpenSIPS-Users] force_rtp_proxy /rtpproxy_offer - Opensips coredump on call without userinfo in contact address ?
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu Jul 15 20:21:06 CEST 2010
Hi Max,
I found something related to this - actually the crash happened because
the Content-len hdr was missing too.
There is a fix on SVN (rev 7030 / 7031) on trunk / 1.6 - please update
and test again to see if the crash still occurs or not.
Regards,
Bogdan
Max Mühlbronner wrote:
> Yes, exactly. The other carrier/switch was sending a 183 without SDP
> body. And at least it seemed like our Server threw a coredump whenever
> it was received, after omitting rtpproxy for this carrier (no
> rtpproxy_offer / nathelper) it works fine --> no crash.
>
> I will try to send you some Siptrace if i still got access to it.
>
>
> Thanks
>
> Max M.
>
> Bogdan-Andrei Iancu schrieb:
>
>> Hi Max,
>>
>> What you mean by "a missing SDP in the progress " ? you mean a 183
>> without SDP ? so a force_rtp_proxy on something without SDP may lead in
>> crash?
>>
>> Regards,
>> Bogdan
>>
>>
>> Max Mühlbronner wrote:
>>
>>
>>> Hello,
>>>
>>> Very sorry for my late reply, i am not fully online at the moment.
>>>
>>> Although in the meantime we did figure out the crashes were not related
>>> to the contact address (my first impression) but the reason was
>>> a missing SDP in the progress from the other carrier. We fixed it
>>> temporarily by omitting rtpproxy for this carrier. --> No more Crashing.
>>>
>>> I will try to find a solution for sending you the coredump as soon as
>>> possible.
>>>
>>> Thanks
>>>
>>> Max M.
>>>
>>> Bogdan-Andrei Iancu schrieb:
>>>
>>>
>>>
>>>> Hi Max,
>>>>
>>>> it will have me a lot if I could get access to the corefile for
>>>> inspection.....do you think is possible ? we are planning a new release
>>>> on 1.6 branch for next week and I really want to have this fixed.
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> Max Mühlbronner wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hello Bogdan,
>>>>>
>>>>> too bad, but the problem continues after update.
>>>>>
>>>>> opensips-dev:/tmp/opensips# gdb /sbin/opensips core.opensips.sig11.9272
>>>>> GNU gdb 6.8-debian
>>>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>> <http://gnu.org/licenses/gpl.html>
>>>>> This is free software: you are free to change and redistribute it.
>>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>>>>> and "show warranty" for details.
>>>>> This GDB was configured as "i486-linux-gnu"...
>>>>> Cannot access memory at address 0xb7f93658
>>>>> (gdb) bt
>>>>> #0 0x080ec894 in get_all_bodies (msg=Cannot access memory at address
>>>>> 0xbfd928a0
>>>>> ) at parser/parse_multipart.c:197
>>>>> Cannot access memory at address 0xbfd9289c
>>>>>
>>>>>
>>>>>
>>>>> svnrevision: 2:6982M
>>>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>> Max M.
>>>>>
>>>>>
>>>>> Bogdan-Andrei Iancu schrieb:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Max,
>>>>>>
>>>>>> yes, that's the last revision on 1.6 branch - just let me know if the
>>>>>> bug is sill there with this version.
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Bogdan
>>>>>>
>>>>>> Max Mühlbronner wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks for the hint. But I really dont understand how this happened
>>>>>>> because i thought i did initially check out the 1.6 branch via svn!?
>>>>>>> (and not 1.5) But maybe i mixed up something..
>>>>>>>
>>>>>>> /usr/src/OPENSIPS-SVN/opensips_1_6
>>>>>>>
>>>>>>> i have updated the same 1.6 on another test-system and it seems to be
>>>>>>> revision 6982. Would this be sufficient for testing again?
>>>>>>>
>>>>>>> Br
>>>>>>>
>>>>>>> Max M.
>>>>>>>
>>>>>>> Bogdan-Andrei Iancu schrieb:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> 6732 is a revision on 1.5 branch from March 2010 - try to first update
>>>>>>>> from SVN branch 1.6 - let me know if the problem is still there or not.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Bogdan
>>>>>>>>
>>>>>>>> Max Mühlbronner wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Sorry for the late reply, i had very limited access to my mail last week.
>>>>>>>>>
>>>>>>>>> version: opensips 1.6.2-notls (i386/linux)
>>>>>>>>> flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM,
>>>>>>>>> SHM_MMA
>>>>>>>>> P, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>>>>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>>>>>>>> MAX_URI_SI
>>>>>>>>> ZE 1024, BUF_SIZE 65535
>>>>>>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>>>>>>>> svnrevision: 2:6732M
>>>>>>>>> @(#) $Id: main.c 6169 2009-09-22 12:48:37Z bogdan_iancu $
>>>>>>>>> main.c compiled on 10:35:28 Mar 23 2010 with gcc 4.3.2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Max M.
>>>>>>>>>
>>>>>>>>> Bogdan-Andrei Iancu schrieb:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Max,
>>>>>>>>>>
>>>>>>>>>> Any chance to get my hands on that core file (on your server) or should
>>>>>>>>>> we try some remote debugging ?
>>>>>>>>>>
>>>>>>>>>> Also, what is the revision number (see with opensips -V )
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Bogdan
>>>>>>>>>>
>>>>>>>>>> Max Mühlbronner wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> yes, it is reproducible for me. 1.6.2
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best Regards
>>>>>>>>>>>
>>>>>>>>>>> Max M.
>>>>>>>>>>>
>>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>>> Von: users-bounces at lists.opensips.org
>>>>>>>>>>> [mailto:users-bounces at lists.opensips.org] Im Auftrag von Bogdan-Andrei Iancu
>>>>>>>>>>> Gesendet: Dienstag, 15. Juni 2010 18:31
>>>>>>>>>>> An: OpenSIPS users mailling list
>>>>>>>>>>> Betreff: Re: [OpenSIPS-Users] force_rtp_proxy /rtpproxy_offer - Opensips
>>>>>>>>>>> coredump on call without userinfo in contact address ?
>>>>>>>>>>>
>>>>>>>>>>> Hi Max,
>>>>>>>>>>>
>>>>>>>>>>> What version of opensips are you using ? I was trying to search for the
>>>>>>>>>>> file and line mentioned by your gdb printout, but I cannot correlate.
>>>>>>>>>>>
>>>>>>>>>>> Also, is this bug reproducible by you? As I'm not 100% sure it is
>>>>>>>>>>> Contact related as the backtrace shows the crash when trying to get the
>>>>>>>>>>> body(s) of the reply.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Bogdan
>>>>>>>>>>>
>>>>>>>>>>> Max Mühlbronner wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have a small problem with opensips 1.6.2 trunk version (updated via
>>>>>>>>>>>> svn few days ago, still same issue.)
>>>>>>>>>>>> I can see the call setup from Opensips to the carrier (using rtpproxy)
>>>>>>>>>>>> which is fine, up to some point: Invite, Progress, Ringing --> OK
>>>>>>>>>>>>
>>>>>>>>>>>> All other calls are fine, I did not notice any difference with this
>>>>>>>>>>>> carrier, but now i realized the contact address of the OK for these
>>>>>>>>>>>> calls contains no userinfo/ @character.
>>>>>>>>>>>>
>>>>>>>>>>>> Server: Sippy.
>>>>>>>>>>>> Contact: Anonymous <sip:195.24.34.24:5061>.
>>>>>>>>>>>>
>>>>>>>>>>>> On a call setup i can reproduce a coredump on every call like this. So i
>>>>>>>>>>>> did some research, but according to RFC2396 (Uniform Resource
>>>>>>>>>>>> Identifiers - URI) and also other sources, a uri can consist of just an
>>>>>>>>>>>> ip adress/port combination without any userinfo@ part. But if i receive
>>>>>>>>>>>> a call in this way, my opensips instance will crash immediately? (But it
>>>>>>>>>>>> is probably more related to the nathelper module /force_rtp_proxy then
>>>>>>>>>>>> opensips?)
>>>>>>>>>>>>
>>>>>>>>>>>> Any ideas, suggestions are really appreciated. Thanks very much in
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
20 - 24 September 2010, Frankfurt, Germany
www.voice-system.ro
More information about the Users
mailing list