date:20120426

Re: [SR-Users] Kamailio Unexpectedly Terminating

2012-04-26 Thread Daniel-Constantin Mierla


Hello,

do you set the realm_prefix parameter of registrar module?

http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082

If yes, can you paste it here?

Cheers,
Daniel

On 4/25/12 9:42 PM, Akan wrote:
I have 2 servers running Solaris and Kamailio 3.2.3 where on one 
Kamailio is terminating when it tries to save the location for a 
register request and the other is producing a core dump when 
processing an Option request. I have one server handling Register 
request while the other sip server forwards the register requests and 
handles the other requests. I have included the backtraces from the 
core dumps and the output from the log for the registrar server as 
well as the command that is causing kamailio to terminate:


if (!save("location"))
sl_reply_error();

4(3364) ERROR: *** cfgtrace: 
c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if
 4(3364) ERROR: *** cfgtrace: 
c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save

14(3374) :  [pass_fd.c:293]: ERROR: receive_fd: EOF on 15
14(3374) DEBUG:  [tcp_main.c:3555]: DBG: handle_ser_child: dead 
child 4, pid 3364 (shutting down?)
14(3374) DEBUG:  [io_wait.h:617]: DBG: io_watch_del (1003743d8, 
15, 0, 0x0) fd_no=18 called
 0(3360) ALERT:  [main.c:751]: child process 3364 exited by a 
signal 10

 0(3360) ALERT:  [main.c:754]: core was not generated
 0(3360) INFO:  [main.c:766]: INFO: terminating due to SIGCHLD
 6(3366) INFO:  [main.c:817]: INFO: signal 15 received
 1(3361) INFO:  [main.c:817]: INFO: signal 15 received
 2(3362) INFO:  [main.c:817]: INFO: signal 15 received
 3(3363) INFO:  [main.c:817]: INFO: signal 15 received
 5(3365) INFO:  [main.c:817]: INFO: signal 15 received
 7(3367) INFO:  [main.c:817]: INFO: signal 15 received
 8(3368) INFO:  [main.c:817]: INFO: signal 15 received
 9(3369) INFO:  [main.c:817]: INFO: signal 15 received
10(3370) INFO:  [main.c:817]: INFO: signal 15 received
11(3371) INFO:  [main.c:817]: INFO: signal 15 received
12(3372) INFO:  [main.c:817]: INFO: signal 15 received
13(3373) INFO:  [main.c:817]: INFO: signal 15 received
14(3374) INFO:  [main.c:817]: INFO: signal 15 received
 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start
 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix 
socket /tmp/kamailio_ctl: Permission denied (13)

 0(3360) DEBUG:  [db_pool.c:102]: removing connection from the pool
 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: PQfinish(100842470)
 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: pkg_free(1004c1f30)
 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start
 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash 
table
 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing 
semaphores
 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying 
tmcb lists

 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done

Thanks

Nathaniel


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] OpenXcap always returns full resource list

2012-04-26 Thread Daniel-Constantin Mierla


Hello,

On 4/25/12 2:04 PM, Fabian Bernhard wrote:

Dear list,

we are running Kamailio 3.2 together with the included OpenXcap server.

by the "included openxcap" server do you mean the xcap_server module?

  * http://kamailio.org/docs/modules/stable/modules_k/xcap_server.html


I try to retrieve only part of a certain resource list using XPath, 
but the server always returns the full list, see example below. I was 
so far not able to retrieve only part of a resource list, independent 
of the XPath expression I'm using.


Do I make something wrong or is this a bug?


Can you try with the master branch (which is upcoming 3.3.0, development 
being frozen already and we are in testing phase for it)? Just to be 
sure it is not a feature we added afterwards - I cannot look right now 
in the sources.


Cheers,
Daniel



Thanks and regards,

Fabian


fubeh@orion:~$ curl --digest -u test4: 
http://192.168.1.134:5060/xcap-root/resource-lists/users/sip:test4@192.168.1.134/index/~~/resource-lists/list%5b@name=Family%5d 





mailto:sip%3Atest1@192.168.1.134>">
Test 1

mailto:sip%3Atest122@192.168.1.134>">

Test 1



mailto:sip%3Atest2@192.168.1.134>">
Test 2

mailto:sip%3Atest222@192.168.1.134>">

Test 2



mailto:sip%3Atest3@192.168.1.134>">
Test 3

mailto:sip%3Atest322@192.168.1.134>">

Test 3






___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] About MSRP relay

2012-04-26 Thread Daniel-Constantin Mierla


Hello,

msrp is a new module to be released in upcoming 3.3.0:

  * http://www.kamailio.org/wiki/features/new-in-devel

You have to use git master branch for now if you want to play with it, 
here are some instruction how to install it:


  * http://www.kamailio.org/wiki/install/devel/git

Cheers,
Daniel

On 4/23/12 7:13 AM, 罗俊明 wrote:


 Hello,

I want to setup a sip server that can support MRSP relay with 
Kamailio,but I do not find the module of msrp relay in kamailio release
version 3.2.3. I want to know which releases of Kamailio will embed 
MSRP relay, and when will the new version be released?


Expecting your reply, Thanks a lot.

Thanks!

Jim luo

- Original Message -
From:"Henning Westerholt" 
To: "罗俊明" 
Cc:"sr-users-ow...@lists.sip-router.org" 


Sent:Fri Apr 20 2012 16:50:34 GMT+0800 (China Standard Time)
Subject: Re: About MSRP relay
On Friday 20 April 2012, 罗俊明 wrote:
> hi everybody,
>
> I want to setup a sip server that can support MSRP relay with
> Kamailio, but I do not find the module of msrp relay in kamailio release
> version 3.2.3. I want to know which releases of Kamailio will embed MSRP
> relay, and when will the new version be released?
>
> Thanks!
> Jim Luo.

