- sr-users - kamailio.org

OpenXcap always returns full resource list
by Fabian Bernhard 01 May '12

01 May '12

Dear list, we are running Kamailio 3.2 together with the included OpenXcap server. 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? Thanks and regards, Fabian fubeh@orion:~$ curl --digest -u test4:XXXX http://192.168.1.134:5060/xcap-root/resource-lists/users/sip:test4@192.168.… <?xml version="1.0"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="Business"> <entry uri="sip:test1@192.168.1.134"> <display-name>Test 1</display-name> </entry> <entry uri="sip:test122@192.168.1.134"> <display-name>Test 1</display-name> </entry> </list> <list name="Family"> <entry uri="sip:test2@192.168.1.134"> <display-name>Test 2</display-name> </entry> <entry uri="sip:test222@192.168.1.134"> <display-name>Test 2</display-name> </entry> </list> <list name="Friends"> <entry uri="sip:test3@192.168.1.134"> <display-name>Test 3</display-name> </entry> <entry uri="sip:test322@192.168.1.134"> <display-name>Test 3</display-name> </entry> </list> <list name="Blocked" /> </resource-lists>

2 4

Re: [SR-Users] testing the value of $si
by Alex Balashov 27 Apr '12

27 Apr '12

It should work. What are your symptoms that it doesn't? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com x-kamailio(a)sidell.org wrote: >How do I compare $si to a particular IP address value? This doesn't >seem to work: > >if( $si == "123.123.123.123") > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

1 0

testing the value of $si
by x-kamailio＠sidell.org 27 Apr '12

27 Apr '12

How do I compare $si to a particular IP address value? This doesn't seem to work: if( $si == "123.123.123.123")

1 0

Re: [SR-Users] dispatcher and call transfer
by charles.chance＠sipcentric.com 27 Apr '12

27 Apr '12

1 0

Re: [SR-Users] dispatcher and call transfer
by charles.chance＠sipcentric.com 27 Apr '12

27 Apr '12

2 1

Re: [SR-Users] dispatcher and call transfer
by charles.chance＠sipcentric.com 27 Apr '12

27 Apr '12

1 0

Re: [SR-Users] dispatcher and call transfer
by Asgaroth 27 Apr '12

27 Apr '12

Hi All, Just resending this as my previous message was too big (bigger than 60k) ---. Thanks all for the suggestions. @Charles Yes that is correct, that is the scenario that is occurring, we are using asterisk, when a call is initiated via asterisk 1, the second call then routes through to asterisk 2, asterisk 1 then gets the REFER but doesn't know about the 2nd call. @Reda I like this option of using the hash table (I'd like to exclude a database lookup for each initial invite), however, would I be forced to use a database in the case of 2 loadbalancers, surely some shared state would need to exist between the loadbalancers to make this decision on where to route the call if it already exists. I suspect the hashtable suggestion may work perfectly in a single loadbalancer scenario, unless I'm missing something. For example, the initialy call may go via loadbalancer 1 however the second call may go through loadbalancer 2, that way loadbalancer 2 may not know of an existing call already been setup. In keeping with the hashtable train of thought, is it really neccessary to keep a reference to the callid, as the second call in the transfer scenario described by Charles, the callid of the second call is different to the original call. Just as an FYI, I am currently using dispatcher algorithm 0 which is a hash over callid. Thanks again all for the suggestions/tips

1 0

Re: [SR-Users] dispatcher and call transfer
by Asgaroth 27 Apr '12

27 Apr '12

