[SR-Users] How to forward REGISTERs to Asterisk in kamailio with dispatcher module with several Asterisk PBXs?
Colin Morelli
colin.morelli at gmail.com
Fri Jul 22 17:01:24 CEST 2016
If you're using Kamailio as a registrar, then it would make the most sense
to also use it as your outbound proxy for Asterisk.
This would mean whenever Asterisk needs to dial an extension, it would
instead make a SIP call to your Kamailio instance which would then perform
the lookup, forking, and forwarding.
Is there a reason this wouldn't work in your infrastructure? If for some
reason it can't - though I can't imagine how - then I don't see the purpose
in using Kamailio as a registrar at all. You should just forward everything
to Asterisk since it needs to be there anyway.
Best,
Colin
On Fri, Jul 22, 2016 at 9:58 AM SamyGo <govoiper at gmail.com> wrote:
> Hi Tickles,
>
> a) Have you tried doing this on Asterisk realtime ? for any regular direct
> registering extension w/o kamailio(even before kamailio) ? If an extension
> registers to one asterisk the rest of the boxes would know where to contact
> this extension via realtime-db ? I'd say give that a try and it may solve
> your problem, else using this REGFWD block you can parallel fork this
> register request to ALL of your boxes and everybox would think it is
> registered locally ! (not a recommended option I must say)
>
> b) If you ignore my previous comment of parallel forking registers, using
> this REGFWD block you can use dispatcher module to replace the $var(rip)
> and $sel(cfg_get.asterisk.bindport) by changing your REGFWD block like
> this:
>
> route[REGFWD] {
> if(!is_method("REGISTER"))
> {
> return;
> }
> if(!ds_select_dst("1", "4")) {
> $var(rip) = $(du{s.select,1,:});
> $var(rport) = $(du{s.select,2,:});
> $uac_req(method)="REGISTER";
> $uac_req(ruri)="sip:" + $var(rip) + ":" + $var(rport) +
> ";transport=tcp";
> $uac_req(furi)="sip:" + $au + "@" + $var(rip);
> $uac_req(turi)="sip:" + $au + "@" + $var(rip);
> $uac_req(hdrs)="Contact: <sip:" + $au + "@"
> + $sel(cfg_get.kamailio.bindip)
> + ":" + $sel(cfg_get.kamailio.bindport) +
> ">\r\n";
> if($sel(contact.expires) != $null)
> $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " +
> $sel(contact.expires) + "\r\n";
> else
> $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " +
> $hdr(Expires) + "\r\n";
> uac_req_send();
> }
>
> }
>
>
> In summary, depending upon your business logic/use case there could be
> other ways to make this work as well.
>
> Regards,
> Sammy
>
>
> On Fri, Jul 22, 2016 at 8:53 AM, Tickling Contest <
> tickling.contest at gmail.com> wrote:
>
>> Hello,
>>
>> When using Kamailio with the dispatcher module for Asterisk load
>> balancing, I am offloading REGISTERs to Kamailio (works fine), but would
>> like to forward the REGISTERs to Asterisk so that outgoing calls from
>> Asterisk will be possible. I know this is not strictly necessary (e.g.,
>> just use Kamailio to forward everything), but I have a lot of application
>> logic behind my Asterisk boxes (using ARI) and so I don't want that to
>> break. Thereby, I do need this information in Asterisk as soon as possible
>> from Kamailio.
>>
>> Let's say I have three boxes Asterisk_1, Asterisk_2 and Asterisk_3 in the
>> dispatcher module like so:
>>
>> 1 sip:192.168.1.201:5060;transport=tcp
>> 1 sip:192.168.1.202:5060;transport=tcp
>> 1 sip:192.168.1.203:5060;transport=tcp
>>
>> My system has endpoints as numerical extensions, from 101 to 110. When a
>> new endpoint registers with kamailio (and authenticates), I would like to
>> send the REGISTER to Asterisk. But I have the following questions:
>>
>> (a) Which Asterisk? I could send it to a round-robinned Asterisk (say,
>> Asterisk_2), but that Asterisk may not be the one responsible for handling
>> calls outbound for the endpoint that just registered. Even if I use "hash
>> over auth username" instead of round-robin (In
>> http://www.kamailio.org/docs/modules/4.0.x/modules/dispatcher.html#idp16940048,
>> choose 5 for "alg", for example) that wont solve this problem as an
>> outbound request may come from another Asterisk box which won't have the
>> requisite registration information. Should I forward REGISTERs to all
>> Asterisk boxes? Maybe I won't have to deal with this issue as I use
>> realtime and so the REGISTER information, sent to one Asterisk box, is
>> available to all Asterisk boxes after the write to the realtime DB. Is my
>> understanding correct?
>>
>> (b) How do I do this in kamailio.cfg? With some examples on the Internet
>> for WITH_ASTERISK directive, I see that you do
>>
>> route[REGFWD] {
>> if(!is_method("REGISTER"))
>> {
>> return;
>> }
>> $var(rip) = $sel(cfg_get.asterisk.bindip);
>> $uac_req(method)="REGISTER";
>> $uac_req(ruri)="sip:" + $var(rip) + ":" +
>> $sel(cfg_get.asterisk.bindport) + ";transport=tcp";
>> $uac_req(furi)="sip:" + $au + "@" + $var(rip);
>> $uac_req(turi)="sip:" + $au + "@" + $var(rip);
>> $uac_req(hdrs)="Contact: <sip:" + $au + "@"
>> + $sel(cfg_get.kamailio.bindip)
>> + ":" + $sel(cfg_get.kamailio.bindport) +
>> ">\r\n";
>> if($sel(contact.expires) != $null)
>> $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " +
>> $sel(contact.expires) + "\r\n";
>> else
>> $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " +
>> $hdr(Expires) + "\r\n";
>> uac_req_send();
>> }
>>
>> What is the equivalent for when you are using the dispatcher module and
>> the kamailio.bindip and asterisk.bindip etc. are not set in the
>> configuration, but instead should be procured from elsewhere?
>>
>> Any help is appreciated.
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160722/af83269d/attachment.html>
More information about the sr-users
mailing list