[Kamailio-Users] Send me an SMS
Hi,Here is the link to send free SMS to any mobile in India. I use it too :-) http://www.indyarocks.com/register_step1.php?invitor=MjEyMjkyMA==&emailencryp=dXNlcnNAbGlzdHMua2FtYWlsaW8ub3Jn.-Sunkara RaviPrakashPlease note: This message was sent to you by a user at Indyarocks.com. Click here in case you do not wish to receive any invite from this user. Click here if you do not wish to get any invitations from any Indyarocks user. If you have any queries please contact us at [EMAIL PROTECTED] ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
[Kamailio-Users] Send me an SMS
Hi,Here is the link to send free SMS to any mobile in India. I use it too :-) http://www.indyarocks.com/register_step1.php?invitor=MjEyMjkyMA==&emailencryp=dXNlcnNAbGlzdHMua2FtYWlsaW8ubmV0.-Sunkara RaviPrakashPlease note: This message was sent to you by a user at Indyarocks.com. Click here in case you do not wish to receive any invite from this user. Click here if you do not wish to get any invitations from any Indyarocks user. If you have any queries please contact us at [EMAIL PROTECTED] ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Alex Balashov wrote:
> Daniel-Constantin Mierla wrote:
>>
>> On 10/16/08 22:07, Alex Balashov wrote:
>>> Ovidiu Sas wrote:
>>>
>>>
> If it is loose_route() that I need to correlate subsequent in-dialog
> requests, why? As you said, if no RR cookies are being used, why
> should the
> proxy care about the Route: header?
>
I don't know how to put it better in other words :(
The proxy doesn't care about the Route header.
The proxy uses the record routing mechanism as a hook into the dialog
internals and the matching is done inside the dialog module. After
that, the dialog module will chose the matching mechanism.
>>> I got that.
>>>
>>> So, why does matching not work unless I call loose_route(), regardless
>>> of match mode? :-)
>>>
>> the matching is triggered by execution of Route processing callbacks
>> that happen only by calling loose_route().
>>
>> The dialog module registers a function to be called when the Route
>> header is processed. In this function the dialog module does the
>> matching algorithm. To get independent of that, for matching mode 2, a
>> function should be exported by dialog for explicit call in the script,
>> something like:
>>
>> if(dialog_match())
>> {
>>
>> }
>>
>> Cheers,
>> Daniel
>
> That's what I figured; there was something in the callback architecture
> that caused the module to otherwise not see the requests.
>
> Cool - that explains it!
>
BTW, I do think it would be a good idea for the dialog module to export
these functions directly into the script symbols so they can be called
that way. I do not like to do loose routing unnecessarily / when I have
no use for it.
-- Alex
--
Alex Balashov
Evariste Systems
Web: http://www.evaristesys.com/
Tel: (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Daniel-Constantin Mierla wrote:
>
>
> On 10/16/08 22:07, Alex Balashov wrote:
>> Ovidiu Sas wrote:
>>
>>
If it is loose_route() that I need to correlate subsequent in-dialog
requests, why? As you said, if no RR cookies are being used, why
should the
proxy care about the Route: header?
>>> I don't know how to put it better in other words :(
>>> The proxy doesn't care about the Route header.
>>> The proxy uses the record routing mechanism as a hook into the dialog
>>> internals and the matching is done inside the dialog module. After
>>> that, the dialog module will chose the matching mechanism.
>>>
>>
>> I got that.
>>
>> So, why does matching not work unless I call loose_route(), regardless
>> of match mode? :-)
>>
> the matching is triggered by execution of Route processing callbacks
> that happen only by calling loose_route().
>
> The dialog module registers a function to be called when the Route
> header is processed. In this function the dialog module does the
> matching algorithm. To get independent of that, for matching mode 2, a
> function should be exported by dialog for explicit call in the script,
> something like:
>
> if(dialog_match())
> {
>
> }
>
> Cheers,
> Daniel
That's what I figured; there was something in the callback architecture
that caused the module to otherwise not see the requests.
Cool - that explains it!
--
Alex Balashov
Evariste Systems
Web: http://www.evaristesys.com/
Tel: (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Core dump on writing dialog profile size into script var.
On 10/16/08 22:03, Alex Balashov wrote: > Daniel, > > This has, indeed, appeared to have fixed the issue. Thanks! ok, I backported to 1.4 Cheers, Daniel > > -- Alex > > Daniel-Constantin Mierla wrote: > >> Hello Alex, >> >> and, if everyone tried to give hints, the command is: >> >> # svn co https://openser.svn.sourceforge.net/svnroot/openser/trunk >> kamailio >> >> However, what I actually want to say is that the patch is very >> minimal, see it here: >> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/dialog/dialog.c?r1=4669&r2=5080 >> >> >> >> You probably can fix it in 1.4 very easy and test it there. >> >> Cheers, >> Daniel >> >> >> >> On 10/16/08 20:33, Henning Westerholt wrote: >>> On Thursday 16 October 2008, Alex Balashov wrote: >>> I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk? >>> >>> Hi Alex, >>> >>> you can checkout from sf.org (can be slow sometimes): >>> https://openser.svn.sourceforge.net/svnroot/openser/trunk >>> >>> or the read/only mirror, which is fast: >>> http://devel.kamailio.org/svn/trunk >>> >>> Cheers, >>> >>> Henning >>> >> > > -- Daniel-Constantin Mierla http://www.asipto.com ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On 10/16/08 22:07, Alex Balashov wrote:
> Ovidiu Sas wrote:
>
>
>>> If it is loose_route() that I need to correlate subsequent in-dialog
>>> requests, why? As you said, if no RR cookies are being used, why should the
>>> proxy care about the Route: header?
>>>
>> I don't know how to put it better in other words :(
>> The proxy doesn't care about the Route header.
>> The proxy uses the record routing mechanism as a hook into the dialog
>> internals and the matching is done inside the dialog module. After
>> that, the dialog module will chose the matching mechanism.
>>
>
> I got that.
>
> So, why does matching not work unless I call loose_route(), regardless
> of match mode? :-)
>
the matching is triggered by execution of Route processing callbacks
that happen only by calling loose_route().
The dialog module registers a function to be called when the Route
header is processed. In this function the dialog module does the
matching algorithm. To get independent of that, for matching mode 2, a
function should be exported by dialog for explicit call in the script,
something like:
if(dialog_match())
{
}
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Now I didn't get it ... lol On Thu, Oct 16, 2008 at 3:07 PM, Alex Balashov <[EMAIL PROTECTED]> wrote: > Ovidiu Sas wrote: > >>> If it is loose_route() that I need to correlate subsequent in-dialog >>> requests, why? As you said, if no RR cookies are being used, why should >>> the >>> proxy care about the Route: header? >> >> I don't know how to put it better in other words :( >> The proxy doesn't care about the Route header. >> The proxy uses the record routing mechanism as a hook into the dialog >> internals and the matching is done inside the dialog module. After >> that, the dialog module will chose the matching mechanism. > > I got that. > > So, why does matching not work unless I call loose_route(), regardless of > match mode? :-) > > -- > Alex Balashov > Evariste Systems > Web: http://www.evaristesys.com/ > Tel: (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote: >> If it is loose_route() that I need to correlate subsequent in-dialog >> requests, why? As you said, if no RR cookies are being used, why should the >> proxy care about the Route: header? > > I don't know how to put it better in other words :( > The proxy doesn't care about the Route header. > The proxy uses the record routing mechanism as a hook into the dialog > internals and the matching is done inside the dialog module. After > that, the dialog module will chose the matching mechanism. I got that. So, why does matching not work unless I call loose_route(), regardless of match mode? :-) -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
> If it is loose_route() that I need to correlate subsequent in-dialog > requests, why? As you said, if no RR cookies are being used, why should the > proxy care about the Route: header? I don't know how to put it better in other words :( The proxy doesn't care about the Route header. The proxy uses the record routing mechanism as a hook into the dialog internals and the matching is done inside the dialog module. After that, the dialog module will chose the matching mechanism. Regards, Ovidiu Sas ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Core dump on writing dialog profile size into script var.
Daniel, This has, indeed, appeared to have fixed the issue. Thanks! -- Alex Daniel-Constantin Mierla wrote: > Hello Alex, > > and, if everyone tried to give hints, the command is: > > # svn co https://openser.svn.sourceforge.net/svnroot/openser/trunk kamailio > > However, what I actually want to say is that the patch is very minimal, > see it here: > http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/dialog/dialog.c?r1=4669&r2=5080 > > > > You probably can fix it in 1.4 very easy and test it there. > > Cheers, > Daniel > > > > On 10/16/08 20:33, Henning Westerholt wrote: >> On Thursday 16 October 2008, Alex Balashov wrote: >> >>> I feel retarded asking this as I'm sure it's abundantly made clear on >>> the web site / dokuwiki, but what's the SVN URI to check out trunk? >>> >> >> Hi Alex, >> >> you can checkout from sf.org (can be slow sometimes): >> https://openser.svn.sourceforge.net/svnroot/openser/trunk >> >> or the read/only mirror, which is fast: >> http://devel.kamailio.org/svn/trunk >> >> Cheers, >> >> Henning >> > -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
And specifically, the ambiguity I am referring to in your narrative is the following: 1) In your first reply to me after I posted the configs, you said: "Your config is bogus. You are not doing proper record-routing (you commented out that section). In-dialog requests are matched during record-route handling, regardless of the dialog match mode." 2) In your subsequent reply to yourself and clarification of the issue with reference to the dialog docs, you say: "The documentation is a little bit fuzzy about this, but here's the hint: http://kamailio.org/docs/modules/1.4.x/dialog#id2507978 http://kamailio.org/docs/modules/1.4.x/dialog#id2508031 This PV will be available only for sequential requests, after doing loose_route(). So it means that you must perform loose_route() if you want to catch in-dialog request and have a consistent dialog state. With your config, all the dialogs will just time out ..." 3) So, which one is it? If I need to record_route(), that is obvious; you cannot monitor dialogs if subsequent in-dialog requests do not pass through the proxy. I am doing that. If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header? Thanks, -- Alex Ovidiu Sas wrote: > The cookie attribute is not used at all in mode 2. Inspect your > traffic and you will see that there are no rr coockes and the dialog > matching is working ok (in mode 2). > The record-route mechanism is used as a _hook_ by the dialog module to > intercept in dialog requests. I don't know how to put this better in > words ... > Hope that this clarifies your dialog matching issue. > > So ... the dlg_match_mode works as advertised in the doc as long as > you have a proper implementation of the record rote mechanism. > For mode 0 and 1 you will have cookies in the Record-Route headers. > For mode 2 you will have no cookies in the Record-Route headers and > the matching will still work. > > > Regards, > Ovidiu Sas > > On Thu, Oct 16, 2008 at 1:58 PM, Alex Balashov > <[EMAIL PROTECTED]> wrote: >> Yep. That was the conclusion I came to as well; even though >> dlg_match_mode insinuates that the cookie attribute is optional, >> implying there are other ways to match subsequent requests as well, >> it is actually not. >> >> On Thu, October 16, 2008 1:45 pm, Ovidiu Sas wrote: That was the topic of my original post: how to correlate dialogs purely based on SIP attributes without the use of loose-routing. >>> short answer: you can't (and the matching method doesn't matter). >>> proper loose-routing is a must. >>> >> >> -- >> Alex Balashov >> Evariste Systems >> Web: http://www.evaristesys.com/ >> Tel: (+1) (678) 954-0670 >> Direct : (+1) (678) 954-0671 >> Mobile : (+1) (706) 338-8599 >> >> -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
That's what I thought too, looking at the traffic. My guess is it correlates by to-tag and/or Call-ID GUID. Are you using "record-route mechanism" and "loose-routing" interchangeably? To me, they are very different things. Record-route causes the subsequent in-dialog requests from both ends to be routed through the server, which is something that I did have applied in my configuration. Loose routing does what RFC 3261 says it does, and specifically in this case, it processes the Route: header and modifies the RURI if necessary. What I commented out was loose-routing, and with that, request correlation broke - even in dlg_match_mode 2. So, what I am assuming is that loose routing is still necessary for the correlation to work, with or without the cookie. My question was why that was so, as there appeared to be no obvious reason for this as long as record-routing is turned on. -- Alex Ovidiu Sas wrote: > The cookie attribute is not used at all in mode 2. Inspect your > traffic and you will see that there are no rr coockes and the dialog > matching is working ok (in mode 2). > The record-route mechanism is used as a _hook_ by the dialog module to > intercept in dialog requests. I don't know how to put this better in > words ... > Hope that this clarifies your dialog matching issue. > > So ... the dlg_match_mode works as advertised in the doc as long as > you have a proper implementation of the record rote mechanism. > For mode 0 and 1 you will have cookies in the Record-Route headers. > For mode 2 you will have no cookies in the Record-Route headers and > the matching will still work. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
[Kamailio-Users] Openser 1.3.2 to Kamailio 1.4.1 Upgrade Problem. Pls HELP.
Hi, I am upgrading openser 1.3.2 to kamailio 1.4.1 and I am having this problem: Oct 16 18:20:25 dev-ser-01 /sbin/kamailio[6466]: ERROR:core:db_check_table_version: invalid version 2 for table presentity found, expected 3 (check table structure and table "version") Is there any database schema change to the presentity table? If so, how do I upgrade the presentity table? I tried to run the kamdbctl script to upgrade the database and I got access denied with 'root' user. How do I run kamdbctl with 'openser' and 'openserrw' to access mysql database? Also, my database is on a remote host so kamdbctl may not be useful. Thanks, George ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
The cookie attribute is not used at all in mode 2. Inspect your traffic and you will see that there are no rr coockes and the dialog matching is working ok (in mode 2). The record-route mechanism is used as a _hook_ by the dialog module to intercept in dialog requests. I don't know how to put this better in words ... Hope that this clarifies your dialog matching issue. So ... the dlg_match_mode works as advertised in the doc as long as you have a proper implementation of the record rote mechanism. For mode 0 and 1 you will have cookies in the Record-Route headers. For mode 2 you will have no cookies in the Record-Route headers and the matching will still work. Regards, Ovidiu Sas On Thu, Oct 16, 2008 at 1:58 PM, Alex Balashov <[EMAIL PROTECTED]> wrote: > > Yep. That was the conclusion I came to as well; even though > dlg_match_mode insinuates that the cookie attribute is optional, > implying there are other ways to match subsequent requests as well, > it is actually not. > > On Thu, October 16, 2008 1:45 pm, Ovidiu Sas wrote: >>> That was the topic of my original post: how to correlate dialogs purely >>> based on SIP attributes without the use of loose-routing. >> >> short answer: you can't (and the matching method doesn't matter). >> proper loose-routing is a must. >> > > > -- > Alex Balashov > Evariste Systems > Web: http://www.evaristesys.com/ > Tel: (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > > ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Core dump on writing dialog profile size into script var.
Hello Alex, and, if everyone tried to give hints, the command is: # svn co https://openser.svn.sourceforge.net/svnroot/openser/trunk kamailio However, what I actually want to say is that the patch is very minimal, see it here: http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/dialog/dialog.c?r1=4669&r2=5080 You probably can fix it in 1.4 very easy and test it there. Cheers, Daniel On 10/16/08 20:33, Henning Westerholt wrote: > On Thursday 16 October 2008, Alex Balashov wrote: > >> I feel retarded asking this as I'm sure it's abundantly made clear on >> the web site / dokuwiki, but what's the SVN URI to check out trunk? >> > > Hi Alex, > > you can checkout from sf.org (can be slow sometimes): > https://openser.svn.sourceforge.net/svnroot/openser/trunk > > or the read/only mirror, which is fast: > http://devel.kamailio.org/svn/trunk > > Cheers, > > Henning > -- Daniel-Constantin Mierla http://www.asipto.com ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Yep. That was the conclusion I came to as well; even though dlg_match_mode insinuates that the cookie attribute is optional, implying there are other ways to match subsequent requests as well, it is actually not. On Thu, October 16, 2008 1:45 pm, Ovidiu Sas wrote: >> That was the topic of my original post: how to correlate dialogs purely >> based on SIP attributes without the use of loose-routing. > > short answer: you can't (and the matching method doesn't matter). > proper loose-routing is a must. > -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
> That was the topic of my original post: how to correlate dialogs purely > based on SIP attributes without the use of loose-routing. short answer: you can't (and the matching method doesn't matter). proper loose-routing is a must. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 1:13 PM, Alex Balashov
<[EMAIL PROTECTED]> wrote:
> Ovidiu Sas wrote:
>>
>> On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov
>>> <[EMAIL PROTECTED]> wrote:
>
> Post your config and the trace of a bad call (ngrep + kamailio logs).
Config: http://pastebin.com/f28051a5
My debug output: http://pastebin.com/d2f667520 (The profile size just
keeps
incrementing with every call that I make from 7709600101)
Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
My debug output with loose routing: http://pastebin.com/d2b0fb533
Packet trace: http://pastebin.com/d77297606
>>>
>>> Your config is bogus. You are not doing proper record-routing (you
>>> commented out that section).
>>> In-dialog requests are matched during record-route handling,
>>> regardless of the dialog match mode.
>>>
>>
>> The documentation is a little bit fuzzy about this, but here's the hint:
>> http://kamailio.org/docs/modules/1.4.x/dialog#id2507978
>> http://kamailio.org/docs/modules/1.4.x/dialog#id2508031
>>
>>
>> This PV will be available only for sequential requests, after doing
>> loose_route().
>>
>>
>> So it means that you must perform loose_route() if you want to catch
>> in-dialog request and have a consistent dialog state. With your
>> config, all the dialogs will just time out ...
>
> What? I did not commend out the record_route section:
>
>if(!is_method("REGISTER|OPTIONS"))
>record_route();
>
> The reason I commented out the loose_route() section was specifically to
> illustrate that dialog correlation does not occur _without_ it. I normally
> have it enabled.
>
> That was the topic of my original post: how to correlate dialogs purely
> based on SIP attributes without the use of loose-routing.
>
> It would seem to follow from what you are saying, from the documentation
> hint you reference (which I read before), and from my examination of the
> source code to see how the dialog correlation works that the only way it
> could possibly work is through the use of a dialog correlate attribute in
> the Route: header. That is why a call to loose_route() is necessary, and
> that is why subsequent in-dialog requests do not get correlated without it.
It seems that I misunderstood your initial question ...
You must use loose_route because this will trigger the dialog callback.
Now how you match your dialog, it's a different story.
I thought that you were complaining about db_dialog_match_mode 2.
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Core dump on writing dialog profile size into script var.
On Thursday 16 October 2008, Alex Balashov wrote: > I feel retarded asking this as I'm sure it's abundantly made clear on > the web site / dokuwiki, but what's the SVN URI to check out trunk? Hi Alex, you can checkout from sf.org (can be slow sometimes): https://openser.svn.sourceforge.net/svnroot/openser/trunk or the read/only mirror, which is fast: http://devel.kamailio.org/svn/trunk Cheers, Henning ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Core dump on writing dialog profile size into script var.
Hi Alex, > I feel retarded asking this as I'm sure it's abundantly made clear on > the web site / dokuwiki, but what's the SVN URI to check out trunk? Go to this address (http://www.kamailio.org/mos/view/Download/) and search for: "SVN Download" Saludos JesusR. > Daniel-Constantin Mierla wrote: > >> Hello Alex, >> >> I found a bug in the dialog module, the profile size is integer and >> the >> variable was set as string value. Can you get the trunk and test? I >> will >> backport afterwards, thanks, >> >> Daniel >> >> >> On 10/16/08 08:04, Alex Balashov wrote: >>> It would seem that the malloc for the script var occasionally fails, >>> which may or may not be central to the issue: >>> >>> [SWITCH] Relaying BYE from 210.23.22.23 to sip:[EMAIL PROTECTED] >>> (DTAG=706 >>> [SWITCH] [D] No dialog affinity for this BYE >>> Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem! >>> Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set >>> svar >>> [SWITCH] [D] Profile size for 7709600101 now: 0 >>> [ONREPLY-ROUTE 2] Received 200 for BYE >>> Relaying INVITE from 210.23.22.23 to sip: >>> [EMAIL PROTECTED]:5060 >>> [D] Added new dialog for 7709600101 >>> [ONREPLY-ROUTE 1] Provisional reply 100 received. >>> [ONREPLY-ROUTE 1] 200 OK received for 7709600101 >>> [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 >>> [ONREPLY-ROUTE 1] Dialog profile size is: > >>> [SWITCH] Relaying ACK from 210.23.22.23 to sip:[EMAIL PROTECTED] >>> (DTAG=706 >>> [SWITCH] [D] No dialog affinity for this ACK >>> Segmentation fault (core dumped) >>> >>> >>> Alex Balashov wrote: >>> >>> I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5). When I write the dialog profile size into an AVP, it works fine. When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes: Relaying INVITE from 210.23.22.23 to sip:[EMAIL PROTECTED]:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped) GDB reveals: Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=>>> at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c: 668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c: 1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693 It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above. Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU. >>> >>> >>> >> > > > -- > Alex Balashov > Evariste Systems > Web: http://www.evaristesys.com/ > Tel: (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > > ___ > Users mailing list > Users@lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > Saludos JesusR. Jesus Rodriguez VozTelecom Sistemas, S.L. [EMAIL PROTECTED] http://www.voztele.com Tel. 902360305 - ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
[Kamailio-Users] lcr module enhancements
i just committed to kamailio trunk an enhanced version of lcr module. changes from kamailio wiki page http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x are as follows: * New high-performance implementation that keeps lcr information in in-memory hash table, whose size can be given in a new module parameter 'lcr_hash_size'. See lcr/README for lcr function execution times. * New 'weight' field in 'gw' table that can be used to assign a gateway a weight among gateways of its group. * Support for prefix_mode=1 has been dropped. * lcr_dump MI function has been split into lcr_gw_dump and lcr_lcr_dump functions. * lcr_reload function is now executed under a lock thus minimizing race conditions. * Regular expressions are now Perl 5.x, instead of POSIX, compatible due to use of PCRE regular expression library. testing and feedback is appreciated. -- juha ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Core dump on writing dialog profile size into script var.
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk? Daniel-Constantin Mierla wrote: > Hello Alex, > > I found a bug in the dialog module, the profile size is integer and the > variable was set as string value. Can you get the trunk and test? I will > backport afterwards, thanks, > > Daniel > > > On 10/16/08 08:04, Alex Balashov wrote: >> It would seem that the malloc for the script var occasionally fails, >> which may or may not be central to the issue: >> >> [SWITCH] Relaying BYE from 210.23.22.23 to sip:[EMAIL PROTECTED] >> (DTAG=706 >> [SWITCH] [D] No dialog affinity for this BYE >> Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem! >> Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set svar >> [SWITCH] [D] Profile size for 7709600101 now: 0 >> [ONREPLY-ROUTE 2] Received 200 for BYE >> Relaying INVITE from 210.23.22.23 to sip:[EMAIL PROTECTED]:5060 >> [D] Added new dialog for 7709600101 >> [ONREPLY-ROUTE 1] Provisional reply 100 received. >> [ONREPLY-ROUTE 1] 200 OK received for 7709600101 >> [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 >> [ONREPLY-ROUTE 1] Dialog profile size is: > >> [SWITCH] Relaying ACK from 210.23.22.23 to sip:[EMAIL PROTECTED] >> (DTAG=706 >> [SWITCH] [D] No dialog affinity for this ACK >> Segmentation fault (core dumped) >> >> >> Alex Balashov wrote: >> >> >>> I also have another interesting problem with the aforementioned >>> configuration (http://pastebin.com/f28051a5). >>> >>> When I write the dialog profile size into an AVP, it works fine. >>> >>> When I write it into a script var, i.e. replace $avp(S:dlg_sz) with >>> $var(dlg_sz), it crashes: >>> >>> Relaying INVITE from 210.23.22.23 to sip:[EMAIL PROTECTED]:5060 >>> [D] Added new dialog for 7709600101 >>> [ONREPLY-ROUTE 1] Provisional reply 100 received. >>> [ONREPLY-ROUTE 1] 200 OK received for 7709600101 >>> [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 >>> Segmentation fault (core dumped) >>> >>> GDB reveals: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 >>> (gdb) where >>> #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 >>> #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, >>> flags=>> at script_var.c:122 >>> #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, >>> profile=0xb5ede180 "\034??\ >>> value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 >>> #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 >>> #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at >>> action.c:138 >>> #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 >>> #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at >>> action.c:138 >>> #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at >>> action.c:118 >>> #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 >>> #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 >>> #10 0x08090d5b in receive_msg ( >>> buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP >>> 215.22.22.22;branch=z9hG4 >>> 08.52.173.18\r\nVia: SIP/2.0/UDP >>> 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc >>> p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 >>> #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 >>> #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693 >>> >>> It would seem to me that there is some sort of buffer overflow issue >>> that results in the garbage seen above. >>> >>> Not sure that it makes a difference, but the glibc being linked >>> against is a Xen-safe one that disables TLS functionality. This is >>> all running inside a Xen DomU. >>> >>> >> >> >> > -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote:
> On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov
>> <[EMAIL PROTECTED]> wrote:
Post your config and the trace of a bad call (ngrep + kamailio logs).
>>> Config: http://pastebin.com/f28051a5
>>>
>>> My debug output: http://pastebin.com/d2f667520 (The profile size just keeps
>>> incrementing with every call that I make from 7709600101)
>>>
>>> Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
>>>
>>> My debug output with loose routing: http://pastebin.com/d2b0fb533
>>>
>>> Packet trace: http://pastebin.com/d77297606
>> Your config is bogus. You are not doing proper record-routing (you
>> commented out that section).
>> In-dialog requests are matched during record-route handling,
>> regardless of the dialog match mode.
>>
>
> The documentation is a little bit fuzzy about this, but here's the hint:
> http://kamailio.org/docs/modules/1.4.x/dialog#id2507978
> http://kamailio.org/docs/modules/1.4.x/dialog#id2508031
>
>
> This PV will be available only for sequential requests, after doing
> loose_route().
>
>
> So it means that you must perform loose_route() if you want to catch
> in-dialog request and have a consistent dialog state. With your
> config, all the dialogs will just time out ...
What? I did not commend out the record_route section:
if(!is_method("REGISTER|OPTIONS"))
record_route();
The reason I commented out the loose_route() section was specifically to
illustrate that dialog correlation does not occur _without_ it. I
normally have it enabled.
That was the topic of my original post: how to correlate dialogs purely
based on SIP attributes without the use of loose-routing.
It would seem to follow from what you are saying, from the documentation
hint you reference (which I read before), and from my examination of the
source code to see how the dialog correlation works that the only way it
could possibly work is through the use of a dialog correlate attribute
in the Route: header. That is why a call to loose_route() is necessary,
and that is why subsequent in-dialog requests do not get correlated
without it.
-- Alex
--
Alex Balashov
Evariste Systems
Web: http://www.evaristesys.com/
Tel: (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas <[EMAIL PROTECTED]> wrote: > On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov > <[EMAIL PROTECTED]> wrote: >>> Post your config and the trace of a bad call (ngrep + kamailio logs). >> >> Config: http://pastebin.com/f28051a5 >> >> My debug output: http://pastebin.com/d2f667520 (The profile size just keeps >> incrementing with every call that I make from 7709600101) >> >> Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b >> >> My debug output with loose routing: http://pastebin.com/d2b0fb533 >> >> Packet trace: http://pastebin.com/d77297606 > > Your config is bogus. You are not doing proper record-routing (you > commented out that section). > In-dialog requests are matched during record-route handling, > regardless of the dialog match mode. > The documentation is a little bit fuzzy about this, but here's the hint: http://kamailio.org/docs/modules/1.4.x/dialog#id2507978 http://kamailio.org/docs/modules/1.4.x/dialog#id2508031 This PV will be available only for sequential requests, after doing loose_route(). So it means that you must perform loose_route() if you want to catch in-dialog request and have a consistent dialog state. With your config, all the dialogs will just time out ... ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov <[EMAIL PROTECTED]> wrote: >> Post your config and the trace of a bad call (ngrep + kamailio logs). > > Config: http://pastebin.com/f28051a5 > > My debug output: http://pastebin.com/d2f667520 (The profile size just keeps > incrementing with every call that I make from 7709600101) > > Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b > > My debug output with loose routing: http://pastebin.com/d2b0fb533 > > Packet trace: http://pastebin.com/d77297606 Your config is bogus. You are not doing proper record-routing (you commented out that section). In-dialog requests are matched during record-route handling, regardless of the dialog match mode. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Client REGISTERED but "404-NOT FOUND" during INVITE
2008/10/16 Victor Pascual Ávila <[EMAIL PROTECTED]>: > In addition, "404 Not Found" is not the correct reponse when the > destination target is not registered, IMO it should be a 480 instead. Yeah!!! 404 should be returned when the proxy/UAS received a request and it's not responsible for it, for example a non existing user (non existing user != non registered user). When a user is not registered, but it does exist in the server, the server must reply "480". -- Iñaki Baz Castillo <[EMAIL PROTECTED]> ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Client REGISTERED but "404-NOT FOUND" during INVITE
On Wed, Oct 15, 2008 at 10:48 AM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote: > 2008/10/15 luzango mfupe <[EMAIL PROTECTED]>: >> >> >> Hi Mates, >> I am testing a Client in Nokia E65 using kamailio 1.3.3. I managed to >> successfull get it Registered but when i attempt to make a call i always get >> the "404 Not Found" message in the INVITE. Strangely enough, the Client >> appears to still be ONLINE in the location table. > > Your conclusion is wrong. A user doen't need to be registered in order > to make a PSTN call (except if you add that logic to your script, that > is not the case). > > So, forget yuor user is registered, it's doesn't matter, and debug why > your dialed number is not matched as a number to the PSTN. Iñaki is right here. In addition, "404 Not Found" is not the correct reponse when the destination target is not registered, IMO it should be a 480 instead. -- Victor Pascual Ávila ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] [OpenSIPS-Users] Problems installing serMyAdmin0.9 in OpenSER1.3.2
Did you update java to version 6? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nuno Marques Sent: Thursday, 16 October 2008 7:10 AM To: users@lists.kamailio.org; [EMAIL PROTECTED] Subject: [OpenSIPS-Users] Problems installing serMyAdmin0.9 in OpenSER1.3.2 Hi, I tried to install the new version of sermyadmin - 0.9 - and it gave me problems. Created a new openser database and notice that the sermyadmin didn't even made any changes to it. Tried with the old sermyadmin 0.7 and everything went well. I didn't made any changes to tomcat... or anything else. As anyone experienced the same problem? Does anyone knows where could i get sermyadmin0.8 to test it? Thanks in advance for any help on this Nuno ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
[Kamailio-Users] debian and solaris packages for kamailio and openser available
Hello all, thanks to Muhammad Akl, packages and binaries for the lastest stable release of openser on solaris 10 (on i386) are now available on www.kamailio.org in the download area [1, 2]. He also build packages for some older releases, like the previous 1.3 and 1.2 branch based releases. I added debian packages for the 1.3.3 release of openser and 1.4.1 release of kamailio for etch (on i386) as well [3, 4]. Packages of kamailio on solaris will be also appear soon there, they are still a few incompatibilites that needs to be sorted out that prevent the building. We're working on it.. If you want to contribute some packages for your favorite distribution or operating system, just contact me per mail or on the #kamailio IRC channel. Cheers, Henning [1] http://www.kamailio.org/pub/openser/1.3.3/bin/solaris/10/ [2] http://www.kamailio.org/pub/openser/1.3.3/packages/solaris/10/ [3] http://www.kamailio.org/pub/openser/1.3.3/packages/debian/etch/ [4] http://www.kamailio.org/pub/kamailio/1.4.1/packages/debian/etch/ -- Henning Westerholt - Development Consumer Products / DSL Core 1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe, Germany ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] 1.4.x Dialog module vs. :dlg_end_dlg: command
> local_route {
> if (is_method("BYE")) {
> acc_log_request("internal bye");
> append_hf("X-note: terminated by dialog module");
> }
> }
>
> This will produce log in syslog
>
> Oct 16 18:51:48 kamailio kamailio[3773]: ACC: request accounted:
> timestamp=1224183108;method=BYE;from_tag=qvoqi;to_tag=d5c2cecb-125b6;[EMAIL
> PROTECTED];co
> de=;reason=internal bye;from_uri=;to_uri=
>
> but it is not logged to the DB. Is it possible to log it into the DB?
> (as I understood the setflag in local_route does not work so this could
> be the problem for db accounting?)
>
I've tried without success acc_db_request("Internal BYE", "acc") from
local_route
Oct 16 19:37:04 kamailio kamailio[3937]: ERROR:core:db_use_table:
invalid parameter value
Oct 16 19:37:04 kamailio kamailio[3937]: ERROR:acc:acc_db_request: error
in use_table
when I use the same command outside local_route, acc_db_request works.
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] 1.4.x Dialog module vs. :dlg_end_dlg: command
Daniel-Constantin Mierla napsal(a):
>
>
> On 10/16/08 13:08, Martin Vít wrote:
>> I've tryed modparam("acc", "failed_transaction_flag", 4) and set the
>> flag in route{ }. I've debug msgs in every route branch but it seems
>> that the BYE sended by the dialog module does not traverse it.
>>
>> For make me sure I've checked some failed transactions (not sended by
>> dialog module) and it is logged properly.
> ok, I thought you have the system to get the answered BYEs, but not
> the ones that fail.
Yes, I'm testing various scenarios with mediaproxy 2.1 - disconecting
both endpoints (GW and Client) so no reply to BYE
> The messages initiated by openser, like hop-to-hop CANCEL, MESSAGE by
> msilo module or these BYEs are not going to the config, but if there
> is another proxy in the path, you could account there.
Unfortunatly there is no proxy. In my setup there will be only central
proxy, GWs and SIP endpoints.
>
> There are two options:
> - you insert the acc record from the application initiating the
> :dlg_end_dlg: command
Goog hint! :) but it would be fine to log it through kamailio functions
> - you compile kamailio with -DUSE_LOCAL_ROUTE and write a local_route
> in the config where you do accounting. Be careful that local_route may
> bring some unexpected behaviors if you use it with branches, time
> variable, a.s.o, but should be fine just for accounting
I've tryed it as described in
(http://lists.openser.org/pipermail/devel/2008-June/014035.html) (for
others: complete info about USE_LOCAL_ROUTE check
http://lists.kamailio.org/pipermail/users/2008-June/018272.html)
I've made new local_route routing, BYE is sended to this route but now I
cannot log the BYE into the DB:
local_route {
if (is_method("BYE")) {
acc_log_request("internal bye");
append_hf("X-note: terminated by dialog module");
}
}
This will produce log in syslog
Oct 16 18:51:48 kamailio kamailio[3773]: ACC: request accounted:
timestamp=1224183108;method=BYE;from_tag=qvoqi;to_tag=d5c2cecb-125b6;[EMAIL
PROTECTED];co
de=;reason=internal bye;from_uri=;to_uri=
but it is not logged to the DB. Is it possible to log it into the DB?
(as I understood the setflag in local_route does not work so this could
be the problem for db accounting?)
>
> Cheers,
> Daniel
>
>>
>> Daniel-Constantin Mierla napsal(a):
>>> Hello,
>>>
>>> acc module has the functionality of logging failed transactions:
>>>
>>> http://www.kamailio.org/docs/modules/1.4.x/acc.html#id2468153
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 10/16/08 11:46, Martin Vít wrote:
Hello,
i'm testing dialog module and trying to account died sessions. I've
problem or i've misunderstood the way how to account it. If I send
dlg_end_dlg, a dialog session is ended and BYE is sended to both
sides.
But if the BYE is not confirmed the acc module will never log this. Is
there any way to immidiatly log BYE asap dialog ends?
thanks for any suggestion
MV
>>>
>>
>
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Change FROM display name
Hello,
On 10/15/08 13:22, ALAEDDINE abbech wrote:
> Hi,
>
> I should change the actual display name in header From with an other
> name stored in avp(s:display) .
> I use uac_replace_from("$avp(s:display)","");, but this function add
> the new name in the end line of From.
> Exemple after tcpdump:
> i like change "aladin" with "11" but i have this line in
> INVITE request,
>
> From: aladin
> ;tag=64204a12d09be0c^M"111"
>
> Have you a solution for this pb.
> Thanks
>
>
are you doing other operations that alter the From header? Like changing
first the URI and then the display name?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] INVITE queue
Hello, On 10/15/08 17:33, sabino frisardi wrote: > > Hi all, > i'm tryng to enqueue invite messages in a queue and to make the > parsing of the invite after the enqueuing. not sure I understand what you want to achieve. Maybe you can explain a bit more. Note that when a SIP request is received, a large range of global variables are set to form the environment for that request, that is going to be used in many decisions for routing. If you just write the requests in a buffer and parse later, that could end in overlapping and unexpected actions. Cheers, Daniel > After the parsing i call tmb.t_relay(msg,0,0,0,0,0,0) from a module. > The rest of messages of the classic sip call pass trhough the main > route. So when i run openser it consume too much memory. > > Is there any error with the call to t_relay through the binding? > Is there any error on the transaction if i call the relay in a module > for INVITE message and in main route for NON_INVITE messages? > Why the consume of memory increase? > > Can anyone help me? > > Thanks for your help. > Regards > > > -- > Sabino Frisardi > > > ___ > Users mailing list > Users@lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > -- Daniel-Constantin Mierla http://www.asipto.com ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] 1.4.x Dialog module vs. :dlg_end_dlg: command
On 10/16/08 13:08, Martin Vít wrote:
> I've tryed modparam("acc", "failed_transaction_flag", 4) and set the
> flag in route{ }. I've debug msgs in every route branch but it seems
> that the BYE sended by the dialog module does not traverse it.
>
> For make me sure I've checked some failed transactions (not sended by
> dialog module) and it is logged properly.
ok, I thought you have the system to get the answered BYEs, but not the
ones that fail. The messages initiated by openser, like hop-to-hop
CANCEL, MESSAGE by msilo module or these BYEs are not going to the
config, but if there is another proxy in the path, you could account there.
There are two options:
- you insert the acc record from the application initiating the
:dlg_end_dlg: command
- you compile kamailio with -DUSE_LOCAL_ROUTE and write a local_route in
the config where you do accounting. Be careful that local_route may
bring some unexpected behaviors if you use it with branches, time
variable, a.s.o, but should be fine just for accounting
Cheers,
Daniel
>
> Daniel-Constantin Mierla napsal(a):
>> Hello,
>>
>> acc module has the functionality of logging failed transactions:
>>
>> http://www.kamailio.org/docs/modules/1.4.x/acc.html#id2468153
>>
>> Cheers,
>> Daniel
>>
>>
>> On 10/16/08 11:46, Martin Vít wrote:
>>> Hello,
>>>
>>> i'm testing dialog module and trying to account died sessions. I've
>>> problem or i've misunderstood the way how to account it. If I send
>>> dlg_end_dlg, a dialog session is ended and BYE is sended to both sides.
>>> But if the BYE is not confirmed the acc module will never log this. Is
>>> there any way to immidiatly log BYE asap dialog ends?
>>>
>>> thanks for any suggestion
>>>
>>> MV
>>>
>>
>
--
Daniel-Constantin Mierla
http://www.asipto.com
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] 1.4.x Dialog module vs. :dlg_end_dlg: command
I've tryed modparam("acc", "failed_transaction_flag", 4) and set the
flag in route{ }. I've debug msgs in every route branch but it seems
that the BYE sended by the dialog module does not traverse it.
For make me sure I've checked some failed transactions (not sended by
dialog module) and it is logged properly.
Daniel-Constantin Mierla napsal(a):
> Hello,
>
> acc module has the functionality of logging failed transactions:
>
> http://www.kamailio.org/docs/modules/1.4.x/acc.html#id2468153
>
> Cheers,
> Daniel
>
>
> On 10/16/08 11:46, Martin Vít wrote:
>> Hello,
>>
>> i'm testing dialog module and trying to account died sessions. I've
>> problem or i've misunderstood the way how to account it. If I send
>> dlg_end_dlg, a dialog session is ended and BYE is sended to both sides.
>> But if the BYE is not confirmed the acc module will never log this. Is
>> there any way to immidiatly log BYE asap dialog ends?
>>
>> thanks for any suggestion
>>
>> MV
>>
>
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Problems installing serMyAdmin0.9 in OpenSER1.3.2
Hi Muhammad, The only error that appears is when i tried to access http:// :8080/serMyAdmin/ Gives me an error 404 and says that the resource is not available... HTTP Status 404 - -- *type* Status report *message* *description* *The requested resource () is not available.* -- Apache Tomcat/6.0.18 I've run java -version and my result is: java version "1.5.0_14" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing) I think my problem is with the version of Java. Going to try to instal java 6. Thanks a lot Muhammad. Nuno 2008/10/16 muhammad akl <[EMAIL PROTECTED]> > > Hi Nuno , > > serMyAdmin-0.9 will work with any version of openser and/or kamailio , > > but alot of changes have been added to the NEW BETA version (0.9) and the > changes AFAIK are depending on java 6 could you please append the error that > appeared for you ? > > Regards > > Muhammad > ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] 1.4.x Dialog module vs. :dlg_end_dlg: command
Hello, acc module has the functionality of logging failed transactions: http://www.kamailio.org/docs/modules/1.4.x/acc.html#id2468153 Cheers, Daniel On 10/16/08 11:46, Martin Vít wrote: > Hello, > > i'm testing dialog module and trying to account died sessions. I've > problem or i've misunderstood the way how to account it. If I send > dlg_end_dlg, a dialog session is ended and BYE is sended to both sides. > But if the BYE is not confirmed the acc module will never log this. Is > there any way to immidiatly log BYE asap dialog ends? > > thanks for any suggestion > > MV > -- Daniel-Constantin Mierla http://www.asipto.com ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] Core dump on writing dialog profile size into script var.
Hello Alex, I found a bug in the dialog module, the profile size is integer and the variable was set as string value. Can you get the trunk and test? I will backport afterwards, thanks, Daniel On 10/16/08 08:04, Alex Balashov wrote: > It would seem that the malloc for the script var occasionally fails, > which may or may not be central to the issue: > > [SWITCH] Relaying BYE from 210.23.22.23 to sip:[EMAIL PROTECTED] > (DTAG=706 > [SWITCH] [D] No dialog affinity for this BYE > Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem! > Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set svar > [SWITCH] [D] Profile size for 7709600101 now: 0 > [ONREPLY-ROUTE 2] Received 200 for BYE > Relaying INVITE from 210.23.22.23 to sip:[EMAIL PROTECTED]:5060 > [D] Added new dialog for 7709600101 > [ONREPLY-ROUTE 1] Provisional reply 100 received. > [ONREPLY-ROUTE 1] 200 OK received for 7709600101 > [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 > [ONREPLY-ROUTE 1] Dialog profile size is: > > [SWITCH] Relaying ACK from 210.23.22.23 to sip:[EMAIL PROTECTED] > (DTAG=706 > [SWITCH] [D] No dialog affinity for this ACK > Segmentation fault (core dumped) > > > Alex Balashov wrote: > > >> I also have another interesting problem with the aforementioned >> configuration (http://pastebin.com/f28051a5). >> >> When I write the dialog profile size into an AVP, it works fine. >> >> When I write it into a script var, i.e. replace $avp(S:dlg_sz) with >> $var(dlg_sz), it crashes: >> >> Relaying INVITE from 210.23.22.23 to sip:[EMAIL PROTECTED]:5060 >> [D] Added new dialog for 7709600101 >> [ONREPLY-ROUTE 1] Provisional reply 100 received. >> [ONREPLY-ROUTE 1] 200 OK received for 7709600101 >> [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 >> Segmentation fault (core dumped) >> >> GDB reveals: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 >> (gdb) where >> #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 >> #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, >> flags=> at script_var.c:122 >> #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 >> "\034??\ >> value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 >> #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 >> #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at >> action.c:138 >> #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 >> #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at >> action.c:138 >> #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 >> #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 >> #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 >> #10 0x08090d5b in receive_msg ( >> buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP >> 215.22.22.22;branch=z9hG4 >> 08.52.173.18\r\nVia: SIP/2.0/UDP >> 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc >> p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 >> #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 >> #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693 >> >> It would seem to me that there is some sort of buffer overflow issue >> that results in the garbage seen above. >> >> Not sure that it makes a difference, but the glibc being linked against >> is a Xen-safe one that disables TLS functionality. This is all running >> inside a Xen DomU. >> >> > > > -- Daniel-Constantin Mierla http://www.asipto.com ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
[Kamailio-Users] 1.4.x Dialog module vs. :dlg_end_dlg: command
Hello, i'm testing dialog module and trying to account died sessions. I've problem or i've misunderstood the way how to account it. If I send dlg_end_dlg, a dialog session is ended and BYE is sended to both sides. But if the BYE is not confirmed the acc module will never log this. Is there any way to immidiatly log BYE asap dialog ends? thanks for any suggestion MV ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
[Kamailio-Users] 1.4.x Dialog module vs. :dlg_end_dlg: command
Hello, i'm testing dialog module and trying to account died sessions. I've problem or i've misunderstood the way how to account it. If I send dlg_end_dlg, a dialog session is ended and BYE is sended to both sides. But if the BYE is not confirmed the acc module will never log this. Is there any way to immidiatly log BYE asap dialog ends? thanks for any suggestion MV ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