Thanks all for the suggestions. @Charles Yes that is correct, that is the scenario that is occurring, we are using asterisk, when a call is initiated via asterisk 1, the second call then routes through to asterisk 2, asterisk 1 then gets the REFER but doesn't know about the 2nd call. @Reda I like this option of using the hash table (I'd like to exclude a database lookup for each initial invite), however, would I be forced to use a database in the case of 2 loadbalancers, surely some shared state would need to exist between the loadbalancers to make this decision on where to route the call if it already exists. I suspect the hashtable suggestion may work perfectly in a single loadbalancer scenario, unless I'm missing something. For example, the initialy call may go via loadbalancer 1 however the second call may go through loadbalancer 2, that way loadbalancer 2 may not know of an existing call already been setup. In keeping with the hashtable train of thought, is it really neccessary to keep a reference to the callid, as the second call in the transfer scenario described by Charles, the callid of the second call is different to the original call. Just as an FYI, I am currently using dispatcher algorithm 0 which is a hash over callid. Thanks again all for the suggestions/tips On 26/04/12 16:12, Charles Chance wrote: > > Yes, I realise Asterisk is not a media relay, but I don't 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-bounces@lists.sip-router.org > [mailto:sr-users-bounces@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 > <charles.chance(a)sipcentric.com <mailto:charles.chance@sipcentric.com>> > 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-bounces@lists.sip-router.org > <mailto:sr-users-bounces@lists.sip-router.org> > [mailto:sr-users-bounces@lists.sip-router.org > <mailto:sr-users-bounces@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.chance(a)sipcentric.com <mailto:charles.chance@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-bounces(a)lists.sip-router.org > <mailto:sr-users-bounces@lists.sip-router.org> > [mailto:sr-users-bounces@lists.sip-router.org > <mailto:sr-users-bounces@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 <00asgaroth00(a)gmail.com > <mailto:00asgaroth00@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(a)lists.sip-router.org <mailto: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:carsten@ng-voice.com <mailto:carsten@ng-voice.com> > > Mobile +49 179 2021244 <tel:%2B49%20179%202021244> > Office +49 40 34927219 <tel:%2B49%2040%2034927219> > Fax +49 40 34927220 <tel:%2B49%2040%2034927220> > > 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(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > ----- > No virus found in this message. > Checked by AVG - www.avg.com <http://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(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com <http://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(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com <http://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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

1 0

Copy reason field from 503 to 500.
by Vitaliy Aleksandrov 27 Apr '12

27 Apr '12

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.

2 4

Gentoo ebuild v3.2.3
by caio 26 Apr '12

26 Apr '12

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

1 0

kamailio Crashes with rls module
by Gnaneshwar Gatla 26 Apr '12

26 Apr '12

Hello, I'm experimenting the usage of rls module with Kamailio. I have been able to successfully update xcap documents on Kamailio XCAP server. I have tried to use SIPp to get a NOTIFY for subscribing a rls-service list. Kamailio does get the xml from the xcap table and tries to parse it and crashes. I'm not sure if this is because the format of the XML, I derived the xml format from the RFC 4662 and 4826. I have attached the Kamailio log. I need help with this. Any help is appreciated, thank you very much. Gnaneshwar Gatla | InTouch Health | Software Developer 6330 Hollister Ave. Goleta CA, 93117 | P: 805.562.8686 ext: 199

1 0

Re: [SR-Users] dispatcher and call transfer
by Reda Aouad 26 Apr '12

26 Apr '12

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 <charles.chance(a)sipcentric.com > 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-bounces(a)lists.sip-router.org [mailto: > sr-users-bounces(a)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.chance(a)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-bounces(a)lists.sip-router.org > [mailto:sr-users-bounces@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 <00asgaroth00(a)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(a)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:carsten@ng-voice.com > > Mobile +49 179 2021244 <%2B49%20179%202021244> > Office +49 40 34927219 <%2B49%2040%2034927219> > 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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users**** > > ----- > 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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users**** > > ** ** > ------------------------------ > > 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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >

2 1

Re: [SR-Users] About MSRP relay
by 罗俊明 26 Apr '12

26 Apr '12

3 2

Re: [SR-Users] dispatcher and call transfer
by Reda Aouad 26 Apr '12

26 Apr '12

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.chance(a)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-bounces(a)lists.sip-router.org > [mailto:sr-users-bounces@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 <00asgaroth00(a)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(a)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:carsten@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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > ----- > 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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >

2 1

dispatcher and call transfer
by Asgaroth 26 Apr '12

26 Apr '12

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.

3 2

generating cdrs
by Pirjo Ahvenainen 26 Apr '12

26 Apr '12

Hi all, I'm currently playing with accounting and cdrs, and meaning to test cdr record generation. Using Kamailio 3.2.3 on Ubuntu. My question is how to enable Kamailio to save cdr data into database (MySql in my case)? I have loaded the dialog module and enabled the cdr generation: modparam("acc", "cdr_enable", 1) ... but no cdrs in db, what else do I need to do? The script is mostly default config, any logic I need to add etc? I'll be fine with the most basic cdrs first and will expand from there. I do get entries in syslog for invite and bye of the transaction. I assume the cdr recodrs should be visible in cdrs table, but have nothing there. According to the acc module documentation: "In order to set up CDR generation, you must enable the CDR switch and load the dialog module", does cdr switch here mean the cdr_enable module parameter of the acc module? cheers, Pirjo -- Pirjo Ahvenainen +35844 559 7729

3 9

reply code for lower cseq
by Daniel-Constantin Mierla 25 Apr '12

25 Apr '12

Hello, I was wondering if someone here can point quickly where specs mention what is the right reply code to send when a request within dialog is received with lower cseq value than the previous request. I couldn't spot the part in the RFC yet, if any related exists. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

4 7

Redirection fails
by Pepe 25 Apr '12

25 Apr '12

Hi, since few days ago I have many problems with the redirections in kamailio (3.1.1). The blind forwarding works fine, but the redirection don't. Here's my code: failure_route[FAIL_ONE] { xlog("L_INFO", "entering failure_route for reply code $T_reply_code\n"); if (is_method("INVITE") && (isbflagset(FLB_NATB) || isflagset(FLT_NATS))) { unforce_rtp_proxy(); } if (t_is_canceled()) { exit; } if (t_check_status("486|408|302")) { xlog("L_NOTICE", "r[FAIL] / &ru TimeOut or Busy\n"); if(avp_db_load("$ru/username","$avp(s:callbusy)")) { xlog("L_NOTICE", "Callbusy activado!\n"); avp_pushto ("$ru","$avp(s:callbusy)"); xlog("Redireccionando a $ru"); km_append_branch(); route(CONSISTENCIA); } t_relay(); } } route[CONSISTENCIA] { xlog("L_NOTICE", "KAM-INFO: r[CONSISTENCIA] / - CONSISTENCY FOR FORWARDINGS \n"); route(NAT); route(ALIAS); } When I make a call to a contact that is using the phone in this moment, i receive a 302 status code, instead of 486. The big problem is this, I make the call, the forwarding works well and call rings in the right destination but i can't hear anything until the primary destination terminates the call. Any help will be apreciated. Best regards.

2 2

Kamailio fails with public ip address for authentication
by Ryan Gholam 25 Apr '12

25 Apr '12

Hello there , I am trying now my kamailio on a real public ip , i am trying to connect from a client from a different public ip , but i always get from kamailio unauthorized eventho the username and password are correct and when i connect to the kamailio localy everything works

2 1

kamailio-sipcapture-modules package?
by Skyler 25 Apr '12

25 Apr '12

Hi all, Is there any kamailio-sipcapture-modules or kamailio-homer-modules package available for amd64? Skyler

3 3

xhttp and xmlrpc
by Krishna Kurapati 24 Apr '12

24 Apr '12

Hi, I have two routes event_route[xhttp:request] { } route[XMLRPC]{ } Both are using HTTP as transport. When I tried to send a XMLRPC POST command, the event_route is getting triggered. Do I need to handle the XMLRPC inside the event_route? Since I am using XMLRPC for Click2Dial kind of feature, I am wondering how the async responses be handled if I include in event_route. Krish Kura

2 2

Re: [SR-Users] RTPproxy and kamailio
by Ryan Gholam 24 Apr '12

24 Apr '12

So let me get this straight , so if i have a client behind a NAT , the client should be able to connect to the stun server ( which has the real ip for example : 192.168.10.1 ) , and by default i should be able to make the stun server connect to the kamailio (which also have a real ip for example : 192.168.10.2 ) . Thank you On 4/24/12, Pavel Segeč <Pavel.Segec(a)fri.uniza.sk> wrote: > HI, > > stun is working completely out of kamailio, it deal only witch SIP clients. > Older fashioned stun server is included for example inside of regular linux > repository, for example for debian > > palo73 > >> -----Original Message----- >> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- >> bounces(a)lists.sip-router.org] On Behalf Of Ryan Gholam >> Sent: Tuesday, April 24, 2012 9:02 AM >> To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users >> Mailing List >> Subject: Re: [SR-Users] RTPproxy and kamailio >> >> Thank you it worked well enough , but do you have an idea if there any >> configuration for Stun server ? , or i just install stun server and link >> it up to kamailio ? >> >> On 4/23/12, Jan Klepal <jan(a)klepal.cz> wrote: >> > Hello Ryan, >> > >> > kamailio default config is already prepared for rtpproxy. Do exactly >> > what is noted in kamailio.cfg :-) >> > >> > - download and install rtpproxy from http://www.rtpproxy.org >> > - start rtpproxy: rtpproxy -l your.public.ip.address -s >> > udp:127.0.0.1:7722 >> > - start kamailio: kamailio -A WITH_NAT >> > >> > Function which controls rtpproxy is rtpproxy_manage(), documented >> here: >> > http://kamailio.org/docs/modules/3.2.x/modules/rtpproxy.html >> > >> > Check flags you can pass to rtpproxy_manage(), especially o and c. >> > >> > Cheers, >> > Jan >> > >> > On Monday 23 of April 2012 11:35:15 Ryan Gholam wrote: >> >> I would appreciate if someone can guide me through the setup to >> >> configure Rtpproxy with kamailio , and what changes should be made in >> >> the kamailio.cfg file . >> > >> > >> > _______________________________________________ >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> > list sr-users(a)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(a)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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >

2 1

call for participation: kamailio project at LinuxTag 2012
by Carsten Bock 24 Apr '12

24 Apr '12

Hello, in about four weeks the kamailio project will (again) be present on the LinuxTag fair, "the most important place for Linux and open source software in Europe" - http://www.linuxtag.org/2012/en.html . If you are in Berlin during this time, plan to visit the LinuxTag or just like to help your favourite SIP server project - please consider supporting us in running our fair booth! Even showing up for one or two hours helps a lot. We need also support to properly present our project, like flyers, a banner, maybe some live demonstrations.. So even if you can't participate in person, there are other ways to help us! Please contact me per mail if you could help at the booth or have some ideas about our project presentation. The actual state of preparations can be found in our wiki: http://sip-router.org/wiki/meetings/berlin-2012 Thanks in advance, Carsten -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany http://www.ng-voice.com mailto:carsten@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!

1 0

RTPproxy and kamailio
by Ryan Gholam 24 Apr '12

24 Apr '12

I would appreciate if someone can guide me through the setup to configure Rtpproxy with kamailio , and what changes should be made in the kamailio.cfg file . Thank you .

3 3

Development frozen for v3.3.0
by Daniel-Constantin Mierla 24 Apr '12

24 Apr '12

Hello, just short message to mark the freezing of the new features development for v3.3.0. For about 1-1.5 months, git master branch should be used to commit only fixes to existing features, improvements to documentation and eventually merges of the duplicated modules without affecting existing database structure. Of course, developers can use personal branches to add new features, which can be merged later in master, once branch 3.3 will be created. Database structure should be in its final format for 3.3.0. The main focus should be now on testing master branch to be sure all goes ok. From my point of view, I would like to ask special attention to registrar/usrloc modules that introduced support for SIP outbound and GRUU, having the location table structure updated. Also add to the wiki pages details about migration from 3.2.x to 3.3.0: * http://www.kamailio.org/wiki/install/upgrade/3.2.x-to-3.3.0 If you discover new features not listed there, add to the page: * http://www.kamailio.org/wiki/features/new-in-devel Cheers, Danie -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

kamailio 3.2.2 - uac calls from sipgate.de - rr [loose.c:103]: failed to parse Route HF
by Karsten Horsmann 23 Apr '12

23 Apr '12

Hello List, after my multihomed setup seems to be fine i have an question about this log entries: Apr 18 10:02:28 kamailio1 rtpproxy[15286]: INFO:handle_command: delete request failed: session 153a2e592314d58d51897ed10187f0da(a)sipgate.de, tags as11f6a774/ds-32764e7d-e76ac287 not found Apr 18 10:02:28 kamailio1 /usr/local/sbin/kamailio[27071]: DEBUG: <script>: BYE OR CANCEL. Dialog lifetime: <null> Status: <null> Apr 18 10:02:28 kamailio1 /usr/local/sbin/kamailio[27071]: DEBUG: <core> [parser/parse_rr.c:62]: parse_rr_body(): No body for record-route Apr 18 10:02:28 kamailio1 /usr/local/sbin/kamailio[27071]: ERROR: rr [loose.c:103]: failed to parse Route HF Apr 18 10:02:28 kamailio1 /usr/local/sbin/kamailio[27071]: ERROR: rr [loose.c:103]: failed to parse Route HF Apr 18 10:02:28 kamailio1 /usr/local/sbin/kamailio[27071]: DEBUG: rr [loose.c:838]: There is no Route HF Any hints to fix that? -- Mit freundlichen Grüßen *Karsten Horsmann*

4 22

Freezing development today for release 3.3.0
by Daniel-Constantin Mierla 23 Apr '12

23 Apr '12

Hello, quick reminder for everyone that by end of today is planned the freezing for the development of the new features to be in version 3.3.0. I know there are going to be few hammerings to newly added features, when discovering issues, that's the testing phase for. But try to get at least the database structure settled by today, as most of the users need to adapt management interfaces to start using the new version. Cheers, Daniel

1 0

replace body content
by Konstantin M. 22 Apr '12

22 Apr '12

Hi, Is there a way to change/replace anything in body message ? Used: replace_body_atonce, replace_body_all, replace_all, subst_body. Nothing is working. Thanks,

1 0

Core Dump from select stmt
by Akan Technology 22 Apr '12

22 Apr '12

hello, I am running kamailio 3.2.2 on Solaris 10 64 bit and I am getting a core dump on this statement: $ru = "sip:" + $rU + "@" + $sel(cfg_get.registrar1.server_ip) + $sel(cfg_get.registrar1.server_port); Here is how the variable is defined: registrar1.server_ip = "xxx.xxx.xxx.xxx" desc "Registrar server IP address" registrar1.server_port = "5080" desc "Registrar server Port" Here is the output from the logs with debug: 10(25373) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=1072 a=65 n=assign 10(25373) DEBUG: <core> [select.c:424]: Calling SELECT 1004b2bc0 10(25373) DEBUG: <core> [select.c:424]: Calling SELECT 1004b4da0 10(25373) ERROR: *** cfgtrace:14(25377) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 22 14(25377) DEBUG: <core> [tcp_main.c:3555]: DBG: handle_ser_child: dead child 10, pid 25373 (shutting down?) 14(25377) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003738b8, 22, 0, 0x0) fd_no=18 called 14(25377) DEBUG: <core> [tcp_main.c:3316]: DBG: handle_tcp_child: dead tcp child 0 (pid 25373, no 10) (shutting down?) 14(25377) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003738b8, 24, 1, 0x0) fd_no=17 called 0(25363) ALERT: <core> [main.c:751]: child process 25373 exited by a signal 11 0(25363) ALERT: <core> [main.c:754]: core was generated 0(25363) INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD 14(25377) INFO: <core> [main.c:817]: INFO: signal 15 received Here is the full route code: route[TO_REGISTRAR] { # check if Registrar server's IP is defined if (strempty($sel(cfg_get.registrar1.server_ip))) { xlog("SCRIPT: REGISTRAR - registrar1.server_ip not defined\n"); return; } $ru = "sip:" + $rU + "@" + $sel(cfg_get.registrar1.server_ip) + ":" + $sel(cfg_get.registrar1.server_port); route(RELAY); exit; } # End of TO_Registrar Route I am trying to setup the proxy server to route all registers requests to another kamailio server Thanks Nathaniel

4 10

reminder - freezing development for next major release v3.3.0
by Daniel-Constantin Mierla 20 Apr '12

20 Apr '12

Hello, a short reminder about freezing the development for next major release v3.3.0. It is planned for April 23, less than two weeks away. If you have new features to add for v3.3.0, commit them or send the patches before the date. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

3 4

htable feature request
by Andreas Granig 20 Apr '12

20 Apr '12

Hi, I'd like to ask for a feature request for htable. Would it be possible to add an MI function to delete specific entries from an htable, e.g. with "sercmd htable.remove <table> <key>" before freezing 3.3? That'd be handy for example if you hold blocked IPs in htable, but want to unblock some of them manually. At the moment, I only see the method of restarting kamailio to whipe the whole table (and it'd only work if dbmode=0). Thanks in advance, Andreas

2 2

Help about VoIP
by Zuzu 20 Apr '12

20 Apr '12

I got my sip account ipadvoip(a)iptel.org what is next step VoIP to complete plz reply thank you my email yahya_satofa(a)yahoo.com

1 0

SIP Attack
by Ricardo Martinez 20 Apr '12

20 Apr '12

Hello. I was wondering if someone could help me here. From time to time I stat to receive from the internet this SIP message : U 190.22.140.170:51316 -> 64.76.154.110:5060 SIP/2.0 400 BadRequest. Via: . From: . To: . Call-ID: . CSeq: . User-Agent: AddPac SIP Gateway. Content-Length: 0. . At burst rate of 124 pps (packets per second), this meesage is entering to Kamailio routine and generating a lot of ERROR logs lie these : Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: ERROR: <core> [msg_translator.c:1943]: ERROR: build_res_buf_from_sip_req: al as, parse_headers failed Apr 1 03:32:19 kmborde /usr/local/sbin/kamailio[2311]: WARNING: sanity [sanity.c:254]: sanity_check(): check_required_headers(): fa iled to send 400 via sl reply Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: ERROR: <core> [msg_translator.c:1943]: ERROR: build_res_buf_from_sip_req: al as, parse_headers failed Apr 1 03:32:20 kmborde /usr/local/sbin/kamailio[2301]: WARNING: sanity [sanity.c:254]: sanity_check(): check_required_headers(): fa iled to send 400 via sl reply Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: ERROR: <core> [parser/msg_parser.c:179]: ERROR: get_hdr_field: bad to header Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [To: <sip:Re gister=>5] Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: ERROR: <core> [msg_translator.c:1943]: ERROR: build_res_buf_from_sip_req: al as, parse_headers failed Apr 1 03:32:23 kmborde /usr/local/sbin/kamailio[2320]: WARNING: sanity [sanity.c:254]: sanity_check(): check_required_headers(): fa iled to send 400 via sl reply The only way that I have now for blocking this packet to hit the Kamailio server is via iptables : iptables -A INPUT -s 190.22.140.170 -p udp --dport 5060 --jump REJECT Is there a better way to do this?! Thanks in advance, * * *Ricardo Martinez.-*

5 5

Re: [SR-Users] sr-users Digest, Vol 83, Issue 77
by Ali Wazni 20 Apr '12

20 Apr '12

Chefta men chway. Jaydeeeeee 7adret el consultant!!!!! Ali Wazni On 20 avr. 2012, at 08:41, sr-users-request(a)lists.sip-router.org wrote: > Send sr-users mailing list submissions to > sr-users(a)lists.sip-router.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > or, via email, send a message with subject or body 'help' to > sr-users-request(a)lists.sip-router.org > > You can reach the person managing the list at > sr-users-owner(a)lists.sip-router.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sr-users digest..." > > > Today's Topics: > > 1. Kamailio v3.2.3 Released (Daniel-Constantin Mierla) > 2. Re: [sr-dev] reminder - freezing development for next major > release v3.3.0 (Peter Dunkley) > 3. Stateless Proxy (Akan) > 4. How does RLS work with kamailio. (Gnaneshwar Gatla) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 19 Apr 2012 19:15:29 +0200 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Subject: [SR-Users] Kamailio v3.2.3 Released > To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users(a)lists.sip-router.org>, sr-dev > <sr-dev(a)lists.sip-router.org>, business(a)lists.kamailio.org > Message-ID: <4F904831.1030503(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > Kamailio SIP Server v3.2.3 stable release is out. > > This is a maintenance release of the latest stable branch, 3.2, that > includes fixes since release of v3.2.2. There is no change to database > schema or configuration language structure that you have to do on > installations of v3.2.0, v3.2.1 or v3.2.2. Deployments running previous > v3.2.x versions are strongly recommended to be upgraded to v3.2.3. > > For more details about version 3.2.3 (including links and hints to > download the tarball or from GIT repository), visit: > > * http://www.kamailio.org/w/2012/04/kamailio-v3-2-3-released/ > > RPMs and Debian/Ubuntu packages will be available soon. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany > http://www.asipto.com/index.php/kamailio-advanced-training/ > > > > > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 18:33:49 +0100 > From: Peter Dunkley <peter.dunkley(a)crocodile-rcs.com> > Subject: Re: [SR-Users] [sr-dev] reminder - freezing development for > next major release v3.3.0 > To: miconda(a)gmail.com, Development mailing list of the sip-router > project <sr-dev(a)lists.sip-router.org> > Cc: "SIP Router - Kamailio $OpenSER$ and SIP Express Router $SER$ > - Users Mailing List" <sr-users(a)lists.sip-router.org> > Message-ID: <1334856829.2795.29.camel@pd-laptop-linux> > Content-Type: text/plain; charset="utf-8" > > Hi, > > One of the developments I am currently working on is to add notifier > processes to presence. I have already done this for RLS. This is > needed not just for performance, but because there are race conditions > (I see them under load) where you get multiple NOTIFY requests > outstanding on the same dialog and, when in DB only mode, they often > have the same CSeq (despite being different requests). > > Unfortunately, I don't believe I will get this finished by the end of > Monday (April 23). I still expect to complete this development next > week. > > As the CSeq issue is quite clearly a problem I would like to get this > development into Kamailio 3.3. Will it be OK for me to put this > development into master next week after the freeze? > > Thanks, > > Peter > > On Wed, 2012-04-11 at 11:34 +0200, Daniel-Constantin Mierla wrote: > >> Hello, >> >> a short reminder about freezing the development for next major release >> v3.3.0. It is planned for April 23, less than two weeks away. If you >> have new features to add for v3.3.0, commit them or send the patches >> before the date. >> >> Cheers, >> Daniel >> > > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd >

1 0

XCAP_Client version error
by Gnaneshwar Gatla 20 Apr '12

20 Apr '12

Hey, In Kamailio 3.2.2: I was working with XCAP and RLS today and found that the XCAP client has not been updated to the latest version of the xcap table. This resulted in error while starting Kamailio. Currently in modules_k/xcap_client/xcap_client.c : #define XCAP_TABLE_VERSION 3 I have set this macro to 4 and started the Kamailio instance. This is in regard to the followup email for rls service, does this have any impact to the rls module? Regards Gnani Gnaneshwar Gatla | InTouch Health | Software Developer 6330 Hollister Ave. Goleta CA, 93117 | P: 805.562.8686 ext: 199

2 1

Stateless Proxy
by Akan 20 Apr '12

20 Apr '12

Hello, I am trying to setup a stateless proxy where certain requests are forwarded to another sip server that will handle those requests specifically. I have the request message forwarding to the other sip server but the reply is being sent back to the original sip server then to the client. When I look at the SIP request and reply, I see a new "Via" header line with the IP address of the original sip proxy server. What I am trying to setup is a stateless proxy which just forwards the original request to another sip server and then this second sip server will handle everything from there. Basically offloading the traffic to other servers. Currently i am rewriting the ruri host and port as done in the sample config and issuing the forward() function. I have tried t_relay() as also in the sample config but I get the same results. Is there something else that I need to do before forwarding to the other sip server? How can I get rid of the new "Via" line? I believe this is from record_route() but I am not issue this before I perform the relay. I have Kamailio 3.2.3 loaded and used the sample config as my base config. Thanks Nathaniel

1 0

How does RLS work with kamailio.
by Gnaneshwar Gatla 19 Apr '12

19 Apr '12

Hello, I'm trying to implement RLS with integrated XCAP server. I have successfully run the Kamailio instance with the following snippet. Since I had no RLS clients available, I have tried to test this with SIPp. The attached pcap trace is the result. Test: 1. Send an XCAP signal over http to Kamailio. 2. Register and subscribe Kamailio. The test does store the xml received over http in the xcap table in the database. But rls module does not store the data neither in rls_presentity or rls_watcher. When I sent the Subscribe with sipp, the server throws error that subscription was not found in the database. I would like to know if I'm doing something wrong to implement this service. Is there any brief tutorial on how to implement this? Kamailio.cfg snippet: ##Presence modparam("presence", "server_address", PRESENCE_IP) modparam("presence", "clean_period", 65) modparam("presence", "db_update_period", 60) modparam("presence", "max_expires", 75) modparam("presence", "fallback2db", 1) modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 0) modparam("presence_xml", "integrated_xcap_server", 1) ##rls modparams modparam("rls", "db_url", DBURL) modparam("rls", "waitn_time", 10) modparam("rls", "integrated_xcap_server", 1) modparam("rls", "max_notify_body_length", 32000) modparam("rls", "to_presence_code", 10) modparam("rls", "server_address", RLS_URI) modparam("rls", "outbound_proxy", PUA_OUTBOUND_PROXY) modparam("rls", "xcap_root", XCAP_ROOT) ##XCAP modparams modparam("xcap_server", "db_url", DBURL) modparam("xcap_client", "db_url", DBURL) modparam("xcap_client", "query_period", 50) route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { $var(ret_code)= rls_handle_subscribe(); xlog("Subscribe: $var(ret_code)"); if($var(ret_code)== 10) handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } In the [xhttp:request]: switch($rm) { case "PUT": xcaps_put("$var(uri)", "$hu", "$rb"); if($xcapuri(u=>auid)=~"pres-rules") { xlog("===== xhttp put: refreshing watchers for $var(uri)\n"); pres_update_watchers("$var(uri)", "presence"); pres_refresh_watchers("$var(uri)", "presence", 1); } else if ($xcapuri(u=>auid)=~"resource-lists" || $xcapuri(u=>auid)=~"rls-services") { xlog("==== xhttp put: refreshing rls watchers $var(uri)\n"); rls_update_subs("$var(uri)", "presence"); } exit; break; Gnaneshwar Gatla | InTouch Health | Software Developer 6330 Hollister Ave. Goleta CA, 93117 | P: 805.562.8686 ext: 199

1 0

Kamailio v3.2.3 Released
by Daniel-Constantin Mierla 19 Apr '12

19 Apr '12

Hello, Kamailio SIP Server v3.2.3 stable release is out. This is a maintenance release of the latest stable branch, 3.2, that includes fixes since release of v3.2.2. There is no change to database schema or configuration language structure that you have to do on installations of v3.2.0, v3.2.1 or v3.2.2. Deployments running previous v3.2.x versions are strongly recommended to be upgraded to v3.2.3. For more details about version 3.2.3 (including links and hints to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2012/04/kamailio-v3-2-3-released/ RPMs and Debian/Ubuntu packages will be available soon. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

1 0

Distributed subscribers Kamailio
by Juanjo 19 Apr '12

19 Apr '12

Hello everybody I have a question about clustering kamailio, i want to register subscribers to two diferent kamailios, and the subscribers from one kamailio should be able to communicate with the subscribers registered in the other kamailio How can i do it? Is there something like DUNDI in the Asterisk world? Thank you in advance.

2 1

uac module incoming INVITE become wrong dst_ip address
by Karsten Horsmann 19 Apr '12

19 Apr '12

Hello List, i am nearly finishing my multihomed config (public ip/internal ip) with kamailio. For incoming calls i want to use the uac module too. Then i want to locate an permanet entry and dispatch it to ivr system behind kamailio. i tried something like this: if (lookup("location") && (dst_ip==222.222.222.222)) { if(ds_select_domain("1", "4")) { Okay for registerd UAC this works perfect - but if made an call to the uac registerd number i got as $Ri the 172.20.100.74 - and thats is the private ip address. Why that??? Any hints to check "if its internal or external" call??? -- Mit freundlichen Grüßen *Karsten Horsmann*

2 3

sqlite -> usrloc tables deleted after 1 minute
by Pedro Antonio Vico Solano 19 Apr '12

19 Apr '12

2 6

Releasing v3.2.3
by Daniel-Constantin Mierla 19 Apr '12

19 Apr '12

Hello, last patch release (v3.2.2) was done quite some time ago, therefore I am thinking of releasing v3.2.3 sometime next week, maybe Wednesday or Thursday. If there are patches in master branch to be backported to 3.2, please start doing them. Also, if anyone is aware of issues in 3.2 branch not reported to the tracker, announce them asap. Thanks, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

1 2

Stress test
by Lucas Alvarez 18 Apr '12

18 Apr '12

Can someone recommend a good stress tool for testing kamailio? Or can point through the right path? Thanks in advance. Lucas

3 2

implementing Kamailio with FreeSwitch.
by Mehdi Badiezadegan 18 Apr '12

18 Apr '12

Hello and thanks for your helping,excuse me I'm newbie in mailing list. I have a question about implementing Kamailio with FreeSwitch. Our plan is a configuration like this at the follow: 1.Kamailio as registering and LoadBalancer ,response to chat and call(voice/video) in p2p 2.we have 2 FreeSwitch media engine just for Conference case(Voice/Video) . How we can implementing above kamailio as loadBalancer for 2 FreeSwitchs in conference case , And at the same time,It answer as voip/chat server for p2p case ? we have success by implementing Kamailio with one FreeSwitch, (FreeSwitch as media Engine just for conference and Kamailio for p2p call) But if we have 2 FreeSwitch with same activity,How we can implementing... And So I had Efforts with dispatcher module, but it was good only for route/Loadbalancer not for answering p2p call. Thanks a lot Mehdi Badiezadegan

2 1

loose_route() for ACK message
by Laurent Schweizer 18 Apr '12

18 Apr '12

Hello all, I have a script working with openser1.2.1 and I try to move them to kamailio 3.2.1 I have actually an issue with the loose_route() function at least for ACK message. When I get the ACK the loose_route function is changing the URI with the value of the route header of the ACK message . The problem is that this value is the local proxy himself so the t_relay() function send the ACK on the loopback interface. Any Idea ? Regards Laurent Apr 16 18:48:08 proxy kamailio[28033]: INFO: <script>: START REQ:[ACK] Tran:[7070] URI:[sip:peoplefone@95.128.80.93:7070] from:[sip:41763770377@sip.call.lt;user=phone] to:[sip:37052077800@81.16.238.195;user=phone] CallID:[25694-UI-05aa645a-7000c6ef6@sip.call.lt] Apr 16 18:48:08 proxy kamailio[28033]: INFO: <script>: SANITY OK, REQ:[ACK] Tran:[7070] URI:[sip:peoplefone@95.128.80.93:7070] from:[sip:41763770377@sip.call.lt;user=phone] to:[sip:37052077800@81.16.238.195;user=phone] CallID:[25694-UI-05aa645a-7000c6ef6@sip.call.lt] Apr 16 18:48:08 proxy kamailio[28033]: INFO: <script>: DIALOG1 REQ:[ACK] Tran:[7070] URI:[sip:peoplefone@95.128.80.93:7070] from:[sip:41763770377@sip.call.lt;user=phone] to:[sip:37052077800@81.16.238.195;user=phone] CallID:[25694-UI-05aa645a-7000c6ef6@sip.call.lt] If (loose_route()) is called Apr 16 18:48:08 proxy kamailio[28033]: INFO: <script>: DIALOG1ACK REQ:[ACK] Tran:[5060] URI:[sip:81.16.238.195;lr;ftag=25694-BR-05aa645b-0f448aeb2] from:[sip:41763770377@sip.call.lt;user=phone] to:[sip:37052077800@81.16.238.195;user=phone] CallID:[25694-UI-05aa645a-7000c6ef6@sip.call.lt] Apr 16 18:48:08 proxy kamailio[28033]: INFO: <script>: NATMANAGE REQ:[ACK] Tran:[5060] URI:[sip:81.16.238.195;lr;ftag=25694-BR-05aa645b-0f448aeb2] from:[sip:41763770377@sip.call.lt;user=phone] to:[sip:37052077800@81.16.238.195;user=phone] CallID:[25694-UI-05aa645a-7000c6ef6@sip.call.lt] Apr 16 18:48:08 proxy kamailio[28033]: INFO: <script>: DIAL_RELAY1 REQ:[ACK] Tran:[5060] URI:[sip:81.16.238.195;lr;ftag=25694-BR-05aa645b-0f448aeb2] from:[sip:41763770377@sip.call.lt;user=phone] to:[sip:37052077800@81.16.238.195;user=phone] CallID:[25694-UI-05aa645a-7000c6ef6@sip.call.lt] Apr 16 18:48:08 proxy kamailio[28033]: INFO: <script>: T_RELAY REQ:[ACK] Tran:[5060] URI:[sip:81.16.238.195;lr;ftag=25694-BR-05aa645b-0f448aeb2] from:[sip:41763770377@sip.call.lt;user=phone] to:[sip:37052077800@81.16.238.195;user=phone] CallID:[25694-UI-05aa645a-7000c6ef6@sip.call.lt] U 81.16.238.195:5060 -> 87.110.233.1:5060 SIP/2.0 200 OK. To: <sip:37052077800@81.16.238.195;user=phone>;tag=e868748c. Via: SIP/2.0/UDP 87.110.233.1:5060;rport=5060;branch=z9hG4bK-26E6-2AB3E9F. Record-Route: <sip:81.16.238.195;lr;ftag=25694-BR-05aa645b-0f448aeb2>. CSeq: 79950814 INVITE. Call-ID: 25694-UI-05aa645a-7000c6ef6(a)sip.call.lt. From: <sip:41763770377@sip.call.lt;user=phone>;tag=25694-BR-05aa645b-0f448aeb2. Content-Type: application/sdp. Contact: <sip:peoplefone@95.128.80.93:7070>. Content-Length: 205. . v=0. o=90706832381 5012 11 IN IP4 81.16.238.195. s=Mapping. c=IN IP4 81.16.238.195. t=0 0. m=audio 8170 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=sendrecv. U 87.110.233.1:5060 -> 81.16.238.195:5060 ACK sip:peoplefone@95.128.80.93:7070 SIP/2.0. Call-ID: 25694-UI-05aa645a-7000c6ef6(a)sip.call.lt. Contact: <sip:87.110.233.1:5060>. CSeq: 79950814 ACK. From: <sip:41763770377@sip.call.lt;user=phone>;tag=25694-BR-05aa645b-0f448aeb2. Max-Forwards: 30. Route: <sip:81.16.238.195;lr;ftag=25694-BR-05aa645b-0f448aeb2>. To: <sip:37052077800@81.16.238.195;user=phone>;tag=e868748c. User-Agent: Cirpack/v4.42o (gw_sip). Via: SIP/2.0/UDP 87.110.233.1:5060;branch=z9hG4bK-388F-2AB3F03. Content-Length: 0. .

2 1

dropped calls after 38 seconds openSER
by Saul Waizer 18 Apr '12

18 Apr '12

Greetings list, I am experiencing a strange behavior with openser 1.3.2 running on ubuntu 10. I have a basic configuration (see bellow) and i am using Linphone for iPad as my client. I have 2 users registered and I am able to place calls no problem. The problem is that the calls (audio or A/V) drop after 38 seconds exactly, this behavior is pretty consistent, 38 seconds is all I can get. There is no firewall in front of the clients. Here is my configuration, ip addresses changed to protect the innocent: http://pastie.org/private/x1ck8rxjcxv6hl44hrmqg You can see the logs of the call here (the majority): http://pastie.org/private/4fj5efpbsrxan8plzqvfza Am I missing something or is there anything that needs to be changed in the routing/configuration to achieve basic functionality? Thank you in advance!

5 15

Re: [SR-Users] CallControl and MediaProxy
by Daniel-Constantin Mierla 18 Apr '12

18 Apr '12

Hello, I will patch and backport during next days -- I was mostly out of the office during past weeks. Cheers, Daniel On 3/12/12 11:30 AM, Reda Aouad wrote: > Hi Daniel, > > Any plans to backport this to 3.2 ? > I could still do the changes manually before compilation if you don't > have time to do it. > > Thank you again > Reda > > > > On Wed, Feb 29, 2012 at 10:19, Reda Aouad <reda.aouad(a)gmail.com > <mailto:reda.aouad@gmail.com>> wrote: > > Daniel, It works with flag 28. > Can you confirm that flag 28 isn't used by another module? > If so, can you patch it? When is the next release scheduled for? > > The following are the changes I made: > > modules_k/call_control.c: flag changed to 28 > ------------------------------------------- > #define FL_USE_CALL_CONTROL (1<<28) // use call control for > a dialog > > parser/msg_parser.h: warning added > ------------------------------------------- > /* WARNING: Value (1 << 28) is temporarily reserved for use in > kamailio call_control > * module (flag FL_USE_CALL_CONTROL )! */ > > > Thank you :) > Reda > > > > On Wed, Feb 29, 2012 at 09:58, Reda Aouad <reda.aouad(a)gmail.com > <mailto:reda.aouad@gmail.com>> wrote: > > A quick grep on flags FL_* in the sources shows the following : > Flag 29 is used by acc module, 31 by nat_traversal, 0 to 12 in > the parser. > Thus I assume that it is safe to test using flag 28. > I'll keep you posted on the test result. > > You'll also find below warnings in msg_parser.h for the used > flags. Since flag 30 is declared for mediaproxy in > msg_parser.h, I'll change the flag of callcontrol to 28. > > ----------------------------------------------------------------- > /* WARNING: Value (1 << 29) is temporarily reserved for use in > kamailio acc > * module (flag FL_REQ_UPSTREAM)! */ > > /* WARNING: Value (1 << 30) is temporarily reserved for use in > kamailio > * media proxy module (flag FL_USE_MEDIA_PROXY)! */ > > /* WARNING: Value (1 << 31) is temporarily reserved for use in > kamailio > * nat_traversal module (flag FL_DO_KEEPALIVE)! */ > ----------------------------------------------------------------- > > $ grep -R 'define FL.* (1' src/kamailio/kamailio-3.2.0 > > modules_k/call_control/call_control.c:#define > FL_USE_CALL_CONTROL (1<<30) // use call control for a dialog > modules_k/nat_traversal/nat_traversal.c:#define > FL_DO_KEEPALIVE (1<<31) > modules_k/acc/acc.h:#define FL_REQ_UPSTREAM (1<<29) > parser/msg_parser.h:#define FL_FORCE_RPORT (1 << 0) /*!< force > rport */ > parser/msg_parser.h:#define FL_FORCE_ACTIVE (1 << 1) /*!< > force active SDP */ > parser/msg_parser.h:#define FL_SDP_IP_AFS (1 << 2) /*!< SDP > IP rewritten */ > parser/msg_parser.h:#define FL_SDP_PORT_AFS (1 << 3) /*!< SDP > port rewritten */ > parser/msg_parser.h:#define FL_SHM_CLONE (1 << 4) /*!< msg > cloned in SHM as a single chunk */ > parser/msg_parser.h:#define FL_TIMEOUT (1 << 5) /*!< > message belongs to an "expired" branch > parser/msg_parser.h:#define FL_REPLIED (1 << 6) /*!< > message branch received at least one reply > parser/msg_parser.h:#define FL_HASH_INDEX (1 << 7) /*!< > msg->hash_index contains a valid value (tm use)*/ > parser/msg_parser.h:#define FL_MTU_TCP_FB (1 << 8) > parser/msg_parser.h:#define FL_MTU_TLS_FB (1 << 9) > parser/msg_parser.h:#define FL_MTU_SCTP_FB (1 << 10) > parser/msg_parser.h:#define FL_ADD_LOCAL_RPORT (1 << 11) /*!< > add 'rport' to local via hdr */ > parser/msg_parser.h:#define FL_SDP_BODY (1 << 12) /*!< > msg has SDP in body */ > modules/mediaproxy/mediaproxy.c:#define FL_USE_MEDIA_PROXY (1<<30) > > ----------------------------------------------------------------- > > > Reda > > > > On Wed, Feb 29, 2012 at 00:18, Daniel-Constantin Mierla > <miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: > > That should be. Try changing one of them to (1<<29) and > see if all works fine. > > On another hand, defining and using core msg flags in a > module is a risk, a different solution has to be done, a > simple one is to move the definition of these flags in the > core, so there will be no overlap in the future. > > Cheers, > Daniel > > > On 2/27/12 9:32 PM, Reda Aouad wrote: >> I looked into mediaproxy.c and found the following : >> >> ------------------------------------------------------- >> #define FL_USE_MEDIA_PROXY (1<<30) >> >> ... >> >> # dialog callback >> >> __dialog_created (...) { >> .... >> if ((request->msg_flags & FL_USE_MEDIA_PROXY) == 0) >> return; >> .... >> use_media_proxy (...); >> } >> ------------------------------------------------------- >> >> >> I also found this in call_control.c >> ------------------------------------------------------- >> #define FL_USE_CALL_CONTROL (1<<30) >> >> # Public API >> CallControl (...) { >> ... >> msg->msg_flags |= FL_USE_CALL_CONTROL; >> ... >> } >> ------------------------------------------------------- >> >> So I suspect that since the call_control module uses the >> same flag as the mediaproxy module, call_control function >> is used, flag 30 is set, and the following condition in >> the __dialog_created callback function above is never met >> >> (request->msg_flags & FL_USE_MEDIA_PROXY) == 0 >> >> so the callback function continues until executing its >> last line : use_media_proxy (...) >> which is called on every call to call_control ( ) function.. >> >> Reda >> >> >> >> On Mon, Feb 27, 2012 at 18:39, Reda Aouad >> <reda.aouad(a)gmail.com <mailto:reda.aouad@gmail.com>> wrote: >> >> Ok thanks Daniel. >> >> I'll do what you suggested and we'll see how to proceed. >> >> Thanks again >> Reda >> > > > -- > Daniel-Constantin Mierla --http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda > > > > -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

2 2

SIP Status: 401 Unauthorized (0 bindings)
by Saul Waizer 17 Apr '12

17 Apr '12

Hello List, I have a fresh install kamailio 3.2.0 running on ubuntu. Everything seems to work fine according to the logs, I have enabled support for the following: - enabled support to connect to MySQL server - enabled user authentication - enabled persistent user location service - enabled NAT traversal and updated RTPProxy control socket parameter I added a few users with kamctl add user pass but when I try to register with my client I get the following: 8.257745 x.x.x.x -> 10.62.99.103 SIP Request: REGISTER sip:x.x.x.x 8.258462 10.62.99.103 -> x.x.x.x SIP Status: 401 Unauthorized (0 bindings) Here are some detailed logs for the reg process: T x.x.x.x:63171 -> 10.62.99.103:5060 [AP] REGISTER sip:x.x.x.x SIP/2.0. Via: SIP/2.0/TCP 192.168.126.19:4369;rport;branch=z9hG4bK239028812. From: <sip:daniel@x.x.x.x>;tag=303867081. To: <sip:daniel@x.x.x.x>. Call-ID: 1300614569. CSeq: 7 REGISTER. Contact: <sip:daniel@x.x.x.x:63171;transport=tcp;line=5a9552052fb65c8>. Max-Forwards: 70. User-Agent: Linphone/3.5.0 (eXosip2/3.6.0). Expires: 600. Content-Length: 0. . T 10.62.99.103:5060 -> x.x.x.x:63171 [AP] SIP/2.0 401 Unauthorized. Via: SIP/2.0/TCP 192.168.126.19:4369 ;rport=63171;branch=z9hG4bK239028812;received=x.x.x.x. From: <sip:daniel@x.x.x.x>;tag=303867081. To: <sip:daniel@x.x.x.x>;tag=b27e1a1d33761e85846fc98f5f3a7e58.b260. Call-ID: 1300614569. CSeq: 7 REGISTER. WWW-Authenticate: Digest realm="x.x.x.x", nonce="T42z9U+NssnZP82+sdkwPgl1nRk61QDm". Server: kamailio (3.2.0 (i386/linux)). Content-Length: 0. Any help is greatly appreciated.

2 3

How to configure Kamailio routing logic based on mobile phone numbers
by Tam Doan 17 Apr '12

17 Apr '12

Hi there, Now I could configure Kamailio routing logic based on service's short code (i.e route calls to 200, 300 to separated service's appliction (so call, app serv 1 and app serv 2). My problem is how can i configure Kamailio so that it can route the call from mobile numbers, such as calls from mobile number starting with 0988 xxxxx, 0978 xxxxx will be routed to app serv1 and the calls of 0976 xxxxx to app serv 2. So do you guys have an answer for me ? I would really appreciate your help!!!

1 0

registrar/usrloc updates - gruu support (rfc 5627)
by Daniel-Constantin Mierla 17 Apr '12

17 Apr '12

Hello, I just pushed GRUU support in git master branch. That implied adding two new columns to location table, therefore if you use devel version, **you have to update your db schema**. Perhaps a bit of tuning will follow in the next days, but GRUU support should be fully functional in terms of routing. Testing and feedback will be very appreciated as well as hints on what SIP hard/phones support GRUU properly. Be also aware that now you may have to do lookup location even for within dialog requests, if the r-uri is a local GRUU. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

1 1

dispatcher didnt use the gateway
by Karsten Horsmann 17 Apr '12

17 Apr '12

Hi List! I try to use the dispatcher module to route calls to my ivr systems. But it didnt load the gateway. I didnt see my xlog message after the ds_select_dst() Any hints? Gateway is Active and Probing. #!ifdef WITH_DISPATCHER if (!lookup("location")) { if(ds_select_dst("1", "4")) xlog("DISPATCHER ds_select_dst\n"); #forward(); } #!endif [root@kamailio1 log]# kamctl fifo ds_list SET_NO:: 1 SET:: 1 URI:: sip:172.20.100.61:5060 flags=AP priority=0 attrs= -- Mit freundlichen Grüßen *Karsten Horsmann*

4 10

PDD Timer (Branch Level)
by Orlando F. Guitian 16 Apr '12

16 Apr '12

Recently, I have used TM's fr_timer() parameter to control PDD, non-responsive gateways, etc. However, I would like to know if it is possible to set the fr_timer(), or something similar, on a per branch level. For example, in comparison to our US-based gateways, some of our international gateways may require a higher PDD value. Is it possible to assign a branch-specific timeout value? Thank you, Orlando -- Orlando F. Guitian OrlandoG(a)gmail.com <OrlandoG(a)gmail.com>www.AsteriskCertified.com<http://www.asteriskcertified.com/>

2 1

kamctl ps in 1.5.0 equivallent in 3.1.2
by Renan Capaverde 16 Apr '12

16 Apr '12

Hello list, In kamailio 1.5.0 there is one command called 'ps'. Which when executed produces an output similar to: Process:: ID=0 PID=29533 Type=attendant Process:: ID=1 PID=29537 Type=SIP receiver udp:192.168.166.75:5060 Process:: ID=2 PID=29538 Type=SIP receiver udp:192.168.166.75:5060 Process:: ID=3 PID=29539 Type=SIP receiver udp:192.168.166.75:5060 Process:: ID=4 PID=29540 Type=SIP receiver udp:192.168.166.75:5060 Process:: ID=5 PID=29541 Type=timer Process:: ID=6 PID=29542 Type=timer Process:: ID=7 PID=29543 Type=MI FIFO Process:: ID=8 PID=29544 Type=TCP receiver Process:: ID=9 PID=29545 Type=TCP receiver Process:: ID=10 PID=29546 Type=TCP receiver Process:: ID=11 PID=29547 Type=TCP receiver Process:: ID=12 PID=29548 Type=TCP main In kamailio 3.1.2, I get the following output: *500 command 'ps' not available *Is there any equivalent for *kamctl ps* in version 3.1.2? Regards, -- *Renan Capaverde* /Estagiário Nível Superior/ /DDT - STE - Soluções em Tecnologia e Embarcados/ *DÍGITRO TECNOLOGIA* *E-mail:* renan.capaverde(a)digitro.com.br <mailto:renan.capaverde@digitro.com.br> *Fone:* +55 48 3281-7000*Ramal:* 8132 *Fax:* +55 48 3281-7299 *Site:* www.digitro.com <http://www.digitro.com> /"Antes de imprimir, pense na sua responsabilidade e no seu compromisso com o meio ambiente"/ Esta mensagem, incluindo seus anexos, é reservada somente à Dígitro e ao destinatário da mensagem. Caso você tenha recebido esta mensagem por engano, queira por favor, retorná-la ao remetente e apagá-la de seus arquivos.

2 4

Kamailio and Oracle
by Orlando F. Guitian 16 Apr '12

16 Apr '12

Hi. I am attempting to install Kamailio with the DB_ORACLE module, but I am running into an error. Basically, I am running a CentOS 64-bit and I have also installed the instant client SDK and header files (v10.2) from Oracle. However, the installation is erroring out when trying to find the Oracle XE Client directory (v10.2). However, I am unable to find an Oracle 10g XE Client download in 64 bit version. Does anybody have a work around? Or is there another way to install Kamailio with Oracle? Thank you, Orlando -- Orlando F. Guitian OrlandoG(a)gmail.com <OrlandoG(a)gmail.com>www.AsteriskCertified.com<http://www.asteriskcertified.com/>

2 2

Failed shared memory allocation even though there's enough free memory
by Alex Hermann 16 Apr '12

16 Apr '12

Hello, i'm seeing a lot of failed memory allocations for shared memory after the shared memory has been fully used once (see shmem:max_used_size below). Used_size keeps increasing fast on a heavy loaded server, until it reaches the total_size. From that moment memory allocations start failing and eventually used_size starts dropping. After while, even when there's a lot of free memory, new allocations keep failing. ERROR:tm:build_uac_req: no more share memory (19852) ERROR:tm:t_uac: failed to build message ERROR:presence:send_notify_request: in function tmb.t_request_within ERROR:presence:notify: sending Notify not successful ERROR:presence:publ_notify: Could not send notify for dialog When i request the shmem statistics at such time, there's lots of free memory: shmem:total_size = 268435456 shmem:used_size = 3749696 shmem:real_used_size = 4822288 shmem:max_used_size = 268048584 shmem:free_size = 263613168 shmem:fragments = 62156 This is on 1.5.x, any suggestion on why it keeps failing and how to prevent this error? -- Greetings, Alex Hermann

2 1

Question about processing of packet
by Fabian Borot 15 Apr '12

15 Apr '12

greetings, I have a customer that is sending the REGISTER with 2 ports in the Contact header: Contact: <sip:44435661000448181@201.xxx.xxx.xxx:19778:5060> After some troubleshooting we found that the wireless router is the one inserting the 2nd port. It is not the SIP UA itself. Is it possible to "sanitize" the REGISTER at the beginning of the configuration logic with the TEXTOPS module so that we can leave one port and then process the REGISTERwith the typical: if (!www_authorize("$fd", "subscriber")){...} Or will this only applies to messages that are proxied/forwarded (example: received malformed INVITE, before calling route[1] to send it to the destination sanitize it with the TEXTOPS functions)I guess my question is: after removing the extra port at the begining, when I call the "if (!www_authorize("$fd", "subscriber"))",will it process the modified version or the original one? txs a lot fborot

3 3

Re: [SR-Users] Visualizing SIP Trace
by Norm 15 Apr '12

15 Apr '12

Take a look at Homer. Reda Aouad <reda.aouad(a)gmail.com> wrote: >Hello, > >Anyone knows a tool/software (NOT CDRTool) to graphically visualize the SIP >traces recorded in database by Kamailio's siptrace module? > >Thanks >Reda > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Visualizing SIP Trace
by Reda Aouad 15 Apr '12

15 Apr '12

Hello, Anyone knows a tool/software (NOT CDRTool) to graphically visualize the SIP traces recorded in database by Kamailio's siptrace module? Thanks Reda

1 0

RFC 5626 Outbound/ sip.instance in Contact header?
by Daniel Pocock 15 Apr '12

15 Apr '12

Hi, I'm just wondering if there has been any type of work to implement any part of RFC 5626, particularly the registrar server code? Lumicall now generates a UUID at install time, and sends that as sip.instance in the Contact header. It always sends reg-id=1 (only trying one proxy at the moment). Although this is not a full implementation of the spec, it seems to be sufficient for eliminating extra Contact records in the repro registration server (from reSIProcate). However, I've noticed Kamailio doesn't seem to understand this parameter yet. Regards, Daniel

2 1

Core Dump from select stmt
by Akan Technology 14 Apr '12

14 Apr '12

hello, I am running kamailio 3.2.2 on Solaris 10 64 bit and I am getting a core dump on this statement: $ru = "sip:" + $rU + "@" + $sel(cfg_get.registrar1.server_ip) + $sel(cfg_get.registrar1.server_port); Here is how the variable is defined: registrar1.server_ip = "xxx.xxx.xxx.xxx" desc "Registrar server IP address" registrar1.server_port = "5080" desc "Registrar server Port" Here is the output from the logs with debug: 10(25373) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=1072 a=65 n=assign 10(25373) DEBUG: <core> [select.c:424]: Calling SELECT 1004b2bc0 10(25373) DEBUG: <core> [select.c:424]: Calling SELECT 1004b4da0 10(25373) ERROR: *** cfgtrace:14(25377) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 22 14(25377) DEBUG: <core> [tcp_main.c:3555]: DBG: handle_ser_child: dead child 10, pid 25373 (shutting down?) 14(25377) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003738b8, 22, 0, 0x0) fd_no=18 called 14(25377) DEBUG: <core> [tcp_main.c:3316]: DBG: handle_tcp_child: dead tcp child 0 (pid 25373, no 10) (shutting down?) 14(25377) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003738b8, 24, 1, 0x0) fd_no=17 called 0(25363) ALERT: <core> [main.c:751]: child process 25373 exited by a signal 11 0(25363) ALERT: <core> [main.c:754]: core was generated 0(25363) INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD 14(25377) INFO: <core> [main.c:817]: INFO: signal 15 received Here is the full route code: route[TO_REGISTRAR] { # check if Registrar server's IP is defined if (strempty($sel(cfg_get.registrar1.server_ip))) { xlog("SCRIPT: REGISTRAR - registrar1.server_ip not defined\n"); return; } $ru = "sip:" + $rU + "@" + $sel(cfg_get.registrar1.server_ip) + ":" + $sel(cfg_get.registrar1.server_port); route(RELAY); exit; } # End of TO_Registrar Route I am trying to setup the proxy server to route all registers requests to another kamailio server Thanks Nathaniel

1 0

200 OK with SDP got wrong Contact HF after fix_nated_contact()
by Karsten Horsmann 13 Apr '12

13 Apr '12

Hello! I got the following problem. My 200 OK with SDP sends the private ip of the B-Leg party. Kamailio is multihomed (pulic/private address) in front of an ivr system. 222.222.222.222 public ip kamailio 172.20.100.74 private ip kamailio 172.20.100.61 private ip ivr 217.217.217.217 public ip uac 172.20.100.203 private ip uac U 2012/04/13 13:56:57.307314 222.222.222.222:5060 -> 217.217.217.217:42885 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.103:28472;rport=42885;branch=z9hG4bK-d8754z-824b81ca678a7de4-1---d8754z-;received=217.217.217.217. From: <sip:4horsmann@222.222.222.222>;tag=e9d1124c. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-1c78ac-2ca01e29. Call-ID: NjQ5YWU0NGYxZjM3YWJhYmE5ZWYxYmQzZjYzYzQyMzI.. CSeq: 2 INVITE. Content-Length: 202. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=e9d1124c;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=e9d1124c;nat=yes>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61:5060>. P-hint: NATMANAGE WITH SDP. . v=0. o=aculab-04246C01 2060618394 2060618394 IN IP4 212.59.42.189. s=-. c=IN IP4 222.222.222.222. t=0 0. m=audio 40390 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=nortpproxy:yes. ############################################################## # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT xlog("NATMANAGE M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); if(has_body("application/sdp")) { xlog("NATMANAGE M=$rm with SDP\n"); append_hf("P-hint: NATMANAGE WITH SDP\r\n"); fix_nated_contact(); } if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (isbflagset(FLB_NATB)) return; if (dst_ip == 212.59.42.189) { xlog("rtpproxy_manage extern zu intern\n"); #rtpproxy_manage("OCFEI","172.20.10.74"); rtpproxy_manage("FWCEI","172.20.10.74"); #xlog("e->i Body vor fix: $rb\n"); #fix_nated_contact(); #xlog("e->i Body nach fix: $rb\n"); } else { xlog("rtpproxy_manage intern zu extern\n"); #rtpproxy_manage("OCFIE","222.222.222.222"); rtpproxy_manage("FWCIE","222.222.222.222"); xlog("i->e Body vor fix: $rb\n"); fix_nated_contact(); xlog("i->e Body nach fix: $rb\n"); } if (is_request()) { if (!has_totag()) { add_rr_param(";nat=yes"); } } if (is_reply()) { if(isbflagset(FLB_NATB)) { fix_nated_contact(); } } #!endif return; } -- Mit freundlichen Grüßen *Karsten Horsmann*

1 0

200 OK with SDP gets private ip in contact field
by Karsten Horsmann 13 Apr '12

13 Apr '12

Hello! I get step by step to my multihomed setup and have now problems that kamailio didnt rewrite the 200 OK to my public ip address. I have attached an ngrep trace and my kamailio 3.2.2 config. Would be great if someone can give me an hint! 222.222.222.222 public ip-address from kamailio 172.20.100.74 private ip-address from kamailio 217.777.777.777 public ip-address from the UAC 172.20.100.103 private ip-address from the UAC 172.20.100.61 sip ip-address from the IVR behind kamailio 172.20.100.71 rtp ip-address from the IVR behind kamailio -- Mit freundlichen Grüßen *Karsten Horsmann*

2 2

LCR routing and From Uri
by Alexey Mechanoshin 13 Apr '12

13 Apr '12

Hello all. In my config added LCR routing by this manual: http://www.amitnepal.com/using-lcr-with-kamailio/ and if added, to 'lcr_rule' table, uri to 'from_uri' column - kamailio always reply 503 - 'No More Gateways' :-( If remove data - routing work. A'm using last kamailio from git ... Please help me change my config to working routing by checking 'from_uri' . Need check routing prefix 5499 only from IP 192.xxx.xxx.59 , as example. In Log: Apr 10 17:01:23 r59vredfs /usr/sbin/kamailio[29582]: INFO: <script>: New request - M=INVITE RURI=sip:5499@192.xxx.xxx.50:5070 F=sip:5491@192.xxx.xxx.59 T=sip:5499@192.xxx.xxx.50:5070 IP=192.xxx.xxx.59 ID=6c518b61-fd9f-122f-91b7-002655e85348 Apr 10 17:01:23 r59vredfs /usr/sbin/kamailio[29582]: INFO: <script>: Entering route[LCR] for method: INVITE <sip:5499@192.xxx.xxx.50:5070>, and rU=5499, caller_uri='0' Apr 10 17:01:23 r59vredfs /usr/sbin/kamailio[29582]: INFO: <script>: No More Gateways … Apr 10 17:01:23 r59vredfs /usr/sbin/kamailio[29582]: INFO: <script>: Send back 503 code … MySQL data: mysql> select * from lcr_rule; +----+--------+--------+----------+---------+---------+ | id | lcr_id | prefix | from_uri | stopper | enabled | +----+--------+--------+----------+---------+---------+ | 1 | 1 | 5498 | | 0 | 1 | | 2 | 1 | 57 | NULL | 0 | 1 | | 3 | 1 | 58 | NULL | 0 | 1 | | 4 | 1 | 541 | NULL | 0 | 1 | | 5 | 1 | 5499 | sip:192.xxx.xxx.59 | 1 | 1 | +----+--------+--------+----------+---------+---------+ 5 rows in set (0.00 sec) mysql> select * from lcr_gw; +----+--------+---------+----------------+----------+------+--------+------------+-----------+-------+--------+------+-------+---------+ | id | lcr_id | gw_name | ip_addr | hostname | port | params | uri_scheme | transport | strip | prefix | tag | flags | defunct | +----+--------+---------+----------------+----------+------+--------+------------+-----------+-------+--------+------+-------+---------+ | 1 | 1 | route1 | 213.xxx.xxx.26 | NULL | 5060 | NULL | 1 | 1 | NULL | | NULL | 1 | NULL | | 2 | 1 | routemy | 192.xxx.xxx.59 | NULL | 5070 | NULL | 1 | 1 | NULL | NULL | NULL | 1 | NULL | | 3 | 1 | route1 | 213.xxx.xxx.27 | NULL | 5060 | NULL | 1 | 1 | NULL | NULL | NULL | 1 | NULL | +----+--------+---------+----------------+----------+------+--------+------------+-----------+-------+--------+------+-------+---------+ 3 rows in set (0.00 sec) mysql> select * from lcr_rule_target; +----+--------+---------+-------+----------+--------+ | id | lcr_id | rule_id | gw_id | priority | weight | +----+--------+---------+-------+----------+--------+ | 1 | 1 | 1 | 1 | 10 | 1 | | 2 | 1 | 2 | 2 | 10 | 1 | | 3 | 1 | 3 | 2 | 10 | 1 | | 4 | 1 | 4 | 2 | 10 | 1 | | 5 | 1 | 5 | 1 | 10 | 1 | | 6 | 1 | 5 | 3 | 20 | 1 | +----+--------+---------+-------+----------+--------+ 6 rows in set (0.00 sec) Config: #!define WITH_LCR ... #!ifdef WITH_LCR loadmodule "avpops.so" loadmodule "lcr.so" #!endif ... #!ifdef WITH_LCR modparam("lcr", "db_url",DBURL) modparam("lcr", "gw_uri_avp", "$avp(i:709)") modparam("lcr", "ruri_user_avp", "$avp(i:500)") modparam("lcr", "flags_avp", "$avp(i:712)") modparam("lcr", "lcr_id_avp", "$avp(s:lcr_id_avp)") #!endif ... # dispatch destinations to PSTN route(PSTN); # LCR route route(LCR); # user location service #route(LOCATION); ... # --=== LCR routing ===-- # route[LCR] { xlog("L_INFO","Entering route[LCR] for method: $rm <$ru>, and rU=$rU, caller_uri='$var(caller_uri)'\n"); #!ifdef WITH_LCR ### if (!load_gws(1)) { ### if (!load_gws(1, $rU)) { if (!load_gws(1)) { sl_send_reply("500", "Server Internal Error - Cannot load gateways"); exit; } else { $var(i) = 0; while(is_avp_set("$(avp(i:709)[$var(i)])")) { xlog("L_INFO", "loading gw_uri_avp[$var(i)]='$(avp(i:709)[$var(i)])'\n"); $var(i) = $var(i) + 1; } if(is_avp_set("$avp(i:709)")) { xlog("L_INFO", "Trying gateway '$avp(i:709)'\n"); } else { xlog("L_INFO", "No More Gateways …\n"); } # try the first matched gateway if (next_gw()) { xlog("L_INFO", "ruri_user_avp='$avp(i:500)'\n"); # Print AVP - for debug #avp_print(); # Route to failure for failover route(RELAY); } else { avp_print(); xlog("L_INFO", "Send back 503 code …\n"); sl_send_reply("503", "No available gateways"); exit; } } #!endif #sl_send_reply("503", "Service Unavailable"); #exit; return; } PS Sorry for my bad English please. -- "В связи с отсутствием интереса общественности, конец света отменяется" (с) ? С Уважением, Механошин Алексей

2 8

rtpproxy 1.2.1 segfaults with kamailio 3.2.2 in bridging mode
by Karsten Horsmann 12 Apr '12

12 Apr '12

Hi all, i try to register at the rtpproxy mailinglist, but its still pending. Maybe someone here had the same issue. In my multihomed setup (with mhomed=1 in kamailio.cfg) i had segfaults from rtpproxy if i called rtpproxy_manage with params. Notice that i must run rtpproxy as root to get core files. Any hints? Maybe my kamailio config isnt right? ulimit -c unlimited ; /usr/local/bin/rtpproxy -u root -s /home/sys/bin/rtpproxy.sock -l <PUBLIC-IP> 172.20.100.74 -d DBUG:LOG_LOCAL5 Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:handle_command: received command "V" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:doreply: sending reply "20040107#012" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:handle_command: received command "VF 20050322" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:doreply: sending reply "1#012" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:handle_command: received command "VF 20071116" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:doreply: sending reply "1#012" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:handle_command: received command "VF 20081102" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:doreply: sending reply "1#012" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:handle_command: received command "UEIc107,0,8,101 NTgxNzRkMmJmYzFlYjg2NTdiN2Q3MzJkYjkzMzI3Yjk. 217.XXX.XXX.XX 49814 00671612;1" Apr 10 15:13:40 kamailio1 rtpproxy[19728]: INFO:handle_command: new session NTgxNzRkMmJmYzFlYjg2NTdiN2Q3MzJkYjkzMzI3Yjk., tag 00671612;1 requested, type strong Apr 10 15:13:40 kamailio1 rtpproxy[19728]: INFO:handle_command: new session on a port 36156 created, tag 00671612;1 Apr 10 15:13:40 kamailio1 rtpproxy[19728]: INFO:handle_command: pre-filling caller's address with 217.XXX.XX.XX:49814 Apr 10 15:13:40 kamailio1 rtpproxy[19728]: DBUG:doreply: sending reply "36156 212.XX.XX.XXX#012" (gdb) bt #0 0x0804ccb8 in ishostseq (ia1=0x99c54c8, ia2=0x0) at rtpp_util.c:55 #1 0x080514ba in handle_command (cf=0xbffb9d8c, controlfd=5, dtime=1334063620.8220949) at rtpp_command.c:761 #2 0x0804afb7 in process_commands (argc=9, argv=0xbffda634) at main.c:752 #3 main (argc=9, argv=0xbffda634) at main.c:856 (gdb) p ia1->sa_family $1 = 2 (gdb) p ia2->sa_family Cannot access memory at address 0x0 # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT xlog("NATMANAGE M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (isbflagset(FLB_NATB)) return; if (dst_ip == PUBLIC_IP ) { xlog("rtpproxy_manage extern zu intern\n"); rtpproxy_manage("OCFEI","172.20.10.74"); } else { xlog("rtpproxy_manage intern zu extern\n"); rtpproxy_manage("OCFIE","PUBLIC_IP"); } if (is_request()) { if (!has_totag()) { add_rr_param(";nat=yes"); } } if (is_reply()) { if(isbflagset(FLB_NATB)) { fix_nated_contact(); } } #!endif return; } -- Mit freundlichen Grüßen *Karsten Horsmann*

3 8

Kamailio Failed to have audo converstaion with RTP
by Ryan Gholam 12 Apr '12

12 Apr '12

Dear Daniel , I thank you for your reply , I have a server having the Astersisk ip address (192.168.10.15) , and rtp + kamailio is installed on an another pc have the following ip (192.168.10.17) which is linked to the Astersik , and on the same pc , another network card exists having the ip address (192.168.20.3 ) which is linked to a client pc having the ip address ( 192.168.20.4) . I tracked the call and i can see SIP ACK nd BYE between 20.3 and 20.4 but there is no audio conversation this is my configuration file for kamailio attached above . P.S : testing without NATING as described in the above setup . I thank you alot again for all your help .

2 1

Variable $fu Kamailio 3.2
by Gilbert T. Gutierrez, Jr. 11 Apr '12

11 Apr '12

I wrote the code below to rewrite an extension to a phone number (It is called in route[LOCATION]). This code works fine with MULTIDOMAIN enabled but when I run it as a single domain the line $fu=$var(b); does not seem to work.. You can see that I have several xlog lines outputting the variable values into my /var/log/messages. $var(b) has the correct value in it, so I do not know what is happening. I have also included the /var/log/messages output which I redacted the phone number, domain, and extension for security purposes. I am sure I am going about this backwards, but can someone provide me some guidance as to what is going wrong? Thank you, Gilbert # Rewrite - Gilbert route[REWRITE] { # This section rewrites the outbound calling number so that caller id works correctly. #!ifdef WITH_REWRITE # lookup an outbound number to replace the extension with $var(b)="NO REV"; sql_xquery("ca","select number from pioutalias where username='$fU'","ra"); # determine if a outbound number exists if ($xavp(ra=>number)) { $var(b)="sip:" + $xavp(ra=>number) + "@" + $fd; xlog("L_INFO","var(b): '$var(b)'"); xlog("L_INFO","fu: '$fu'"); # Assign the outbound calling number $fu=$var(b); xlog("L_INFO","New fu: '$fu'"); } sql_result_free("ra"); # see if it found a number and log if it did not if ($var(b)=="NO REV") xlog("L_INFO","No number found for extension: '$fu'"); #!endif } /var/log/messages output Apr 9 14:38:38 tempfax /usr/sbin/kamailio[6088]: INFO: <script>: var(b): 'sip:602XXXXXXX@xxxx.com' Apr 9 14:38:38 tempfax /usr/sbin/kamailio[6088]: INFO: <script>: fu: 'sip:30XXXXX@xxxx.com' Apr 9 14:38:38 tempfax /usr/sbin/kamailio[6088]: INFO: <script>: New fu: 'sip:30XXXXX@xxxx.com'

2 1

dropped calls after 38 seconds openSER
by Saul Waizer 11 Apr '12

11 Apr '12

Greetings list, I am experiencing a strange behavior with openser 1.3.2 running on ubuntu 10. I have a basic configuration (see bellow) and i am using Linphone for iPad as my client. I have 2 users registered and I am able to place calls no problem. The problem is that the calls (audio or A/V) drop after 38 seconds exactly, this behavior is pretty consistent, 38 seconds is all I can get. There is no firewall in front of the clients. Here is my configuration, ip addresses changed to protect the innocent: http://pastie.org/private/x1ck8rxjcxv6hl44hrmqg You can see the logs of the call here (the majority): http://pastie.org/private/4fj5efpbsrxan8plzqvfza Am I missing something or is there anything that needs to be changed in the routing/configuration to achieve basic functionality? Thank you in advance!

2 1

Re: [SR-Users] Variable $fu Kamailio 3.2
by Alex Balashov 10 Apr '12

10 Apr '12

$fu is not mutable. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com "Gilbert T. Gutierrez, Jr." <mailing-lists(a)phoenixinternet.net> wrote: >I wrote the code below to rewrite an extension to a phone number (It is >called in route[LOCATION]). This code works fine with MULTIDOMAIN >enabled but when I run it as a single domain the line $fu=$var(b); does >not seem to work.. You can see that I have several xlog lines >outputting the variable values into my /var/log/messages. $var(b) has >the correct value in it, so I do not know what is happening. I have also >included the /var/log/messages output which I redacted the phone number, >domain, and extension for security purposes. I am sure I am going about >this backwards, but can someone provide me some guidance as to what is >going wrong? > >Thank you, >Gilbert > ># Rewrite - Gilbert >route[REWRITE] { ># This section rewrites the outbound calling number so that caller id >works correctly. >#!ifdef WITH_REWRITE > # lookup an outbound number to replace the extension with > $var(b)="NO REV"; > sql_xquery("ca","select number from pioutalias where >username='$fU'","ra"); > # determine if a outbound number exists > if ($xavp(ra=>number)) { > $var(b)="sip:" + $xavp(ra=>number) + "@" + $fd; > xlog("L_INFO","var(b): '$var(b)'"); > xlog("L_INFO","fu: '$fu'"); > # Assign the outbound calling number > $fu=$var(b); > xlog("L_INFO","New fu: '$fu'"); > } > sql_result_free("ra"); > # see if it found a number and log if it did not > if ($var(b)=="NO REV") > xlog("L_INFO","No number found for extension: '$fu'"); >#!endif >} > > >/var/log/messages output > >Apr 9 14:38:38 tempfax /usr/sbin/kamailio[6088]: INFO: <script>: >var(b): 'sip:602XXXXXXX@xxxx.com' >Apr 9 14:38:38 tempfax /usr/sbin/kamailio[6088]: INFO: <script>: fu: >'sip:30XXXXX@xxxx.com' >Apr 9 14:38:38 tempfax /usr/sbin/kamailio[6088]: INFO: <script>: New >fu: 'sip:30XXXXX@xxxx.com' > > > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 5

[OT] sip:provider CE v2.5 is out!
by Andreas Granig 10 Apr '12

10 Apr '12

Hi all, I'm excited to announce the release of the Sipwise sip:provider Community Edition v2.5, a free and open source turn-key platform, which uses Kamailio, Sems and Asterisk in its core to provide a full-blown and feature-rich VoIP soft-switch. http://www.sipwise.com/news/announcements/spce-v2_5-release/ New core features are IPv6 and video support, serial call hunting and time based routing, beside lots of other fixes and enhancements. Check our VM images to get started within a couple of minutes and learn what can be built with the power of Kamailio as a stateless load-balancer and a stateful proxy/registrar, and Sems as an SBC and application server. Thanks a lot to all developers, contributors and members of this mailing list to make this possible and for helping us out! Andreas

1 0

ClueCon 2012: Call For Speakers
by Michael Collins 10 Apr '12

10 Apr '12

[image: Inline image 2] ClueCon 2012 - Call For Speakers ClueCon - the open source telephony conference by developers, for developers - would like to announce that we are having an open call for speaking proposals for this year's event. If you have an idea for a technical presentation for ClueCon 2012 then we would like to hear about. What makes a great ClueCon presentation? The tech savvy crowd that attends ClueCon loves *technical* presentations. In general, the more technical the presentation, the better. If you are thinking about a presentation then consider these points: - ClueCon talks are 30 minutes in length, including Q&A time with the audience - ClueCon has a special focus on open source VoIP and telephony projects like FreeSWITCH, Asterisk, OpenSIPS, and Kamailio - Attendees enjoy hearing about projects built with open source tools - Highly technical discussions that show the nuts and bolts are especially well-liked - The audience appreciates seeing and participating in live demonstrations Please send your proposals to marketing(a)cluecon.com. Be sure to include a working title, description of the talk, and name of the presenter. Don't delay! There are a limited number of openings. ClueCon 2012 Registration Information ClueCon 2012 registration is now open. Visit the registration page<http://www.cluecon.com/register?cc12cfs>for details. Be sure to book your room at the Wyndham <http://www.cluecon.com/hotels?cc12cfs> and qualify for the $300 discount. As always, feel free to call us at 877.742.CLUE (877.742.2583) if you have any questions about ClueCon 2012. Also, keep in mind that the FreeSWITCH community has a conference call<http://wiki.freeswitch.org/wiki/Weekly_Conference_Call?cc12cfs>each Wednesday at 1PM Eastern time. This is a great opportunity to talk about open source telephony and get to know a number folks who will be at ClueCon 2012. Stay tuned for more news about ClueCon speakers, sponsors, and related events! -- Michael S Collins ClueCon Team http://www.cluecon.com 877-7-4ACLUE cc12cfs2

1 0

Can rtpproxy be used withou NAT ?
by Rabary 10 Apr '12

10 Apr '12

Hi mailing, I installed kamailio 3.2, rtpproxy 1.2.1, callcontrol 2.0.15 on a vz, and cdrtool 8.2.5 and freeradius 2.1.10 on another vz. The 2 vz container have public ip address, and the UAC have private ip address. I want to use rtpproxy, and the following are what ps and netstat command returns about rtpproxy: teddy@kamailio:~$ ps aux | grep rtpproxy teddy 22866 0.0 0.0 3312 800 pts/0 S+ 11:08 0:00 grep rtpproxy teddy 31326 0.0 0.0 11360 804 ? Ssl Apr06 0:02 /usr/sbin/rtpproxy -F -l our_public_ip -s udp:localhost 22222 teddy@kamailio:~$ sudo netstat -pln | grep rtp udp 0 0 127.0.0.1:22222 0.0.0.0:* 31326/rtpproxy And my problem is: when I make calls, for example the UAC1 calls UAC2, with ngrep I see the UAC1 calls UAC1 and not UAC2, and I don't know why. In kamailio config file, there are directive WITH_NAT for everything related to rtpproxy (loadmodule, routing logic, etc) as you can see in the attached conf file. I try disable the use of this directive WITH_NAT so I disable the use of rtpproxy in kamailio and it works: when UAC1 calls UAC2, the UAC2 is ringing. Please tell me what am I doing wrong, or to use rtpproxy without NAT is not possible ? In attached file the kamailio config file, the diff between rtpproxy enable and rtpproxy disable, and the result of ngrep and what is in syslog when I made calls. Thanks in advance. -- Rabary Teddy Inutile d'imprimer ce mail

2 2

ACK to 200 OK discarded by loose_route()
by SIP Mailing-list 10 Apr '12

10 Apr '12

Hi guys, Hope someone can help me with this. The background: I'm just trying to implement a simple load balancer with one source and multiple destinations using the call load balancer (ALG10) in dispatcher. kamailio version 3.2.0 The symptoms: I have a simple script working in one test environment (csipsimple -> kamailaio -> Twinkle) but can't get it to work in another (Dialogic HMP 3.0 -> kamailio -> Dialogic HMP 3.0) The details: I've done a debug trace (below) in both environments and can't see the problem. For some reason the ACK is destroyed before it is forwarded even though the log says "[forward.c:601]: Sending:#012ACK..." Any help would be much appreciated! TIA, Richard kamailio.cfg: ... #!KAMAILIO # # Kamailio (OpenSER) SIP Server v3.2 - default configuration script # - web: http://www.kamailio.org # - git: http://sip-router.org # # Direct your questions about this file to: <sr-users(a)lists.sip-router.org> # # Refer to the Core CookBook at http://www.kamailio.org/dokuwiki/doku.php # for an explanation of possible statements, functions and parameters. # # # Several features can be enabled using '#!define WITH_FEATURE' directives: # # RAC: Uses dispatcher algorithm 10 to keep track of load distribution # # Use: kamctl start/stop/restart ####### Global Parameters ######### # Output goes to /var/log/syslog # 5 gives too much output # 3 is DEBUG, even this can go crazy # 2 is INFO # 1 is NOTICE debug=3 #log_stderror=yes memdbg=5 memlog=5 mem_summary=2 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ auto_aliases=no /* add local domain aliases */ alias=10.130.11.121:5060 /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:10.130.11.121:5060 /* port to listen to * - can be specified more than once if needed to listen on many ports */ #port=5062 # life time of TCP connection when there is no traffic # - a bit higher than registration expires to cope with UA behind NAT tcp_connection_lifetime=3605 ####### Modules Section ######## # set paths to location of modules (to sources or installation folders) #!ifdef WITH_SRCPATH mpath="modules_k:modules" #!else mpath="/usr/lib/kamailio/modules_k/:/usr/lib/kamailio/modules/" #!endif # For the kamctl interface loadmodule "mi_fifo.so" #loadmodule "kex.so" # TM module is required for t_relay() loadmodule "tm.so" #loadmodule "tmx.so" loadmodule "sl.so" # RR module is required for loose_route() and record_route() loadmodule "rr.so" # PV is required for avp's for ALG10 loadmodule "pv.so" # Used for mf_process_maxfwd_header() loadmodule "maxfwd.so" #loadmodule "usrloc.so" #loadmodule "registrar.so" # textops is required for is_method() loadmodule "textops.so" # For has_totag() loadmodule "siputils.so" # xlog is required for user xlog() formatted messages. Output goes to /var/log/messages loadmodule "xlog.so" # For sanity_check() loadmodule "sanity.so" #loadmodule "ctl.so" #loadmodule "cfg_rpc.so" #loadmodule "mi_rpc.so" #loadmodule "acc.so" # Added by RAC 2012-04-04: required for ds_select_dst() etc loadmodule "dispatcher.so" # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # Added by RAC 2012-04-04 # ----- dispatcher params ----- modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "force_dst", 0) modparam("dispatcher", "use_default", 1) modparam("dispatcher", "ds_ping_method", "OPTIONS") # Only set ping reply codes that are acceptable. CE should only reply "200OK" if OK, "486 Busy Here" if not modparam("dispatcher", "ds_ping_reply_codes", "class=2") modparam("dispatcher", "ds_ping_from", "sip:proxy@10.130.11.121") modparam("dispatcher", "ds_ping_interval", 20) # In this mode only inactive destinations marked as probe-able will be pinged modparam("dispatcher", "ds_probing_mode", 2) modparam("dispatcher", "ds_probing_threshhold", 1) modparam("dispatcher", "ds_hash_expire", 3600) # Flag "2" MUST be set to use the AVPs listed below. If not set these will be <null> modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") # For algorithm 10, call load distribution duid (in list_file), dstid_avp and ds_hash_size are required modparam("dispatcher", "dstid_avp", "$avp(dsdstid)") # Appears to be the size (2^ds_hash_size) of a hashtable for storing the state of individual sessions # Presumably needs to be bigger than the number of concurrent sessions expected # 2^12 = 4096 modparam("dispatcher", "ds_hash_size", 12) ####### Routing Logic ######## # ds_load_update(): # if it is a BYE or CANCEL - remove the load from destination address used to forward the INVITE # if it is a reply to INVITE - set internal state to confirmed for call load structure when reply code is 2xx. # # ds_load_unset(): Remove the call load for the destination that routed the call. # Main SIP request routing logic # - processing of any incoming SIP request starts with this route # - note: this is the same as route { ... } request_route { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } # Added by RAC 2012-04-04 # Do not run ds_load_update() here; the reply to the orginal invite is sufficient to release the load # loose_route() performs routing of in-dialog requests if(has_totag()) { if (loose_route()) { # t_relay() relays a message statefully; forward() (stateless) easily gets in a muddle if(!t_relay()) { if (method == "ACK") xlog("L_ERR", "cid:$ci [$rm] [200-OK] t_relay failed\n"); else xlog("L_WARN", "cid:$ci Existing Transaction relay failed: [$rm] from($ft) [$fu] to($tt) [$tu]\n"); sl_reply_error(); } else xlog("L_INFO", "cid:$ci Existing Transaction: [$rm] from($ft) [$fu] to($tt) [$tu]\n"); } else if (method == "ACK") { if (t_check_trans()) { # stateful ACK after 487 or 404 t_relay(); } else { # ACK without transaction, ignore and discard xlog("L_WARN", "cid:$ci Dropping ACK: from($ft) [$fu] to($tt) [$tu]\n"); } } else { sl_send_reply("404","Not here"); } exit; } # has_totag() # dest set1, ALG10: call load distribution: least number of calls receives the next call # Keeps a hash table of calls based on Call-ID to track call load per destination if(ds_select_dst("1", "10")) xlog("L_NOTICE", "cid:$ci Destination Selected: [$rm] from($ft) [$fu] routed to [sip:$tU@$dd:$dp] ($avp(dsdstid))\n"); else { xlog("L_ERR", "No destinations available: [$rm] from [$fu]\n"); sl_send_reply("500","No destinations available"); drop(); exit(); } # record_route() causes ALL messages to go through the proxy including ACKs and BYEs. Results in 16 SIP packets # Without record_route(), after 200OK, the ACK and BYE is sent direct. Results in 11 SIP packets # Must use record_route() with call load distribution, otherwise we will not know when a call is released # and cannot account for it record_route(); # With t_relay(), the proxy creates its own messages like 100 trying, instead of forwarding the original # forward() is not recommended t_relay(); } event_route[dispatcher:dst-down] { xlog("L_ERR", "Destination down: [$rm] $ru ($du)\n"); } event_route[dispatcher:dst-up] { xlog("L_NOTICE", "Destination up: [$rm] $ru\n"); } # Added by RAC 2012-04-04: Update call loads on replies for ALG10. # Default action is to reply upstream statelessly using Via headers onreply_route { xlog("L_INFO", "cid:$ci Reply: [$rm] [$rs-$rr] from($ft) [$fu] to($tt) [$tu]\n"); if(is_method("INVITE")) { if(status=~"2[0-9][0-9]") ds_load_update(); else if(status=~"[3-7][0-9][0-9]") ds_load_unset(); } else if(is_method("BYE")) { ds_load_update(); } } ... Bad debug trace (CE to IVRSim): NOTE: Phone numbers have been changed ... Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:628]: SIP Request: Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:630]: method: <ACK> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:632]: uri: <sip:18000005835@10.130.11.121> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:634]: version: <SIP/2.0> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=f8a6698-0-13c4-50022-16d0d4-103b30a3-16d0d4 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [81]; uri=[ sip:18000005835@10.130.11.121] Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [<sip:18000005835@10.130.11.121>] Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <ACK> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/parse_via.c:1288]: Found param type 232, <branch> = <z9hG4bK-182890-5e5e75ec-235d6d1e>; state=16 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/parse_via.c:2563]: end of header reached, state=5 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [receive.c:146]: After parse_msg... Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [receive.c:187]: preparing to run routing scripts... Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: sl [sl_funcs.c:307]: DEBUG : sl_filter_ACK: to late to be a local ACK! Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: maxfwd [mf_funcs.c:85]: value = 70 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=774ee38-650b820a-13c4-50022-182890-4de156df-182890 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: sanity [mod_sanity.c:251]: sanity checks result: 1 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: siputils [checks.c:107]: totag found Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: rr [loose.c:85]: is_preloaded: No Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [socket_info.c:502]: grep_sock_info - checking if host==us: 13==13 && [10.130.11.121] == [10.130.11.121] Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [socket_info.c:505]: grep_sock_info - checking if port 5060 matches port 5060 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: rr [loose.c:594]: Next hop: 'sip:10.130.11.121;lr;ftag=774ee38-650b820a-13c4-50022-182890-4de156df-182890' is loose router Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: rr [loose.c:644]: The last route URI: 'sip:10.130.11.121;lr;ftag=774ee38-650b820a-13c4-50022-182890-4de156df-182890' Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=6 , global msg id=5 , T on entrance=(nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=37904, isACK=1 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [msg_translator.c:204]: check_via_address(10.130.11.101, 10.130.11.101, 0) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [forward.c:601]: Sending:#012ACK sip:10.130.11.121;lr;ftag=774ee38-650b820a-13c4-50022-182890-4de156df-182890 SIP/2.0#015#012From: <sip:441865000101@10.130.11.101>;tag=774ee38-650b820a-13c4-50022-182890-4de156df-182890#015#012To: <sip:18000005835@10.130.11.121>;tag=f8a6698-0-13c4-50022-16d0d4-103b30a3-16d0d4#015#012Call-ID: fb041312-da6d-4fb7-bfee-32677fbab37b#015#012CSeq: 1 ACK#015#012Via: SIP/2.0/UDP 10.130.11.121;branch=z9hG4bKcydzigwkX#015#012Via: SIP/2.0/UDP 10.130.11.101:5060;branch=z9hG4bK-182890-5e5e75ec-235d6d1e#015#012Max-Forwards: 69#015#012Contact: <sip:441865000101@10.130.11.101>#015#012Allow-Events: refer#015#012Content-Length: 0#015#012#015#012. Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [forward.c:603]: orig. len=550, new_len=566, proto=1 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:628]: SIP Request: Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:630]: method: <ACK> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:632]: uri: <sip:10.130.11.121;lr;ftag=774ee38-650b820a-13c4-50022-182890-4de156df-182890> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:634]: version: <SIP/2.0> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=f8a6698-0-13c4-50022-16d0d4-103b30a3-16d0d4 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [81]; uri=[ sip:18000005835@10.130.11.121] Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28277]: DEBUG: <core> [receive.c:290]: receive_msg: cleaning up Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [<sip:18000005835@10.130.11.121>] Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <ACK> Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_via.c:1288]: Found param type 232, <branch> = <z9hG4bKcydzigwkX>; state=16 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_via.c:2563]: end of header reached, state=5 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [receive.c:146]: After parse_msg... Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [receive.c:187]: preparing to run routing scripts... Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: sl [sl_funcs.c:307]: DEBUG : sl_filter_ACK: to late to be a local ACK! Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_via.c:1288]: Found param type 232, <branch> = <z9hG4bK-182890-5e5e75ec-235d6d1e>; state=16 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_via.c:2563]: end of header reached, state=5 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=100 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:528]: parse_headers: this is the second via Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: maxfwd [mf_funcs.c:85]: value = 69 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=774ee38-650b820a-13c4-50022-182890-4de156df-182890 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: sanity [mod_sanity.c:251]: sanity checks result: 1 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: siputils [checks.c:107]: totag found Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: rr [loose.c:108]: No Route headers found Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: rr [loose.c:838]: There is no Route HF Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: tm [t_lookup.c:1079]: DEBUG: t_check_msg: msg id=6 global id=5 T start=(nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=37904, isACK=1 Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: tm [t_lookup.c:1148]: DEBUG: t_check_msg: msg id=6 global id=6 T end=(nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: WARNING: <script>: cid:fb041312-da6d-4fb7-bfee-32677fbab37b Dropping ACK: from(774ee38-650b820a-13c4-50022-182890-4de156df-182890) [ sip:441865000101@10.130.11.101] to(f8a6698-0-13c4-50022-16d0d4-103b30a3-16d0d4) [ sip:18000005835@10.130.11.121] Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: last message repeated 5 times Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil) Apr 6 14:10:29 UKCY-VM-LINUX199 /usr/sbin/kamailio[28276]: DEBUG: <core> [receive.c:290]: receive_msg: cleaning up ... Bad SIP ACK: ... Session Initiation Protocol Request-Line: ACK sip:18000005835@10.130.11.121 SIP/2.0 Method: ACK Request-URI: sip:18000005835@10.130.11.121 Request-URI User Part: 18000005835 Request-URI Host Part: 10.130.11.121 [Resent Packet: False] [Request Frame: 7] [Response Time (ms): 29] Message Header From: <sip:441865000101@10.130.11.101 >;tag=774ee38-650b820a-13c4-50022-182890-4de156df-182890 SIP from address: sip:441865000101@10.130.11.101 SIP from address User Part: 441865000101 SIP from address Host Part: 10.130.11.101 SIP tag: 774ee38-650b820a-13c4-50022-182890-4de156df-182890 To: <sip:18000005835@10.130.11.121 >;tag=f8a6698-0-13c4-50022-16d0d4-103b30a3-16d0d4 SIP to address: sip:18000005835@10.130.11.121 SIP to address User Part: 18000005835 SIP to address Host Part: 10.130.11.121 SIP tag: f8a6698-0-13c4-50022-16d0d4-103b30a3-16d0d4 Call-ID: fb041312-da6d-4fb7-bfee-32677fbab37b CSeq: 1 ACK Sequence Number: 1 Method: ACK Via: SIP/2.0/UDP 10.130.11.101:5060 ;branch=z9hG4bK-182890-5e5e75ec-235d6d1e Transport: UDP Sent-by Address: 10.130.11.101 Sent-by port: 5060 Branch: z9hG4bK-182890-5e5e75ec-235d6d1e Max-Forwards: 70 Route: <sip:10.130.11.121;lr;ftag=774ee38-650b820a-13c4-50022-182890-4de156df-182890> Contact: <sip:441865000101@10.130.11.101> Contact Binding: <sip:441865000101@10.130.11.101> URI: <sip:441865000101@10.130.11.101> SIP contact address: sip:441865000101@10.130.11.101 Allow-Events: refer Content-Length: 0 ... Good debug trace (Richard laptop, Twinkle local and csipsimple on wifi): ... Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:628]: SIP Request: Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:630]: method: <ACK> Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:632]: uri: <sip:123@192.168.0.104;transport=udp> Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:634]: version: <SIP/2.0> Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/parse_via.c:1288]: Found param type 235, <rport> = <n/a>; state=6 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/parse_via.c:1288]: Found param type 232, <branch> = <z9hG4bKPjWvIFG5BzVRtUe1jnpRa1ilioYiezOrTz>; state=16 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/parse_via.c:2563]: end of header reached, state=5 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [receive.c:146]: After parse_msg... Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [receive.c:187]: preparing to run routing scripts... Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: sl [sl_funcs.c:307]: DEBUG : sl_filter_ACK: to late to be a local ACK! Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=ggpxl Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [35]; uri=[ sip:123@192.168.0.104] Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [<sip:123@192.168.0.104>] Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <10807> <ACK> Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: rr [loose.c:85]: is_preloaded: No Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [socket_info.c:502]: grep_sock_info - checking if host==us: 13==13 && [192.168.0.104] == [192.168.0.104] Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [socket_info.c:505]: grep_sock_info - checking if port 5062 matches port 5060 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [forward.c:448]: check_self: host != me Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [socket_info.c:502]: grep_sock_info - checking if host==us: 13==13 && [192.168.0.104] == [192.168.0.104] Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [socket_info.c:505]: grep_sock_info - checking if port 5062 matches port 5062 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: rr [loose.c:709]: Topmost route URI: 'sip:192.168.0.104:5062;lr;ftag=gYRr.jGE57ZMeLuxYrVmKDuHlnX964Fa' is me Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: rr [loose.c:173]: No next Route HF found Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: rr [loose.c:728]: No next URI found Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=2 , global msg id=1 , T on entrance=0xffffffffffffffff Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=17962, isACK=1 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [msg_translator.c:204]: check_via_address(192.168.0.3, 192.168.0.3, 0) Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [forward.c:601]: Sending:#012ACK sip:123@192.168.0.104;transport=udp SIP/2.0#015#012Via: SIP/2.0/UDP 192.168.0.104:5062;branch=z9hG4bKcydzigwkX#015#012Via: SIP/2.0/UDP 192.168.0.3:51351;rport=51351;branch=z9hG4bKPjWvIFG5BzVRtUe1jnpRa1ilioYiezOrTz#015#012Max-Forwards: 70#015#012From: <sip:racitup@mobile>;tag=gYRr.jGE57ZMeLuxYrVmKDuHlnX964Fa#015#012To: <sip:123@192.168.0.104>;tag=ggpxl#015#012Call-ID: zH5ub5H6ooVWQmBzZyswgMSLn7rb2xJl#015#012CSeq: 10807 ACK#015#012Content-Length: 0#015#012#015#012. Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [forward.c:603]: orig. len=418, new_len=411, proto=1 Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: last message repeated 5 times Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil) Apr 6 14:24:30 adventure /usr/sbin/kamailio[8545]: DEBUG: <core> [receive.c:290]: receive_msg: cleaning up ... Good ACK: ... Session Initiation Protocol Request-Line: ACK sip:123@192.168.0.104;transport=udp SIP/2.0 Method: ACK Request-URI: sip:123@192.168.0.104;transport=udp Request-URI User Part: 123 Request-URI Host Part: 192.168.0.104 [Resent Packet: False] [Request Frame: 13] [Response Time (ms): 6489] Message Header Via: SIP/2.0/UDP 192.168.0.3:38653 ;rport;branch=z9hG4bKPjyL0GhUP12E0Dkn2CQ5BR9aQm67DdxKfE Transport: UDP Sent-by Address: 192.168.0.3 Sent-by port: 38653 RPort: rport Branch: z9hG4bKPjyL0GhUP12E0Dkn2CQ5BR9aQm67DdxKfE Max-Forwards: 70 From: <sip:racitup@mobile>;tag=6UtDyO9vBPzP46w7K8AGOfL6qQbFciij SIP from address: sip:racitup@mobile SIP from address User Part: racitup SIP from address Host Part: mobile SIP tag: 6UtDyO9vBPzP46w7K8AGOfL6qQbFciij To: <sip:123@192.168.0.104>;tag=lsboj SIP to address: sip:123@192.168.0.104 SIP to address User Part: 123 SIP to address Host Part: 192.168.0.104 SIP tag: lsboj Call-ID: 1jtxqtjWsDqEL3C2tsrhS3WtRirBFcB7 CSeq: 3674 ACK Sequence Number: 3674 Method: ACK Route: <sip:192.168.0.104:5062 ;lr;ftag=6UtDyO9vBPzP46w7K8AGOfL6qQbFciij> Content-Length: 0 ...

2 2

SER or Kamailio
by Daniel Gonzalez 10 Apr '12

10 Apr '12

Hello, I am starting to deploy a SIP router, and after reading the documentation in http://sip-router.org I am a bit confused. I am planning to integrate the SIP router with an asterisk PBX. Which of the available projects is recommended to get in touch with the technology, SER or Kamailio? Which are most of you in the list using? Is there a particular use case where one or the other is more appropriate? Thanks, Daniel Gonzalez

4 5

RTPPROXY not working with kamailio .
by Ryan Gholam 10 Apr '12

10 Apr '12

Hello I need help concerning this issue , i am creating a testing scenario to make the RTPPROXY work , where i have a server having installed on it Asterisk , running on (192.168.10.15), and another pc connected to the Asterisk server having the ip (192.168.10.17) , on this same pc i've installed RTPPROXY and managed to insert another Ethernet card to connect to a client on ip (192.168.20.3) . After connecting any client on this ip 192.168.20.* , i manage to make a call i hear the ring but no audio conversation . My RTPPROXY command is : /usr/sbin/rtpproxy -F -s udp:192.168.10.17:22222 -l 192.168.20.3/192.168.10.17 -d DBUG:LOG_LOCAL0 Thank you

2 1

status 407 proxy authentication required
by Marwan Idriss 10 Apr '12

10 Apr '12

Greeting, while Registering with correct authentication I am getting : status 407 proxy authentication required even though the registration is successfull, do you know how I can get rid of this error Regards Marwan

1 0

Re: [SR-Users] SER or Kamailio
by Alex Balashov 10 Apr '12

10 Apr '12

My perception is that SER is something like a kernel, but Kamailio a user-oriented distribution and ecosystem wrapper around it that serves to "practicalise" it in an applied way. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: >Hello, > >if you install from sources, there is practically everything: ser + >kamailio together, it is up to you what modules you want to use. > >If you install from kamailio packages (debian, centos), you get only >kamailio specific modules (what is located in modules/ and modules_k/). > >Maturity of the code is the same, I am more into kamailio specific >modules, though, since I use them. Kamailio is traditionally more >interactive in terms of public relations, having a clear release policy, >with packages built every time. > >Also, kamailio specific modules have more into SIMPLE extensions (I mean >here presence, xcap, ...), but this is not a problem since you can use >the modules with the ones developed in the past by SER. So there is >nothing different between Kamailio and SER if you install from sources. >As mentioned in the link, there are just some inter-module dependencies, >so when using a module, you have have to use another specific one. This >is actually valid in the same group of modules (like in modules_k), one >module requires another one. > >What really make the difference in a deployment is the database >structure used behind. If you start from scratch, it does not matter >probably, but people upgrading from older versions, tend to stick to >what they have, so they continue using one or the other. > > From my observations on this mailing list, it is more likely you get >people answering more often for kamailio than ser. Also, there are more >tutorials showing how to use kamailio, including integration with >asterisk, if that is main concern, for example: > > * http://kb.asipto.com/asterisk:index > >Cheers, >Daniel > > > >On 4/9/12 9:43 PM, Daniel Gonzalez wrote: >> Thanks for the link. >> >> If I understand correctly, both projects share the same source code, >> and implement more or less the same functionality. >> Is there a list of specific features which are only available in SER >> or in Kamailio? >> >> Which is the most widely deployed / documented option? Which is more >> mature / stable? Which is the option which interoperates easier with >> Asterisk? >> >> Sorry for the beginner questions, but I have found no place where this >> questions are adressed. >> >> On Mon, Apr 9, 2012 at 9:17 PM, SamyGo <govoiper(a)gmail.com >> <mailto:govoiper@gmail.com>> wrote: >> >> :-| >> >> http://www.kamailio.org/w/sip-router-releases/ >> >> >> >> On Mon, Apr 9, 2012 at 11:06 PM, Daniel Gonzalez >> <gonvaled(a)gonvaled.com <mailto:gonvaled@gonvaled.com>> wrote: >> >> Hello, >> >> I am starting to deploy a SIP router, and after reading the >> documentation in http://sip-router.org I am a bit confused. I am >> planning to integrate the SIP router with an asterisk PBX. >> Which of >> the available projects is recommended to get in touch with the >> technology, SER or Kamailio? Which are most of you in the list >> using? >> Is there a particular use case where one or the other is more >> appropriate? >> >> Thanks, >> Daniel Gonzalez >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users >> mailing list >> sr-users(a)lists.sip-router.org >> <mailto: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(a)lists.sip-router.org <mailto: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(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >-- >Daniel-Constantin Mierla >Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany >http://www.asipto.com/index.php/kamailio-advanced-training/ > > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

1 0

Re: [SR-Users] Installing in a non-standard path
by Alex Balashov 10 Apr '12

10 Apr '12

The prefix only specifies the destination for the build targets. As far as things like module paths, they are not affected. You will have to change them manually in kamailio.cfg. However, the good news is that there aren't a whole lot of paths to change; you really only need to change it in kamailio,cfg, and in any init scripts. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com Daniel Gonzalez <gonvaled(a)gonvaled.com> wrote: >Hello, > >This is my first message to this list. > >I have installed sip-router as follows (my system is Ubuntu 10.04): > > cd /tmp > git clone --depth 1 git://git.sip-router.org/sip-router sip-router > cd sip-router > git checkout -b 3.1 origin/3.1 > local prefix=/tmp/my/very/strange/path > mkdir -p $prefix > sudo apt-get install -y flex > sudo apt-get install -y docbook2x > make proper > make cfg prefix=$prefix > make all prefix=$prefix > make install prefix=$prefix > >And this has worked as expected. > >Now I try to start the daemon: > > $ /tmp/my/very/strange/path/sbin/ser > loading modules under /usr/lib/ser/modules:/usr/lib/ser/modules_s > >What can I do so that my non-standard path is fully recognized by all >sip router tools? > >Thanks, >Daniel Gonzalez > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 4

Kamailio 3.2.2 Error - usrloc
by Gilbert T. Gutierrez, Jr. 09 Apr '12

09 Apr '12

2 4

Send() function
by Gustavo Vidovich 09 Apr '12

09 Apr '12

Hi everyone, We are using Kamailio as a dispatcher to other two Kamailio servers and want it to stateless forward messages without adding a VIA header. We try to use the send function, but you can not give a pseudo variable as a parameter ($dd in this case as this variable is set by the ds_select_dst() function). We attemp to add a rule for this function to accept pseudo variables as an argument (in cfg.y file, pvar argument) but the problem was that when starting Kami (our friendly name for the Kamailio server), the pseudo variable is empty, then the program attemp to do a dns lookup trying to solve the empty string and obviously fail to start. We partially solve the issue by hard-coding the IP's to dispatch (the only way to make the send() function to work was the sintaxis "send(IP)"). We want a little bit elegancy in configuration file, but can not solve in another way. Any brighter ideas to make it work? Cheers from Uruguay, ODT

2 1

Installing in a non-standard path
by Daniel Gonzalez 07 Apr '12

07 Apr '12

Hello, This is my first message to this list. I have installed sip-router as follows (my system is Ubuntu 10.04): cd /tmp git clone --depth 1 git://git.sip-router.org/sip-router sip-router cd sip-router git checkout -b 3.1 origin/3.1 local prefix=/tmp/my/very/strange/path mkdir -p $prefix sudo apt-get install -y flex sudo apt-get install -y docbook2x make proper make cfg prefix=$prefix make all prefix=$prefix make install prefix=$prefix And this has worked as expected. Now I try to start the daemon: $ /tmp/my/very/strange/path/sbin/ser loading modules under /usr/lib/ser/modules:/usr/lib/ser/modules_s What can I do so that my non-standard path is fully recognized by all sip router tools? Thanks, Daniel Gonzalez

1 0

to tag not correctly inserted in rtpproxy command with kamailio 3.2.2
by Laurent Schweizer 07 Apr '12

07 Apr '12

Dear all, I see that in some scenario the To Tag is not passed in the command string to configure the rtpproxy. At least I see this scenario: I start a call -> all is ok I do a ReINVITE without any SDP in the INVITE , so I call the rtp_offer() for the 200 OK and the function rtpproxy_answer() for the ACK The problem is with the function rtpproxy_answer() only the from tag is passed so the stream cannot be found (lookup request failed) I do a test with the version 3.2.1 and they was no problem. Bellow rtpproxy log of both version. Regards Laurent With ver: 3.2.2 Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "24732_28 Uc0,8,18,101 ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92 62.12.250.165 62968 pm04tutcvv;1 1332342221131;1" Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 11416/18748, session timer restarted Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: update Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: update from cmd requested Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: new IP : 62.12.250.165's address port 62968 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: old IP: 62.12.250.165 address port 26495 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: RTP IP are the same, we don't update them Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: RTCP IP are the same, we don't update them Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "24732_28 18748 50.10.21.8#012" Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "24679_17 Lc0,101 ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92 50.10.21.92 64078 pm04tutcvv;1" Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: lookup request failed: session ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92, tags pm04tutcvv;1/NONE not found Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "24679_17 0 50.10.21.8#012" With ver: 3.2.1 Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "10958_13 Uc0,8,18,101 4e21d3a85ce70fe0dfa28f517484cba1(a)50.10.21.92 62.12.250.165 56522 jddmr2qwrf;1 1332350278581;1" Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 9974/16864, session timer restarted Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: update Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: update from cmd requested Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: new IP : 62.12.250.165's address port 56522 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: old IP: 62.12.250.165 address port 29436 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: RTP IP are the same, we don't update them Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: RTCP IP are the same, we don't update them Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "10958_13 16864 50.10.21.8#012" Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "10793_9 Lc0,101 4e21d3a85ce70fe0dfa28f517484cba1(a)50.10.21.92 50.10.21.92 63990 jddmr2qwrf;1 1332350278581;1" Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 9974/16864, session timer restarted

3 2

Kamailio server with Two interface
by Marwan Idriss 06 Apr '12

06 Apr '12

Greeting, I have a Kamailio server connected to two network, Network one their an Asterisk server, at network two we have the client one a client call , the call will have no audio voice how I can solve this using Kamailio and rtp server ? Thanks for your help Regards

3 2

rtpproxy and CANCEL in serial forked scenarios
by Andreas Granig 05 Apr '12

05 Apr '12

Hi, I ran into a scenario with couple of serial forks where kamailio loops to itself and, due to the looping, the INVITE to a new branch happens before the CANCEL to an old branch. What I do at the moment is force rtpproxy in branch route, and stop rtpproxy in the failure route. The problem with this scenario is that in rtpproxy_offer and unforce_rtpproxy, the rtpproxy module only passes the call-id and from-tag to rtpproxy (because there is no to-tag yet), which then in unforce_rtpproxy for a CANCEL deletes all calls related to it (because it can only match on from-tag and call-id, obviously). This means that when I do a subsequent rtpproxy_answer for my new branch, rtpproxy doesn't find the session anymore, since it has been removed with the CANCEL. A fix I can think of is to also pass the branch of the top-most via to rtpproxy in order to perform a more fine-grained matching. Are there solutions to that out there somewhere, or is it something I should just introduce, eg. as a new param to offer/answer/unforce functions? Objections? Other approaches? Andreas

3 2

in doubt about in-dialog INVITE Route params processing
by Andrew Pogrebennyk 05 Apr '12

05 Apr '12

I've been pondering an issue with Route header parameters being not mirrored by kamailio proxy into Record-Route field on in-dialog requests over the last few hours so I thought I'd just whether I'm missing something obvious. The call scenario in UA -> lb -> proxy -> sems. Everything is fine with initial INVITE transaction where we add rr param ;rtpprx=yes. (We also use dialog module.) The UA does re-INVITE where it mirrors RR headers to Route set just fine. However, when forwarding re-INVITE kamailio proxy removes own Route header and inserts RR header without rtpproxy, did etc params. The kamailio default config from branch 3.1 routes in-dialog requests in the same fashion and I can't tell really if this is how it is supposed to work? I can workaround this by add_rr_param() but shouldn't missing did param cause a problem with dialog matching? Here is the debug with log level 3: > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:792]: Topmost route URI: 'sip:127.0.0.1:5062;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-' is me > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:257]: No next Route HF found > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:811]: No next URI found > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [rr_cb.c:97]: callback id 1 entered with <lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_handlers.c:910]: route param is '8a3.aab32831' (len=12) > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:442]: ref dlg 0x7f0a0be918b0 with 1 -> 3 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:444]: dialog id=327302058 found on entry 936 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:757]: dialog 0x7f0a0be918b0 changed from state 4 to state 4, due event 8 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_handlers.c:1042]: sequential request successfully processed > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_timer.c:117]: inserting 0x7f0a0be91900 for 127601858 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:411]: cseq is 10760 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [rr_cb.c:97]: callback id 0 entered with <lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: uac [from.c:421]: getting 'vsf' Route param > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: uac [from.c:429]: route param is 'aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-' (len=44) > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: uac [from.c:479]: decoded uris are: new=[sip:43991001@192.168.51.210] old=[sip:sipwise-user1@192.168.51.210] > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:983]: params are <;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: siputils [checks.c:76]: totag found > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: textops [textops.c:1789]: content type is 196611 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:983]: params are <;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:983]: params are <;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: INFO: <script>: Use mediaproxy for forward direction for IPv4/IPv4 - M=INVITE R=sip:127.0.0.1:5080 F=sip:sipwise-user1@192.168.51.210 T=sip:43991002@192.168.51.210 IP=192.168.51.1:35189 (127.0.0.1:5060) ID=M6obxlxpUOPPR3CQYE-d2t9-fgybDo6y > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rtpproxy [rtpproxy_funcs.c:148]: type <application/sdp> found valid > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rtpproxy [rtpproxy.c:2260]: proxy reply: 30080 192.168.51.210 4#012 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: INFO: <script>: Relaying request - M=INVITE R=sip:127.0.0.1:5080 F=sip:sipwise-user1@192.168.51.210 T=sip:43991002@192.168.51.210 IP=192.168.51.1:35189 (127.0.0.1:5060) ID=M6obxlxpUOPPR3CQYE-d2t9-fgybDo6y

2 2

Problem with xpath updates of XCAP documents
by Peter Dunkley 05 Apr '12

05 Apr '12

Hi, I have been experimenting with uploading, and modifying existing, XCAP documents. I have been trying out the example from RFC 4827 and I can't get it to work with Kamailio. To upload the document (this works) I use the command: curl --digest -u 111:111 -T pidf.xml -X PUT http://192.168.0.130:5060/xcap-root/pidf-manipulation/users/sip:111@mydomai… To modify the document (this doesn't work) I use the command: curl --digest -u 111:111 -T pidf_modify.xml -H "Content-Type: application/xcap-el+xml" -X PUT http://192.168.0.130:5060/xcap-root/pidf-manipulation/users/sip:111@mydomai…'x8eg92n'%5d/note When I try to modify the document I get the error: "Apr 4 17:12:08 pd-laptop-linux kamailio[16862]: ERROR: xcap_server [xcap_server.c:596]: no new content" I went through the XCAP server code and added some debug and found that the check on xcap_misc.c:491 is succeeding (which means "no selection for xpath parent expression") and the document is not being changed. Also, from my limited understanding of XPath and libxml2, I would have expected the code path which should have been followed to go through the else clause of the conditional on xcap_misc.c:468 - which means I don't think that the xcaps_xpath_set() function is doing the right thing at all. Is there anyone here that is more familiar with libxml2 that can give me any pointers here. As far as I can tell the XCAP server code looks OK to me, and I believe the documents (attached) and my XCAP queries are correct as well. Thanks, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd

2 3

Acc Module - logging forked calls.
by Stephen Dodge (Bistech) 05 Apr '12

05 Apr '12

Hello, We currently use the acc module to capture information to generate CDR missed call info. I have now introduced serial forking and I would like to see if I can improve how accounting is working for missed calls. I am using the following configuration. # turn accounting on for all new calls if (is_method("INVITE")){ setflag(1); # do accouting setflag(2); # missed calls record_route(); } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")){ setflag(1); # do accounting setflag(3); # even if the transaction fails xdbg("## BISNET ## - RTPPROXY CHECK \n"); # clear any rtpproxy sessions in progress unforce_rtp_proxy(); } I've noticed that accounting for missed calls is generated for the main branch (1st destination) only, whether this is a 486 response or a 408 on expiry of the 'fr_inv_timer'. After a receiving a failure another destination is created/tried by the script, we are allowing up to 4 serial forks. I do see the 183 message for each fork and if the call is answered then the acc table is updated correctly. How can I log the missed call response for each fork, or only log the final failure message for the call? Logging failed transactions seems to put them into the main acc table and not the missed call table which I would have expected. Thanks, Steve. ________________________________ Information in this message, including any attachments, is confidential to the person to whom it is addressed and may be legally privileged. If you are not the intended recipient please notify the sender and delete the message from your system. Please note that Bistech Group plc, Bistech plc, Bisnet Limited and the sender do not accept any responsibility for viruses. It is your responsibility to check the e-mail and any attachments for viruses. Calls may be monitored and recorded.

2 2

KAMAILIO no audio establishment
by Ryan Gholam 05 Apr '12

05 Apr '12

Hello , i am facing an issue concerning kamailio where i am trying to connect the kamailio to the asterisk using a private ip and the kamailio is connected using a public ip for the clients .I am trying to create a call from the client the phone rings but there is no audio conversation happening , what is the best method to use ? N.B : i have tried RTPproxy but it didnt work i think because their is no proper NATING . Thank you

2 1

Questions on multihomed setup
by Karsten Horsmann 05 Apr '12

05 Apr '12

Hi all! I try to setup an kamailio 3.2.2 that is multihomed (mhomed=1) with public and private ip addresses. It should *always* use rtpproxy for all rtp traffic. In wireshark i see that an ACK is missing, the log shows me an error in rr module: rr [loose.c:103]: failed to parse Route HF So my questions are: 1.) Is my NATMANAGE route logic correct? 2.) Why is the ACK dropped by kamailio (ends without transactions)? 3.) Should the SDP/contact field to the 3rd party sipserver have the public ip??? Now it becomes the private IVR ip address. Thanks! Cheers Karsten ########################################## Kamailio public ip 222.222.222.222 Kamailio private ip 172.20.100.74 ########################################## # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT xlog("NATMANAGE M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (isbflagset(FLB_NATB)) return; if (dst_ip == 222.222.222.222) { xlog("rtpproxy_manage ext to int\n"); rtpproxy_manage("FAEI","172.20.10.74"); } else { xlog("rtpproxy_manage int to ext\n"); rtpproxy_manage("FAIE","222.222.222.222"); } if (is_request()) { if (!has_totag()) { add_rr_param(";nat=yes"); } } if (is_reply()) { if(isbflagset(FLB_NATB)) { fix_nated_contact(); } } #!endif return; } ########################################## Kamailio public ip 222.222.222.222 Kamailio private ip 172.20.100.74 IVR ip 172.20.100.61 ########################################## U 2012/04/04 14:05:59.918472 217.10.79.9:5060 -> 222.222.222.222:5060 INVITE sip:kalkbrenner@222.222.222.222:5060 SIP/2.0. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK703f9495. Via: SIP/2.0/UDP 217.10.67.13:5060;received=217.10.67.13;branch=z9hG4bK703f9495;rport=5060. Max-Forwards: 67. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>. Contact: <sip:alice@217.10.67.13>. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Content-Type: application/sdp. Content-Length: 428. . v=0. o=root 1567926566 1567926566 IN IP4 217.10.67.13. s=sipgate VoIP GW. c=IN IP4 217.10.67.13. t=0 0. m=audio 17430 RTP/AVP 8 0 3 97 18 112 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:112 G726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. U 2012/04/04 14:05:59.919629 222.222.222.222:5060 -> 217.10.79.9:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK703f9495. Via: SIP/2.0/UDP 217.10.67.13:5060;received=217.10.67.13;branch=z9hG4bK703f9495;rport=5060. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Server: Kamailio. Content-Length: 0. Warning: 392 222.222.222.222:5060 "Noisy feedback tells: pid=12262 req_src_ip=217.10.79.9 req_src_port=5060 in_uri=sip:kalkbrenner@222.222.222.222:5060 out_uri=sip:kalkbrenner@172.20.100.61 via_cnt==4". . U 2012/04/04 14:05:59.921070 172.20.100.74:5060 -> 172.20.100.61:5060 INVITE sip:kalkbrenner@172.20.100.61 SIP/2.0. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;rport=5060;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK703f9495. Via: SIP/2.0/UDP 217.10.67.13:5060;received=217.10.67.13;branch=z9hG4bK703f9495;rport=5060. Max-Forwards: 66. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>. Contact: <sip:alice@217.10.67.13>. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Content-Type: application/sdp. Content-Length: 448. . v=0. o=root 1567926566 1567926566 IN IP4 222.222.222.222. s=sipgate VoIP GW. c=IN IP4 222.222.222.222. t=0 0. m=audio 47798 RTP/AVP 8 0 3 97 18 112 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:112 G726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 U 2012/04/04 14:05:59.925396 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 0. . U 2012/04/04 14:05:59.966415 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:05:59.966775 222.222.222.222:5060 -> 217.10.79.9:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 236. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 222.222.222.222. s=-. c=IN IP4 222.222.222.222. t=0 0. m=audio 52564 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=nortpproxy:yes. U 2012/04/04 14:06:00.009715 217.10.79.9:5060 -> 222.222.222.222:5060 ACK sip:222.222.222.222:5060 SIP/2.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.3. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.3. Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK55e1bf7a. Via: SIP/2.0/UDP 217.10.67.13:5060;received=217.10.67.13;branch=z9hG4bK55e1bf7a;rport=5060. Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>,<sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Max-Forwards: 67. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Contact: <sip:alice@217.10.67.13>. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 ACK. Content-Length: 0. X-hint: rr-enforced. . U 2012/04/04 14:06:00.467283 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:00.467915 222.222.222.222:5060 -> 217.10.79.9:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 236. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 222.222.222.222. s=-. c=IN IP4 222.222.222.222. t=0 0. m=audio 52564 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=nortpproxy:yes. U 2012/04/04 14:06:01.468092 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:01.469460 222.222.222.222:5060 -> 217.10.79.9:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 236. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 222.222.222.222. s=-. c=IN IP4 222.222.222.222. t=0 0. m=audio 52564 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=nortpproxy:yes. U 2012/04/04 14:06:03.468631 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:03.472282 222.222.222.222:5060 -> 217.10.79.9:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 236. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 222.222.222.222. s=-. c=IN IP4 222.222.222.222. t=0 0. m=audio 52564 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=nortpproxy:yes. U 2012/04/04 14:06:07.469772 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:07.470020 172.20.100.74:5060 -> 217.10.79.9:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:11.470798 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:11.471041 172.20.100.74:5060 -> 217.10.79.9:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:13.282635 217.247.216.82:12780 -> 222.222.222.222:5060 . . .............. U 2012/04/04 14:06:15.468037 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK6021.34ce1643.0. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd3aff-40a69134. Call-ID: 2d9296f200e0212711db47c036e68917(a)sipgate.de. CSeq: 102 INVITE. Content-Length: 218. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=as0ebb1d67;nat=yes>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Record-Route: <sip:172.20.40.2;lr=on>. Record-Route: <sip:217.10.79.9;lr;ftag=as0ebb1d67>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Allow: MESSAGE. Contact: <sip:172.20.100.61>. . v=0. o=aculab-0204CC01 1431055130 1431055130 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19512 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2012/04/04 14:06:15.468272 172.20.100.74:5060 -> 217.10.79.9:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6021.0ca5d221.1;rport=5060. Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6021.0ca5d221.1. Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK703f9495;received=217.10.68.226. Via: SIP/2.0/UDP 217.10.67.13:5060;rport=5060;branch=z9hG4bK703f9495;received=217.10.67.13. From: "alice" <sip:alice@sipgate.de>;tag=as0ebb1d67. To: <sip:bob@sipgate.de>;tag=ds-46dd -- Mit freundlichen Grüßen *Karsten Horsmann*

2 2

LCR
by Jeff Russell 05 Apr '12

05 Apr '12

As a rule, I have managed to work my way through any issues however, I would really appreciate and help in getting the LCR module working (with postgres), what I really need is working examples of working config and database tables, Many thanks, Jeff

3 8

Re: [SR-Users] Kamailio and billing services .
by Daniel-Constantin Mierla 05 Apr '12

05 Apr '12

Hello, do not write private emails started from mailing list -- they will be ignored. Also, if it is a different topic, create a new email with appropriate subject. Then provide details about what you tried (config file parts) and results (log messages and sip traces). Otherwise nobody can guess what happens and cannot give hints. Cheers, Daniel On 4/4/12 4:10 PM, Ryan Gholam wrote: > Hello Daniel , > > I thank you for the last email you've sent me it helped me alot , but > now i am facing an issue concerning kamailio where i am trying to > connect the kamailio to the asterisk using a private ip and the > kamailio is connected using a public ip for the clients . > > I am trying to create a call from the client the phone rings but there > is no audio conversation happening , what is the best method to use ? > > N.B : i have tried RTPproxy but it didnt work i think because their > is no proper NATING . > > Thank you -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

2 1

kamailio rpm build
by Min Wang 05 Apr '12

05 Apr '12

HI I tried to build Kamailio 3.2.2 rpm pkg on Centos 6.2 following instruction from: http://kb.asipto.com/kamailio:install:3.1.x-rpms-centos5x I got the following error ( at the end of the email) also tried: pkg-config --cflags glib-2.0 export C_INCLUDE_PATH="/usr/include/glib-2.0 /usr/lib64/glib-2.0/include" export CPLUS_INCLUDE_PATH="/usr/include/glib-2.0 /usr/lib64/glib-2.0/include" the try to build again, got the same error. anything could be wrong? thanks. min ////////////////////////////////////////////////////////// + make every-module group_include=kpurple CC (gcc) [M purple.so] clientaccount.o In file included from /usr/include/glib-2.0/glib/galloca.h:34, from /usr/include/glib-2.0/glib.h:32, from /usr/include/libpurple/account.h:30, from clientaccount.c:21: /usr/include/glib-2.0/glib/gtypes.h:410:2: error: #error unknown ENDIAN type In file included from /usr/include/glib-2.0/glib.h:33, from /usr/include/libpurple/account.h:30, from clientaccount.c:21: /usr/include/glib-2.0/glib/garray.h:50: error: expected specifier-qualifier-list before 'guint8' /usr/include/glib-2.0/glib/garray.h:152: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /usr/include/glib-2.0/glib/garray.h:157: error: expected ';', ',' or ')' before '*' token /usr/include/glib-2.0/glib/garray.h:160: error: expected ';', ',' or ')' before '*' token In file included from /usr/include/glib-2.0/glib/gerror.h:30, from /usr/include/glib-2.0/glib/gthread.h:34, from /usr/include/glib-2.0/glib/gasyncqueue.h:34, from /usr/include/glib-2.0/glib.h:34, from /usr/include/libpurple/account.h:30, from clientaccount.c:21: /usr/include/glib-2.0/glib/gquark.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'GQuark' /usr/include/glib-2.0/glib/gquark.h:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'g_quark_try_string' /usr/include/glib-2.0/glib/gquark.h:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'g_quark_from_static_string' /usr/include/glib-2.0/glib/gquark.h:44: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'g_quark_from_string' /usr/include/glib-2.0/glib/gquark.h:45: error: expected ')' before 'quark' In file included from /usr/include/glib-2.0/glib/gthread.h:34, ....

2 5

t_relay is failing after 45 seconds...
by Krishna Kurapati 04 Apr '12

04 Apr '12

Hi, I have # Time in seconds after a TCP connection will be closed if it is not available for writing in this interval tcp_send_timeout=2 And I am using save("location", "0x04")) to save only one contact per user. However, when I tried to relay message to a user, sometimes it is taking over 45 seconds for t_relay to timeout and return 477 error. How can I reduce the t_relay timeout? Thanks Krish Kura

2 2

TLS module not working
by Gnaneshwar Gatla 04 Apr '12

04 Apr '12

Hello, I'm trying to upgrade my company's sip server to the latest Kamailio to 3.1.5. My development environment contained Openssl 0.9.8K version and everything works fine here. I have tried to install a fresh package for my release, the openssl version from the Ubuntu packages is Openssl 1.0.0e And I get the following error. My error looks like this: sudo /etc/init.d/kamailio start Not starting kamailio: invalid configuration file! -e 0(26880) ERROR: <core> [sr_module.c:523]: ERROR: load_module: could not open module </home/p4dev/BLand_password-Evo-N800v_4700/sw/SipServer/main/kamailio/lib/kamailio/modules/tls.so>: /home/p4dev/BLand_password-Evo-N800v_4700/sw/SipServer/main/kamailio/lib/kamailio/modules/tls.so: undefined symbol: SSLv2_client_method 0(26880) : <core> [cfg.y:3416]: parse error in config file /home/p4dev/BLand_password-Evo-N800v_4700/sw/SipServer/main/kamailio/etc/kamailio/kamailio.cfg, line 259, column 12-19: failed to load module 0(26880) WARNING: <core> [sr_module.c:578]: /home/p4dev/BLand_password-Evo-N800v_4700/sw/SipServer/main/kamailio/lib/kamailio/modules_k/perl.so: exports dlflags interface is deprecated and it will not be supported in newer versions; consider using mod_register() instead 0(26880) ERROR: <core> [modparam.c:161]: set_mod_param_regex: No module matching <tls> found 0(26880) : <core> [cfg.y:3419]: parse error in config file /home/p4dev/BLand_password-Evo-N800v_4700/sw/SipServer/main/kamailio/etc/kamailio/kamailio.cfg, line 437, column 118: Can't set module parameter ERROR: bad config file (2 errors) I'm not sure if this is a compatibility issue or is there some library missing that I have to install. I saw this patch online with reference to Crypt-SSLeay at https://rt.cpan.org/Public/Bug/Display.html?id=70565 *The linker complains about missing SSLv2_method. The following patch works for me:* --- SSLeay.xs~ 2011-08-29 07:25:46.000000000 +0200 +++ SSLeay.xs 2011-08-29 07:29:04.000000000 +0200 @@ -125,13 +125,9 @@ if(ssl_version == 23) { ctx = SSL_CTX_new(SSLv23_client_method()); } - else if(ssl_version == 3) { + else { ctx = SSL_CTX_new(SSLv3_client_method()); } - else { - /* v2 is the default */ - ctx = SSL_CTX_new(SSLv2_client_method()); - } SSL_CTX_set_options(ctx,SSL_OP_ALL|0); SSL_CTX_set_default_verify_paths(ctx); SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);

2 2

Re: [SR-Users] Kamailio- Max PDD
by Daniel-Constantin Mierla 04 Apr '12

04 Apr '12

Hello, please use mailing lists (sr-users(a)lists.sip-router.org in this case, cc-ed) for questions about kamailio - after first reply, private emails are discarded. Perhaps you need to use tm module and adjust fr_timer/fr_inv_timer values -- see readme of the module. Cheers, Daniel On 4/3/12 11:35 PM, Orlando F. Guitian wrote: > [...] Recently, I have been working on a project and I would like to > enable a 'Max PDD' function. For example, if I send the call out and > more than four (4) seconds have passed and there is no ringing, then I > would like to cancel that call and move on. Is that possible with > Kamailio? Is there a module for that? -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

1 0

Network Architecture Question
by Rob Watkin 03 Apr '12

03 Apr '12

Hi, I am just getting started with Kamailio and have been following the book "Building Telephony Systems with OpenSER" by Flavio E. Goncalves. The book describes an architecture with a SIP Proxy handling registrations and handing calls to a PSTN Gateway. I now have a basic test network running where calls are routed via the SIP Proxy (Kamailio) to a third party PSTN Gateway. I feel that a better design would be to implement my own PSTN Gateway using Kamailio. This single gateway would then handle all third party PSTN gateways. Thus one Kamailio server would be facing my clients while another would be facing my suppliers. Is this a sensible architecture and are there any sample configurations for Kamailio performing this role? Thanks Rob Watkin

4 7

ul permanent vs ul registered
by Karsten Horsmann 03 Apr '12

03 Apr '12

Hi all! I use kamailio 3.2.2 in the following setup INET -----> public-ip(kamailio)private-ip ----> IVR Now i got the following issue. If i setup an permanet ul to an IVR system, the INVITE SDP had the public-ip and not the private-ip. If the target is an regular register UAC, then i see the INVITE SDP to the UAC from the private ip address. The kamailio.cfg is nearly the default one. Any hints? -- Mit freundlichen Grüßen *Karsten Horsmann*

2 1

Multihomed Setup - Missrouted ACK and not rewritten SDP Packet
by Karsten Horsmann 03 Apr '12

03 Apr '12

Hi all, missing or missrouted ACKs are often to read on the mailinglist. But i didnt found my issue there. 1.) After the 200 ok SDP the proxy gots an ACK from the UAC. But its not send to the IVR, kamailio send it back to the UAC (with the wrong source ip). 2.) The outgoing SDP packets contains RFC1918 (private) addresses. How can i fix that issues? mhomed=1 is set. Thanks! Sipphone 111.111.111.111 Kamailio external 222.222.222.222 Kamailio internal 172.20.100.74 IVR internal/signaling 172.20.100.74 IVR internal/rtp 172.20.100.71 U 2012/04/03 09:11:37.578461 111.111.111.111:1862 -> 222.222.222.222:5060 INVITE sip:kalkbrenner@222.222.222.222 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-86d05e7b67b750aa-1---d8754z-;rport. Max-Forwards: 70. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 1 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Supported: replaces. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 232. . v=0. o=- 12977910697532256 1 IN IP4 111.111.111.111. s=CounterPath X-Lite 4.1. c=IN IP4 111.111.111.111. t=0 0. m=audio 25646 RTP/AVP 107 0 8 101. a=rtpmap:107 BV32/16000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. U 2012/04/03 09:11:37.578821 222.222.222.222:5060 -> 111.111.111.111:1862 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-86d05e7b67b750aa-1---d8754z-;rport=1862. To: <sip:kalkbrenner@222.222.222.222>;tag=4816d6de4e8ef5d73984156a735bce4d.9a24. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 1 INVITE. Proxy-Authenticate: Digest realm="222.222.222.222", nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR". Server: Kamailio. Content-Length: 0. Warning: 392 222.222.222.222:5060 "Noisy feedback tells: pid=6640 req_src_ip=111.111.111.111 req_src_port=1862 in_uri=sip:kalkbrenner@222.222.222.222 out_uri=sip:kalkbrenner@222.222.222.222 via_cnt==1". . U 2012/04/03 09:11:37.606220 111.111.111.111:1862 -> 222.222.222.222:5060 ACK sip:kalkbrenner@222.222.222.222 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-86d05e7b67b750aa-1---d8754z-;rport. Max-Forwards: 70. To: <sip:kalkbrenner@222.222.222.222>;tag=4816d6de4e8ef5d73984156a735bce4d.9a24. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 1 ACK. Content-Length: 0. . U 2012/04/03 09:11:37.616989 111.111.111.111:1862 -> 222.222.222.222:5060 INVITE sip:kalkbrenner@222.222.222.222 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-;rport. Max-Forwards: 70. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. Supported: replaces. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 232. . v=0. o=- 12977910697532256 1 IN IP4 111.111.111.111. s=CounterPath X-Lite 4.1. c=IN IP4 111.111.111.111. t=0 0. m=audio 25646 RTP/AVP 107 0 8 101. a=rtpmap:107 BV32/16000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. U 2012/04/03 09:11:37.617725 222.222.222.222:5060 -> 111.111.111.111:1862 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-;rport=1862. To: <sip:kalkbrenner@222.222.222.222>. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Server: Kamailio. Content-Length: 0. Warning: 392 222.222.222.222:5060 "Noisy feedback tells: pid=6639 req_src_ip=111.111.111.111 req_src_port=1862 in_uri=sip:kalkbrenner@222.222.222.222 out_uri=sip:kalkbrenner@172.20.100.61 via_cnt==1". . U 2012/04/03 09:11:37.617820 172.20.100.74:5060 -> 172.20.100.61:5060 INVITE sip:kalkbrenner@172.20.100.61 SIP/2.0. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Supported: replaces. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 232. . v=0. o=- 12977910697532256 1 IN IP4 111.111.111.111. s=CounterPath X-Lite 4.1. c=IN IP4 111.111.111.111. t=0 0. m=audio 25646 RTP/AVP 107 0 8 101. a=rtpmap:107 BV32/16000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. U 2012/04/03 09:11:37.637302 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 0. . U 2012/04/03 09:11:37.688813 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:37.688941 222.222.222.222:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:37.787049 111.111.111.111:1862 -> 222.222.222.222:5060 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:37.787358 172.20.100.74:5060 -> 111.111.111.111:50350 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKcydzigwkX. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:38.188102 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:38.188276 222.222.222.222:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:38.223905 111.111.111.111:1862 -> 222.222.222.222:5060 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:38.224112 172.20.100.74:5060 -> 111.111.111.111:50350 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKcydzigwkX. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:39.188999 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:39.189218 222.222.222.222:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:39.226368 111.111.111.111:1862 -> 222.222.222.222:5060 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:39.226627 172.20.100.74:5060 -> 111.111.111.111:50350 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKcydzigwkX. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:41.190535 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:41.190756 222.222.222.222:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:41.228037 111.111.111.111:1862 -> 222.222.222.222:5060 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:41.228334 172.20.100.74:5060 -> 111.111.111.111:50350 ACK sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKcydzigwkX. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-8871cba456efbdcd-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 ACK. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@222.222.222.222",response="ffb11f60ece5a99bde74a8ecd0d31ffa",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:45.191673 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:45.191794 172.20.100.74:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:47.383023 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:47.383313 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:47.873118 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:47.879461 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:48.873114 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:48.879817 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:49.214687 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:49.214786 172.20.100.74:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:49.408642 222.222.222.222:5060 -> 184.73.248.111:42889 .... U 2012/04/03 09:11:50.873111 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:50.879209 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:51.123116 111.111.111.111:1862 -> 222.222.222.222:5060 . . .............. U 2012/04/03 09:11:53.215781 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:53.215892 172.20.100.74:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:54.873112 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:54.879908 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:57.216932 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:57.217186 172.20.100.74:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:11:58.873115 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:11:58.880227 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:12:01.233871 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:12:01.234013 172.20.100.74:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:12:02.873119 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:12:02.880004 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:12:05.234992 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:12:05.235244 172.20.100.74:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:12:06.873115 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:12:06.879853 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:12:09.233045 172.20.100.61:5060 -> 172.20.100.74:5060 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bK9a5c.71c78a75.0. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:12:09.233186 172.20.100.74:5060 -> 111.111.111.111:1862 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 111.111.111.111:1862;rport=1862;branch=z9hG4bK-d8754z-eb5e522e536eef78-1---d8754z-. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 2 INVITE. Content-Length: 182. Content-Type: application/sdp. Record-Route: <sip:172.20.100.74;r2=on;lr=on;ftag=b20de0d4>. Record-Route: <sip:222.222.222.222;r2=on;lr=on;ftag=b20de0d4>. Supported: replaces. Supported: 100rel. Allow: INVITE. Allow: ACK. Allow: BYE. Allow: CANCEL. Allow: OPTIONS. Allow: NOTIFY. Allow: REFER. Allow: PRACK. Allow: INFO. Allow: UPDATE. Contact: <sip:kalkbrenner@172.20.100.61>. . v=0. o=aculab-F1A4D801 132722796 132722796 IN IP4 172.20.100.61. s=-. c=IN IP4 172.20.100.71. t=0 0. m=audio 19752 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2012/04/03 09:12:10.873117 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:12:10.880323 111.111.111.111:1862 -> 222.222.222.222:5060 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport. Max-Forwards: 70. Route: <sip:222.222.222.222;lr;r2=on;ftag=b20de0d4>. Route: <sip:111.111.111.111:35446;r2=on;lr=on;ftag=b20de0d4>. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d69578c77",algorithm=MD5. User-Agent: X-Lite 4 release 4.1 stamp 63214. Content-Length: 0. . U 2012/04/03 09:12:14.873104 172.20.100.74:5060 -> 111.111.111.111:50350 BYE sip:kalkbrenner@111.111.111.111:50350 SIP/2.0. Via: SIP/2.0/UDP 172.20.100.74;branch=z9hG4bKaa5c.ac657af.0. Via: SIP/2.0/UDP 111.111.111.111:1862;branch=z9hG4bK-d8754z-78a6cdbd7b67534f-1---d8754z-;rport=1862. Max-Forwards: 69. Contact: <sip:4horsmann@111.111.111.111:1862>. To: <sip:kalkbrenner@222.222.222.222>;tag=ds-64cb3b56-1225d1a0. From: <sip:4horsmann@222.222.222.222>;tag=b20de0d4. Call-ID: NDhkZjkyMDUyNGE5NzA1YjA0ZTZiMTcwYjcyMTFlMGI.. CSeq: 3 BYE. Proxy-Authorization: Digest username="4horsmann",realm="222.222.222.222",nonce="T3qj1E96oqiPKdTJdL8hDVDVtni2/3OR",uri="sip:kalkbrenner@172.20.100.61",response="da7cb73aad1d5cf2b9c42b1d695 -- Mit freundlichen Grüßen *Karsten Horsmann*

2 1

ClueCon 2012 Registration Is Now Open!
by Michael Collins 02 Apr '12

02 Apr '12

*ClueCon 2012 - Register Today!* The ClueCon team is pleased to announce that registration is now open for ClueCon 2012. We invite all to visit our new website<http://www.cluecon.com/?cc12reg01>and get registered today. 2012 marks the 8th annual ClueCon event. This year we return to the beautiful Wyndham Hotel in downtown Chicago. ClueCon 2012 will be held August 7-9. ClueCon is best known as the open source telephony conference that is by developers, for developers. As in years past we will have highly technical presentations on a variety of subjects. You'll be able to rub elbows with the authors of powerful open source telephony projects like Kamailio, OpenSIPS, and, of course, FreeSWITCH. VoIP security will again be an important subject and we are pleased to have Phil Zimmermann returning to discuss how VoIP security affects us all and how ZRTP can help. Stay tuned for announcements about specific talks, speakers, new sponsors, and the ClueCon 2012 schedule of events. *Wyndham Discount * Those staying at the Wyndham will enjoy a $300 discount off the regular admission price of $999. Select the appropriate PayPal button from the registration <http://www.cluecon.com/register/?cc12reg01> page. For more information about the Wyndham, visit the ClueCon hotel<http://www.cluecon.com/hotels/?cc12reg01>page. Make your plans and register right away. We look forward to seeing everyone this August! The ClueCon Team http://www.ClueCon.com <http://www.cluecon.com/> 877.742.CLUE <http://www.cluecon.com/?cc12reg01> CC120402-2

1 0

Re: [SR-Users] (no subject)
by Daniel-Constantin Mierla 02 Apr '12

02 Apr '12

Hello, thanks for sharing the info, then I guess there is a trojan/virus out there having fun with Yahoo users. Because a second spam came from same user, for the moment I set the "moderated" flag on the two Yahoo users sending spam today. Let's see if they react. The mailing list has few hundreds yahoo emails, hopefully not all of them will start spamming. Cheers, Daniel On 4/2/12 3:04 PM, Charles Chance wrote: > Hi Daniel, > > We have a couple of customers from whose email addresses we have received > spam over the past few days and they are both Yahoo! mailboxes. > > Best, > > Charles Chance > Managing Director > > > t. 0121-285-44-00 m. 07932-063-891 > > www.sipcentric.com > > Follow us on twitter @sipcentric > > Sipcentric Ltd. Company registered in England& Wales no. 7365592. > Registered office: 9th Floor, Centre City Tower, Hill Street, Birmingham, B5 > 4UA. > > -----Original Message----- > From: sr-users-bounces(a)lists.sip-router.org > [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of > Daniel-Constantin Mierla > Sent: 02 April 2012 13:46 > To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > UsersMailing List > Subject: Re: [SR-Users] (no subject) > > I see some spam coming to the list (two so far today). > > Is anyone here aware of Yahoo! mail being compromised? > > I checked the logs of mailman, the two users that spammed are registered > to mailing list, they didn't register recently (not in the past week), > so either they are sleeping spammers activated now or something else is > wrong out there... > > I can disable them, but it looks like it is not one user keep spamming > ... so we may get from others soon. > > Cheers, > Daniel > -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

1 0

(no subject)
by anthony thomas 02 Apr '12

02 Apr '12

<a href="http://djfordj.info/mp/02efpk.html"> http://djfordj.info/mp/02efpk.html</a>

1 0

Missing "Route" in ACK or BYE request
by Hervé Cochet 02 Apr '12

02 Apr '12

2 4

(no subject)
by sylver_b 02 Apr '12

02 Apr '12

<a href="http://sxsolar.cl/wp-content/themes/alabastroswp/js/cache/02efpk.html"> http://sxsolar.cl/wp-content/themes/alabastroswp/js/cache/02efpk.html</a>

4 3

(no subject)
by anthony thomas 02 Apr '12

02 Apr '12

<a href="http://cahir.net/roadtrip/journal/archives/02efpk.html"> http://cahir.net/roadtrip/journal/archives/02efpk.html</a>

1 0

CANCEL message processing
by Stephen Dodge (Bistech) 02 Apr '12

02 Apr '12

Hi Guys, I have a question regarding the correct processing for cancelled requests 1. (A)--------------------INVITE ------------------->(B) 2. (A)<------------------180 RIGING------------------(B) 3. (A)--------------------CANCEL-------------------->(B) 4. (A)<------------------OK--------------------------(B) 5. (A)<---------487 Request Terminated---------------(B) 6. (A)--------------------ACK----------------------->(B) I have the following section to deal with cancel messages however I am finding that the 487 response still hits my failure_route block. The failure_route block is called for serial forking. # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) xdbg("## BISNET ## - Cancel Processing\n"); t_relay(); exit; } I can obviously do something like a (!t_check_status("487")) within the failure block but is there a better way to deal with this response ? Although this doesn't really cause me a problem at the moment I see the following error in the debug /usr/sbin/kamailio[23786]: ERROR: tm [tm.c:1368]: ERROR: w_t_relay_to: t_relay_to failed /usr/sbin/kamailio[23786]: ERROR: sl [sl_funcs.c:282]: ERROR: sl_reply_error used: transaction canceled (487/SL) As always your help is appreciated. Steve ________________________________ Information in this message, including any attachments, is confidential to the person to whom it is addressed and may be legally privileged. If you are not the intended recipient please notify the sender and delete the message from your system. Please note that Bistech Group plc, Bistech plc, Bisnet Limited and the sender do not accept any responsibility for viruses. It is your responsibility to check the e-mail and any attachments for viruses. Calls may be monitored and recorded.

2 2

uac floods the syslog
by Karsten Horsmann 02 Apr '12

02 Apr '12

Hi! i use kamailio 3.2.2 on Centos 6 and got in my logfile massiv these entries: ERROR: uac [uac.c:462]: src pv value is not string What is the srv pv? Must it be set? -- Mit freundlichen Grüßen *Karsten Horsmann*

2 1

Planning for next major release v3.3.0
by Daniel-Constantin Mierla 02 Apr '12

02 Apr '12

Hello, based on last IRC devel meeting, the next major release was planned to happen before the summer holidays. I am considering freezing the development for v3.3.0 by April 23, test for 4-6 months and release by end of May/beginning of June. If anyone else prefer a different schedule, reply with alternative options. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

2 2

Failed to open TLS connection from the client...
by Krishna Kurapati 01 Apr '12

01 Apr '12

I restarted Kamailio after a while and I see this issue... Not sure what triggered this. It was working fine before. Krish Kura Apr 1 07:41:02 (none) /usr/sbin/kamailio[24074]: INFO: tls [tls_domain.c:235]: TLSs<10.1.0.4:5061>: verify_certificate=1 Apr 1 07:41:02 (none) /usr/sbin/kamailio[24074]: INFO: tls [tls_domain.c:238]: TLSs<10.1.0.4:5061>: verify_depth=3 Apr 1 07:41:02 (none) /usr/sbin/kamailio[24074]: INFO: tls [tls_domain.c:567]: TLSs<10.1.0.4:5061>: IF client provides certificate then it MUST be valid Apr 1 07:41:02 (none) /usr/sbin/kamailio[24082]: INFO: ctl [io_listener.c:225]: io_listen_loop: using epoll_lt io watch method (config) Apr 1 07:41:41 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3575]: BUG: handle_ser_child: fd -1 for 0 (pid 24074) Apr 1 07:41:41 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3338]: BUG: handle_tcp_child: fd -1061109568 for 0 (pid 0, ser no 0) Apr 1 07:41:41 (none) /usr/sbin/kamailio[24084]: : <core> [pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 19 on -1061109568: Bad file descriptor (9) Apr 1 07:41:41 (none) /usr/sbin/kamailio[24084]: ERROR: <core> [tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0x7ff3c82b3bb8 (flags 0x4018), fd 19 Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3575]: BUG: handle_ser_child: fd -1 for 0 (pid 24074) Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3338]: BUG: handle_tcp_child: fd -1061109568 for 0 (pid 0, ser no 0) Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: : <core> [pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 19 on -1061109568: Bad file descriptor (9) Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: ERROR: <core> [tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0x7ff3c82b3bb8 (flags 0x4018), fd 19 Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3575]: BUG: handle_ser_child: fd -1 for 0 (pid 24074) Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3338]: BUG: handle_tcp_child: fd -1061109568 for 0 (pid 0, ser no 0) Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: : <core> [pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 19 on -1061109568: Bad file descriptor (9) Apr 1 07:42:21 (none) /usr/sbin/kamailio[24084]: ERROR: <core> [tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0x7ff3c82b3bb8 (flags 0x4018), fd 19 Apr 1 07:42:45 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3575]: BUG: handle_ser_child: fd -1 for 0 (pid 24074) Apr 1 07:42:45 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3338]: BUG: handle_tcp_child: fd -1061109568 for 0 (pid 0, ser no 0) Apr 1 07:42:45 (none) /usr/sbin/kamailio[24084]: : <core> [pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 19 on -1061109568: Bad file descriptor (9) Apr 1 07:42:45 (none) /usr/sbin/kamailio[24084]: ERROR: <core> [tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0x7ff3c82b3bb8 (flags 0x4018), fd 19 Apr 1 07:43:39 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3575]: BUG: handle_ser_child: fd -1 for 0 (pid 24074) Apr 1 07:43:39 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3338]: BUG: handle_tcp_child: fd -1061109568 for 0 (pid 0, ser no 0) Apr 1 07:43:39 (none) /usr/sbin/kamailio[24084]: : <core> [pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 19 on -1061109568: Bad file descriptor (9) Apr 1 07:43:39 (none) /usr/sbin/kamailio[24084]: ERROR: <core> [tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0x7ff3c82b3bb8 (flags 0x4018), fd 19 Apr 1 07:45:22 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3575]: BUG: handle_ser_child: fd -1 for 0 (pid 24074) Apr 1 07:45:22 (none) /usr/sbin/kamailio[24084]: : <core> [tcp_main.c:3338]: BUG: handle_tcp_child: fd -1061109568 for 0 (pid 0, ser no 0) Apr 1 07:45:22 (none) /usr/sbin/kamailio[24084]: : <core> [pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 19 on -1061109568: Bad file descriptor (9) Apr 1 07:45:22 (none) /usr/sbin/kamailio[24084]: ERROR: <core> [tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0x7ff3c82b3bb8 (flags 0x4018), fd 19

1 1

need advice
by Nima Jalali 01 Apr '12

01 Apr '12

*Hello dear iptel supporter * Sorry, Is pbxes.org yours ? if No : I need a one sip trunk(with many extensions) with my domain hosted. if Yes : How can i hosted my domain on pbxes ? Please Advice . I Appreciate it . Sincerely Yours Nima Jalali

1 0

siptrace error...
by Krishna Kurapati 30 Mar '12

30 Mar '12

Hi, I keep getting this error in the sip_trace module: Mar 26 06:19:26 siptest /usr/sbin/kamailio[4279]: ERROR: siptrace [siptrace.c:1705]: there is not a valid number port 5060?/?? Krish Kura

3 7

SEMS IVR issue
by Uri Shacked 30 Mar '12

30 Mar '12

Hi, If anyone here is familiar with SEMS.... I installed it today, and could not figure out how to load the IVR application... there is no ivr.so file.... any ideas? there is so little info about it on the web... BR, Uri

3 2

acc log in two databases
by Johannes Wagner-Meingassner 30 Mar '12

30 Mar '12

hi, is it possible configure accounting to log into 2 databases at the same time? thanks, hannes modparam("acc", "db_url", "mysql://user:pw@localhost/ser") modparam("acc", "db_url", "mysql://user:pw@10.10.10.10/ser") modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 3)

3 3

Kamailio and billing services .
by Ryan Gholam 30 Mar '12

30 Mar '12

hello, Is there any billing application or modules to use with kamailio , for example if i want to check the credits of the user on every passing minute , and when he's out of credits i stop the call . Please reply ASAP . Thank you

2 1

Kamailio Shutdown when received a packet without RR
by Javier Vidal 30 Mar '12

30 Mar '12

Hi all, when i send a packet to a carrier with topoh activated he answers a packet without RR and kamailio shutdown himself. I understand that my Carrier shouldn't send me a SIP Packet without RR, but i also can't understand why kamailio shutdowns. Thank you in advance and Good IPv6 Friday. :) DEBUG: Feb 24 14:52:29 sbc /usr/sbin/kamailio[18305]: DEBUG: topoh [th_msg.c:514]: no record route header Feb 24 14:52:29 sbc /usr/sbin/kamailio[18305]: DEBUG: topoh [th_msg.c:906]: +++++++++++++ added cookie header [TH: uch#015#012] Feb 24 14:52:29 sbc /usr/sbin/kamailio[18317]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 24 Feb 24 14:52:29 sbc /usr/sbin/kamailio[18317]: DEBUG: <core> [tcp_main.c:3552]: DBG: handle_ser_child: dead child 10, pid 18305 (shutting down?) Sip Traces: U IPA.IPA.IPA.IPA:5060 -> IPB.IPB.IPB.IPB:5060 INVITE sip:XXXX@XXXX SIP/2.0. Record-Route: <sip:XXXX;lr=on;ftag=ej9ta117t310r;nat=yes;did=01e.e6a1617>. Via: SIP/2.0/UDP 0;branch=z9hG4bK711.2c4d5be1.0. Via: SIP/2.0/UDP 192.168.0.1;branch=z9hG4bKsr-YD8Tc92pXoRWfxhHXugAcu29X-rkcu2ASuyY-jkFlv6zbai0baTRSPhOXjyIbGxp6OHRNu8df9fI-9iOlaU5WPm2EuioEGY*. Max-Forwards: 33. From: "XXXX" <sip:XXXX@XXXX>;tag=ej9ta117t310r. To: <sip:XXXX@XXXX:5060>. Call-ID: !!:XuWFwjmG4Phy4jF16-DKXuUGcP5Iwjby6GX9XjWI4jUIwjh9. CSeq: 24711539 INVITE. Contact: <sip:192.168.0.1;line=sr-bO8JwGmqLkfiPgyfTj2KXIrAX9gpS-rAXu6QSPhOXjyDbGxpbqi0baTRmEfJwOmqsWfiPgyf>. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 224. X-FS-Support: update_display. Remote-Party-ID: "XXX" <sip:XXXX@XXXX>;party=calling;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1330077574 1330077575 IN IP4 XXXX. s=FreeSWITCH. c=IN IP4 XXXX. t=0 0. m=audio 38806 RTP/AVP 18 8 0 101 13. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=nortpproxy:yes. U IPB.IPB.IPB.IPB:5060 -> IPA.IPA.IPA.IPA:5060 SIP/2.0 100 Trying. From: "XXXX" <sip:XXXX@XXXX>;tag=ej9ta117t310r. To: <sip:XXXX@XXXX>;tag=1491ef95c94cd6e3fd8ab36b. CSeq: 24711539 INVITE. Call-ID: !!. Via: SIP/2.0/UDP XXXX:5060;branch=z9hG4bK711.2c4d5be1.0. Via: SIP/2.0/UDP 192.168.0.1:5060;branch=z9hG4bKsr-YD8Tc92pXoRWfxhHXugAcu29X-rkcu2ASuyY-jkFlv6zbai0baTRSPhOXjyIbGxp6OHRNu8df9fI-9iOlaU5WPm2EuioEGY*. Content-Length: 0.

3 5

Reload lua script?
by Javier Gallart 30 Mar '12

30 Mar '12

Hello all I'm starting to play with lua scripting in Kamailio. It's really cool, some complex stuff in the script becomes really easy this way. The script is becoming quite big, therefore I'd like to use lua_run instead of lua_dofile. My doubt is pretty basic: if i load a script in memory at startup via the "load" parameter and the script is modifed afterwards, is there any way to reload the module so the script is reread? Thanks in advance Regards Javi

2 3

alphabetic indexes for devel version
by Daniel-Constantin Mierla 30 Mar '12

30 Mar '12

Hello, I generated alphabetic indexes for module parameters, functions, mi commands and statistics: - https://www.kamailio.org/wiki/start#alphabetic_indexes If any of you find errors or missing items, report back to the lists. A note for developers, if you have to use '[[' in the __title__ of the sections for these components, add a space between them otherwise will conflict with wiki syntax and break the indexing (such '[' is commonly used for optional parameters). Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

1 0

Re: [SR-Users] how to configure Kamailio in ECHO mode
by Alex Balashov 29 Mar '12

29 Mar '12

No, it's not possible. I think you have the wrong idea about what Kamailio is. Kamailio neither receives nor produces audio at all. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Atlanta, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com "Fomitchev, AndreiX" <andreix.fomitchev(a)intel.com> wrote: >Oups, sorry, bad manipulation: >I want to configure Kamailio in echo mode, i.e. SIP server repeats the input audio into the output, so I can hear myself with a very small amount of delay... > >Is it possible? If so, how? > >Thank you for your help. > >Best regards, > >From: Fomitchev, AndreiX >Sent: Thursday, March 29, 2012 1:34 PM >To: 'sr-users(a)lists.sip-router.org' >Subject: how to configure Kamailio in ECHO mode > >Hi, > >For testing purpose, I want to configure a Kamailio server in ECHO mode, i.e. SIP server >--------------------------------------------------------------------- >Intel Corporation SAS (French simplified joint stock company) >Registered headquarters: "Les Montalets"- 2, rue de Paris, >92196 Meudon Cedex, France >Registration Number: 302 456 199 R.C.S. NANTERRE >Capital: 4,572,000 Euros > >This e-mail and any attachments may contain confidential material for >the sole use of the intended recipient(s). Any review or distribution >by others is strictly prohibited. If you are not the intended >recipient, please contact the sender and delete all copies. > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 3

branches usage
by Uri Shacked 29 Mar '12

29 Mar '12

Thanks. so, when i do append_branch and t_relay... i will send two invites at once, right? BR, Uri

2 1

early media: How to change to tag
by Min Wang 29 Mar '12

29 Mar '12

HI I am trying to do the early media like this: PSTN/GW1 -> Kamailio -> Asterisk --> PSTN/GW2 GW1 send invite to Kamilio, Kamilio proxy to Asterisk, Asterisk reply with 183 ( with to tag=A) and sdp After the playing some medium, asterisk send 603 reply to Kamailio Kamilio intercept the 603, and lookup the routing table, decide to send invite to GW2. GW2 reply with 180/200OK with to tag=B In order to properly proxy the msg to GW1, Kamailio seems need to change the to tag from B to A. Is it the right way to do? If so how to change the to tag? or do I need B2BUA ( only signalling) to do the early media? thanks. min

5 6

Update of wiki write access
by Daniel-Constantin Mierla 29 Mar '12

29 Mar '12

Hello, just to let you know that over the weekend the ACL (user authentication) for write access to wiki portals of the project has been turned on. Anyone that wants to write to the wiki has to create herself/himself an account. The reason for requiring user authentication is weakness of the captha system used for anonymous posting -- during the past weeks lot of wiki pages were updated by spam bots. If anyone is aware of a stronger captcha-like system to be used for anonymous posting, write back here. It has to work with dokuwiki. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

3 4

Re: [SR-Users] how to configure Kamailio in ECHO mode
by Alex Balashov 29 Mar '12

29 Mar '12

Probably a user agent that is actually an endpoint, like a PBX or media server. You should take a look at Asterisk or Freeswitch. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Atlanta, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com "Fomitchev, AndreiX" <andreix.fomitchev(a)intel.com> wrote: >Hi Alex, > >Thank you for your response. Please, could you tell me what I need to setup a SIP “echo service”? I am new in SIP domain :/ > >Regards, > >From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov >Sent: Thursday, March 29, 2012 1:38 PM >To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List >Subject: Re: [SR-Users] how to configure Kamailio in ECHO mode > >No, it's not possible. I think you have the wrong idea about what Kamailio is. Kamailio neither receives nor produces audio at all. > >-- >Alex Balashov - Principal >Evariste Systems LLC >235 E Ponce de Leon Ave >Suite 106 >Atlanta, GA 30030 >Tel: +1-678-954-0670 >Fax: +1-404-961-1892 >Web: http://www.evaristesys.com/, http://www.alexbalashov.com > >"Fomitchev, AndreiX" <andreix.fomitchev(a)intel.com<mailto:andreix.fomitchev@intel.com>> wrote: >Oups, sorry, bad manipulation: >I want to configure Kamailio in echo mode, i.e. SIP server repeats the input audio into the output, so I can hear myself with a very small amount of delay… > >Is it possible? If so, how? > >Thank you for your help. > >Best regards, > >From: Fomitchev, AndreiX >Sent: Thursday, March 29, 2012 1:34 PM >To: 'sr-users(a)lists.sip-router.org' >Subject: how to configure Kamailio in ECHO mode > >Hi, > >For testing purpose, I want to configure a Kamailio server in ECHO mode, i.e. SIP server >--------------------------------------------------------------------- >Intel Corporation SAS (French simplified joint stock company) >Registered headquarters: "Les Montalets"- 2, rue de Paris, >92196 Meudon Cedex, France >Registration Number: 302 456 199 R.C.S. NANTERRE >Capital: 4,572,000 Euros > >This e-mail and any attachments may contain confidential material for >the sole use of the intended recipient(s). Any review or distribution >by others is strictly prohibited. If you are not the intended >recipient, please contact the sender and delete all copies. >--------------------------------------------------------------------- >Intel Corporation SAS (French simplified joint stock company) >Registered headquarters: "Les Montalets"- 2, rue de Paris, >92196 Meudon Cedex, France >Registration Number: 302 456 199 R.C.S. NANTERRE >Capital: 4,572,000 Euros > >This e-mail and any attachments may contain confidential material for >the sole use of the intended recipient(s). Any review or distribution >by others is strictly prohibited. If you are not the intended >recipient, please contact the sender and delete all copies. > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Re: [SR-Users] how to configure Kamailio in ECHO mode
by Alex Balashov 29 Mar '12

29 Mar '12

Can you elaborate on what that means? If you are talking about acoustic echo, it's not possible. Kamailio is a proxy / SIP server, it does not handle media or answer calls or anything like that. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Atlanta, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com "Fomitchev, AndreiX" <andreix.fomitchev(a)intel.com> wrote: >Hi, > >For testing purpose, I want to configure a Kamailio server in ECHO mode, i.e. SIP server >--------------------------------------------------------------------- >Intel Corporation SAS (French simplified joint stock company) >Registered headquarters: "Les Montalets"- 2, rue de Paris, >92196 Meudon Cedex, France >Registration Number: 302 456 199 R.C.S. NANTERRE >Capital: 4,572,000 Euros > >This e-mail and any attachments may contain confidential material for >the sole use of the intended recipient(s). Any review or distribution >by others is strictly prohibited. If you are not the intended >recipient, please contact the sender and delete all copies. > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

1 0

Re: [SR-Users] how to configure Kamailio in ECHO mode
by Fomitchev, AndreiX 29 Mar '12

29 Mar '12

Oups, sorry, bad manipulation: I want to configure Kamailio in echo mode, i.e. SIP server repeats the input audio into the output, so I can hear myself with a very small amount of delay... Is it possible? If so, how? Thank you for your help. Best regards, From: Fomitchev, AndreiX Sent: Thursday, March 29, 2012 1:34 PM To: 'sr-users(a)lists.sip-router.org' Subject: how to configure Kamailio in ECHO mode Hi, For testing purpose, I want to configure a Kamailio server in ECHO mode, i.e. SIP server --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

how to configure Kamailio in ECHO mode
by Fomitchev, AndreiX 29 Mar '12

29 Mar '12

Hi, For testing purpose, I want to configure a Kamailio server in ECHO mode, i.e. SIP server --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

branches usage
by Uri Shacked 29 Mar '12

29 Mar '12

Hi, Thanks, this was very helpful for understanding. Still let’s see if i got it right: I get the INVITE. Do whatever I do on the main route. Then do: “append_branch();” “changes….changes…..;” Now before the t_relay do t_on_branch(name of branch). Get the reply (301 in my case) And from here I am back to the original request? maybe a stupid question now but - I must use the append_branch() right :-)? BR, Uri Hi, On 03/27/2012 04:46 PM, Uri Shacked wrote: >* In my case i need to change the header and then send it. *>* *>* Here the case works if i make the changes after i sent the invite and *>* got the reply. As i know the t_on_branch will work after the invite is *>* sent... am i wrong? *>* *>* There are many questions to ask about the branches... when do they work *>* in a serial manner, when parallel... where can i find it documented best? * Actually it's quite simple. If a request comes in and you modify it in a normal route (e.g. calling rtpproxy_offer(), uac_replace_from(), adding additional headers and stuff like that) and you send it out using e.g. t_relay(), then in a serial scenario when you re-enter via a failure-route, these changes will still be there (which is not always what you want). On the other hand, if you register a branch route via t_on_branch() and do your changes there instead of prior to calling t_relay(), then these changes from branch route will be rolled back, and you can do your changes easily again in the same or another branch route starting with your original message. This is important for example in serial call forward scenarios, where the first destination might require an rtpproxy, but the second doesn't, or when the first destination requires different custom headers compare to the second. Basically the same applies to parallel scenarios. If you modify your message before calling lookup() and you've multiple contacts registered for your destination, then your changes will apply for all branches which are created by that. However if you move your modifications to a branch route, then you can work on your messages individually, depending on the branch. Hope this clarifies it a bit. Andreas

2 2

AVPs in timer-route
by Klaus Darilion 29 Mar '12

29 Mar '12

Hi! I wonder what happens to AVPs defined in a route which is executed by rtimer? It seems (tests on Kamailio 1.5) that the AVPs, once they are defined, they life forever. This would be fine for my application. Are there any issues when using AVPs in timer routes? Thanks Klaus

2 3

ITSPA 2012 Award for Open Source VoIP Projects
by Daniel-Constantin Mierla 28 Mar '12

28 Mar '12

Hello, ITSPA UK has unveiled the winners of its 4th annual Awards, an event designed to celebrate innovation and best practice in the VoIP industry: * http://www.itspaawards.org.uk/ Open Source VoIP Projects won a special category this year, Members' Pick, for providing a real value to VoIP Industry. I had the chance to attend the event in London and I have been selected to pick up the award. I made a news on kamailio.org website with more details: * http://www.kamailio.org/w/2012/03/itspa-awards-2012-open-source-voip-projec… As you would expect, a complete voip platform usually involves several open source projects, for components such as load balancers, registrar, proxy or media servers, thus the decision of ITSPA for awarding to the group. I am reiterating the thanks to everyone in the community, developers or users, for their dedication in improving the project. This time extended credits to our British community, very active in both development and usage, for their support in this awards ceremony and overall advertising on the UK markets. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

2 2

TCP memory failures...
by Krishna Kurapati 28 Mar '12

28 Mar '12

I keep getting these... I am using master branch... Mar 26 06:46:34 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:1063]: ERROR: tcpconn_new: mem. allocation failure Mar 26 06:46:34 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:4135]: ERROR: handle_new_connect: tcpconn_new failed, closing socket Mar 26 06:46:48 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:1063]: ERROR: tcpconn_new: mem. allocation failure Mar 26 06:46:48 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:4135]: ERROR: handle_new_connect: tcpconn_new failed, closing socket Mar 26 06:47:51 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:1063]: ERROR: tcpconn_new: mem. allocation failure Mar 26 06:47:51 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:4135]: ERROR: handle_new_connect: tcpconn_new failed, closing socket Mar 26 06:48:45 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:1063]: ERROR: tcpconn_new: mem. allocation failure Mar 26 06:48:45 siptest /usr/sbin/kamailio[5062]: ERROR: <core> [tcp_main.c:4135]: ERROR: handle_new_connect: tcpconn_new failed, closing socket I have never seen this before... what could cause this? Is there something I could do to fix this issue? Krish Kura