Hi 罗俊明,

please address questions like this to the user list at sr-us...@lists.sip-
router.org

Viele Grüße/ best regards,

Henning Westerholt

*
*






___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] generating cdrs

2012-04-26 Thread Pirjo Ahvenainen

Hi,

Thanks Timo, I think you've done excellent job, the problem was just
me using the wrong underlying database version. But all clarifications
help me and others I'm sure, thanks!

cheers,
Pirjo



26. huhtikuuta 2012 1.57 Timo Reimann  kirjoitti:
> Am 25.04.2012 um 21:00 schrieb Timo Reimann:
>> Am 23.04.2012 um 22:57 schrieb Pirjo Ahvenainen:
>>> No prob, and thanks for your comments, I'm suspecting I had installed
>>> a devel version on the system I was testing before installing 3.2.3
>>> and had used its db creation scripts. So what I will need to do is go
>>> back to testing the right version! ;) I installed a clean box with
>>> 3.2.3, no cdrs table vs. the one I had, I'll use that for devel
>>> version testing. Next job, I'll try it out with the devel version.
>>>
>>> So the cdr to db is on its way, the 3.2 documentation means saving
>>> only to syslog. Originally I associated this to the cdrs table I was
>>> staring at. I think I can call this myth busted!
>>
>> Admittedly, the docs could be a bit more clear on the fact that CDR 
>> generation doesn't involve database storage (yet). Being the original 
>> author, I'm the one to blame. :) I'll try to increase documentation accuracy 
>> of the acc module as soon as I can get to it.
>
> Done! (See commit caee2de.)
>
>
> HTH,
>
> --Timo
>
>
>
>>> 23. huhtikuuta 2012 18.15 Timo Reimann  kirjoitti:
 Hey Pirjo,

 sorry for the delay!


 Am 20.04.2012 um 20:05 schrieb Pirjo Ahvenainen:
> That would sort of make sense... Although, 'kamdbctl create' generates
> cdrs table along with all others, why have a table (+ 3.2
> documentation), with nothing to populate that table in code?

 I cannot find any instances of the word "cdr" in any file of the 
 util/kamctl and lib/ directories. Are you sure that there are CDR-related 
 tables being created with that script?

 With regards to the acc documentation, there's no mentioning of any 
 database storage as far as I can tell. I wrote the original piece of 
 documentation, so unless someone has extended the code base and updated 
 the docs there shouldn't be any reference (yet) to the feature you desire. 
 What the original CDR-generating implementation allowed you to do was to 
 create a syslog-based stream of CDRs similar to how transaction logging 
 works in the acc module. Pumping that CDR stream into a database had to be 
 done via an external process, however.


 Cheers,

 --Timo



> 20. huhtikuuta 2012 20.48 Timo Reimann  kirjoitti:
>> Hey Pirjo,
>>
>>
>> Am 20.04.2012 um 15:21 schrieb Pirjo Ahvenainen:
>>> Hi Karsten,
>>>
>>> Thanks for the tip, I do have that defined but no cdrs.
>>>
>>> cheers,
>>> Pirjo
>>
>> I haven't looked at the acc module in quite a while but to my knowledge, 
>> direct-to-DB storage of CDRs is still in the making. The second to last 
>> commit messages by Sven Knoblich (7b4567) mentions that the patch is 
>> "necessary for the upcoming db-storage of cdr's."
>>
>>
>> HTH,
>>
>> --Timo
>>
>>
>>
>>> 20. huhtikuuta 2012 16.15 Karsten Horsmann  
>>> kirjoitti:
 Hi Pirijo,

 try

 #!define WITH_ACCDB

 in your kamailio.cfg


 --
 Mit freundlichen Grüßen
 *Karsten Horsmann*

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> --
>>>
>>> --
>>> Pirjo Ahvenainen
>>> +35844 559 7729
>>>
>>> ___
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users@lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
>
> --
>
> --
> Pirjo Ahvenainen
> +35844 559 7729

>>>
>>>
>>>
>>> --
>>>
>>> --
>>> Pirjo Ahvenainen
>>> +35844 559 7729
>>
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>



-- 

--
Pirjo Ahvenainen
+35844 559 7729

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] dispatcher and call transfer

2012-04-26 Thread Asgaroth

Hi All,

Currently we are running kamailio in a loadbalanced fashion whereby calls
come in via the loadbalancers and distribute calls accross 2 media servers.
We have come accross and issue whereby call transfers may be distributed
accross two media servers and when the REFER message comes along to
transfer the call, in some cases (if we're lucky) the message arrives at
the wrong media server (transaction leg doesnt exist).

Some googling later and it appears that dispatcher doesnt play nice when it
comes to this scenario. Some suggestions popped up in my previous searches
saying that a potential work around is to use the dialog module to check if
a call is eastablished and then to send all calls to the same media server
based on the dialog already being established.

I'd appreciate some input from the guru's out there that have come accross
this same issue and, if possible, some suggestions on how to work around
the problem, does the dispatcher module have a hashing algorithm that can
be suited for this particular scenario?

Thanks in advance for any tips or sugestions.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dispatcher and call transfer

2012-04-26 Thread Carsten Bock

Hi,

if you look at the docs of the dispatcher module, you'll find this:

alg - the algorithm used to select the destination address. The
parameter can be an integer or a variable holding an interger.
- “0” - hash over callid
(http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492)

But probably you should look into record/loose_route for your setup.
Since REFER is normally an in-dialog request (belongs to another
voice-session), it should take the same route as the initial INVITE.
This is normally achieved by the record/loose-route mechanisms
described in RFC3261.
In the example config of Kamailio you find an configuration example (below).

It is not a bug in the dispatcher module, it's how you use it.

So long,
Carsten

 455 # handle requests within SIP dialogs
 456 route(WITHINDLG);

[...]

 473 # record routing for dialog forming requests (in case
they are routed)
 474 # - remove preloaded route headers
 475 remove_hf("Route");
 476 if (is_method("INVITE|SUBSCRIBE"))
 477 record_route();

