Hello,
Kelvin Chua wrote:
> (gdb) bt
> #0 0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
> dlg_db_handler.c:501
This corresponds to
SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str);
so assumingly sip-router crashes when it tries to access the callee's
Alex, Juha-
> On 04/21/2010 05:43 AM, Juha Heinanen wrote:
>
>> i would prefer a solution that does not involve sip-router dialog module
>> at all. that module tries to accomplish something that is alien to the
>> definition of a sip proxy.
>
> In principle, I would prefer such a solution too; h
(gdb) bt
#0 0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
dlg_db_handler.c:501
#1 0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=, param=) at dlg_handlers.c:361
#2 0x2ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0
it may be very tricky to make the b2bua media relay to work reliably.
if relaying part crashes, then the byes need to get send and if
signaling part crashes, then ...???
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
On 4/21/10 1:31 PM, Iñaki Baz Castillo wrote:
2010/4/21 Daniel-Constantin Mierla:
Hello,
are you using the latest git version of branch kamailio_3.0? It was a fix to
dialog after the 3.0.0 release, adding some sanity checks for broken
messages:
http://git.sip-router.org/cgi-bin/gitweb.cgi
2010/4/21 Daniel-Constantin Mierla :
> Hello,
>
> are you using the latest git version of branch kamailio_3.0? It was a fix to
> dialog after the 3.0.0 release, adding some sanity checks for broken
> messages:
> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1
Hello,
On 4/21/10 12:23 PM, Kelvin Chua wrote:
hi daniel,
i'm not using git version. so maybe i'm missing some patches. can you
confirm if what i am
experiencing is the same problem and the fix is indeed available from
the git version? thanks
I recommend using at least 3.0.1, as a matter of
Stefan Sayer writes:
> also, I think that implementing the mediaproxy relay part control in
> SEMS is more work than impelementing RTP packet forward (actually, in
> RTP receiver, it only needs to check whether relay is turned on for
> that session, construct an RTP packet from the buffer,
Stefan Sayer writes:
> > perhaps it would be possible in the same way detach rtp component from
> > sems b2bua signaling component. perhaps it even would be possible to
>
> but, is that desirable? isn't it better if one has only one process to
> start/configure/watch?
may it does not matte
Juha Heinanen wrote:
perhaps it would be possible in the same way detach rtp component from
sems b2bua signaling component. perhaps it even would be possible to
but, is that desirable? isn't it better if one has only one process to
start/configure/watch?
also, I think that implementing the me
Alex Balashov wrote:
On 04/21/2010 06:03 AM, Stefan Sayer wrote:
or you can also combine SEMS b2bua with libiptrtpproxy to have in-kernel
forwarding.
I would be curious for your account of what such an approach would look
like, from an implementational mechanics perspective.
implementationa
hi daniel,
i'm not using git version. so maybe i'm missing some patches. can you
confirm if what i am
experiencing is the same problem and the fix is indeed available from the
git version? thanks
here is the backtrace:
#0 0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
dlg_d
Alex Balashov writes:
> In principle, I would prefer such a solution too; however, my
> argument was that as far as I can tell (and that may not be very far),
> all presented avenues of solution are equidistantly complex and
> presently nonexistent.
alex,
i was just thinking about a simp
Stefan Sayer writes:
> As for 1.b, SEMS does not yet have an RTP relay mode (only transcode).
> If you are really interested in it, I think we can work on that;
> again, the basic components are there, it needs just adding some
> things here and there.
i'm currently using mediaproxy and th
On 04/21/2010 06:03 AM, Stefan Sayer wrote:
or you can also combine SEMS b2bua with libiptrtpproxy to have in-kernel
forwarding.
I would be curious for your account of what such an approach would
look like, from an implementational mechanics perspective.
--
Alex Balashov - Principal
Evarist
Hello,
are you using the latest git version of branch kamailio_3.0? It was a
fix to dialog after the 3.0.0 release, adding some sanity checks for
broken messages:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c
On the other hand, I
Alex Balashov wrote:
On 04/21/2010 05:43 AM, Juha Heinanen wrote:
just route your calls via sems as a b2bua and make it send the byes, if
media stops flowing. if something is missing in order to allow that to
be easily implemented by dsm or ivr plugins, i'm sure stephan and
raphael will take c
Hi,
Alex Balashov wrote:
1) Inline B2BUA in the signaling path of all calls;
1a) Make it do SSTs; or
1b) Make it relay media, too, and hang up the call (bidirectional BYE)
> on RTP receive timeout;
[...]
Needless to say, I am interested in the option that requires the least
work but st
On 04/21/2010 05:43 AM, Juha Heinanen wrote:
just route your calls via sems as a b2bua and make it send the byes, if
media stops flowing. if something is missing in order to allow that to
be easily implemented by dsm or ivr plugins, i'm sure stephan and
raphael will take care of it.
The other
On 04/21/2010 05:43 AM, Juha Heinanen wrote:
i would prefer a solution that does not involve sip-router dialog module
at all. that module tries to accomplish something that is alien to the
definition of a sip proxy.
In principle, I would prefer such a solution too; however, my
argument was
Alex Balashov writes:
> However, we all have to make pragmatic concessions to
> the realities of real-world operation, which I assume is the
> motivation for dialog timeouts, dlg_bye(), and other perversions from
> the point of view of a purist. :-)
>
> I welcome your thoughts and sugge
ok, i'll enable debug for now.
but if it's indeed a buggy UA, the dialog module should not have crashed
but instead dropped the dialog/session and moved on, something i think
we need to address to be more resilient.
i hope i catch the culprit when this happens again.
Kelvin Chua
On Wed, Apr 21,
2010/4/21 Kelvin Chua :
> i wonder if anybody from list is also experiencing this?
Perhaps in your case you have a buggy UA setting an invalid Contact
header and it causes Kamailio to crash, maybe the reason others have
not detected same issue.
Could you get some SIP traces until the problem occu
yeah lots of traffic.
so there's no way of telling whether that particular BYE caused the crashed
or not.
unless i enable debug for the server.
besides, you're right it might just be a simple case of receiving a BYE for
an expired
dialog or something, doesn't seem too fishy at all. i wonder if any
Hi all,
Please forgive the slightly long post, but if you have anything to
contribute on this topic, please consider giving it a read as I could
really use your input. :-)
As I'm sure many others of you running proxy-based service delivery
platforms of some description also, I am faced with
2010/4/21 Kelvin Chua :
> hi inaki,
> unfortunately since i am not expecting any segfaults from kamailio, i have
> very little
> debug info, only those spurted out by syslog. not been using 1.5 for some
> time now.
> bad news, happened twice today. in a
> span of 3 hours. seems like an inbound BYE.
hi inaki,
unfortunately since i am not expecting any segfaults from kamailio, i have
very little
debug info, only those spurted out by syslog. not been using 1.5 for some
time now.
bad news, happened twice today. in a
span of 3 hours. seems like an inbound BYE. here is the other instance:
Apr 21
2010/4/21 Kelvin Chua :
> currently using kamailio 3.0 with around 1000 users.
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> [dlg_handlers.c:218]: bad sip message or missing Contact hdr
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> [dlg_hand
currently using kamailio 3.0 with around 1000 users.
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
[dlg_handlers.c:218]: bad sip message or missing Contact hdr
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
[dlg_handlers.c:350]: could not add furth
On 04/21/2010 04:37 AM, Daniel-Constantin Mierla wrote:
On 4/20/10 8:36 PM, Alex Balashov wrote:
On 04/19/2010 05:15 AM, Daniel-Constantin Mierla wrote:
event_route should be called in this case. Can you test with dlg bridge
to see if the event route is executed?
I have not had a chance to
On 4/20/10 8:36 PM, Alex Balashov wrote:
On 04/19/2010 05:15 AM, Daniel-Constantin Mierla wrote:
event_route should be called in this case. Can you test with dlg bridge
to see if the event route is executed?
I have not had a chance to test this with dlg_bridge() yet, but it
clearly is not
On 04/20/2010 05:08 PM, Iñaki Baz Castillo wrote:
2010/4/20 Alex Balashov:
Hi, yes, a workaround is adding the headers in branch_route, it works.
However I wonder if the expected behavior is that added headers are
not keep in serial forking. Well, it could make sense. I just want to
confirm.
I
>>> Hello,
>>>
>>> I am trying to use SQLOps Module in my kamailio 1.5 configuration.
>>>
>>> According to your explanations every result of sql_query should be
>>> freed just after using that data.
>>> So it means that there will be better to fetch for THE SAME data three
>>> times instead of just
33 matches
Mail list logo