2 3

uac with more then one target?
by Karsten Horsmann 28 Mar '12

28 Mar '12

Hello, my kamailio proxy handles calls between public sip-clients and internal ivr systems. Some customer give us calls via sip-trunks to our proxy and this goes to the ivr too. Now some ask if we can act as UAC to get calls from them, for example authenticate to sipgate and feed the landline calls to our ivr system via kamailio. AFAIK the module UAC provides only one pair of user/password credentials. Is that right? Have i here a chance to do the job with kamailio or must i use an second voip system for that? -- Mit freundlichen Grüßen *Karsten Horsmann*

3 2

Re: [SR-Users] Search all dialogs - Kamailiio 3.0.3
by Daniel-Constantin Mierla 28 Mar '12

28 Mar '12

Hello, On 3/23/12 2:00 PM, Charles Chance wrote: > > Hi all, > > I was wondering if anyone could offer any advice please. > > We are using the dialog module and need to be able to find out whether > another dialog exists within a particular profile and having a > specific value, so that we can send the new call to the same gateway. > As far as I am aware, the only way to see other dialogs from the > request route is to query the database (having set db mode to > realtime). This is ok, but the profile/value is not stored in the > database table. Is there a way of fetching the information that I am > missing, or should we just add some customisation to the module so > that it also writes this information to db? > in the last version you can attach variables to dialog and they are stored in database -- but that requires you to upgrade. Also, devel version saves the profiles in database, in a json format. What you can do with 3.0.x: - use sqlops to write to db table the info you need -- you would have to update db based on call events, such as initial invite: insert record to db; 200ok to initial invite, confirm the dialog in the record; bye: delete the db record; you need to delete also for the case of negative reply to invite. You can use rtimer to delete old records (those that don't get bye). This is pretty much what dialog module does, but hides it in the c code -- all doable in the config - use htable module to store the details in memory instead of a db table In summary: upgrading to 3.2.x makes your life much easier. Next major release comes with a better dialog storage, you may want to play with it as well. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

2 1

siptrace and duplicate_uri - not forwarding the packets
by Mino Haluz 28 Mar '12

28 Mar '12

Hi, I have siptrace working but when I set duplicate_uri, no packet is sent to the destination. Was there some bug fix or anything I have to set further? There is nothing in syslog, siptrace locally is stored fine. modparam("siptrace", "db_url", "mysql://localhost/kamailio") # Database URL # modparam("siptrace", "traced_user_avp", "$avp(s:traced_user)") modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_flag", 22) # Flag is used to mark messages to trace modparam("siptrace", "trace_sl_acks", 0) # Do not trace ACKs separately. They are traced during normal sip_trace() modparam("siptrace", "duplicate_uri", "sip:IP1:5060") kamailio 3.2.0 Thanks Mino

2 2

kamailio 3.2.2 undefined symbol: boot_OpenSER while loading module perl
by Karsten Horsmann 28 Mar '12

28 Mar '12

Hi, i am using Centos 6 (32bit) and kamailio 3.2.2 build from the tar.gz. I installed all dependencies for the modules and the make all, make install seems to be fine. But something is wrong with my kamailio - how can i fix this? If i try to load the perl module i get this error messages: ERROR: <core> [sr_module.c:565]: ERROR: load_module: could not open module </usr/local/lib/kamailio/modules_k/perl.so>: /usr/local/lib/kamailio/modules_k/perl.so: undefined symbol: boot_OpenSER <core> [cfg.y:3501]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 214, column 12-20: failed to load module ls -la /usr/local/lib/kamailio/modules_k/perl.so -rwxr-xr-x 1 root root 107985 28. Mär 09:38 /usr/local/lib/kamailio/modules_k/perl.so ldd /usr/local/lib/kamailio/modules_k/perl.so linux-gate.so.1 => (0x008fe000) libperl.so => /usr/lib/perl5/CORE/libperl.so (0x00dd8000) libresolv.so.2 => /lib/libresolv.so.2 (0x00343000) libnsl.so.1 => /lib/libnsl.so.1 (0x00cdf000) libdl.so.2 => /lib/libdl.so.2 (0x0024f000) libm.so.6 => /lib/libm.so.6 (0x00fab000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x002c3000) libutil.so.1 => /lib/libutil.so.1 (0x00d21000) libpthread.so.0 => /lib/libpthread.so.0 (0x00110000) libc.so.6 => /lib/libc.so.6 (0x0035c000) libkmi.so.1 => /usr/local/lib/kamailio/libkmi.so.1 (0x00aa1000) /lib/ld-linux.so.2 (0x004f7000) libfreebl3.so => /lib/libfreebl3.so (0x00632000) -- Kind Regards Mit freundlichen Grüßen *Karsten Horsmann*

2 1

CRLF Error with tcp_crlf_ping
by Jijo 27 Mar '12

27 Mar '12

Hi All. As per the tcp_crlf_ping description, kamailio shall reply CRLF only when it receives "CRLF CRLF". But In the 3.1.0 version, if kamailio recieves "CRLF", it respond back CRLF. Is this an expected behavior or an error? Thanks Jijo

2 6

Re: [SR-Users] Error loading pv.so undefined symbol: msg_ctx_id_set
by Daniel-Constantin Mierla 27 Mar '12

27 Mar '12

Hello, On 3/27/12 9:33 PM, Simpson Chua wrote: > Hi, > > [..] > > # /usr/local/kamailio/sbin/kamailio -V > version: kamailio 3.3.0-dev6 (x86_64/linux) 6853a8 for devel version be sure you run latest version from master branch. I just started with default config and runs fine, no missing symbol. Cheers, Daniel > [...] > ------------------------------------------------------------------------ > *From:* Daniel-Constantin Mierla <miconda(a)gmail.com> > *To:* Simpson Chua <simpsonchua(a)yahoo.com>; SIP Router - Kamailio > (OpenSER) and SIP Express Router (SER) - Users Mailing List > <sr-users(a)lists.sip-router.org> > *Sent:* Tuesday, March 27, 2012 2:23 PM > *Subject:* Re: [SR-Users] Error loading pv.so undefined symbol: > msg_ctx_id_set > > Hello, > > are you sure you are running 3.2.x? That version does not have > msg_ctx_id_set() at all yet. Can you send the output of 'kamailio -V'? > > Cheers, > Daniel > > On 3/27/12 8:51 PM, Simpson Chua wrote: >> Hi, >> >> I'm getting the following error when attempting to load pv.so >> >> kamailio: ERROR: <core> [sr_module.c:572]: ERROR: load_module: could >> not open module </usr/local/lib64/kamailio/modules_k/pv.so>: >> /usr/local/lib64/kamailio/modules_k/pv.so: undefined symbol: >> msg_ctx_id_set >> >> I'm running Kamailio 3.2.x. >> >> Thanks, >> Simpson >> >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla > Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany > http://www.asipto.com/index.php/kamailio-advanced-training/ > > -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

1 0

Error loading pv.so undefined symbol: msg_ctx_id_set
by Simpson Chua 27 Mar '12

27 Mar '12

Hi, I'm getting the following error when attempting to load pv.so kamailio: ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/local/lib64/kamailio/modules_k/pv.so>: /usr/local/lib64/kamailio/modules_k/pv.so: undefined symbol: msg_ctx_id_set I'm running Kamailio 3.2.x. Thanks, Simpson

2 1

Re: [SR-Users] branches usage
by Uri Shacked 27 Mar '12

27 Mar '12

On Tue, Mar 27, 2012 at 3:13 PM, Uri Shacked <uri.shacked(a)gmail.com> wrote: > Hi, > > > > Following the advice I got on the subject “remove_hf" and "append_hf" one > after the other , twice, issue”, I tried to work with the “append_branch()” > function. > > What I need to do is, after I received the invite from the original user, > I use SIP methods to work with the NP server. I subst() the user part, send > the call to the NP server, get the reply, parse it and then subst() back to > the destination and send the call out. > > Doing it with “append_branch” seems logical. > > I do “append_branch()” before changing the user, get the reply (301), > goes on to failure route after the branch route was called, and from there > I have a problem. > > I need to continue my flow without the branch I added. How do I return to > the original on? > > I read about the t_drop_replies but didn’t quit understand….. > > > > BR, > > Uri >

4 5

Re: [SR-Users] Kamailio modifying ruri during loose-route - SOLVED
by Dan-Cristian Bogos 27 Mar '12

27 Mar '12

Another one bites the dust ;). My problem was strict vs loose routing done by loose_route function. In order to loop through B2BUA I have defined the loopback interface's IP as a local alias for simplicity in checking myself in routing script. When doing loose_route, the route address was for some reason not matching my server and due to strict routing the RURI was rewritten with the weird address in the route header. Hope my report helps someone in the future. DanB