and the relevent parts in the "WITHINDLG" route:

 566 # Handle requests within SIP dialogs
 567 route[WITHINDLG] {
 568 if (has_totag()) {
 569 # sequential request withing a dialog should
 570 # take the path determined by record-routing
 571 if (loose_route()) {
[...]
 580 route(RELAY);
 581 } else {
[...]
 587 if ( is_method("ACK") ) {
 588 if ( t_check_trans() ) {
 589 # no loose-route, but stateful ACK;
 590 # must be an ACK after a 487
 591 # or e.g. 404 from upstream server
 592 t_relay();
 593 exit;
 594 } else {
 595 # ACK without matching
transaction ... ignore and discard
 596 exit;
 597 }
 598 }
 599 sl_send_reply("404","Not here");
 600 }
 601 exit;
 602 }
 603 }

2012/4/26 Asgaroth <00asgarot...@gmail.com>:
> Hi All,
>
> Currently we are running kamailio in a loadbalanced fashion whereby calls
> come in via the loadbalancers and distribute calls accross 2 media servers.
> We have come accross and issue whereby call transfers may be distributed
> accross two media servers and when the REFER message comes along to transfer
> the call, in some cases (if we're lucky) the message arrives at the wrong
> media server (transaction leg doesnt exist).
>
> Some googling later and it appears that dispatcher doesnt play nice when it
> comes to this scenario. Some suggestions popped up in my previous searches
> saying that a potential work around is to use the dialog module to check if
> a call is eastablished and then to send all calls to the same media server
> based on the dialog already being established.
>
> I'd appreciate some input from the guru's out there that have come accross
> this same issue and, if possible, some suggestions on how to work around the
> problem, does the dispatcher module have a hashing algorithm that can be
> suited for this particular scenario?
>
> Thanks in advance for any tips or sugestions.
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
Carsten Bock
CEO (Geschäftsführer)

ng-voice GmbH
Schomburgstr. 80
D-22767 Hamburg / Germany

http://www.ng-voice.com
mailto:cars...@ng-voice.com

Mobile +49 179 2021244
Office +49 40 34927219
Fax +49 40 34927220

Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284

Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/

-- 
Meet ng-voice at LinuxTag 2012 in Berlin - May 23rd - 26th, 2012. Save the 
date!

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dispatcher and call transfer

2012-04-26 Thread Charles Chance

Hi,

Actually, this won't help for attended transfers where another call is
initiated first then the two are joined together by REFER. In this case, the
second INVITE must be routed to the same media server as the existing call
for the transfer to work.

What we do is store the dialogs in DB, then when a new call comes in, prior
to doing ds_select_dst we query DB for existing call involving same user. If
we find one, we simply replace destination host with that from the contact
(to/from depending on direction of call).

It may not be the most elegant way but it works for us :)

Charles


-Original Message-
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Carsten Bock
Sent: 26 April 2012 13:25
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Subject: Re: [SR-Users] dispatcher and call transfer

Hi,

if you look at the docs of the dispatcher module, you'll find this:

alg - the algorithm used to select the destination address. The
parameter can be an integer or a variable holding an interger.
- 0 - hash over callid
(http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492)

But probably you should look into record/loose_route for your setup.
Since REFER is normally an in-dialog request (belongs to another
voice-session), it should take the same route as the initial INVITE.
This is normally achieved by the record/loose-route mechanisms
described in RFC3261.
In the example config of Kamailio you find an configuration example (below).

It is not a bug in the dispatcher module, it's how you use it.

So long,
Carsten

 455 # handle requests within SIP dialogs
 456 route(WITHINDLG);

[...]

 473 # record routing for dialog forming requests (in case
they are routed)
 474 # - remove preloaded route headers
 475 remove_hf("Route");
 476 if (is_method("INVITE|SUBSCRIBE"))
 477 record_route();

and the relevent parts in the "WITHINDLG" route:

 566 # Handle requests within SIP dialogs
 567 route[WITHINDLG] {
 568 if (has_totag()) {
 569 # sequential request withing a dialog should
 570 # take the path determined by record-routing
 571 if (loose_route()) {
[...]
 580 route(RELAY);
 581 } else {
[...]
 587 if ( is_method("ACK") ) {
 588 if ( t_check_trans() ) {
 589 # no loose-route, but stateful
ACK;
 590 # must be an ACK after a 487
 591 # or e.g. 404 from upstream
server
 592 t_relay();
 593 exit;
 594 } else {
 595 # ACK without matching
transaction ... ignore and discard
 596 exit;
 597 }
 598 }
 599 sl_send_reply("404","Not here");
 600 }
 601 exit;
 602 }
 603 }

