sr-users April 2012

sr-users@lists.kamailio.org

75 participants
133 discussions

Start a nNew thread

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

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

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 April 2012