1 0

"remove_hf" and "append_hf" one after the other , twice, issue.
by Uri Shacked 27 Mar '12

27 Mar '12

Thanks. I read option 2 and i agree on 1 :-) Didnt use any "branch stuff" yet :-(... it seems very logical to do so when i send the call to the NP server. Will hit the docs... Hi, when you are adding the new Contact-Header in Failure-Route (after you received the 3xx reply), you are working on the original message again. So the old Contact is still removed and the new Contact is added (as for the initial request). There are two options for you: 1) Move your remove_hf/append_hf into a branch route (so the changes are only for the current branch) 2) Use "msg_apply_changes()" before removing and adding the header again (see http://kamailio.org/docs/modules/devel/modules/textopsx.html#textopsx.msg_a… ) I i were you, i'd choose option 1, since for Option 2 the message and the headers need to be parsed again.... (performance penalty). Good luck, Carsten 2012/3/27 Uri Shacked <ushacked at gmail.com<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> >: >* Hi, *>* *>* *>* *>* In the scenario i am using, the flow is as followed: *>* *>* 1. Getting the INVITE from the user *>* *>* 2. Sending an INVITE with RURI changes to the NP server (sip NP server) *>* *>* 3. Getting a 301 reply (using the reply for the NP code) *>* *>* 4. Sending the call to the destination. *>* *>* *>* *>* My problem is that the NP server needs some parameters in the contact *>* header. *>* *>* So, here is what i do : *>* *>* *>* *>* First, before sending the invite to the NP: *>* *>* *>* *>* remove_hf("Contact"); *>* *>* append_hf("Contact *>* :<sip:XXX at server_ip<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> :port;param1=p1;param2=p2>\r\n","Contact"); *>* *>* *>* *>* (The invite is sent perfectly and works great) *>* *>* *>* *>* After the NP reply i do: *>* *>* *>* *>* remove_hf("Contact"); *>* *>* append_hf("Contact :$ct","Contact"); *>* *>* *>* *>* Now I notice there are two contact headers. It seems that the remove_hf *>* didn’t work this time. *>* *>* Any ideas? *>* *>* *>* *>* Thanks, *>* *>* Uri *

1 0

"remove_hf" and "append_hf" one after the other , twice, issue.
by Uri Shacked 27 Mar '12

27 Mar '12

Hi, In the scenario i am using, the flow is as followed: 1. Getting the INVITE from the user 2. Sending an INVITE with RURI changes to the NP server (sip NP server) 3. Getting a 301 reply (using the reply for the NP code) 4. Sending the call to the destination. My problem is that the NP server needs some parameters in the contact header. So, here is what i do : First, before sending the invite to the NP: remove_hf("Contact"); append_hf("Contact :<sip:XXX@server_ip :port;param1=p1;param2=p2>\r\n","Contact"); (The invite is sent perfectly and works great) After the NP reply i do: remove_hf("Contact"); append_hf("Contact :$ct","Contact"); Now I notice there are two contact headers. It seems that the remove_hf didn’t work this time. Any ideas? Thanks, Uri

2 1

Passwords in Kamailio user table are not encrypted.
by Albert Petit 27 Mar '12

27 Mar '12

good morning When provisioning subscriebrs to Kamailio with the kamctl tool i see the passwords are stored in clear on the database. For my use-case I would not like to have that passwords in clear on the db. What can I do to avoid this problem? Should I provision the users in a different way and not using kamctl tool or configure kamailio differently? If there is no way to achieve this would be dangerous if I edit the kamctl tool so it does not store any value on the password column and just store HA and HA1B values? BR,

2 1

Re: [SR-Users] Kamailio Load Testing
by Uri Shacked 26 Mar '12

26 Mar '12

> > > >How do you reload your htable? Is it using the exec( ) function to call > the > >mi command sht_reload? Or do you have another method? > > I use the exec() to run a shell script with the relevant mi command. the > shell script return code is used to make sure all went OK. > > >Thanks > > >Reda > > > > On Mon, Mar 26, 2012 at 14:56, Uri Shacked <ushacked at gmail.com<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>> > wrote: > > >* Hi, > *>* > *>* > *>* > *>* I made these kinds of tests before. I have two tips for you to pay > *>* attention to: > *>* > *>* 1. Read about the [routes] on SIPp, It is tricky to satisfy > kamailio > *>* with SIPp scenarios. > *>* > *>* 2. Make sure your DB table is well build (use less varchars and > more > *>* integers). > *>* > *>* I found out that there are many kamailio modules I can use to load > data in > *>* to memory and I hardly use the DB (only for ACC). I use MTREE, HTABLE, > *>* DIALPLAN, CARRIERROUTE, DROUTING, and so to store the information I > need. > *>* And I get it with the simple functions of the module. > *>* > *>* I load around 6 million numbers and other data which takes about 1.5 > Gb of > *>* the memory. > *>* > *>* For getting around the real-time changes that I need to deal with (In > DB > *>* the data changes are immediately made on your service…). I have a > RTIMER > *>* every 120 sec that check is a reload is needed. If so, it reloads the > *>* relevant data (very fast). > *>* > *>* BR, > *>* > *>* Uri > *>* > *>* > *>* > *>* > *>* Hello, > *>* > *>* On 3/20/12 12:12 PM, Stephen Dodge (Bistech) wrote: > *>* >* > *>* *>* Hello, > *>* *>* > *>* *>* I am running Kamailio 3.1.5 with a MySQL backend on CentOS. A > *>* *>* connection to MySQL (an off box MySQL cluster) is required for > every > *>* *>* call, sqlops is used to determine destinations and acc to record > CDR * > *>* >* information. > *>* *>* > *>* *>* I am planning to load test our server using SIPp to generate > calls, I > *>* *>* was wondering if anyone has done something similar and could > provide > *>* *>* advice on what we should monitor on our Kamailio Server. i.e > Server > *>* *>* CPU & Memory > *>* *>* > *>* *>* Thanks in advance for your help. > *>* *>* > *>* *if you do a lot of direct DB interactions, perhaps latency of the > *>* queries will be relevant. You can use benchmark module to see how long > *>* it takes to execute part of the config file. > *>* > *>* I think you don't fetch lot of records from db in config, so memory > *>* should be no problem, however you can dump private/shared memory usage > *>* via RPC commands within sercmd cli. CPU is a good metric always and > easy > *>* to watch with systems tools. > *>* > *>* Cheers, > *>* Daniel > *>* >* > *>* *>* Steve. > *>* * > * >

1 0

TLS delay on request processing
by Andreas Heise 26 Mar '12

26 Mar '12

Hi list, I use Kamailio 3.2.2 as TLS<=>TCP gateway this is working well, but if I create some traffic by SIPP then Kamailio response time increase with every new call, seems to be that Kamailio process call by call. I made a test with 30caps then after ~200calls Kamailio need ~3s to response an initial INVITE from the PBX. This delay seems to be increased with each call. test scenario: SIPP UAC---TCP---PABX---TLS---Kamailio---TCP---SIPP UAS 1.1.1.1 = PABX 2.2.2.2 = SIPP UAS 5.5.5.5 = Kamailio if ($si == "1.1.1.1") # from PABX { xlog("L_INFO","FROM PABX: $rm, $ci\n"); t_on_reply("1"); force_send_socket(tcp:5.5.5.5:5060); rewritehostport("2.2.2.2:5070"); t_relay_to_tcp("2.2.2.2","5070"); exit; }; I got all the calls in a single TLS connection from the PBAX so increasing of TCP childs doesn't help. I also already tried to adjust some TCP buffers and played with TCP_ASYNC. With UDP / TCP it's better, is really the TLS/openssl is the bottleneck or the way I relay the request? The test machine has only 512MB RAM and is a single core cpu (2,8GHZ), but 30caps isn't much? Any suggestions? many thanks, Andreas

2 2

Kamailio modifying ruri during loose-route
by Dan-Cristian Bogos 26 Mar '12

26 Mar '12

Hey Guys, I have noticed some unexpected behavior (at least by me) during my tests. When routing specific ACK message back to 200 OK originator, Kamailio will rewrite the ruri with the value of route header. Is that known or some memory access problem? Call setup: B2BUA(127.0.0.1) -> Kamailio (1.2.3.4) -> End device (2.3.4.5). Bellow is a trace of 200 OK -ACK flow before and after kamailio, together with the xlog capture of ruri before and after calling loose_route on ACK. Thanks in advance for any kind of tip. DanB PS: Since testing with a newer version would be a bit harder due to some particular features I use in 3.1 which are taking a bit of effort to migrate, have tried my luck here before, so hope to get your understanding. Kamailio version: """ root@kam:/home/dan# kamailio -V version: kamailio 3.1.5 (x86_64/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 07:41:01 Sep 15 2011 with gcc 4.4.5 """ Syslog: """ Mar 26 14:27:01 kam /usr/sbin/kamailio[7929]: ERROR: <script>: Before loose_route, ru is sip:01234567@127.0.0.1:5069;transport=udp Mar 26 14:27:01 kam /usr/sbin/kamailio[7929]: ERROR: <script>: Loose route, ru is sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes """ Ngrep of call: """ # U 2012/03/26 14:27:00.089455 127.0.0.1:5069 -> 1.2.3.4:25060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 1.2.3.4:25060;branch=z9hG4bK361e.ba530345.0. Via: SIP/2.0/UDP 192.168.1.29:5060;rport=3081;received=2.3.4.5;branch=z9hG4bK-373632-e2d6ebcc5a1d2a481e4957541b393f9a. Record-Route: <sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes>. From: "ines.demo" <sip:ines.demo@mydomain.net>;tag=a9c837bc. To: <sip:01234567@mydomain.net>;tag=BcBSHa56Bp7ge. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 INVITE. Contact: <sip:01234567@127.0.0.1:5069;transport=udp>. User-Agent: WebiB2BUA 1.0.6. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 417. Remote-Party-ID: "01234567" <sip:01234567@mydomain.net>;party=calling;privacy=off;screen=no. . v=0. o=root 13076 13076 IN IP4 1.2.3.4. s=session. c=IN IP4 1.2.3.4. t=0 0. m=audio 48548 RTP/AVP 8 0 102 3 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:102 iLBC/8000. a=fmtp:102 mode=30. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=nortpproxy:yes. m=video 0 RTP/AVP 96 97 98. a=rtpmap:96 /0. a=rtpmap:97 /0. a=rtpmap:98 /0. # U 2012/03/26 14:27:00.089589 1.2.3.4:25060 -> 2.3.4.5:3081 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.29:5060;rport=3081;received=2.3.4.5;branch=z9hG4bK-373632-e2d6ebcc5a1d2a481e4957541b393f9a. Record-Route: <sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes>. From: "ines.demo" <sip:ines.demo@mydomain.net>;tag=a9c837bc. To: <sip:01234567@mydomain.net>;tag=BcBSHa56Bp7ge. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 INVITE. Contact: <sip:01234567@127.0.0.1:5069;transport=udp>. User-Agent: WebiB2BUA 1.0.6. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 417. Remote-Party-ID: "01234567" <sip:01234567@mydomain.net>;party=calling;privacy=off;screen=no. . v=0. o=root 13076 13076 IN IP4 1.2.3.4. s=session. c=IN IP4 1.2.3.4. t=0 0. m=audio 48548 RTP/AVP 8 0 102 3 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:102 iLBC/8000. a=fmtp:102 mode=30. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=nortpproxy:yes. m=video 0 RTP/AVP 96 97 98. a=rtpmap:96 /0. a=rtpmap:97 /0. a=rtpmap:98 /0. # U 2012/03/26 14:27:00.160046 2.3.4.5:3081 -> 1.2.3.4:25060 ACK sip:01234567@127.0.0.1:5069;transport=udp SIP/2.0. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 ACK. Via: SIP/2.0/UDP 192.168.1.29:5060;branch=z9hG4bK-373632-6eac5ecf0ba5ab4ce7094ad17870dca3. From: "ines.demo" <sip:ines.demo@mydomain.net>;tag=a9c837bc. To: <sip:01234567@mydomain.net>;tag=BcBSHa56Bp7ge. Max-Forwards: 70. Route: <sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes>. Contact: "ines.demo" <sip:ines.demo@192.168.1.29:5060;transport=udp;registering_acc=mydomain_net>. User-Agent: Jitsi1.0-beta1-nightly.build.3820Windows 7. Content-Length: 0. . # U 2012/03/26 14:27:00.160278 1.2.3.4:25060 -> 1.2.3.4:25060 ACK sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes SIP/2.0. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 ACK. Via: SIP/2.0/UDP 1.2.3.4:25060;branch=z9hG4bKcydzigwkX. Via: SIP/2.0/UDP 192.168.1.29:5060;rport=3081;received=2.3.4.5;branch=z9hG4bK-373632-6eac5ecf0ba5ab4ce7094ad17870dca3. From: "ines.demo" <sip:ines.demo@mydomain.net>;tag=a9c837bc. To: <sip:01234567@mydomain.net>;tag=BcBSHa56Bp7ge. Max-Forwards: 69. Contact: "ines.demo" <sip:ines.demo@2.3.4.5:3081;transport=udp;registering_acc=mydomain_net>. User-Agent: Jitsi1.0-beta1-nightly.build.3820Windows 7. Content-Length: 0. """

2 1

Kamailio Load Testing
by Uri Shacked 26 Mar '12

26 Mar '12

Hi, I made these kinds of tests before. I have two tips for you to pay attention to: 1. Read about the [routes] on SIPp, It is tricky to satisfy kamailio with SIPp scenarios. 2. Make sure your DB table is well build (use less varchars and more integers). I found out that there are many kamailio modules I can use to load data in to memory and I hardly use the DB (only for ACC). I use MTREE, HTABLE, DIALPLAN, CARRIERROUTE, DROUTING, and so to store the information I need. And I get it with the simple functions of the module. I load around 6 million numbers and other data which takes about 1.5 Gb of the memory. For getting around the real-time changes that I need to deal with (In DB the data changes are immediately made on your service…). I have a RTIMER every 120 sec that check is a reload is needed. If so, it reloads the relevant data (very fast). BR, Uri Hello, On 3/20/12 12:12 PM, Stephen Dodge (Bistech) wrote: >* *>* Hello, *>* *>* I am running Kamailio 3.1.5 with a MySQL backend on CentOS. A *>* connection to MySQL (an off box MySQL cluster) is required for every *>* call, sqlops is used to determine destinations and acc to record CDR *>* information. *>* *>* I am planning to load test our server using SIPp to generate calls, I *>* was wondering if anyone has done something similar and could provide *>* advice on what we should monitor on our Kamailio Server. i.e Server *>* CPU & Memory *>* *>* Thanks in advance for your help. *>* *if you do a lot of direct DB interactions, perhaps latency of the queries will be relevant. You can use benchmark module to see how long it takes to execute part of the config file. I think you don't fetch lot of records from db in config, so memory should be no problem, however you can dump private/shared memory usage via RPC commands within sercmd cli. CPU is a good metric always and easy to watch with systems tools. Cheers, Daniel >* *>* Steve. *

2 1

2 rollover contacts per user
by Krishna Kurapati 26 Mar '12

26 Mar '12

Hi, Is there a way to set up maximum of 2 active roll over contacts per user? Currently when I setup max contacts param as 2, The third one is responding with 503 error for 3rd Register. How can we remove one of the contacts and replace it with the new one. I need it when the device is switching over from Wifi to 3G and back. or Wifi network to Wifi network switching. Thanks Krish Kura

3 5

Kamailio IMS + TLS
by trojak＠st.fri.uniza.sk 26 Mar '12

26 Mar '12

Hello, I am trying to add TLS support to kamailio PCSCF sever. After defining WITH_TLS value and editing tls.cfg file for right path to certificate and key I am still getting following errors: Mar 26 10:23:03 pcscf /usr/sbin/kamailio[12916]: ERROR: pcscf [mod.c:951]: ERR:P-CSCF:mod_init: get_tls_session_hash not found ! Mar 26 10:23:03 pcscf /usr/sbin/kamailio[12916]: ERROR: <core> [sr_module.c:875]: init_mod(): Error while initializing module pcscf (/usr/lib/kamailio/modules/pcscf.so) Mar 26 10:23:03 pcscf kamailio: ERROR: <core> [daemonize.c:269]: Main process exited before writing to pipe Is tls supported yet ? Will by packages in your repository updated to work with kamailio 3.2 ? Or any future updates of kamailio-ims-modules ? Thank you for help Best regards Lubo

2 1

question about cdrtool + freeradius
by Rabary 26 Mar '12

26 Mar '12

Hi all, I don't know if I'm in the right mailing, if not sorry in advance, if yes why I can't insert record in the mysql database for call accounting because it seems like the request is not complete. I put an attachment file, mysql log and /etc/freeradius/sql.conf. Thanks. -- Rabary Teddy Gulfsat Madagascar Service Technique +261-203-085-085 +261-345-600-080 Inutile d'imprimer ce mail

1 1

Absorbing ack's
by Egbert Groot 26 Mar '12

26 Mar '12

Hi all, I'm having an issue with ACK's being proxied. When an INVITE first comes in (new transaction, new dialog), I do a 'www_challenge(...)'. This makes the proxy send a '401 Unauthorized' reply. The client acknowledges this reply with "ACK". This ACK is 'absorbed' by the proxy. When during an established call/dialog the client sends an INVITE to set the call on hold, this is an in dialog INVITE (with to-tag etc). Although authentication for this INVITE isn't very necessary, my script does 'www_challenge' anyway. The proxy sends '401 Unauthorized', the client responds with 'ACK'. This ACK however is not 'absorbed' as it should be, but forwarded/proxied (or at least handed over to the routing script). Is this intended behaviour? If so, how can I recognize this ACK to be able to drop it? I found some related info in this email thread: http://lists.kamailio.org/pipermail/devel/2008-December/017246.html but doesn't discuss this exact issue. Though this isn't a big problem for me (the upstream gateway ignores the ack, and I can disable authentication for re-invite's), I'm curious why the proxy behaves this way. Hopefully someone can enlighten me. regards, Egbert.