2012/4/26 Asgaroth <00asgarot...@gmail.com>:
> Hi All,
>
> Currently we are running kamailio in a loadbalanced fashion whereby calls
> come in via the loadbalancers and distribute calls accross 2 media
servers.
> We have come accross and issue whereby call transfers may be distributed
> accross two media servers and when the REFER message comes along to
transfer
> the call, in some cases (if we're lucky) the message arrives at the wrong
> media server (transaction leg doesnt exist).
>
> Some googling later and it appears that dispatcher doesnt play nice when
it
> comes to this scenario. Some suggestions popped up in my previous searches
> saying that a potential work around is to use the dialog module to check
if
> a call is eastablished and then to send all calls to the same media server
> based on the dialog already being established.
>
> I'd appreciate some input from the guru's out there that have come accross
> this same issue and, if possible, some suggestions on how to work around
the
> problem, does the dispatcher module have a hashing algorithm that can be
> suited for this particular scenario?
>
> Thanks in advance for any tips or sugestions.
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
Carsten Bock
CEO (Geschäftsführer)

ng-voice GmbH
Schomburgstr. 80
D-22767 Hamburg / Germany

http://www.ng-voice.com
mailto:cars...@ng-voice.com

Mobile +49 179 2021244
Office +49 40 34927219
Fax +49 40 34927220

Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID

Re: [SR-Users] dispatcher and call transfer

2012-04-26 Thread Reda Aouad

Hi,

@Carsten
Dispatcher algorithm 0 based on call-id should do it in your case of
re-invite within dialog with same call-id.

@Charles
In the case of attended transfers, shouldn't both media servers be relaying
media between them? I didn't understand why your are obliged to dispatch to
the same media server since they are 2 different calls with different
call-ids.

Reda



On Thu, Apr 26, 2012 at 14:30, Charles Chance  wrote:

> Hi,
>
> Actually, this won't help for attended transfers where another call is
> initiated first then the two are joined together by REFER. In this case,
> the
> second INVITE must be routed to the same media server as the existing call
> for the transfer to work.
>
> What we do is store the dialogs in DB, then when a new call comes in, prior
> to doing ds_select_dst we query DB for existing call involving same user.
> If
> we find one, we simply replace destination host with that from the contact
> (to/from depending on direction of call).
>
> It may not be the most elegant way but it works for us :)
>
> Charles
>
>
> -Original Message-
> From: sr-users-boun...@lists.sip-router.org
> [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Carsten Bock
> Sent: 26 April 2012 13:25
> To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> UsersMailing List
> Subject: Re: [SR-Users] dispatcher and call transfer
>
> Hi,
>
> if you look at the docs of the dispatcher module, you'll find this:
>
> alg - the algorithm used to select the destination address. The
> parameter can be an integer or a variable holding an interger.
> - “0” - hash over callid
> (
> http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492
> )
>
> But probably you should look into record/loose_route for your setup.
> Since REFER is normally an in-dialog request (belongs to another
> voice-session), it should take the same route as the initial INVITE.
> This is normally achieved by the record/loose-route mechanisms
> described in RFC3261.
> In the example config of Kamailio you find an configuration example
> (below).
>
> It is not a bug in the dispatcher module, it's how you use it.
>
> So long,
> Carsten
>
>  455 # handle requests within SIP dialogs
>  456 route(WITHINDLG);
>
> [...]
>
>  473 # record routing for dialog forming requests (in case
> they are routed)
>  474 # - remove preloaded route headers
>  475 remove_hf("Route");
>  476 if (is_method("INVITE|SUBSCRIBE"))
>  477 record_route();
>
> and the relevent parts in the "WITHINDLG" route:
>
>  566 # Handle requests within SIP dialogs
>  567 route[WITHINDLG] {
>  568 if (has_totag()) {
>  569 # sequential request withing a dialog should
>  570 # take the path determined by record-routing
>  571 if (loose_route()) {
> [...]
>  580 route(RELAY);
>  581 } else {
> [...]
>  587 if ( is_method("ACK") ) {
>  588 if ( t_check_trans() ) {
>  589 # no loose-route, but stateful
> ACK;
>  590 # must be an ACK after a 487
>  591 # or e.g. 404 from upstream
> server
>  592 t_relay();
>  593 exit;
>  594 } else {
>  595 # ACK without matching
> transaction ... ignore and discard
>  596 exit;
>  597 }
>  598 }
>  599 sl_send_reply("404","Not here");
>  600 }
>  601 exit;
>  602 }
>  603 }
>
> 2012/4/26 Asgaroth <00asgarot...@gmail.com>:
> > Hi All,
> >
> > Currently we are running kamailio in a loadbalanced fashion whereby calls
> > come in via the loadbalancers and distribute calls accross 2 media
> servers.
> > We have come accross and issue whereby call transfers may be distributed
> > accross two media servers and when the REFER message comes along to
> transfer
> > the call, in some cases (if we're lucky) the message arrives at the wrong
> > media server (transaction leg doesnt exist).
> >
> > Some googling later and it appears that dispatcher doesnt play nice when
> it
> > comes to this scenario. Some suggestions popped up in my previous
> searches
> > saying that a potential work around is to use the dialog module to check
> if
> > a call is eastablished and then to send all calls to the same media
> server
> > based on the dialog already being established.
> >
> > I'd appreciate some input from the guru's out there that have come
> accross
> > this same issue and, if possible, some suggestions on how to work around
> the
> > problem, does the dispatcher module have a hashing algorithm

Re: [SR-Users] dispatcher and call transfer

2012-04-26 Thread Charles Chance

Hi Reda,

Sorry, I should have been more specific  I am referring to instances where
the media server is for example Asterisk. If first call goes through
Asterisk 1, second call goes through Asterisk 2, when Asterisk 2 receives
the REFER it does not know of initial call on Asterisk 1. The only way we
have found for it to work is to ensure the second call is dispatched to the
same Asterisk box as the first.

I would be pleased to hear of an alternative method.

Regards,

Charles

  _  

From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Reda Aouad
Sent: 26 April 2012 14:34
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Subject: Re: [SR-Users] dispatcher and call transfer

Hi,

@Carsten
Dispatcher algorithm 0 based on call-id should do it in your case of
re-invite within dialog with same call-id.

@Charles
In the case of attended transfers, shouldn't both media servers be relaying
media between them? I didn't understand why your are obliged to dispatch to
the same media server since they are 2 different calls with different
call-ids.

Reda

On Thu, Apr 26, 2012 at 14:30, Charles Chance
 wrote:

Hi,

Actually, this won't help for attended transfers where another call is
initiated first then the two are joined together by REFER. In this case, the
second INVITE must be routed to the same media server as the existing call
for the transfer to work.

What we do is store the dialogs in DB, then when a new call comes in, prior
to doing ds_select_dst we query DB for existing call involving same user. If
we find one, we simply replace destination host with that from the contact
(to/from depending on direction of call).

It may not be the most elegant way but it works for us :)