2 3

Swetha Raj wants to chat
by Swetha Raj 25 Mar '12

25 Mar '12

----------------------------------------------------------------------- Swetha Raj wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-862072731c-0c524df936-ytpYnbv7Nb5LSAtA5JKiVfr… You'll need to click this link to be able to chat with Swetha Raj. To get Gmail - a free email account from Google with over 2,800 megabytes of storage - and chat with Swetha Raj, visit: http://mail.google.com/mail/a-862072731c-0c524df936-ytpYnbv7Nb5LSAtA5JKiVfr… Gmail offers: - Instant messaging right inside Gmail - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into "conversations" - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages All this, and its yours for free. But wait, there's more! By opening a Gmail account, you also get access to Google Talk, Google's instant messaging service: http://www.google.com/talk/ Google Talk offers: - Web-based chat that you can use anywhere, without a download - A contact list that's synchronized with your Gmail account - Free, high quality PC-to-PC voice calls when you download the Google Talk client We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser).

1 0

Kamailio Load Testing
by Stephen Dodge (Bistech) 24 Mar '12

24 Mar '12

Hello, I am running Kamailio 3.1.5 with a MySQL backend on CentOS. A connection to MySQL (an off box MySQL cluster) is required for every call, sqlops is used to determine destinations and acc to record CDR information. I am planning to load test our server using SIPp to generate calls, I was wondering if anyone has done something similar and could provide advice on what we should monitor on our Kamailio Server. i.e Server CPU & Memory Thanks in advance for your help. Steve. ________________________________ Information in this message, including any attachments, is confidential to the person to whom it is addressed and may be legally privileged. If you are not the intended recipient please notify the sender and delete the message from your system. Please note that Bistech Group plc, Bistech plc, Bisnet Limited and the sender do not accept any responsibility for viruses. It is your responsibility to check the e-mail and any attachments for viruses. Calls may be monitored and recorded.

3 2

Re: [SR-Users] Accessing #!define "variables" from within lua
by Alex Balashov 24 Mar '12

24 Mar '12

I am not sure that exporting #defines to third-party language API modules makes much sense just because some user thought it would be neat. The #!... constructs are all intended as preprocessor directives, to make easier management of global constant values in the native Kamailio config environment and to allow easier management of conditionally-enabled chunks of code therein, right? Conceptually, it does not seem to me that they should have any representation outside of that evaluative context. It would be like making preprocessor macro values in C available through the libdl/ELF dynamic shared object interface. It doesn't make any sense. If you really want to export preprocessor macro-dependent values, trouble yourself to use an intermediate variable--a real variable. In Kamailio, this would take the form: #!ifdef MYPROJECT #!define MYPROJECT_IP 1.2.3.4 # Exportable symbol: myproject.ip = "MYPROJECT_IP" descr "..." #!endif Doesn't that make much more sense, in terms of what these directives were really intended for? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Atlanta, GA 30030 Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: >Hello, > >On 3/23/12 2:00 PM, Asgaroth wrote: >> I'll check this option out, thanks for the tip Alex. >it is a good way to do, $sel(...) are available in Lua, @... format not, >but they are the same, just different access mechanism. > >> >> I guess the other option too, which I have not tried, is to possibly >> pass in the values as lua script parameters. > >Yes, you can do that. You may need to use 'subst' instead of 'define' in >order to be able to replace the token inside another string. > >Exporting defines to Lua could be a good enhancement anyhow, I will >think about and maybe add it in the near future. > >Cheers, >Daniel > >> >> On 23/03/12 12:12, Alex Balashov wrote: >>> Have you considered using selectors/cfg_get variables instead? >>> >>> They are also a common way to store various types of "global" >>> values/constants, with the difference that they can be accessed at >>> run time using PV container functions instead of set at preprocessing. >>> >>> myproject.local_ip = "1.2.3.4" descr "IP address" >>> >>> $sel(cfg_get.my project.local_ip) >>> Or SER-style: @cfg_get.my project.local_ip >>> >>> You can evaluate those in Lua, right? >>> >>> -- >>> Alex Balashov - Principal >>> Evariste Systems LLC >>> 235 E Ponce de Leon Ave >>> Suite 106 >>> Atlanta, GA 30030 >>> Tel: +1-678-954-0671 >>> Web: http://www.evaristesys.com/, http://www.alexbalashov.com >>> >>> Asgaroth<00asgaroth00(a)gmail.com> wrote: >>> >>>> Hi All, >>>> >>>> I am looking at writing a lua function that would really benefit from >>>> accessing "variables" that I would have defined by using the #!define >>>> statement. Is this at all possible? I've tried looking at the >>>> documentation surrounding lua and kamailio, but I cannot see how I >>>> would >>>> access it. I thought I'd ask the list to see if anyone else may have >>>> attempted this. >>>> >>>> for example, I may have >>>> >>>> #!define INTERNAL_ADDRESS 1.2.3.4 >>>> >>>> Which I subsequently use through the the routing script to refer to the >>>> internal address I am listening on. Now I would like to try and access >>>> this "variable" from a lua script. Any pointers/tips/workarounds would >>>> be greatly appreciated. >>>> >>>> Thanks >>>> >>>> _______________________________________________ >>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>> sr-users(a)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(a)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(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >-- >Daniel-Constantin Mierla >Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany >http://www.asipto.com/index.php/kamailio-advanced-training/ > > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

www_authenticate("127.0.0.1", "credentials")
by Marwan Idriss 24 Mar '12

24 Mar '12

Greeting, I want to ask you how the function www_authenticate("127.0.0.1", "credentials") work and what should I put the credentials Table Regards Marwan

2 1

Re: [SR-Users] Accessing #!define "variables" from within lua
by Alex Balashov 24 Mar '12

24 Mar '12

Have you considered using selectors/cfg_get variables instead? They are also a common way to store various types of "global" values/constants, with the difference that they can be accessed at run time using PV container functions instead of set at preprocessing. myproject.local_ip = "1.2.3.4" descr "IP address" $sel(cfg_get.my project.local_ip) Or SER-style: @cfg_get.my project.local_ip You can evaluate those in Lua, right? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Atlanta, GA 30030 Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com Asgaroth <00asgaroth00(a)gmail.com> wrote: >Hi All, > >I am looking at writing a lua function that would really benefit from >accessing "variables" that I would have defined by using the #!define >statement. Is this at all possible? I've tried looking at the >documentation surrounding lua and kamailio, but I cannot see how I would >access it. I thought I'd ask the list to see if anyone else may have >attempted this. > >for example, I may have > >#!define INTERNAL_ADDRESS 1.2.3.4 > >Which I subsequently use through the the routing script to refer to the >internal address I am listening on. Now I would like to try and access >this "variable" from a lua script. Any pointers/tips/workarounds would >be greatly appreciated. > >Thanks > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 2

Forward UAC Registration with Authentication (like Upper Registration or Passthrough Registration)
by Robert 24 Mar '12

24 Mar '12

Sorry to spam all 3 boards at the same time I know there are smart people on these lists and hoping that one might be willing to send an example config to assist a n00b to SER. I need to configure a proxy (like SBC) to listen on port X where X is not 5060. I want the UAC's registration to be forwarded (NOT REDIRECT) to the real SIP server on port 5060 The far end is not an Asterisk server so any examples of Asterisk do not work. It is not IP auth the authentication relies in the far end. Open to any solution of open source software K/OpenSIPS/OpenSBC etc. IP phone ----> open source -----> SIP server (UAC) ( PORT != 5060) ( PORT = 5060) I have tried all sorts of methods like rewritehostport / t_relay etc etc. Would uac_auth work? And if so anyone have any good examples of dynamic as I do not want to store any credentials in the open source proxy.

2 1

Re: [SR-Users] modify FROM field in the "failure_route" block
by Alex Balashov 24 Mar '12

24 Mar '12

I am going to have to go with the "upgrade" crowd in this one. Running OpenSER 1.3 at this point is like running a libc5-based Linux distro. Almost no advice or discussion is relevant to it because there have been such tectonic, generational shifts since. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Atlanta, GA 30030 Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com Edson - Lists <4lists(a)gmail.com> wrote: >Please upgrade to latest stable and try again.... > >Why? If you have to ask it, than you didn't got it... > >new version === new functionalities > >99% of list support and tips are based on last stable version. 1.3 is >pretty old... > >Edson. > >Em 23/03/2012 10:06, Robert R escreveu: >> Hi, >> >> Even though when I try to use "uac_replace_from( )" in branch_route >> block I get the same error message: >> >> branch_route[2] >> { >> if ( $avp(i:204) ) >> { >> uac_replace_from("hello"); >> } >> >> } >> >> >> error message: >> >> Not starting openser: invalid configuration file! >> Mar 23 09:03:00 [7542] CRITICAL:core:yyerror: parse error in config >> file, line 623, column 26-27: Command cannot be used in the block >> Mar 23 09:03:00 [7542] ERROR:core:main: bad config file (1 errors) >> >> PS: I am running an old release of openser 1.3. >> >> Thanks, >> R >> >> >> >> >> On Thu, Mar 22, 2012 at 1:23 PM, Daniel-Constantin Mierla >> <miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: >> >> >> >> On 3/22/12 6:12 PM, Alex Balashov wrote: >> >> On 03/22/2012 01:00 PM, Robert R wrote: >> >> When I am trying to modify FROM field in the "failure_route" >> block I >> get an error message: >> >> failure_route[1] >> { >> ... >> uac_replace_from("$avp(i:204)"__); >> append_branch(); >> t_relay(); >> } >> >> Not starting openser: invalid configuration file! >> Mar 22 10:51:39 [6457] CRITICAL:core:yyerror: parse error in >> config >> file, line 662, column 32-33: Command cannot be used in the >> block >> Mar 22 10:51:39 [6457] ERROR:core:main: bad config file (1 >> errors) >> >> >> You can probably get around it this way: >> >> failure_route[1] >> { >> ... >> >> append_branch(); >> >> route(STUFF); >> t_relay(); >> } >> >> >> route[STUFF] >> { >> uac_replace_from(...); >> } >> >> indeed this should work -- it is no reason of not being usable in >> failure_route, perhaps is so from the time of development. The >> function itself is allowed in branch_route which is called from >> inside t_relay() (when t_on_branch(...) is used), therefore we can >> relax the restriction for failure_route, imo. >> >> One thing to take care of, if you use uac_replace_from() in request >> route and then in failure route, you may end in malformed format, so >> it is recommended to use it in branch_route, then the changes done >> by the function will be per each forwarded branch. >> >> Cheers, >> Daniel >> >> -- >> Daniel-Constantin Mierla >> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany >> http://www.asipto.com/index.__php/kamailio-advanced-__training/ >> <http://www.asipto.com/index.php/kamailio-advanced-training/> >> >> >> >> _________________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> >> http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users >> <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> >> >> >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)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(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 2