Charles

-Original Message-
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Carsten Bock
Sent: 26 April 2012 13:25
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Subject: Re: [SR-Users] dispatcher and call transfer

Hi,

if you look at the docs of the dispatcher module, you'll find this:

alg - the algorithm used to select the destination address. The
parameter can be an integer or a variable holding an interger.
- 0 - hash over callid
(http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492)

But probably you should look into record/loose_route for your setup.
Since REFER is normally an in-dialog request (belongs to another
voice-session), it should take the same route as the initial INVITE.
This is normally achieved by the record/loose-route mechanisms
described in RFC3261.
In the example config of Kamailio you find an configuration example (below).

It is not a bug in the dispatcher module, it's how you use it.

So long,
Carsten

 455 # handle requests within SIP dialogs
 456 route(WITHINDLG);

[...]

 473 # record routing for dialog forming requests (in case
they are routed)
 474 # - remove preloaded route headers
 475 remove_hf("Route");
 476 if (is_method("INVITE|SUBSCRIBE"))
 477 record_route();

and the relevent parts in the "WITHINDLG" route:

 566 # Handle requests within SIP dialogs
 567 route[WITHINDLG] {
 568 if (has_totag()) {
 569 # sequential request withing a dialog should
 570 # take the path determined by record-routing
 571 if (loose_route()) {
[...]
 580 route(RELAY);
 581 } else {
[...]
 587 if ( is_method("ACK") ) {
 588 if ( t_check_trans() ) {
 589 # no loose-route, but stateful
ACK;
 590 # must be an ACK after a 487
 591 # or e.g. 404 from upstream
server
 592 t_relay();
 593 exit;
 594 } else {
 595 # ACK without matching
transaction ... ignore and discard
 596 exit;
 597 }
 598 }
 599 sl_send_reply("404","Not here");
 600 }
 601 exit;
 602 }
 603 }