Re: [SR-Users] Authentication on loose_route();
by Alex Balashov 24 Mar '12

24 Mar '12

Clearly, you can only authenticate sequential requests corresponding to calls whose initial requests were subject to authentication. If the initial request was not authenticated, there is no reason to believe that the endpoint would support authentication of sequential requests. As to whether you should do this, that is a controversial matter. I suppose that the security-maximising approach would be to challenge all requests, but it invites problems with many endpoints. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Atlanta, GA 30030 Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com David <kamailio.org(a)spam.lublink.net> wrote: > > >Hello, > >Should I be requiring users to authenticate before letting >them into loose_route(); ? What about anonymous calls from E164, how do >I authenticate these calls after they have started? > >Thanks, > >David > > > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Authentication on loose_route();
by David 23 Mar '12

23 Mar '12

Hello, Should I be requiring users to authenticate before letting them into loose_route(); ? What about anonymous calls from E164, how do I authenticate these calls after they have started? Thanks, David

1 0

cached $TV is 0 in failure route
by Klaus Darilion 23 Mar '12

23 Mar '12

Hi! Is this by design? I would expect it to be either the same value as in the request route, or even better to be calculated new every time it enters the failure route. regards Klaus

2 7

memory allocation failure while reading ca_list
by Juha Heinanen 23 Mar '12

23 Mar '12

in tls.cfg, i made ca_list to point to ca-certificates.crt file that comes with debian. when i then started sip router, i got errors Mar 19 08:45:42 test /usr/sbin/sip-proxy[28093]: ERROR: tls [tls_domain.c:447]: TLSc<default>: Unable to load CA list '/etc/ssl/certs/ca-certificates.crt' Mar 19 08:45:42 test /usr/sbin/sip-proxy[28093]: ERROR: tls [tls_domain.c:448]: load_ca_list:error:07064041:memory buffer routines:BUF_MEM_grow:malloc failure Mar 19 08:45:42 test /usr/sbin/sip-proxy[28093]: ERROR: tls [tls_domain.c:448]: load_ca_list:error:0906D041:PEM routines:PEM_read_bio:malloc failure Mar 19 08:45:42 test /usr/sbin/sip-proxy[28093]: ERROR: tls [tls_domain.c:448]: load_ca_list:error:0B084009:x509 certificate routines:X509_load_cert_crl_file:PEM lib Mar 19 08:45:42 test /usr/sbin/sip-proxy[28093]: ERROR: <core> [sr_module.c:889]: init_mod_child(): Error while initializing module tls (/usr/lib/sip-proxy/modules/tls.so) Mar 19 08:45:42 test /usr/sbin/sip-proxy[28093]: ERROR: <core> [main.c:1554]: ERROR: main: error in init_child(PROC_INT) -- exiting is that because there are too many (= 139) entries in ca-certificates.crt? if so, how to solve the problem? would it be a good idea that sip router would be default be able to handle this correctly? -- juha

3 14

modify FROM field in the "failure_route" block
by Robert R 23 Mar '12

23 Mar '12

Hi, When I am trying to modify FROM field in the "failure_route" block I get an error message: failure_route[1] { ... uac_replace_from("$avp(i:204)"); append_branch(); t_relay(); } Not starting openser: invalid configuration file! Mar 22 10:51:39 [6457] CRITICAL:core:yyerror: parse error in config file, line 662, column 32-33: Command cannot be used in the block Mar 22 10:51:39 [6457] ERROR:core:main: bad config file (1 errors) It seems "uac_replace_from()" can not be used in the "failure_route" block. What's the correct way to modify (appending a tag) FROM field in the "failure_route" block? Thanks, R

5 5

Search all dialogs - Kamailiio 3.0.3
by Charles Chance 23 Mar '12

23 Mar '12

Hi all, I was wondering if anyone could offer any advice please. We are using the dialog module and need to be able to find out whether another dialog exists within a particular profile and having a specific value, so that we can send the new call to the same gateway. As far as I am aware, the only way to see other dialogs from the request route is to query the database (having set db mode to realtime). This is ok, but the profile/value is not stored in the database table. Is there a way of fetching the information that I am missing, or should we just add some customisation to the module so that it also writes this information to db? Many thanks in advance, Charles

1 0

Accessing #!define "variables" from within lua
by Asgaroth 23 Mar '12

23 Mar '12

Hi All, I am looking at writing a lua function that would really benefit from accessing "variables" that I would have defined by using the #!define statement. Is this at all possible? I've tried looking at the documentation surrounding lua and kamailio, but I cannot see how I would access it. I thought I'd ask the list to see if anyone else may have attempted this. for example, I may have #!define INTERNAL_ADDRESS 1.2.3.4 Which I subsequently use through the the routing script to refer to the internal address I am listening on. Now I would like to try and access this "variable" from a lua script. Any pointers/tips/workarounds would be greatly appreciated. Thanks

1 0

Relaying message to Recent contact list...
by Krishna Kurapati 23 Mar '12

23 Mar '12

Hi, I am trying to relay the message to the Registered user. However, I would like to relay only to a recent contact. In case, there are multiple contact, I do not want to relay to older contacts. I am using t_relay() which is currently forking the request to all contacts. Any other way to accomplish my need? Thanks Krish Kura

2 3

Thank you from Google!
by resume-thanks＠google.com 23 Mar '12

23 Mar '12

1 0

ACCDB insert issues
by Uri Shacked 22 Mar '12

22 Mar '12

Hi, I am using the ACCDB with extra data. I collect the data to AVP's and set it on the db_extra. It gets to be 37 columns…. Pretty long… The problem I experience is that after a while (2-3 hours) with about 15 CAPS the MySQL ACC insert error appears. And, I am loosing accounting data. Except of narrowing the amount of columns and setting the fields (INT,CHAR etc.), does anyone has any ideas? The db_insert_mode set to 1 does not work (my ACC table is INNODB because I don’t want to lose info). BR, Uri

2 6

error when using "uac_replace_from( )" in the "failure_route" block
by Robert R 22 Mar '12

22 Mar '12

Hi, When I am trying to modify FROM field in the "failure_route" block I get an error message: failure_route[1] { ... uac_replace_from("$avp(i:204)"); append_branch(); t_relay(); } Not starting openser: invalid configuration file! Mar 22 10:51:39 [6457] CRITICAL:core:yyerror: parse error in config file, line 662, column 32-33: Command cannot be used in the block Mar 22 10:51:39 [6457] ERROR:core:main: bad config file (1 errors) It seems "uac_replace_from()" can not be used in the "failure_route" block. What's the correct way to modify (appending a tag) FROM field in the "failure_route" block? Thanks, R

3 2

Proxy Registrations offset port
by Robert 22 Mar '12

22 Mar '12

I've been playing with OpenSIPS and am willing to change over if it means I'll get a more informed answer from this community.. I need to set up a proxy forwarding server that can listen on a port other than 5060 I.e. 8080 and forward the registration requests to another Voip platform we have that is running on 5060. I've been able to do this under OpenSIPS but I'm having issues with inbound calls. It could be a NAT issue. Basically listen on 8080 forward any and all registrations to x:5060 which I've done using rewritehostport Anyone have any good example configs for this? I'm a n00b at this OpenSER stuff but have been around asterisk / freeswitch / portaone for a while. Thanks in advance

6 12

Does anyone know how to use Sipp to test Kamailio?
by Jiaxiang Zhou 22 Mar '12

22 Mar '12

Hi I want to do the performance testing on the Kamailio. I found the related document about openser 1.2.0 version at: http://www.kamailio.org/docs/openser-performance-tests/. But somehow, I can't make it work with Kamailio 3.1. Do you happen to know what to do? By following the test case at http://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c, I use the command as below to do the test: ./sipp -sf uac_inv.xml<http://www.kamailio.org/docs/openser-performance-tests/data/uac_inv.xml>-rsa 10.1.11.24:5060 192.10.1.11.24:5081 -m 200000 -r 7000 -d 1 -l 27 where 10.1.11.24:5060 is for Kamailio, and 10.1.11.24:5081 is for sipp uas. In the error log, I got the error message: *********************************************************************'. 2012-03-22 08:55:43:933 1332377743.933861: Aborting call on unexpected message for Call-Id '77062-11425(a)172.16.220.1': while expecting '100' (index 1), received 'SIP/2.0 403 Not relaying Via: SIP/2.0/UDP 172.16.220.1:5060 ;branch=z9hG4bK-11425-77062-0;rport=5060;received=10.1.11.197 From: sipp <sip:sipp@172.16.220.1:5060>;tag=11425SIPpTag0077062 To: sut <sip:service@10.1.1.197:5080 >;tag=b27e1a1d33761e85846fc98f5f3a7e58.489a Call-ID: 77062-11425(a)172.16.220.1 CSeq: 1 INVITE Server: kamailio (3.2.0 (x86_64/linux)) Content-Length: 0 '. 2012-03-22 08:55:43:933 1332377743.933965: Aborting call on unexpected message for Call-Id '77063-11425(a)172.16.220.1': while expecting '100' (index 1), received 'SIP/2.0 403 Not relaying Via: SIP/2.0/UDP 172.16.220.1:5060 ;branch=z9hG4bK-11425-77063-0;rport=5060;received=10.1.11.197 From: sipp <sip:sipp@172.16.220.1:5060>;tag=11425SIPpTag0077063 To: sut <sip:service@10.1.1.197:5080 >;tag=b27e1a1d33761e85846fc98f5f3a7e58.853f Call-ID: 77063-11425(a)172.16.220.1 CSeq: 1 INVITE Server: kamailio (3.2.0 (x86_64/linux)) Content-Length: 0 ********************************************************************* Thanks, Josh

2 1

Re: [SR-Users] ACCDB insert issues
by Yufei Tao 22 Mar '12

22 Mar '12

Hi I've also seen this error "ERROR: acc [acc.c:405]: failed to insert into database ". This seem to happen when cdrs_procedure runs at the same time of acc table insert. Can also be reliably reproduced by locking the acc table, make a call (about 20 seconds or more), end the call, wait for a short while, unlock acc table. This causes this error, and Kamailio inserts duplicated INIVTE / BYE entries into acc table. The number of duplicated entries depends on how long you've locked the table for. So I think this acc insert error may have been to do with table locking when cdrs_procedure is run. When there are duplicated entries in acc table, cdrs_procedure takes the first INVITE/BYE entires and updated the cdrs table correctly. But threw an error when it hits the next duplicated entry and stop. So for us it didn't seem to cause any trouble for cdrs records so I didn't chase it further. But would be nice if we could stop/handle the duplicated entries some how. Not a fix at at all, just some clues that might help. Yufei Message: 5 Date: Wed, 21 Mar 2012 20:28:33 +0200 From: Uri Shacked <ushacked(a)gmail.com> Subject: Re: [SR-Users] ACCDB insert issues To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List" <sr-users(a)lists.sip-router.org> Message-ID: <CAMMbDhTK2h4s1y_YJ_Tp8J7eZT4cmn_w1OkDBAS+3oAaZEZpAw(a)mail.gmail.com> Content-Type: text/plain; charset="windows-1252" Well, after some experiments... Two things made the difference: 1. Use only the id as Pkey and remove all other indexes (helped a little). 2. Set myisam engine to the table (i knew that but tried innodb for its reliability) Now we are back in order to deal with many, many CAPS. Thanks, If someone has another idea, and uses innodb for the ACC. please advise... BR, Uri On Tue, Mar 20, 2012 at 12:22 PM, Uri Shacked <ushacked(a)gmail.com> wrote: > > no log on the msqld for it. > > there is the CDR server that collects the events every 5 min and deletes > > old once... i disabled it becoase i believed it was it. but, no.... the > > error apears again... > > a BI specialist told me it must have something to do with the number of > > columns and the data type... > > > > On Tue, Mar 20, 2012 at 12:06 PM, Daniel-Constantin Mierla < > > miconda(a)gmail.com> wrote: > > >> >> Do you have error messages in mysql server logs? Is there another >> >> application that may block the acc table? >> >> >> >> The error refers to unavailability of the mysql server... >> >> >> >> Cheers, >> >> Daniel >> >> >> >> >> >> On 3/20/12 11:03 AM, Uri Shacked wrote: >> >> >> >> ERROR: db_mysql [km_dbase.c:122]: driver error on query: Lost >> >> connection to MySQL server during query >> >> Mar 18 20:03:38 net-ivr-KamIN-J1 /usr/local/sbin/kamailio[2671]: ERROR: >> >> <core> [db_query.c:186]: error while submitting query >> >> Mar 18 20:03:38 net-ivr-KamIN-J1 /usr/local/sbin/kamailio[2671]: ERROR: >> >> acc [acc.c:405]: failed to insert into database >> >> >> >> Whe apears, from time to time, for some of them. it can rest for 2-10 >> >> hours, then have a "glitch" of 160 sql driver errors, and rest again.... >> >> >> >> >> >> >> >> On Tue, Mar 20, 2012 at 11:51 AM, Daniel-Constantin Mierla < >> >> miconda(a)gmail.com> wrote: >> >> >>> >>> Hello, >>> >>> >>> >>> >>> >>> On 3/20/12 10:11 AM, Uri Shacked wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> >>> >>> >>> >>> I am using the ACCDB with extra data. I collect the data to AVP's and >>> >>> set it on the db_extra. It gets to be 37 columns?. Pretty long? >>> >>> The problem I experience is that after a while (2-3 hours) with about 15 >>> >>> CAPS the MySQL ACC insert error appears. >>> >>> And, I am loosing accounting data. >>> >>> >>> >>> what are the errors? Once they appear, is it for all records or just >>> >>> from time to time, to some of them? >>> >>> >>> >>> Cheers, >>> >>> Daniel >>> >>> >>> >>> >>> >>> >>> >>> Except of narrowing the amount of columns and setting the fields >>> >>> (INT,CHAR etc.), does anyone has any ideas? >>> >>> >>> >>> >>> >>> >>> >>> The db_insert_mode set to 1 does not work (my ACC table is INNODB >>> >>> because I don?t want to lose info). >>> >>> >>> >>> >>> >>> >>> >>> BR, >>> >>> >>> >>> Uri >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> >>> >>> >>> -- >>> >>> Daniel-Constantin Mierla >>> >>> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germanyhttp://www.asipto.com/index.php/kamailio-advanced-training/ >>> >>> >>> >>> >> >> >> >> -- >> >> Daniel-Constantin Mierla >> >> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germanyhttp://www.asipto.com/index.php/kamailio-advanced-training/ >> >> >> >> > >

1 0

need help for newbie in Kamailio
by Rabary 21 Mar '12

21 Mar '12

Hi mailing, Newbie to kamailio, I follow this tuto http://nil.uniza.sk/sip/kamailio/adding-mysql-support-kamailio-31-debian-le… for the registration SIP via mysql database and it works fine, but I saw that when during the call we disconnect the called UAC from network or turn the power off the caller UAC don't hangup. Is there any tool for how to hangup call when the UAC on the other side has no network connection or it isn't power on durring a call ? I heard for mediaroxy or rtpproxy but I don't know if them can do what I except to haveand we also use ip routing to make kamailio server to communicate with the UAC so we don't use NAT. Our topology is: kamailio (with public IP address) ---> cisco switch ---> LAN ---> UAC (with private IP address) Thanks in advance. -- Inutile d'imprimer ce mail

5 9

Kamailio NP module
by Ahmed 21 Mar '12

21 Mar '12

Hi, I try to run this module, but unsuccesfully. Can you give me some advices? How I can start the pdb_server? I compile and install it, but don´t know how get it run. I must add loadmodule="pdb.so" in kamailio.cfg file? When I did it, kamailio didnt start. Starting end with error. I think that there missing bracket : # query external service for routing information if (!pdb_query("$rU", "$avp(i:82)")) $avp(i:82) = 0; # default routing } cr_route("$avp(i:82)", "$rd", "$rU", "$rU", "call_id"); Thank you for your answer. Have a nice day.

2 1

Pdb module
by Ahmed 20 Mar '12

20 Mar '12

Hi, I try to run this module, but unsuccesfully. Can you give me some advices? How I can start the pdb_server? I compile and install it, but donÂ´t know how get it run. I must add loadmodule="pdb.so" in kamailio.cfg file? When I did it, kamailio didnt start. Starting end with error. I think that there missing bracket : # query external service for routing information if (!pdb_query("$rU", "$avp(i:82)")) $avp(i:82) = 0; # default routing } cr_route("$avp(i:82)", "$rd", "$rU", "$rU", "call_id"); Thank you for your answer. Have a nice day.

1 0

Request-URI in fail route
by Jan Klepal 20 Mar '12

20 Mar '12

Hello, I am trying to set simple no-answer forward scenario: Alice calls Bob and after timeout 5s forward to Carol (and additionally Carol timeout forward to Dave). I am using Kamailio 3.2.2 default config. There is part of routing logic for no-answer forwarding: route[RELAY] { if(is_method("INVITE")) { t_set_fr(5000); t_on_branch("BRANCH_ONE"); t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if(!t_relay()) { sl_reply_error(); } } branch_route[BRANCH_ONE] { $avp(divert) = $null; if($rU == "bob") { $avp(divert) = "carol"; } # second problem if($rU == "carol") { $avp(divert) = "dave"; } } failure_route[FAIL_ONE] { if($avp(divert) != $null) { add_diversion("no-answer"); $rU = $avp(divert); route(LOOKUP); route(RELAY); } } First problem I encountered is that I can't check $rU in failure_route (it is always set to original Request-URI - bob). Is this normal behavior or am I missing something? Because of that I have to set divert destination in branch route. Second problem is when Carol's no-answer forward to Dave happens. Then add_diversion adds invalid diversion header because it uses Request-URI which is still set to bob. Kind Regards, Jan

2 5

server overload mitigation
by Vineet Menon 20 Mar '12

20 Mar '12

Hi, does kamailio mitigate server overload???If yes how is that?? Is there a setting for high water mark or something?? Regards, Vineet Menon

2 1

FW: Unsuccessful call using DRouting - Request Timeout
by Fatima Chahrour~Vanrise Support 20 Mar '12

20 Mar '12

Dears, I started my lab on VMware (debian lenny) where I installed Kamailio 3.2 and started drouting configuration. I'm using 2 PCs each having an x-lite softphone and the Kamailio on the vmware all connected locally. My primary test is to make a call from x-lite on PC (192.168.111.11) to x-lite on PC (192.168.111.226) through Kamailio\ drouting modules (192.168.111.139). What is happening is that when I call 9611558800, for example, am getting 'Calling' message on PC x-lite followed by 'Call Failed: Request Timeout' after a certain time. Attached is my routing logic script, and ngrep for the call that is failing. And my dr_tables data is : dr_rules: 4, '0', '9611', '', 0, '', '#3', 'Lebanon Fix' dr_gw_lists: 3, '5', 'Test Call' dr_groups: 3, '.*', '.*', 0, 'Everyone' dr_gateways: 5, 1, '192.168.111.226', 0, '', '', 2, 'PC1' I tried adding port number to the gateways, remove '#' and add 5 in the dr_rules, remove the "0" from do_routing in the script, but with no success. Reading some related documents and books, I found that all scenarios using drouting have gateways as media servers (Asterisks) . So my question: is this a must, to have a media proxy even using my above primary enviroment? If not, can you please help me finding my mistake that prohibit the call's success(ringing)? Thanks in advance. F.Chahrour

3 5

Dispatcher and round-robin ignoring priorities?
by Øyvind Kolbu 20 Mar '12

20 Mar '12

Our PSTN provider has three servers. Two of them are located in our town, and we prefer them, and the last one much further away. We can use them interchangeably. >From our dispatcher file: # 10: PSTN 10 sip:preferred1.example.com:7476 0 5 10 sip:preferred2.example.com:7476 0 5 10 sip:third.example.com:7476 0 4 In our dispatch router we use 'ds_select_dst("10","4")'. Then the round-robin algorithm evenly distributes the load on all three of them, instead of round robin on the ones with priority 5 and fallbacking to priority 4. Is the unconditional round robin as excepted? When changing the selection algorithm to "8", «use first destination», the dispatcher module correctly uses first "preferred2", then "preferred1" and then lastly "third". Why «first destination» is not the first one listed in the dispatcher file has always puzzled me.. # kamailio -V version: kamailio 3.2.1 (i386/linux) 31c991 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 31c991 compiled on 08:08:06 Dec 6 2011 with gcc 4.1.2 -- Øyvind Kolbu

2 2

Users being registered without any Authentication
by Faisal Rehman 20 Mar '12

20 Mar '12

Hi, I have the below configuration file kamailio.cfg but all the users are not being registered with authentication, so am I doing some mistake in it? #!KAMAILIO # # Kamailio (OpenSER) SIP Server v3.2 - default configuration script # - web: http://www.kamailio.org # - git: http://sip-router.org # # Direct your questions about this file to: <sr-users(a)lists.sip-router.org> # # Refer to the Core CookBook at http://www.kamailio.org/dokuwiki/doku.php # for an explanation of possible statements, functions and parameters. # # Several features can be enabled using '#!define WITH_FEATURE' directives: # # *** To run in debug mode: # - define WITH_DEBUG # # *** To enable mysql: # - define WITH_MYSQL # # *** To enable authentication execute: # - enable mysql # - define WITH_AUTH # - add users using 'kamctl' # # *** To enable IP authentication execute: # - enable mysql # - enable authentication # - define WITH_IPAUTH # - add IP addresses with group id '1' to 'address' table # # *** To enable persistent user location execute: # - enable mysql # - define WITH_USRLOCDB # # *** To enable presence server execute: # - enable mysql # - define WITH_PRESENCE # # *** To enable nat traversal execute: # - define WITH_NAT # - install RTPProxy: http://www.rtpproxy.org # - start RTPProxy: # rtpproxy -l _your_public_ip_ -s udp:localhost:7722 # # *** To enable PSTN gateway routing execute: # - define WITH_PSTN # - set the value of pstn.gw_ip # - check route[PSTN] for regexp routing condition # # *** To enable database aliases lookup execute: # - enable mysql # - define WITH_ALIASDB # # *** To enable speed dial lookup execute: # - enable mysql # - define WITH_SPEEDDIAL # # *** To enable multi-domain support execute: # - enable mysql # - define WITH_MULTIDOMAIN # # *** To enable TLS support execute: # - adjust CFGDIR/tls.cfg as needed # - define WITH_TLS # # *** To enable XMLRPC support execute: # - define WITH_XMLRPC # - adjust route[XMLRPC] for access policy # # *** To enable anti-flood detection execute: # - adjust pike and htable=>ipban settings as needed (default is # block if more than 16 requests in 2 seconds and ban for 300 seconds) # - define WITH_ANTIFLOOD # # *** To block 3XX redirect replies execute: # - define WITH_BLOCK3XX # # *** To enable VoiceMail routing execute: # - define WITH_VOICEMAIL # - set the value of voicemail.srv_ip # - adjust the value of voicemail.srv_port # # *** To enhance accounting execute: # - enable mysql # - define WITH_ACCDB # - add following columns to database #!ifdef ACCDB_COMMENT ALTER TABLE acc ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN src_ip varchar(64) NOT NULL default ''; ALTER TABLE acc ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_ip varchar(64) NOT NULL default ''; ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; #!endif ####### Defined Values ######### # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define DBURL "mysql://faisal:faisal123@localhost/kamailio" #!endif #!ifdef WITH_MULTIDOMAIN # - the value for 'use_domain' parameters #!define MULTIDOMAIN 1 #!else #!define MULTIDOMAIN 0 #!endif # - flags # FLT_ - per transaction (message) flags #FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_NATS 5 #!define FLB_NATB 6 #!define FLB_NATSIPPING 7 ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ #auto_aliases=no /* add local domain aliases */ /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:192.162.15.23:5161 listen=tcp:129.162.15.23:5161 alias="xmpp.kamailio.org" /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5161 #!ifdef WITH_TLS enable_tls=yes #!endif # life time of TCP connection when there is no traffic # - a bit higher than registration expires to cope with UA behind NAT tcp_connection_lifetime=3605 ####### Custom Parameters ######### # These parameters can be modified runtime via RPC interface # - see the documentation of 'cfg_rpc' module. # # Format: group.id = value 'desc' description # Access: $sel(cfg_get.group.id) or @cfg_get.group.id # #!ifdef WITH_PSTN # PSTN GW Routing # # - pstn.gw_ip: valid IP or hostname as string value, example: # pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" # # - by default is empty to avoid misrouting pstn.gw_ip = "" desc "PSTN GW Address" #!endif #!ifdef WITH_VOICEMAIL # VoiceMail Routing on offline, busy or no answer # # - by default Voicemail server IP is empty to avoid misrouting voicemail.srv_ip = "" desc "VoiceMail IP Address" voicemail.srv_port = "5060" desc "VoiceMail Port" #!endif ####### Modules Section ######## # set paths to location of modules (to sources or installation folders) #!ifdef WITH_SRCPATH mpath="modules_k:modules" #!else mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "xmpp.so" #!ifdef WITH_AUTH loadmodule "auth.so" loadmodule "auth_db.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!endif #!ifdef WITH_ALIASDB loadmodule "alias_db.so" #!endif #!ifdef WITH_SPEEDDIAL loadmodule "speeddial.so" #!endif #!ifdef WITH_MULTIDOMAIN loadmodule "domain.so" #!endif #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_NAT loadmodule "nathelper.so" loadmodule "rtpproxy.so" #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_ANTIFLOOD loadmodule "htable.so" loadmodule "pike.so" #!endif #!ifdef WITH_XMLRPC loadmodule "xmlrpc.so" #!endif #!ifdef WITH_DEBUG loadmodule "debugger.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) #--------XMPP Module Params--------------- modparam("xmpp", "domain_separator", "%") modparam("xmpp", "xmpp_domain", "192.168.15.23") modparam("xmpp", "xmpp_host", "192.168.15.23") modparam("xmpp", "gateway_domain", "192.168.15.23") modparam("xmpp", "backend", "server") modparam("xmpp", "xmpp_port", 5299) modparam("xmpp", "xmpp_password", "casilla233") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- registrar params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # max value for expires of registrations modparam("registrar", "max_expires", 3600) # ----- acc params ----- /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) /* enhanced DB accounting */ #!ifdef WITH_ACCDB modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) modparam("acc", "db_url", DBURL) modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") #!endif # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN) # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", DBURL) modparam("permissions", "db_mode", 1) #!endif #!endif # ----- alias_db params ----- #!ifdef WITH_ALIASDB modparam("alias_db", "db_url", DBURL) modparam("alias_db", "use_domain", MULTIDOMAIN) #!endif # ----- speedial params ----- #!ifdef WITH_SPEEDDIAL modparam("speeddial", "db_url", DBURL) modparam("speeddial", "use_domain", MULTIDOMAIN) #!endif # ----- domain params ----- #!ifdef WITH_MULTIDOMAIN modparam("domain", "db_url", DBURL) # use caching modparam("domain", "db_mode", 1) # register callback to match myself condition with domains list modparam("domain", "register_myself", 1) #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) #!endif #!ifdef WITH_NAT # ----- rtpproxy params ----- modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") # params needed for NAT traversal in other modules modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/usr/local/etc/kamailio/tls.cfg") #!endif #!ifdef WITH_ANTIFLOOD # ----- pike params ----- modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 16) modparam("pike", "remove_latency", 4) # ----- htable params ----- # ip ban htable with autoexpire after 5 minutes modparam("htable", "htable", "ipban=>size=8;autoexpire=300;") #!endif #!ifdef WITH_XMLRPC # ----- xmlrpc params ----- modparam("xmlrpc", "route", "XMLRPC"); modparam("xmlrpc", "url_match", "^/RPC") #!endif #!ifdef WITH_DEBUG # ----- debugger params ----- modparam("debugger", "cfgtrace", 1) #!endif ####### Routing Logic ######## # Main SIP request routing logic # - processing of any incoming SIP request starts with this route # - note: this is the same as route { ... } request_route { # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); #authentication route(AUTH); ###############-----------------------------------XMPP Server Configuration----------------------------------------################# if (uri =~ "sip:.+@sip-xmpp\.kamailio\.org") { #absorb transmission if (!t_newtran()){ sl_reply_error(); exit; } #Handling Instant Messaging if (is_method("MESSAGE")){ xlog("message to XMPP: from <$fu> ru>\n"); if (xmpp_send_message()){ sl_send_reply("202", "Accepted"); } else { sl_send_reply("404", "Not found"); } exit; } #Un-supported Type of SIP Message xlog("message to XMPP: method [$rm] not supported yet\n"); sl_send_reply("503", "Service unavailable"); exit; } ##################--------------------------------XMPP Server Configuration-----------------------------------------------############### # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } # dispatch requests to foreign domains route(SIPOUT); ### requests for my local domains # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations to PSTN route(PSTN); # user location service route(LOCATION); route(RELAY); } route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|SUBSCRIBE")) { t_on_branch("MANAGE_BRANCH"); t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { #!ifdef WITH_ANTIFLOOD # flood dection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if(src_ip!=myself) { if($sht(ipban=>$si)!=$null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } if ( is_method("ACK") ) { # ACK is forwarded statelessy route(NATMANAGE); } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } } # Handle SIP registrations route[REGISTRAR] { if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } if (!save("location")) sl_reply_error(); exit; } } # USER location service route[LOCATION] { #!ifdef WITH_SPEEDIAL # search for short dialing - 2-digit extension if($rU=~"^[0-9][0-9]$") if(sd_lookup("speed_dial")) route(SIPOUT); #!endif #!ifdef WITH_ALIASDB # search in DB-based aliases if(alias_db_lookup("dbaliases")) route(SIPOUT); #!endif $avp(oexten) = $rU; if (!lookup("location")) { $var(rc) = $rc; route(TOVOICEMAIL); t_newtran(); switch ($var(rc)) { case -1: case -3: send_reply("404", "Not Found"); exit; case -2: send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } # Authentication route route[AUTH] { #!ifdef WITH_AUTH if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("$td", "subscriber")) { www_challenge("$td", "0"); exit; } if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { #!ifdef WITH_IPAUTH if(allow_source_address()) { # source IP allowed return; } #!endif # authenticate if from local subscriber if (from_uri==myself) { if (!proxy_authorize("$fd", "subscriber")) { proxy_challenge("$fd", "0"); exit; } if (is_method("PUBLISH")) { if ($au!=$fU || $au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } if ($au!=$rU) { sl_send_reply("403","Forbidden R-URI"); exit; } #!ifdef WITH_MULTIDOMAIN if ($fd!=$rd) { sl_send_reply("403","Forbidden R-URI domain"); exit; } #!endif } else { if ($au!=$fU) { sl_send_reply("403","Forbidden auth ID"); exit; } } consume_credentials(); # caller authenticated } else { # caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (!uri==myself) { sl_send_reply("403","Not relaying"); exit; } } } #!endif return; } # Caller NAT detection route route[NATDETECT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { fix_nated_contact(); } setflag(FLT_NATS); } #!endif return; } # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpproxy_manage(); if (is_request()) { if (!has_totag()) { add_rr_param(";nat=yes"); } } if (is_reply()) { if(isbflagset(FLB_NATB)) { fix_nated_contact(); } } #!endif return; } # Routing to foreign domains route[SIPOUT] { if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(RELAY); } } # PSTN GW routing route[PSTN] { #!ifdef WITH_PSTN # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN rotuing enabled but pstn.gw_ip not defined\n"); return; } # route to PSTN dialed numbers starting with '+' or '00' # (international format) # - update the condition to match your dialing rules for PSTN routing if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); route(RELAY); exit; #!endif return; } # XMLRPC routing #!ifdef WITH_XMLRPC route[XMLRPC] { # allow XMLRPC from localhost if ((method=="POST" || method=="GET") && (src_ip==127.0.0.1)) { # close connection only for xmlrpclib user agents (there is a bug in # xmlrpclib: it waits for EOF before interpreting the response). if ($hdr(User-Agent) =~ "xmlrpclib") set_reply_close(); set_reply_no_connect(); dispatch_rpc(); exit; } send_reply("403", "Forbidden"); exit; } #!endif # route to voicemail server route[TOVOICEMAIL] { #!ifdef WITH_VOICEMAIL if(!is_method("INVITE")) return; # check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail rotuing enabled but IP not defined\n"); return; } if($avp(oexten)==$null) return; $ru = "sip:" + $avp(oexten) + "@" + $sel(cfg_get.voicemail.srv_ip) + $sel(cfg_get.voicemail.srv_port); route(RELAY); exit; #!endif return; } # manage outgoing branches branch_route[MANAGE_BRANCH] { xdbg("new branch [$T_branch_idx] to $ru\n"); route(NATMANAGE); } # manage incoming replies onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=~"[12][0-9][0-9]") route(NATMANAGE); } # manage failure routing cases failure_route[MANAGE_FAILURE] { route(NATMANAGE); if (t_is_canceled()) { exit; } #!ifdef WITH_BLOCK3XX # block call redirect based on 3xx replies. if (t_check_status("3[0-9][0-9]")) { t_reply("404","Not found"); exit; } #!endif #!ifdef WITH_VOICEMAIL # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(TOVOICEMAIL); exit; } #!endif } Regards, Faisal

3 5

Presence question
by David 19 Mar '12

19 Mar '12

Hello, I am running a presence server. I am searching for a problem with my presence, and I have traced it down to this query : delete from active_watchers where presentity_uri='sip:test109@domain.tld' AND event='dialog' AND to_tag='f0253efb8005057b3cc0ab8fa35ff1d9-c961' This query is being sent to the database a few seconds after the initial subscribe is received. So the subscription only lasts in the database for a few seconds. I tried running level 3 error reporting ( hundreds of DEBUG ). I did not see any justification for query. Where is this query coming from ( source code/ config file )? Why is this subscription being deleted almost immediatly after it is setup ? Thanks, David Here is a sample request ( not the same as the one above, I did not capture the SIP at the same time as the SQL ) : U PROXYIP:5060 -> PRESENCEIP:5060 SUBSCRIBE sip:test109@domain.tld SIP/2.0. Record-Route: <sip:PROXYIP;lr=on;ftag=db911ce615f1598c>. Record-Route: <sip:TCPPROXYIP;r2=on;lr=on>. Record-Route: <sip:TCPPROXYIP;transport=tcp;r2=on;lr=on>. Via: SIP/2.0/UDP PROXYIP;branch=z9hG4bK9543.f0668033.0. Via: SIP/2.0/UDP TCPPROXYIP;branch=z9hG4bK9543.d2e18073.0;i=0a3. Via: SIP/2.0/TCP USERIP:61334;branch=z9hG4bK-6ee64c28;rport=61334. To: sip:test109@domain.tld. From: "103 Zone T" <sip:test103@domain.tld>;tag=db911ce615f1598c. Call-ID: 3f55db6e-b2ec6ca4(a)192.168.219.109. CSeq: 53944 SUBSCRIBE. Max-Forwards: 68. Contact: "103 Zone T" <sip:test103@USERIP:8280;transport=tcp>. Accept: application/dialog-info+xml. Expires: 1800. Event: dialog. User-Agent: Cisco/SPA504G-7.4.9c. Content-Length: 0. . # U PRESENCEIP:5060 -> PROXYIP:5060 SIP/2.0 202 OK. Record-Route: <sip:PROXYIP;lr=on;ftag=db911ce615f1598c>. Record-Route: <sip:TCPPROXYIP;r2=on;lr=on>. Record-Route: <sip:TCPPROXYIP;transport=tcp;r2=on;lr=on>. Via: SIP/2.0/UDP PROXYIP;branch=z9hG4bK9543.f0668033.0. Via: SIP/2.0/UDP TCPPROXYIP;branch=z9hG4bK9543.d2e18073.0;i=0a3. Via: SIP/2.0/TCP USERIP:61334;branch=z9hG4bK-6ee64c28;rport=61334. To: sip:test109@domain.tld;tag=f0253efb8005057b3cc0ab8fa35ff1d9-8c10. From: "103 Zone T" <sip:test103@domain.tld>;tag=db911ce615f1598c. Call-ID: 3f55db6e-b2ec6ca4(a)192.168.219.109. CSeq: 53944 SUBSCRIBE. Expires: 1800. Contact: <sip:PRESENCEIP:5060>. Server: kamailio (3.1.5 (x86_64/linux)). Content-Length: 0.

2 1

Re: [SR-Users] XMPP module not passing subscribes coming from xmpp side
by Dan-Cristian Bogos 19 Mar '12

19 Mar '12

Hi Pavel, Many thanks for your reaction. Good to know about the issues, saved me some important time with troubleshooting. Will try to find alternatives in this case since I already found some other limitations which stop me in having an enterprise solution. Have a good one! DanB > > Hi Dan, > > student of mine (Martin) realized that, but it was using Jabberd2 not > opernfire XMPP server, because the Openfire did not register domain from the > XMPP component correctly and did some other strange things. > Here are parts of Martin communication > > http://comments.gmane.org/gmane.comp.voip.openser.user/31713 > > > palo73 > >> -----Original Message----- >> From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users- >> bounces(a)lists.sip-router.org] On Behalf Of Dan-Cristian Bogos >> Sent: Friday, March 02, 2012 11:22 AM >> To: sr-users(a)lists.sip-router.org >> Subject: [SR-Users] XMPP module not passing subscribes coming from xmpp >> side >> >> Hey Guys, >> >> I was wondering if anyone having experience with using xmpp module as >> presence gateway between SIP and XMPP. I started evaluating it and till >> now got some weird results, not sure if it is just my setup which does >> not match the one widely used or the module is incomplete. >> >> Regarding my setup, I use OpenFIRE 3.7.1 on one side and Kamailio 3.2.0 >> out of debian packages on the other. >> >> The issue I got right now is that the subscribe coming from XMPP side >> produces no action/reply on SIP side. Bellow you can see the packet >> coming from OpenFIRE: >> # >> T 2012/03/02 09:49:57.743750 127.0.0.1:5275 -> 127.0.0.1:49965 [AP] >> <presence id="4h8F6-19" to="dan4(a)gw.mydomain.com" type="subscribe" >> from="dan(a)mydomain.com"><c xmlns="http://jabber.org/protocol/caps" >> ext="voice-v1 video-v1 camera-v1 " hash="sha-1" >> node="http://jitsi.org" >> ver="ohjz8WKq0ZQRiNWRNcapX4BBHLk="/></presence> >> """ >> >> Anyone here got this working somehow? >> >> Ta, >> DanB >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi- >> bin/mailman/listinfo/sr-users > > > > > ------------------------------ > > Message: 5 > Date: Fri, 2 Mar 2012 11:44:12 +0100 > From: Reda Aouad <reda.aouad(a)gmail.com> > Subject: [SR-Users] Registration Limits > To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users(a)lists.sip-router.org> > Message-ID: > <CAA30pc7pkPcBSfMSdRpvCSHNm0kiSw9r13huUe4jikiEPdcr1Q(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > Is there a way to ensure single-registration per user-agent for a user, > which overwrites previous registration ? > Or is there a way to limit the number of registrations per user, but > overwriting the earliest registration for each new one ? > > Thanks, > Reda >

3 4

Unsuccessful call using DRouting - Request Timeout
by Fatima Chahrour~Vanrise Support 19 Mar '12

19 Mar '12

Dears, I started my lab on VMware (debian lenny) where I installed Kamailio 3.2 and started drouting configuration. I'm using 2 PCs each having an x-lite softphone and the Kamailio on the vmware all connected locally. My primary test is to make a call from x-lite on PC (192.168.111.11) to x-lite on PC (192.168.111.226) through Kamailio\ drouting modules (192.168.111.139). What is happening is that when I call 9611558800, for example, am getting 'Calling' message on PC x-lite followed by 'Call Failed: Request Timeout' after a certain time. Attached is my routing logic script, and ngrep for the call that is failing. And my dr_tables data is : dr_rules: 4, '0', '9611', '', 0, '', '#3', 'Lebanon Fix' dr_gw_lists: 3, '5', 'Test Call' dr_groups: 3, '.*', '.*', 0, 'Everyone' dr_gateways: 5, 1, '192.168.111.226', 0, '', '', 2, 'PC1' I tried adding port number to the gateways, remove '#' and add 5 in the dr_rules, remove the "0" from do_routing in the script, but with no success. Reading some related documents and books, I found that all scenarios using drouting have gateways as media servers (Asterisks) . So my question: is this a must, to have a media proxy even using my above primary enviroment? If not, can you please help me finding my mistake that prohibit the call's success(ringing)? Thanks in advance. F.Chahrour

1 0

message offline store questions...
by Krishna Kurapati 19 Mar '12

19 Mar '12

Hi, I am using msilo module to store offline message. I am sending back "202 pending" when the message is stored (m_store) However, when I message delivered (m_dump), how do I inform the sender that the message is successfully delivered? Also, how do I handle if the sender if offline when I try to inform about the delivery of the message. I think I need offline notify store to handle this condition. Instead of removing the message from the silo table upon receipt of 200 OK from the receiver, I am thinking keep the message there until the NOTIFY is successfully delivered to the sender. In effect, the silo table in the database function as offline message and notify store. I reviewed module_k/msilo source code, and the functionality that I need seems missing. I am thinking of two approaches. 1) Extend the msilo module to implement the feature, if more people need it, then I can submit the changes. 2) Write sqlops + lua script to address the missing function. In either case, I am thinking of storing the callid of the original message (possibly in silo table?) in the database and sending the NOTIFY with the callid to the sender. I would like to extend the silo table with two columns: 1. the callid of the message 2. flags to indicate status of the delivery of the message. Appreciate your comments, suggestions and alternatives. Thanks Krish Kura