2012/4/26 Asgaroth <00asgarot...@gmail.com>:
> Hi All,
>
> Currently we are running kamailio in a loadbalanced fashion whereby calls
> come in via the loadbalancers and distribute calls accross 2 media
servers.
> We have come accross and issue whereby call transfers may be distributed
> accross two media servers and when the REFER message comes along to
transfer
> the call, in some cases (if we're lucky) the message arrives at the wrong
> media server (transaction leg doesnt exist).
>
> Some goog

[SR-Users] Copy reason field from 503 to 500.

2012-04-26 Thread Vitaliy Aleksandrov


Hi all,

I have Kamailio connected to PSTN gateway.

Sometimes gateway replies with "503 temporary unavailable". PSTN gateway 
adds a "reason" header with ISUP code.
But according to RFC 3261 kamailio doesn't forward 503 replies 
transparently. When 503 reply is received Kamailio replaces 503 with a 
500 which is created from original request (build_res_buf_from_sip_req).
I have tried append_hf from textops module, but it's not working with a 
locally generated replies.


How can i copy Reason header from 503 to 500 ?


I will appreciate your help with this situation.

Best regards,
Vitaliy Aleksandrov.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Copy reason field from 503 to 500.

2012-04-26 Thread Reda Aouad

Hi,

In which route did you try append_hf ?
"event_route[tm:local-request]" is the route executed for locally generated
requests, I think you should be trying to modify it there.

Reda



On Thu, Apr 26, 2012 at 16:10, Vitaliy Aleksandrov
wrote:

> Hi all,
>
> I have Kamailio connected to PSTN gateway.
>
> Sometimes gateway replies with "503 temporary unavailable". PSTN gateway
> adds a "reason" header with ISUP code.
> But according to RFC 3261 kamailio doesn't forward 503 replies
> transparently. When 503 reply is received Kamailio replaces 503 with a 500
> which is created from original request (build_res_buf_from_sip_req).
> I have tried append_hf from textops module, but it's not working with a
> locally generated replies.
>
> How can i copy Reason header from 503 to 500 ?
>
>
> I will appreciate your help with this situation.
>
> Best regards,
>Vitaliy Aleksandrov.
>
>
> __**_
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dispatcher and call transfer

2012-04-26 Thread Reda Aouad

Asterisk is not really a media relay. Asterisk establishes 2 legs for each
call, and I'm not sure what happens in this case.

An improvement you can make is to use a hash table (in-memory) to store the
information you need (call-id, from, to) then lookup in
the htable for existing calls for same users. That should relieve your
database from a query on every invite and increase performance if you have
a large number of calls.

Reda



On Thu, Apr 26, 2012 at 15:52, Charles Chance  wrote:

> ** ** ** **
>
> Hi Reda,
>
> ** **
>
> Sorry, I should have been more specific – I am referring to instances
> where the media server is for example Asterisk. If first call goes through
> Asterisk 1, second call goes through Asterisk 2, when Asterisk 2 receives
> the REFER it does not know of initial call on Asterisk 1. The only way we
> have found for it to work is to ensure the second call is dispatched to the
> same Asterisk box as the first.
>
> ** **
>
> I would be pleased to hear of an alternative method.
>
> ** **
>
> Regards,
>
> ** **
>
> Charles
>  --
>
> *From:* sr-users-boun...@lists.sip-router.org [mailto:
> sr-users-boun...@lists.sip-router.org] *On Behalf Of *Reda Aouad
> *Sent:* 26 April 2012 14:34
>
> *To:* **SIP Router - Kamailio** (OpenSER) and SIP Express Router (SER) -
> UsersMailing List
> *Subject:* Re: [SR-Users] dispatcher and call transfer
> 
>
>  ** **
>
> Hi,
>
> @Carsten
> Dispatcher algorithm 0 based on call-id should do it in your case of
> re-invite within dialog with same call-id.
>
> @Charles
> In the case of attended transfers, shouldn't both media servers be
> relaying media between them? I didn't understand why your are obliged to
> dispatch to the same media server since they are 2 different calls with
> different call-ids.
>
> ** **
>
> Reda
>
> ** **
>
> ** **
>
> On Thu, Apr 26, 2012 at 14:30, Charles Chance <
> charles.cha...@sipcentric.com> wrote:
>
> Hi,
>
> Actually, this won't help for attended transfers where another call is
> initiated first then the two are joined together by REFER. In this case,
> the
> second INVITE must be routed to the same media server as the existing call
> for the transfer to work.
>
> What we do is store the dialogs in DB, then when a new call comes in, prior
> to doing ds_select_dst we query DB for existing call involving same user.
> If
> we find one, we simply replace destination host with that from the contact
> (to/from depending on direction of call).
>
> It may not be the most elegant way but it works for us :)
>
> Charles
>
>
>
> -Original Message-
> From: sr-users-boun...@lists.sip-router.org
> [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Carsten Bock
> Sent: 26 April 2012 13:25
> To: **SIP Router - Kamailio** (OpenSER) and SIP Express Router (SER) -
> UsersMailing List
> Subject: Re: [SR-Users] dispatcher and call transfer
>
> Hi,
>
> if you look at the docs of the dispatcher module, you'll find this:
>
> alg - the algorithm used to select the destination address. The
> parameter can be an integer or a variable holding an interger.
> - “0” - hash over callid
> (
> http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492
> )
>
> But probably you should look into record/loose_route for your setup.
> Since REFER is normally an in-dialog request (belongs to another
> voice-session), it should take the same route as the initial INVITE.
> This is normally achieved by the record/loose-route mechanisms
> described in RFC3261.
> In the example config of Kamailio you find an configuration example
> (below).
>
> It is not a bug in the dispatcher module, it's how you use it.
>
> So long,
> Carsten
>
>  455 # handle requests within SIP dialogs
>  456 route(WITHINDLG);
>
> [...]
>
>  473 # record routing for dialog forming requests (in case
> they are routed)
>  474 # - remove preloaded route headers
>  475 remove_hf("Route");
>  476 if (is_method("INVITE|SUBSCRIBE"))
>  477 record_route();
>
> and the relevent parts in the "WITHINDLG" route:
>
>  566 # Handle requests within SIP dialogs
>  567 route[WITHINDLG] {
>  568 if (has_totag()) {
>  569 # sequential request withing a dialog should
>  570 # take the path determined by record-routing
>  571 if (loose_route()) {
> [...]
>  580 route(RELAY);
>  581 } else {
> [...]
>  587 if ( is_method("ACK") ) {
>  588 if ( t_check_trans() ) {
>  589 # no loose-route, but stateful
> ACK;
>  590 # must be an ACK after a 487
>  591 # or e.g. 404 from upstream
> server
>  592 t_relay();
>  593 exit;

Re: [SR-Users] About MSRP relay

2012-04-26 Thread Ozren Lapcevic

Hi Daniel, Jim,

can you guys please recommend some good SIP clients for testing the new
MSRP feature? Thanks!

Cheers
Ozren


On Thu, Apr 26, 2012 at 10:53 AM, Daniel-Constantin Mierla <
mico...@gmail.com> wrote:

>  Hello,
>
> msrp is a new module to be released in upcoming 3.3.0:
>
>   * http://www.kamailio.org/wiki/features/new-in-devel
>
> You have to use git master branch for now if you want to play with it,
> here are some instruction how to install it:
>
>   * http://www.kamailio.org/wiki/install/devel/git
>
> Cheers,
> Daniel
>
>
> On 4/23/12 7:13 AM, 罗俊明 wrote:
>
>  Hello,
>
> I want to setup a sip server that can support MRSP relay with Kamailio,but
> I do not find the module of msrp relay in kamailio release
> version 3.2.3. I want to know which releases of Kamailio will embed MSRP
> relay, and when will the new version be released?
>
> Expecting your reply, Thanks a lot.
>
> Thanks!
>
> Jim luo
>
>
> - Original Message -
> From:"Henning Westerholt" 
> 
> To: "罗俊明"  
> Cc:"sr-users-ow...@lists.sip-router.org"
> 
> Sent:Fri Apr 20 2012 16:50:34 GMT+0800 (China Standard Time)
> Subject: Re: About MSRP relay
>  On Friday 20 April 2012, 罗俊明 wrote:
> > hi everybody,
> >
> > I want to setup a sip server that can support MSRP relay with
> > Kamailio, but I do not find the module of msrp relay in kamailio release
> > version 3.2.3. I want to know which releases of Kamailio will embed MSRP
> > relay, and when will the new version be released?
> >
> > Thanks!
> > Jim Luo.
>
> Hi 罗俊明,
>
> please address questions like this to the user list at sr-us...@lists.sip-
> router.org
>
> Viele Grüße/ best regards,
>
> Henning Westerholt
>
> *
> *
>
>
>
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda 
> - http://www.linkedin.com/in/miconda
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dispatcher and call transfer

2012-04-26 Thread Charles Chance

Yes, I realise Asterisk is not a media relay, but I dont think the OP is
using a pure media relay, otherwise the REFER message would not be sent to
it, would it?

 

Thank you for the hash table suggestion by the way.

 

Charles

 

  _  

From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Reda Aouad
Sent: 26 April 2012 15:15
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Subject: Re: [SR-Users] dispatcher and call transfer

 

Asterisk is not really a media relay. Asterisk establishes 2 legs for each
call, and I'm not sure what happens in this case.

An improvement you can make is to use a hash table (in-memory) to store the
information you need (call-id, from, to) then lookup in 
the htable for existing calls for same users. That should relieve your
database from a query on every invite and increase performance if you have a
large number of calls.


 

Reda

 

 

On Thu, Apr 26, 2012 at 15:52, Charles Chance
 wrote:

Hi Reda,

 

Sorry, I should have been more specific  I am referring to instances where
the media server is for example Asterisk. If first call goes through
Asterisk 1, second call goes through Asterisk 2, when Asterisk 2 receives
the REFER it does not know of initial call on Asterisk 1. The only way we
have found for it to work is to ensure the second call is dispatched to the
same Asterisk box as the first.

 

I would be pleased to hear of an alternative method.

 

Regards,

 

Charles

  _  

From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Reda Aouad
Sent: 26 April 2012 14:34


To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Subject: Re: [SR-Users] dispatcher and call transfer

 

Hi,

@Carsten
Dispatcher algorithm 0 based on call-id should do it in your case of
re-invite within dialog with same call-id.

@Charles
In the case of attended transfers, shouldn't both media servers be relaying
media between them? I didn't understand why your are obliged to dispatch to
the same media server since they are 2 different calls with different
call-ids.

 

Reda

 

 

On Thu, Apr 26, 2012 at 14:30, Charles Chance
 wrote:

Hi,

Actually, this won't help for attended transfers where another call is
initiated first then the two are joined together by REFER. In this case, the
second INVITE must be routed to the same media server as the existing call
for the transfer to work.

What we do is store the dialogs in DB, then when a new call comes in, prior
to doing ds_select_dst we query DB for existing call involving same user. If
we find one, we simply replace destination host with that from the contact
(to/from depending on direction of call).

It may not be the most elegant way but it works for us :)

Charles



-Original Message-
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Carsten Bock
Sent: 26 April 2012 13:25
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Subject: Re: [SR-Users] dispatcher and call transfer

Hi,

if you look at the docs of the dispatcher module, you'll find this:

alg - the algorithm used to select the destination address. The
parameter can be an integer or a variable holding an interger.
- 0 - hash over callid
(http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492)

But probably you should look into record/loose_route for your setup.
Since REFER is normally an in-dialog request (belongs to another
voice-session), it should take the same route as the initial INVITE.
This is normally achieved by the record/loose-route mechanisms
described in RFC3261.
In the example config of Kamailio you find an configuration example (below).

It is not a bug in the dispatcher module, it's how you use it.

So long,
Carsten

 455 # handle requests within SIP dialogs
 456 route(WITHINDLG);

[...]

 473 # record routing for dialog forming requests (in case
they are routed)
 474 # - remove preloaded route headers
 475 remove_hf("Route");
 476 if (is_method("INVITE|SUBSCRIBE"))
 477 record_route();

and the relevent parts in the "WITHINDLG" route:

 566 # Handle requests within SIP dialogs
 567 route[WITHINDLG] {
 568 if (has_totag()) {
 569 # sequential request withing a dialog should
 570 # take the path determined by record-routing
 571 if (loose_route()) {
[...]
 580 route(RELAY);
 581 } else {
[...]
 587 if ( is_method("ACK") ) {
 588 if ( t_check_trans() ) {
 589 # no loose-route, but stateful
ACK;
 590 # must be an ACK after a 487
 591 # or e.g. 404 f

Re: [SR-Users] Copy reason field from 503 to 500.

2012-04-26 Thread Vitaliy Aleksandrov


I have tried to use "append_hf" in onreply_route.
How can i use it in local-request ? According to documentation it can be 
used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.


Sorry forgot to mention that kamailio version is 3.0.2, but i have 
looked at t_repy.c (tm module from 3.2) and didn't find any changes 
which can help me.



Hi,

In which route did you try append_hf ?
"event_route[tm:local-request]" is the route executed for locally 
generated requests, I think you should be trying to modify it there.


Reda



On Thu, Apr 26, 2012 at 16:10, Vitaliy Aleksandrov 
mailto:vitalik.v...@gmail.com>> wrote:


Hi all,

I have Kamailio connected to PSTN gateway.

Sometimes gateway replies with "503 temporary unavailable". PSTN
gateway adds a "reason" header with ISUP code.
But according to RFC 3261  kamailio doesn't forward 503
replies transparently. When 503 reply is received Kamailio
replaces 503 with a 500 which is created from original request
(build_res_buf_from_sip_req).
I have tried append_hf from textops module, but it's not working
with a locally generated replies.

How can i copy Reason header from 503 to 500 ?


I will appreciate your help with this situation.

Best regards,
   Vitaliy Aleksandrov.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org 
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Copy reason field from 503 to 500.

2012-04-26 Thread Reda Aouad

Well 5xx error codes are processed in failure_route and not onreply_route.
Not sure though if you can append_hf there.. Give it a try.

FYI, for using a function in event_route (seems not possible for append_hf):

event_route[tm:local-request] {
  ...
  append_hf(...);
  ...
}

Reda

On 26 avr. 2012, at 18:10, Vitaliy Aleksandrov 
wrote:

 I have tried to use "append_hf" in onreply_route.
How can i use it in local-request ? According to documentation it can be
used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.

Sorry forgot to mention that kamailio version is 3.0.2, but i have looked
at t_repy.c (tm module from 3.2) and didn't find any changes which can help
me.

 Hi,

In which route did you try append_hf ?
"event_route[tm:local-request]" is the route executed for locally generated
requests, I think you should be trying to modify it there.

 Reda

On Thu, Apr 26, 2012 at 16:10, Vitaliy Aleksandrov
wrote:

> Hi all,
>
> I have Kamailio connected to PSTN gateway.
>
> Sometimes gateway replies with "503 temporary unavailable". PSTN gateway
> adds a "reason" header with ISUP code.
> But according to RFC 3261 kamailio doesn't forward 503 replies
> transparently. When 503 reply is received Kamailio replaces 503 with a 500
> which is created from original request (build_res_buf_from_sip_req).
> I have tried append_hf from textops module, but it's not working with a
> locally generated replies.
>
> How can i copy Reason header from 503 to 500 ?
>
>
> I will appreciate your help with this situation.
>
> Best regards,
>Vitaliy Aleksandrov.
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio Unexpectedly Terminating

2012-04-26 Thread Akan


No, but I do have an alias defined.

alias="mydomain.com:5080"

Thanks

Nathaniel

On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote:

Hello,

do you set the realm_prefix parameter of registrar module?

http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082

If yes, can you paste it here?

Cheers,
Daniel

On 4/25/12 9:42 PM, Akan wrote:
I have 2 servers running Solaris and Kamailio 3.2.3 where on one 
Kamailio is terminating when it tries to save the location for a 
register request and the other is producing a core dump when 
processing an Option request. I have one server handling Register 
request while the other sip server forwards the register requests and 
handles the other requests. I have included the backtraces from the 
core dumps and the output from the log for the registrar server as 
well as the command that is causing kamailio to terminate:


if (!save("location"))
sl_reply_error();

4(3364) ERROR: *** cfgtrace: 
c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if
 4(3364) ERROR: *** cfgtrace: 
c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save

14(3374) :  [pass_fd.c:293]: ERROR: receive_fd: EOF on 15
14(3374) DEBUG:  [tcp_main.c:3555]: DBG: handle_ser_child: dead 
child 4, pid 3364 (shutting down?)
14(3374) DEBUG:  [io_wait.h:617]: DBG: io_watch_del (1003743d8, 
15, 0, 0x0) fd_no=18 called
 0(3360) ALERT:  [main.c:751]: child process 3364 exited by a 
signal 10

 0(3360) ALERT:  [main.c:754]: core was not generated
 0(3360) INFO:  [main.c:766]: INFO: terminating due to SIGCHLD
 6(3366) INFO:  [main.c:817]: INFO: signal 15 received
 1(3361) INFO:  [main.c:817]: INFO: signal 15 received
 2(3362) INFO:  [main.c:817]: INFO: signal 15 received
 3(3363) INFO:  [main.c:817]: INFO: signal 15 received
 5(3365) INFO:  [main.c:817]: INFO: signal 15 received
 7(3367) INFO:  [main.c:817]: INFO: signal 15 received
 8(3368) INFO:  [main.c:817]: INFO: signal 15 received
 9(3369) INFO:  [main.c:817]: INFO: signal 15 received
10(3370) INFO:  [main.c:817]: INFO: signal 15 received
11(3371) INFO:  [main.c:817]: INFO: signal 15 received
12(3372) INFO:  [main.c:817]: INFO: signal 15 received
13(3373) INFO:  [main.c:817]: INFO: signal 15 received
14(3374) INFO:  [main.c:817]: INFO: signal 15 received
 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start
 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix 
socket /tmp/kamailio_ctl: Permission denied (13)
 0(3360) DEBUG:  [db_pool.c:102]: removing connection from the 
pool

 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: PQfinish(100842470)
 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: pkg_free(1004c1f30)
 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start
 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying 
hash table
 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing 
semaphores
 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying 
tmcb lists

 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done

Thanks

Nathaniel


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda

No virus found in this message.
Checked by AVG - www.avg.com 
Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12



___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Gentoo ebuild v3.2.3

2012-04-26 Thread caio

Good afternoon,

It's ready the Gentoo ebuild for 3.2.3.

You can get it from the Git repository or from the Gentoo Portage overlays:

http://goo.gl/35uFX
http://goo.gl/fmFIU

Best regards,
Caio
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio Unexpectedly Terminating

Re: [SR-Users] OpenXcap always returns full resource list

Re: [SR-Users] About MSRP relay

Re: [SR-Users] generating cdrs

[SR-Users] dispatcher and call transfer

Re: [SR-Users] dispatcher and call transfer

Re: [SR-Users] dispatcher and call transfer

Re: [SR-Users] dispatcher and call transfer

Re: [SR-Users] dispatcher and call transfer

[SR-Users] Copy reason field from 503 to 500.

Re: [SR-Users] Copy reason field from 503 to 500.

Re: [SR-Users] dispatcher and call transfer

Re: [SR-Users] About MSRP relay

Re: [SR-Users] dispatcher and call transfer

Re: [SR-Users] Copy reason field from 503 to 500.

Re: [SR-Users] Copy reason field from 503 to 500.

Re: [SR-Users] Kamailio Unexpectedly Terminating

[SR-Users] Gentoo ebuild v3.2.3

18 matches

Site Navigation

Mail list logo

Footer information