2 2

Re: [SR-Users] DRouting cause Kamailio 3.2 to stop
by Fatima Chahrour~Vanrise Support 19 Mar '12

19 Mar '12

Dear Daniel, Thanks for your reply.. I'd like to ask you too if my script in my first post that am using in the routing area is correct? I found file named core in the '/' location as you mentioned. When I open it using #cat core, the opened file go crazy and writes strange characters and it ending with the below: /usr/local/sbin/kamailio-P/var/run/kamailio.pid-f/usr/local/etc/kamailio//ka mailio.cfgSSH_AGENT_PID=3234GPG_AGENT_INFO=/tmp/seahorse-jKaZEU/S.gpg-agent: 3246:1TERM=xtermDESKTOP_STARTUP_ID=SHELL=/bin/bashGTK_RC_FILES=/etc/gtk/gtkr c:/home/vanrise/.gtkrc-1.2-gnome2WINDOWID=33580848USER=rootGNOME_KEYRING_SOC KET=/tmp/keyring-ZKxFck/socketSSH_AUTH_SOCK=/tmp/keyring-ZKxFck/sshUSERNAME= vanriseSESSION_MANAGER=local/debian:/tmp/.ICE-unix/3188MAIL=/var/mail/rootPA TH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/DESKTOP_SES SION=defaultGDM_XSERVER_LOCATION=localPWD=/usr/local/etc/kamailioLANG=en_US. UTF-8GDM_LANG=en_US.UTF-8GDMSESSION=defaultSHLVL=4HOME=/rootGNOME_DESKTOP_SE SSION_ID=DefaultLOGNAME=rootDBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus -sH8atcWdX4,guid=f0dcba443f8fd1d5267161364f4dd99dXDG_DATA_DIRS=/usr/local/sh are/:/usr/share/:/usrdebian:/# 62;9;c62;9 Sorry, I've just realized an info that I should mention and would be helpful, am running this Kamailio on a debian Lenny VMware as a trial before migrating it to its server. Thank you, F.Chahrour From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Thursday, March 01, 2012 10:15 AM To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List Cc: Fatima Chahrour~Vanrise Support; sr-users-bounces(a)lists.sip-router.org Subject: Re: [SR-Users] DRouting cause Kamailio 3.2 to stop Hello, have you found the core file in /var/log/? It is a strange location unless you started with -w /var/log. The core file is named usually 'core' or core.pid (replace pid with same number, like, 'core.1234'). The default location in in '/' unless there is a different location set via -w or enforced by operating system (e.g., mac os x puts it in '/corefiles'). Hope it helps to locate the core file and send the backtrace. Cheers, Daniel On 3/1/12 9:05 AM, Fatima Chahrour~Vanrise Support wrote: I also tried : #gdb /usr/local/sbin/kamailio /var/log/core.file (gdb) bt And got No Stack.. BR, F.Chahrour

2 9

ser_mysql.sh
by Marwan Idriss 19 Mar '12

19 Mar '12

Greeting, I need the ser_mysql.sh for the ser version ser 2.0.0-4ubuntu2 Regards Marwan

1 0

Best approach for TCP/TLS connection re-use for nated Contacts
by Giacomo Vacca 19 Mar '12

19 Mar '12

Hi all, I have a scenario where it's not clear to me what the best approach should be (Kamailio 3.2.0 on Squeeze, although I think it's a matter of routing logic only). I have a client behind NAT that sends an initial REGISTER request with a Contact containing private ip:port (e.g. Contact: "GV" <sip:12345@192.168.1.2:54321;transport=tcp> ) However, after it's challenged for authentication with a 401, it sends the following REGISTER request with Authorization header and with a Contact containing ip:port equal to the 'received' SIP URI (with a combination of 'rport' and 'received' parameters (e.g. Contact: "GV" <sip:12345@[receivedIP]:[rport];transport=tcp> ) In this case kamailio's routing logic is not marking the REGISTER as natted (no Received field in location and no NAT flags set). You can imagine I have a fairly standard NAT handling: route[NATDETECT] { force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { fix_nated_contact(); } setflag(FLT_NATS); } return; } FLT_NATS won't be set, and so it won't FLB_NATB in the following processing. This client receives a call: Kamailio relays the INVITE to it using the stored Contact. The INVITE is correctly received by the client, because the stored Contact refers to the connected socket ([received]:rport). The trouble starts when then the client replies with a 200 OK containing the private ip:port in the Contact header field (again 192.168.1.2:54321). The ACK will then have that private ip:port in the R-URI, and its relaying will fail. One of the solutions I've found is using always add_contact_alias() in onreply_route when handling the 200 OK, and then use handle_ruri_alias() when defining the destination for the ACK. I know that without traces and the full .cfg this is quite a broad question, but I wonder if you have already had to deal with this kind of client behaviour and can provide advice on the best practices. This is in particular useful for the re-use of TCP-based connections. Thanks in advance, Giacomo Truphone Limited is a limited liability company registered in England & Wales, registered office: 4 Royal Mint Court, London, EC3N 4HJ. Registered No. 04187081. VAT No. GB 851 5278 19. Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a trading name for a number of distinct legal entities that operate in combination. www.truphone.com<http://www.truphone.com>. This e-mail, and any attachment(s), may contain information which is confidential and/or privileged, and is intended for the addressee only. If you are not the intended recipient, you may not use, disclose, copy or distribute this information in any manner whatsoever. If you have received this e-mail in error, please contact the sender immediately and delete it.

3 3

register_udomain(): Invalid table version (use ser_mysql.sh reinstall)
by Ryan Gholam 19 Mar '12

19 Mar '12

Hello , I hope someone encountered this problem on UBUNTU , when connecting to the database i get this error in my log file :var/log/sys Mar 19 14:09:46 rayan-desktop /usr/sbin/ser[21807]: register_udomain(): Invalid table version (use ser_mysql.sh reinstall) Mar 19 14:09:46 rayan-desktop /usr/sbin/ser[21807]: domain_fixup(): Error while registering domain Any help is appreciated . Thank you .

1 0

add_contact_alias and handle_ruri_alias vs fix_nated_contact
by yufei.tao 19 Mar '12

19 Mar '12

Hi I have been using fix_nated_register/fix_nated_contact for NAT traversal and all worked fine. I've come across add_contact_alias and handle_ruri_alias: http://sip-router.org/wiki/tutorials/alias-example where it says: "The benefits of using add_contact_alias() and handle_ruri_alias() functions instead of conventional NAT traversal solutions are: * Request-URI in requests to UAs behind NATs is always what UAs expect * Re-use of tcp/tls sessions between proxy and UAs " I assumed the 'conventional NAT traversal solution' here means fix_nated_contact? I understand the first point, in that the R-URI always contains what the client puts in the contact hf. But for the second point, about tcp/tls reuse, does fix_nated_contact do the same trick, or does add_contact_alias and handle_ruri_alias give you more benefit over fix_nated_contact? So far I feel they achieve the same thing but would like this confirmed/corrected. Thank you very much! Yufei

4 3

Re: [SR-Users] dns lookup and store IP in avp..
by MingHon 19 Mar '12

19 Mar '12

On Mon, Mar 19, 2012 at 4:56 PM, MingHon <gminghon(a)gmail.com> wrote: > Thanks Daniel... :) > > > On Mon, Mar 19, 2012 at 4:18 PM, Daniel-Constantin Mierla < > miconda(a)gmail.com> wrote: > >> Hello, >> >> >> On 3/19/12 8:22 AM, Klaus Darilion wrote: >> >>> No. If you really need it, then you can use exec() and a tool like "dig" >>> or "host". >>> >> apart of exec module functions, another option would be using an embedded >> language script (Lua/Perl...). >> >> Cheers, >> Daniel >> >>> >>> regards >>> Klaus >>> >>> On 19.03.2012 03:19, MingHon wrote: >>> >>>> Hi All, >>>> >>>> is this function available?? >>>> >>>> http://sourceforge.net/**tracker/?func=detail&aid=** >>>> 2687695&group_id=139143&atid=**743023<http://sourceforge.net/tracker/?func=detail&aid=2687695&group_id=139143&ati…> >>>> <http://sourceforge.net/**tracker/?func=detail&aid=** >>>> 2687695&group_id=139143&atid=**743023<http://sourceforge.net/tracker/?func=detail&aid=2687695&group_id=139143&ati…>> >>>> >>>> >>>> Thanks :) >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> MingHon >>>> >>> >>> ______________________________**_________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> >>> >> >> -- >> Daniel-Constantin Mierla >> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany >> http://www.asipto.com/index.**php/kamailio-advanced-**training/<http://www.asipto.com/index.php/kamailio-advanced-training/> >> >> > > > -- > Regards, > > MingHon > -- Regards, MingHon

1 1

Memory Question
by Klaus Darilion 19 Mar '12

19 Mar '12

Hi! Started kamailio with "-m 100 -M 30". Thus I would suspect that every process needs 30MB, and one of the processes needs 30+100Mb as it allocates the shared memory. The further would conclude that the memory will be allocated only once during startup. Can this be somehow verified? Normal "ps" output shows that every process needs ~130MB virtual memory, but this is probably not what I am looking for. Thanks Klaus # ps aux PID %CPU %MEM VSZ RSS TTY STAT COMMAND 846 0.2 0.8 139732 4112 ? S kamailio -m 100 -M 30 847 0.0 0.2 139732 1188 ? S kamailio -m 100 -M 30 848 0.0 0.2 139732 1184 ? S kamailio -m 100 -M 30 849 0.0 0.2 139732 1184 ? S kamailio -m 100 -M 30 850 0.0 0.2 139732 1184 ? S kamailio -m 100 -M 30 851 0.0 0.2 139732 1220 ? S kamailio -m 100 -M 30 852 0.0 0.2 139732 1208 ? S kamailio -m 100 -M 30 853 0.0 0.2 139736 1032 ? S kamailio -m 100 -M 30 854 0.0 0.2 139732 1176 ? S kamailio -m 100 -M 30 855 0.0 0.2 139732 1392 ? S kamailio -m 100 -M 30 856 0.0 0.2 139732 1392 ? S kamailio -m 100 -M 30 857 0.0 0.2 139732 1392 ? S kamailio -m 100 -M 30 858 0.0 0.2 139732 1392 ? S kamailio -m 100 -M 30 859 0.0 0.2 139732 1396 ? S kamailio -m 100 -M 30

2 1

Settings
by Robert Schleusener 19 Mar '12

19 Mar '12

Hello, on the iptel.org website I created an account. Also my own domain is registered and all works fine. I prefer numbers in the SIP-ID. With my own domain, I thought, I can use every number. But that is not true. Every number must start with the digit 8, for example 8555(a)mydomain.de. What is the reason for that? Have I the possibility to change that setting? I can also create aliases, for example 4123(a)mydomain.de and that works fine. But the telephonee sees still the number 8555 from the account name. Any ideas? Best regards, Robert

2 1

dns lookup and store IP in avp..
by MingHon 19 Mar '12

19 Mar '12

Hi All, is this function available?? http://sourceforge.net/tracker/?func=detail&aid=2687695&group_id=139143&ati… Thanks :) -- Regards, MingHon

3 2

Hi Daniel.
by Andres Collazos 17 Mar '12

17 Mar '12

thanks for all the support for all this years. Can you please help me to know if there is any way to route sip calls based on transport protocol, for example a call incoming on tcp i will assign a route and if a call comes in udp i will assign a different route. my scenario is calls coming from different devices registering to kamailio and then kamailio send those calls to asterisk. unfortunately i have to create a different peer set for each device. for this scenario i have two types of UAs and they need completely different configuration on the asterisk switch. i am planing on segregate the traffic and build a media server for each type of device means 2 asterisk, teh only way that i can identify those incoming registrations is by the use of the port one client connects trough udp the other trough tcp. I appreciated any input in this matter. and again thank a lot to all for the great support. Andres Collazos.

2 1

Presence in Kamailio
by Faisal Rehman 16 Mar '12

16 Mar '12

Hi, I am building Kamailio as a Stand-alone XMPP server so that XMPP clients can IM each other; but I also want the below functionality: The XMPP clients should all be able to see each others presence So do I need to look out the Kamailio presence module and will it fulfill my above requirement. Regards, Faisal Rehman

3 3

Again problems with ACK and Bye
by Stoyan Mihaylov 16 Mar '12

16 Mar '12

In wireshark, there are 2 fields - Source and Destination. I am curious if there are variables in Kamailio which can show me those values. System: MYIP - IP of kamailio sip.mydomain.com - address of kamailio User (Imsdroid for Android) ->Kamailio->Asterisk->Kamailio (same) ->Other user. Problem - register, voice, video, and ring are OK, but ACK and BYE are going in dead loop - and this happens may be around in 50% of cases - not in all cases. If I am using other client (like hardware SIP phones), then I have no problems, but it is really hard to find some client for Android which supports video with Kamailio. To solve problem, I made one function in Kamailio.cfg - ACKBYE, which is called only within dialog. And within dialog is called in main route. route[ACKBYE] { #!ifdef WITH_MYFORWARD xlog("SCRIPT: AckBye $td;$si;$du;$dd\n"); if((($td=="sip.mydomain.com")||($td=="MYIP"))&&($si=="MYIP")){ $du=$sht(forw=>$ft); xlog("SCRIPT: AckBye2 $td;$si;$du\n"); return; } #!endif return; } Of cource I have if(is_method("INVITE")){ ds_select_dst("1","4"); $sht(forw=>$ft)=$du; } This worked for long time. But then we updated client (libraries etc), and problem appeared again - from time to time. Calls between 2 same clients can pass 2 or 5 times, and then problem appear. Before - $td and $si showed destination and source but now there is difference: ERROR: <script>: SCRIPT: AckBye 192.168.2.251;MYIP;<null>;<null> $td in this case show destination, which is correct, but in wireshark, destination and source = MYIP. ACK sip:MYIP;lr=on;nat=yes SIP/2.0 Via: SIP/2.0/UDP MYIP;branch=z9hG4bKcydzigwkX Via: SIP/2.0/UDP MYIP;rport=5060;branch=z9hG4bKcydzigwkX ............................................ Via: SIP/2.0/UDP MYIP;rport=5060;branch=z9hG4bKcydzigwkX Via: SIP/2.0/UDP 192.168.2.105:44794;branch=z9hG4bK338581244;rport=44794 From: <sip:11171@sip.MYDOMAIN.com>;tag=1687441663 To: <sip:11175@192.168.2.251>;tag=as13c57096 Contact: <sip:11171@MYIP :5060;transport=udp>;+g.oma.sip-im;language="en,fr";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" Call-ID: 4026cd88-aab9-19db-dfbe-1510baafdbb3 CSeq: 473985105 ACK Content-Length: 0 Max-Forwards: 0 Proxy-Authorization: Digest username="11171",realm="sip.stribogkonsult.com ",nonce="T2NZUU9jWCWxMUHSQweHXVQppHS8iFhd",uri="sip:11175@MYIP :5060",response="c5a95942af1502c208fa05d34c405907",algorithm=MD5 Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, UPDATE, REFER Privacy: none P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000 User-Agent: IM-client/OMA1.0 android-ngn-stack/v2.0.453 (doubango r653)

2 1

Re: [SR-Users] define-check for dlg_var doesn't work
by Daniel-Constantin Mierla 16 Mar '12

16 Mar '12

On 3/16/12 10:25 AM, Sven Knoblich wrote: > Thanks Daniel, > this solves the problem. I will fix it for master and cherry pick it > for 3.2 as well. ok -- keeping the list cc-ed will allow people reading the thread on users to see the final results. Cheers, Daniel > > Bye Sven > > > Am 15.03.2012 23:16, schrieb Daniel-Constantin Mierla: >> Hello, >> >> from the code, I see that if the value does not exists, the get-function >> for dlg_var is just returning 0. Probably it should return PV null >> value. >> >> Try again after changing return 0 in return pv_get_null(...) inside >> function pv_get_dlg_variable(...) from dlg_var.c >> >> If works, you can commit the fix. >> >> Cheers, >> Daniel >> >> On 3/15/12 4:53 PM, Sven Knoblich wrote: >>> sip-router:master >>> >>> Hi all, >>> i want to use the define-check also for dlg_var. But after testing a >>> bit it seems to me, that define does not work with dlg_var's. I am >>> always getting a true. Did i miss something? >>> >>> # $dlg_var(test) is not defined >>> >>> if( defined $dlg_var(test)) >>> { >>> xlog("L_Notice","dlg_var $dlg_var(test) is defined\n"); >>> } >>> >>> I hope anybody can help me to clarify this. >>> >>> Thanks in advance, >>> Sven >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

2 2

define-check for dlg_var doesn't work
by Sven Knoblich 16 Mar '12

16 Mar '12

sip-router:master Hi all, i want to use the define-check also for dlg_var. But after testing a bit it seems to me, that define does not work with dlg_var's. I am always getting a true. Did i miss something? # $dlg_var(test) is not defined if( defined $dlg_var(test)) { xlog("L_Notice","dlg_var $dlg_var(test) is defined\n"); } I hope anybody can help me to clarify this. Thanks in advance, Sven

2 3

ser.cofig
by Marwan Idriss 16 Mar '12

16 Mar '12

Greeting, I want to do the following : if (method=="REGISTER") { then save the message received in the ser database } Regards Marwan

2 1

Needed Modules Functions
by Marwan Idriss 16 Mar '12

16 Mar '12

Greeting, I need a detailed modules explanation and their function Regards Marwan

2 1

[nube] Simple TCP/TLS proxy?
by Matthew Roderick 15 Mar '12

15 Mar '12

Hi All, I've been googling for a little while now and although I found others asking the question and answers says "yes it's possible" I haven't managed to find out *how* to do it! I have a relatively simple scenario where I'd like to use Kamailio (or something else?) to take TCP or UDP connections from my Linksys PAP2T ATA and proxy them to my sip provide which only allows TLS connections (obviously the Linksys doesn't support TLS). The kicker is that, although I understand the theory and principles of SIP, I'm completely new to SIP software and how to configure it, etc. If anyone can point me to a (good and recent) beginners guide to Kamailio installation and configuration that would also help ;-) Many thanks Matt PS. Installation status is I have Kamailio installed on Ubuntu with TLS configured (define WITH_TLS & module installed), started and listening! I've but not yet enabled mysql (not sure if it's needed for what I want to do!)

2 1

collecting statistics
by Klaus Darilion 15 Mar '12

15 Mar '12

Hi! I want to collect statistics on a load-balancer, e.g. how many NOTIFYs, SUBSCRIBEs, ... and the respective response codes, e.g. NOTIFYs-200, NOTIFYs-408,...., response time from the backend-servers, ... Further I want to do this separately for each backend-server in the cluster, i.e. for every IP address in the dispatcher list. Built in statistics or not detailed enough, so thought of implementing the counting and measuring in script using htable and a periodic timer which dumps the htable values to log file. Thus, I will end up with lots of code, especially for dumping I have to address all possible keys manually: e.g. request route: $var(key) = $rm + "::" + $dd; $sht(stat=>$var(key)) = $sht(stat=>$var(key)) + 1; e.g. reply route: if ($rs != "200" && $rs != "480" ) { $var(key) = $rm + "::" + $si + "::XXX"; } else { $var(key) = $rm + "::" + $si + "::" + $rs; } $sht(stat=>$var(key)) = $sht(stat=>$var(key)) + 1; e.g. dumping: xlog("PUBLISH::83.136.32.169=$sht(stat=>PUBLISH::83.136.32.169)"); $sht(stat=>PUBLISH::83.136.32.169)=0; xlog("PUBLISH_200::83.136.32.169=$sht(stat=>PUBLISH_200::83.136.32.169)"); $sht(stat=>PUBLISH_200::83.136.32.169)=0;xlog("PUBLISH_480::83.136.32.169=$sht(stat=>PUBLISH_480::83.136.32.169)"); $sht(stat=>PUBLISH_480::83.136.32.169)=0; xlog("PUBLISH_XXX::83.136.32.169=$sht(stat=>PUBLISH_XXX::83.136.32.169)"); $sht(stat=>PUBLISH_XXX::83.136.32.169)=0; It works, but is not very nice, IMO. Thus, I wonder if someone has a better, more elegant way to achieve this. Thanks Klaus

2 3

MI Command in Script
by Reda Aouad 15 Mar '12

15 Mar '12

Hi, Can we call MI commands from the script ? I'm thinking about reloading dispatcher or hash table from database for example.. Thanks Reda

2 2

Kamailio consumes memory
by Martin Tichatschek 15 Mar '12

15 Mar '12

Hi everyone, I have a problem with Kamailio consuming memory. I started testing with Kamailio 3.2.1 upgraded to 3.2.2 and also tested 3.1.5, everywhere the same problem. Whereas Kamailio 1.5.0 is working fine. Kamailio -V shows the following: kamailio@test:~$ kamailio -V version: kamailio 3.2.2 (i386/linux) 98ba92 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 98ba92 compiled on 17:51:30 Feb 29 2012 with gcc 4.2.4 kamailio@test:~$ My test scenario consists of two SIPp servers (a UAC and a UAS) and the Kamailio in the middle proxying the SIP traffic. The UAC sends 300 calls per second (INVITE, 100, 180, 200, ACK) and releases the calls (BYE, 200) after 20 sec call duration. UAS is simply sending back the right responds. Protocol is UDP. After some minutes the Kamailio floods the syslog file with error messages indicating that he is running out of memory. The SIPp shows retransmissions and also timeouts. When I stop the test and do a single call I get some lines of error messages. I found three different sets of error messages for a single call so far: Mar 2 09:35:44 test P-CSCFtest[21251]: ERROR:<core> [parser/msg_parser.c:172]: get_hdr_field: out of memory Mar 2 09:35:44 test P-CSCFtest[21251]: INFO:<core> [parser/msg_parser.c:353]: ERROR: bad header field [To:<sip:00498111111] Mar 2 09:35:44 test P-CSCFtest[21251]: ERROR: tm [t_lookup.c:1118]: ERROR: reply cannot be parsed Mar 2 09:35:44 test P-CSCFtest[21251]: ERROR:<core> [msg_translator.c:1884]: ERROR: build_res_buf_from_sip_res: out of mem Mar 2 09:35:44 test P-CSCFtest[21251]: ERROR:<core> [forward.c:794]: ERROR: forward_reply: building failed Mar 2 09:35:44 test P-CSCFtest[21228]: ERROR:<core> [msg_translator.c:1884]: ERROR: build_res_buf_from_sip_res: out of mem Mar 2 09:35:44 test P-CSCFtest[21228]: ERROR: tm [t_reply.c:1786]: ERROR: relay_reply: no mem for outbound reply buffer Mar 2 09:35:44 test P-CSCFtest[21228]: ERROR:<core> [msg_translator.c:2036]: ERROR: build_res_buf_from_sip_req: out of memory ; needs 311 Mar 2 10:19:43 test P-CSCFtest[21346]: ERROR:<core> [msg_translator.c:1884]: ERROR: build_res_buf_from_sip_res: out of mem Mar 2 10:19:43 test P-CSCFtest[21346]: ERROR: tm [t_reply.c:1786]: ERROR: relay_reply: no mem for outbound reply buffer Mar 2 10:19:43 test P-CSCFtest[21346]: ERROR:<core> [msg_translator.c:2036]: ERROR: build_res_buf_from_sip_req: out of memory ; needs 311 Mar 2 10:20:16 test P-CSCFtest[21328]: ERROR:<core> [action.c:852]: ERROR: do_action: memory allocation failure Mar 2 10:20:16 test P-CSCFtest[21328]: ERROR:<core> [action.c:1568]: run action error at: /usr/local/etc/kamailio//kamailio.cfg:28 Mar 2 10:20:16 test P-CSCFtest[21328]: ERROR:<core> [action.c:852]: ERROR: do_action: memory allocation failure Mar 2 10:20:16 test P-CSCFtest[21328]: ERROR:<core> [action.c:1568]: run action error at: /usr/local/etc/kamailio//kamailio.cfg:32 Mar 2 10:20:16 test P-CSCFtest[21328]: ERROR:<core> [parser/parse_from.c:71]: ERROR:parse_from_header: out of pkg_memory Mar 2 10:20:16 test P-CSCFtest[21328]: ERROR: tm [t_lookup.c:1326]: ERROR: new_t: no valid From in INVITE Mar 2 10:20:16 test P-CSCFtest[21328]: ERROR: tm [t_lookup.c:1478]: ERROR: t_newtran: new_t failed Mar 2 10:20:16 test P-CSCFtest[21328]: WARNING:<core> [receive.c:209]: WARNING: receive_msg: error while trying script I repeated the test various times, it always generates a memory problem. The "top" command shows that the free memory is decreasing constantly during the test. Stopping the test and waiting for some time (1 hour) doesn't increase the free memory showed by "top". Only a restart of the Kamailio frees the memory again. I executed the test with 30 calls per second too and got the same behaviour (after some more minutes). I finally simplified the Kamailio config as far as possible and came to this minimum: #!KAMAILIO listen=10.10.10.10:5060 children=30 user="kamailio" group="kamailio" debug=2 disable_core_dump=yes log_facility=LOG_LOCAL0 log_name="P-CSCFtest" server_signature=no sip_warning=0 syn_branch=0 disable_tcp=yes ####### Modules Section ####### mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/" loadmodule "tm.so" ####### Main Routing Logic ######## route{ if (src_ip==1.2.3.4) { rewritehost("5.6.7.8"); } else { rewritehost("1.2.3.4"); }; rewriteport("5061"); t_relay(); } This config still generates the memory problem. After replacing the "t_relay()" with the stateless "forward()" the problem is gone. I played around with the number of child processes too, but no difference. Is this a memory leak of the TM module or is there a different explanation? Regards Fred

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users