Re: [SR-Users] Transaction Lookup Failing
Apologies for the false alarm here - Kamailio was not to blame. There was a code change in a recent version of PJSIP that resulted in the second Via header not including the src port that the request originated from. Effectively this meant that the Via header was not an exact match for the invite, which caused the transaction to not match. Through some configuration changes in PJSIP I was able to work around this. Best, Colin On Sat, Apr 8, 2017 at 7:56 PM, Colin Morelli wrote: > Hey all, > > Trying to debug an issue with canceling an invite. I have two different > types of clients. On one client, canceling an invite works correctly. With > the other client, it t_check_trans fails. > > Both clients show the same request/responses: > > On Client A: > -> INVITE > <- 183 > -> PRACK > <- 200 > -> UPDATE (from successful STUN binding) > <- 200 > -> CANCEL > <- 200 > > On Client B: > -> INVITE > <- 183 > -> PRACK > <- 200 > -> UPDATE (from successful STUN binding) > <- 200 > -> CANCEL > <- 481 (this is sent from my kamailio script when t_check_trans fails) > > I can't see much that's different between the leading requests/responses > of each. They seem to be virtually identical (with the exception of IP > addresses and tag values, of course). This makes sense, since they're both > based on PJSIP (albeit different versions of PJSIP, but not off by much) > > Is there anything in particular I should be looking out for that might be > obvious? I could provide more detailed logs and traces if required. > > Best, > Colin > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Transaction Lookup Failing
Hey all, Trying to debug an issue with canceling an invite. I have two different types of clients. On one client, canceling an invite works correctly. With the other client, it t_check_trans fails. Both clients show the same request/responses: On Client A: -> INVITE <- 183 -> PRACK <- 200 -> UPDATE (from successful STUN binding) <- 200 -> CANCEL <- 200 On Client B: -> INVITE <- 183 -> PRACK <- 200 -> UPDATE (from successful STUN binding) <- 200 -> CANCEL <- 481 (this is sent from my kamailio script when t_check_trans fails) I can't see much that's different between the leading requests/responses of each. They seem to be virtually identical (with the exception of IP addresses and tag values, of course). This makes sense, since they're both based on PJSIP (albeit different versions of PJSIP, but not off by much) Is there anything in particular I should be looking out for that might be obvious? I could provide more detailed logs and traces if required. Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] using kamailio to forward ipv6 to ipv4
Can't answer whether or not it's possible as I haven't tried it - but, Consider how this will impact the negotiation between clients and servers. If your B2BUA thinks calls are coming in from IPV4 (instead of IPV6), then it may not offer IPV6 in the invite. Similarly, if the client thinks it's connecting to your SIP infrastructure via V6, then it'll likely offer V6 in the invite which your B2BUA can't accept. ICE can probably help here, by offering both V4 and V6 candidates, but that's going to depend on your client/server setups. Unless you want Kamailio to proxy media s well, in which case you may be able to escape this, but by adding complexity you Kamailio. If at all possible, I'd try to preserve the source protocol through to the end. If this is something you already thought of though, great! Would be good to hear what you come up with here. Best, Colin On Thu, Jan 5, 2017 at 12:24 PM, anfecora wrote: > Hi guys hope you have a great new year. > I would appreciate if anyone can point me in to the right direction . > > I need to build a proxy to translate from ipv6 to ipv4, but kamailio > should not process the registers or invites, only translate from ipv6 to > ipv4 and forward all registrations over. > > > is that possible? > thanks. > > > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Limiting Registration Contacts
Hey Daniel, This makes sense, thanks for the explanation. While I can understand why it works the way it does now, I still think having an option here would be great. My thought is, whether the mobile phone that re-registers every 10 minutes or the desk phone is "older," the point is that they're both older than the device which is currently trying to register and is unable to. There's also some preferential logic you could try to add here - perhaps try to remove .invalid contacts first, which are generally used by browsers and likely less stable than contacts with an IP address. All that said, I appreciate the clarification. I believe it's fairly trivial to do this with sqlops anyway so it's not a huge deal. I also may be able to do something in the edge proxy to automatically send an unregister if a websocket connection closes after a register request. Thanks! Colin On Mon, Dec 5, 2016 at 6:02 AM Daniel-Constantin Mierla wrote: > Hello, > > right now the rule is to reject the registrations that exceed the > max_contacts limit. The main reason behind this policy is the registration > mechanism in SIP which requires periodic update/refresh but also different > expires intervals. > > In this way it's hard to select the "old device". Can be a desktop phone > registering every hour and stable connection but also a mobile phone > registering every 10 minutes, changing the ip every now and then. By just > relying on the oldest registration, the desktop phone is likely the > candidate to remove most of the time, but keep other invalid mobile > contacts. > > The solution would be to use GRUU (or the instance parameter) for > registration contacts. In this way each new registration from a device will > replace its own old contact, even if it has a different contact address. > > Cheers, > Daniel > > On 01/12/2016 23:59, Colin Morelli wrote: > > Hey Alex - not sure I'm quite following what you mean. The bindings are > only for web clients. Are you suggesting the clients themselves > de-register? I'd have no problem with that with the exception of the fact > that there's simply no way to guarantee that happens. It's a race condition > between whether the unregistration can be sent before the browser kills the > websocket connection on refresh. > > On Thu, Dec 1, 2016 at 5:57 PM, Alex Balashov > wrote: > > Wouldn't it be more fruitful to delete and reach old bindings in such a > scenario? Or are these bindings not only for web clients? > > On December 1, 2016 5:54:06 PM EST, Colin Morelli > wrote: > >Hey all, > > > >I know Kamailio's registrar module has a max_contacts parameter that > >will > >limit the number of active contacts for an AOR. However, is there any > >mechanism to control what happens when that number is hit? > > > >When using a web client where every page refresh registers a new > >contact > >with Kamailio, it would be useful to automatically roll off the oldest > >registrations and replace to make room for the new ones. I know this > >can be > >manually accomplished with sqlops, but I was hoping something like this > >already existed. > > > >Best, > >Colin > > > > > > > > > >___ > >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > >sr-users@lists.sip-router.org > >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing > listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Dual Stack Environments
Hey all, Sorry for two questions out at the same time! I'm using kamailio in front of FS, and I'm about to enable IPv6, but I have a question that I'm not entirely clear on. What's the proper way to forward traffic using the same interface that it came in on? Specifically, if a client connects to kamailio on IPv6, it should connect to FS on IPv6, so that FS knows to advertise its v6 address in the SDP. The same should be true for v4. Is this possible? Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Limiting Registration Contacts
Hey Alex - not sure I'm quite following what you mean. The bindings are only for web clients. Are you suggesting the clients themselves de-register? I'd have no problem with that with the exception of the fact that there's simply no way to guarantee that happens. It's a race condition between whether the unregistration can be sent before the browser kills the websocket connection on refresh. On Thu, Dec 1, 2016 at 5:57 PM, Alex Balashov wrote: > Wouldn't it be more fruitful to delete and reach old bindings in such a > scenario? Or are these bindings not only for web clients? > > On December 1, 2016 5:54:06 PM EST, Colin Morelli > wrote: > >Hey all, > > > >I know Kamailio's registrar module has a max_contacts parameter that > >will > >limit the number of active contacts for an AOR. However, is there any > >mechanism to control what happens when that number is hit? > > > >When using a web client where every page refresh registers a new > >contact > >with Kamailio, it would be useful to automatically roll off the oldest > >registrations and replace to make room for the new ones. I know this > >can be > >manually accomplished with sqlops, but I was hoping something like this > >already existed. > > > >Best, > >Colin > > > > > > > > > >___ > >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > >sr-users@lists.sip-router.org > >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Limiting Registration Contacts
Hey all, I know Kamailio's registrar module has a max_contacts parameter that will limit the number of active contacts for an AOR. However, is there any mechanism to control what happens when that number is hit? When using a web client where every page refresh registers a new contact with Kamailio, it would be useful to automatically roll off the oldest registrations and replace to make room for the new ones. I know this can be manually accomplished with sqlops, but I was hoping something like this already existed. Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] TCP Keepalive for NAT'd Clients
Don't know how I missed this. Thanks, Daniel! Best, Colin On Tue, Nov 8, 2016 at 3:46 AM Daniel-Constantin Mierla wrote: > Hello, > > you can set per tcp connection lifetime using tcpops module: > >- https://www.kamailio.org/docs/modules/stable/modules/tcpops.html > > You can do that when you get the INVITE, before sending a negative > response from kamailio.cfg. Or, if you relay the invite, set a failure > route for it and do the operation there. > > Cheers, > Daniel > > On 07/11/16 23:26, Colin Morelli wrote: > > Hey all, > > Looking to figure out the best way to allow TCP connections to stay alive > for NAT'd clients, however, to protect against people just opening TCP > connections to the server, I'm hoping to only keepalive TCP connections for > connections that have sent an INVITE and received a 200 OK. > > Does this type of per-socket connection lifetime setting exist? > > For a bit more background: this is specifically for clients that are using > the TCP connection for an INVITE. They don't register with the server, and > as a result there's no active flow timer for their connection. Is there a > way to enable this type of behavior without registering? > > Best, > Colin > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing > listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - > http://www.linkedin.com/in/miconda > Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] TCP Keepalive for NAT'd Clients
Hey all, Looking to figure out the best way to allow TCP connections to stay alive for NAT'd clients, however, to protect against people just opening TCP connections to the server, I'm hoping to only keepalive TCP connections for connections that have sent an INVITE and received a 200 OK. Does this type of per-socket connection lifetime setting exist? For a bit more background: this is specifically for clients that are using the TCP connection for an INVITE. They don't register with the server, and as a result there's no active flow timer for their connection. Is there a way to enable this type of behavior without registering? Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Send JSON document over http and process response
Hey Jonathan,
You can also use the Jansson module to create the JSON request. For
example, in one of my configs, I have a route that looks basically like:
$var(params) = $null;
jansson_set("string", "request.uri", "$ru", "$var(params)");
jansson_set("string", "request.method", "$rm", "$var(params)");
jansson_set("string", "request.domain", "$rd", "$var(params)");
/// other fields set here
http_set_timeout(5000);
http_set_method("POST");
http_append_header("Content-Type: application/json");
http_async_query("https://mydomain.com/api/v1/blah";, "$var(params)",
"API_ROUTE_REPLY");
Then a API_ROUTE_REPLY block that processes the response like:
if $http_ok {
if $http_rs == 200 {
$var(action) = $null;
jansson_get_field("$http_rb", "authentication.action",
"$var(action)");
// other stuff
}
}
Hopefully that's helpful.
Best,
Colin
On Mon, Aug 22, 2016 at 9:52 AM Jonathan Hunter
wrote:
> Hi Guys,
>
> I need to send a JSON document over HTTP to a server, and then process the
> response, both in the kamailio configuration file.
>
> I assume I need to use Jansson module to extract contents of response?
>
> What is the best method for generating the initial request containing JSON
> ?
>
>
> Many thanks
>
> Jon
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Path & Loose Route
Luke,
This is actually the behavior I would expect, though admittedly I've never
tried to rely on received= parameter routing for requests (I wasn't aware
that was something that should be supported).
However, you're probably better of addressing your NAT issues in a
different part of your request lifecycle. Could you share a bit more about
the setup you're using here? Is this Freeswitch dialing out to a registered
endpoint? Where are registrations being handled? How is FS creating the
route headers?
If you just start with a layout if your infrastructure it'll probably
answer all those questions and we can come up with a solution from there.
Best,
Colin
On Mon, Aug 1, 2016 at 11:57 AM Luke Milbourne
wrote:
> Hi All,
>
> I've been going through my script against other examples on the internet
> and cannot see any differences, also changing use_received between 1 and 0
> makes no different.
>
> Kamailio still uses the Contact header instead of the Route header.
>
> If any one has any suggestions it would be very much appreciated, but I'll
> continue going through the config line by line.
>
> Kind regards,
> Luke
>
> On 1 August 2016 at 13:46, Luke Milbourne
> wrote:
>
>> Is it correct to use loose_route() along side the path module?
>>
>> On 1 August 2016 at 13:33, Luke Milbourne
>> wrote:
>>
>>> Hi Daniel,
>>>
>>> Yep, I've got the below in my kamailio.cfg
>>>
>>> modparam("path", "use_received", 1)
>>>
>>> Kind regards,
>>> Luke
>>>
>>> On 1 August 2016 at 13:25, Daniel-Constantin Mierla
>>> wrote:
>>>
Hello,
On 01/08/16 14:14, Luke Milbourne wrote:
Hi all,
Currently trying to use Kamailio as a passthrough to some FreeSWITCH
boxes.
When receiving an invite from FreeSWITCH which contains a Route header
including received information, example below;
Route: ;lr;received=sip:[PUBLIC_IP]:45126
When using loose_route() Kamailio still send the invite to the rfc1918
address instead of the received IP:PORT in the Route header.
Am I misunderstanding how this should work?
if you use path module, have you enabled the option to use the received
parameter?
https://www.kamailio.org/docs/modules/stable/modules/path.html#idp38033932
Cheers,
Daniel
--
Daniel-Constantin Mierlahttp://www.asipto.com -
http://www.kamailio.orghttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Luke Milbourne
>>>
>>>
>>> Tel: 07857154817
>>> Google Talk/Email: luke.milbou...@gmail.com
>>>
>>
>>
>>
>> --
>> Luke Milbourne
>>
>>
>> Tel: 07857154817
>> Google Talk/Email: luke.milbou...@gmail.com
>>
>
>
>
> --
> Luke Milbourne
>
>
> Tel: 07857154817
> Google Talk/Email: luke.milbou...@gmail.com
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] SIP Outbound / t_next_contacts()
I'm not suggesting that t_next_contacts deviates from the README. I'm looking for its specific use case when combined with the outbound module. At the very least, the example registrar configuration here: http://www.kamailio.org/docs/modules/4.4.x/modules/outbound.html is incomplete, in that it will always result in this error when there's only one binding in the registrations table. I suppose it's just a matter of checking for t_next_contacts() == -1 in the initial fork, and then check for < 0 in subsequent failure routes. I apologize if my original message was unclear, but this was a request for clarification, not a bug report - though I will try to make a PR for the outbound documentation page when I get this working. Best, Colin On Sun, Jul 24, 2016 at 12:51 PM Juha Heinanen wrote: > Colin Morelli writes: > > > When there's one registration binding in the locations table, > > t_load_contacts doesn't seem to do anything and as a result > > t_next_contacts fails. > > t_next_contacts() does work as specified in README: > > Function returns 1 if contacts_avp was not empty and a destination set > was successfully added, returns -2 if contacts_avp was empty and thus > there was nothing to do, and returns -1 in case of an error (see > syslog). > > so you just have to test the return value accordingly. > > -- juha > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] SIP Outbound / t_next_contacts()
Juha, I changed the message between when I copied the code and the logs. Those lines are the lines that produce the error message. As I mentioned in the original message - I'm aware that there's only one branch in the set. That is the case that this doesn't work. When there's one registration binding in the locations table, t_load_contacts doesn't seem to do anything and as a result t_next_contacts fails. Presumably I could add a special case to detect when there's only a single binding by looking at $branch(count), and not run this code, but that feels like a case that t_load_contacts *should* handle itself, no? Best, Colin On Sun, Jul 24, 2016 at 12:35 PM Juha Heinanen wrote: > Colin Morelli writes: > > > 8(27) DEBUG: tm [t_serial.c:191]: t_load_contacts(): nr_branches is 0 > > 8(27) DEBUG: tm [t_serial.c:194]: t_load_contacts(): nothing to do - > only > > one contact! > > 8(27) DEBUG: tm [t_serial.c:455]: t_next_contacts(): no contacts in > > contacts_avp - we are done! > > 8(27) ERROR:
[SR-Users] SIP Outbound / t_next_contacts()
Hey all, I've got two layers of Kamailio proxies running. One set of edge proxies that are parking outbound connections and doing load balancing to a set of registrar/proxies. This is working well with one exception: I can't seem to get t_load_contacts/t_next_contacts working correctly for handling multiple outbound connections. It *appears* to work (though I haven't extensively tested) whenever there's more than one registration binding for an AOR. However, when there's only one, I get: 8(27) DEBUG: tm [t_serial.c:191]: t_load_contacts(): nr_branches is 0 8(27) DEBUG: tm [t_serial.c:194]: t_load_contacts(): nothing to do - only one contact! 8(27) DEBUG: tm [t_serial.c:455]: t_next_contacts(): no contacts in contacts_avp - we are done! 8(27) ERROR:
Re: [SR-Users] How to forward REGISTERs to Asterisk in kamailio with dispatcher module with several Asterisk PBXs?
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 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: + $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.cont...@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";
>>
Re: [SR-Users] WEBRTC Confusion (2)
Zakia, Alright, starting with the basics: IP based voice/video communications generally involve two distinct responsibilities: signaling and media. The job of the signaling layer is to exchange information about calls between two parties. For example, if I call you, I use my signaling protocol to talk to my signaling server to send you an invitation to connect. The server (somehow - implementation dependent) relays that information to you. Once you've received the information, you can answer/ignore/reject the invitation. The signaling layer is responsible for notifying me about your response. The ultimate goal of the signaling layer is to exchange media descriptions, that tell each party where/how they can communicate with each other. SIP is an example of a signaling protocol, and it uses SDPs to exchange information about media. The job of the media layer is to actually exchange the media between two endpoints. With the job of the signaling layer complete, I should have some information about how I can talk to you. With that information I received over the signaling layer, I should be able to open my local audio/video devices, and stream data to you regardless of where you are. The media layer is responsible for handling that data and ensuring it gets to its destination. WebRTC is a spec for a media implementation which uses STUN/TURN/ICE for NAT traversal and reliable media exchange. While it is commonly built on top of SIP, there is no reason it needs to be. SIP is not directly involved in WebRTC at all. Rather, WebRTC-capable SIP endpoints simply generate an SDP containing all the information WebRTC needs to know in order to take over the rest (what codecs should be used, ICE candidates where the remote party can be reached, etc). Now, Kamailio is a SIP server/proxy. This means it speaks/understands the SIP protocol. This also means that its primary concern is with signaling. If you want to use Kamailio as the signaling layer for your application - then you'll need to talk to it via SIP. sipml5 is a javascript based SIP client that can run in browser, but there are others as well (SIP.js, JsSIP). You'll probably want to use one of these rather than build your own. Now, because SIP is just the signaling layer - there's no reason you *need* to use SIP in order to work with WebRTC. However, the Kamailio group, as well as the SIP client authors, have spent a lot of time building and refining their products to make them production-grade and robust. If you want to use Kamailio, you need a SIP client. Even with WebRTC (remember, WebRTC is only about media). If you were feeling very adventurous (although I would never recommend it), you could build your own signaling layer and use your own custom client. But you'd also have to build a server component that speaks your new protocol. Bottom line: you probably just want to stick with Kamailio + one of the great javascript SIP clients I mentioned above. They're quite stable/reliable. Hopefully that helps. Best, Colin On Tue, Jul 19, 2016 at 3:11 PM Zaka wrote: > Hello Colin: > > Thanks a lot! It solved the issue. Though I had got a hint by succeeding > to specify the address using *kamailio -l desired address/port *option, > yet never noticed the lack of *MY-WS_ADDRESS* > > Last, but not the least, in a browser supporting WEBRTC (FF, CHROME) do we > still need SIP ML5as on: https://www.doubango.org/sipml5/ > > If not, I wonder how will the WS or WSS URL post the login credentials to > the KAMAILIO WEBRTC server? > > BR, > > Zaka > > > > On 16 July 2016 at 18:11, Colin Morelli wrote: > >> Zaka, >> >> I could be wrong here but I don't think you ever actually have a "listen" >> line for MY_WS_ADDR. >> >> I believe you have a typo, as you have listen=MY_IP_ADDR twice, once >> within the guard for WITH_WEBSOCKETS. Replace the one inside the if with >> MY_WS_ADDR and I think your problem should be resolved. >> >> Best, >> Colin >> >> On Sat, Jul 16, 2016 at 3:36 AM Zaka wrote: >> >>> Dear List: >>> >>> I am still stuck. Still unable to get Kamailio to listen on WEBRTC port* >>> (in this case 8000)* >>> >>> Please advise if it has something to do with disabling TLS/MSRP? >>> >>> >>> Please see the log & related config file in line here: >>> >>> *Log:* >>> >>> 0(5724) INFO: [ppcfg.c:82]: pp_subst_add(): ### added subst >>> expression: !MY_WS_PORT!8000!g >>> >>> >>> *and the result of config file check:* >>> >>> root@callcntr:/usr/local/etc/kamailio# kamailio -eE -ddd -cf >>> /usr/local/etc/kamailio/websocket.cfg >>> 0(5902) INFO: [main.c:1911]: main(): private (
Re: [SR-Users] WEBRTC Confusion (2)
Zaka, I could be wrong here but I don't think you ever actually have a "listen" line for MY_WS_ADDR. I believe you have a typo, as you have listen=MY_IP_ADDR twice, once within the guard for WITH_WEBSOCKETS. Replace the one inside the if with MY_WS_ADDR and I think your problem should be resolved. Best, Colin On Sat, Jul 16, 2016 at 3:36 AM Zaka wrote: > Dear List: > > I am still stuck. Still unable to get Kamailio to listen on WEBRTC port* > (in this case 8000)* > > Please advise if it has something to do with disabling TLS/MSRP? > > > Please see the log & related config file in line here: > > *Log:* > > 0(5724) INFO: [ppcfg.c:82]: pp_subst_add(): ### added subst > expression: !MY_WS_PORT!8000!g > > > *and the result of config file check:* > > root@callcntr:/usr/local/etc/kamailio# kamailio -eE -ddd -cf > /usr/local/etc/kamailio/websocket.cfg > 0(5902) INFO: [main.c:1911]: main(): private (per process) memory: > 8388608 bytes > 0(5902) DEBUG: [mem/f_malloc.c:323]: fm_malloc_init(): > fm_malloc_init: F_OPTIMIZE=16384, /ROUNDTO=2048 > 0(5902) DEBUG: [mem/f_malloc.c:325]: fm_malloc_init(): > fm_malloc_init: F_HASH_SIZE=2099, fm_block size=33912 > 0(5902) DEBUG: [mem/f_malloc.c:327]: fm_malloc_init(): > fm_malloc_init(0x7f9ca6e1f010, 8388608), start=0x7f9ca6e1f010 > 0(5902) DEBUG: [route.c:129]: route_add(): mapping routing block > (0xac2700)[0] to 0 > 0(5902) DEBUG: [route.c:129]: route_add(): mapping routing block > (0xac2680)[0] to 0 > 0(5902) DEBUG: [route.c:129]: route_add(): mapping routing block > (0xac26c0)[0] to 0 > 0(5902) DEBUG: [route.c:129]: route_add(): mapping routing block > (0xac2720)[0] to 0 > 0(5902) DEBUG: [route.c:129]: route_add(): mapping routing block > (0xac26a0)[0] to 0 > 0(5902) DEBUG: [route.c:129]: route_add(): mapping routing block > (0xac26e0)[0] to 0 > 0(5902) DEBUG: [pvapi.c:1976]: pv_init_buffer(): PV print buffer > initialized to [10][8192] > 0(5902) DEBUG: [main.c:2097]: main(): read 286773155 from > /dev/urandom > 0(5902) DEBUG: [main.c:2103]: main(): seeding PRNG with 1755363211 > 0(5902) DEBUG: [main.c:2107]: main(): test random numbers > 726213135 321707966 991183401 > 0(5902) DEBUG: [re.c:313]: subst_parser(): ok, se is 0x7f9ca6e3fc48 > 0(5902) INFO: [ppcfg.c:82]: pp_subst_add(): ### added subst > expression: !DBURL!mysql://kamailio:kamailiorw@localhost/kamailio!g > 0(5902) DEBUG: [cfg.lex:1690]: pp_define(): defining id: DBURL > 0(5902) DEBUG: [cfg.lex:1776]: pp_define_set(): ### setting define > ID [DBURL] value [mysql://kamailio:kamailiorw@localhost/kamailio] > 0(5902) DEBUG: [ppcfg.c:160]: pp_substdef_add(): ### added > substdef: [DBURL]=[mysql://kamailio:kamailiorw@localhost/kamailio] (0) > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBUG: [re.c:313]: subst_parser(): ok, se is 0x7f9ca6e3ffe8 > 0(5902) INFO: [ppcfg.c:82]: pp_subst_add(): ### added subst > expression: !MY_IP_ADDR!192.168.1.16!g > 0(5902) DEBUG: [cfg.lex:1690]: pp_define(): defining id: MY_IP_ADDR > 0(5902) DEBUG: [cfg.lex:1776]: pp_define_set(): ### setting define > ID [MY_IP_ADDR] value [192.168.1.16] > 0(5902) DEBUG: [ppcfg.c:160]: pp_substdef_add(): ### added > substdef: [MY_IP_ADDR]=[192.168.1.16] (0) > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBUG: [re.c:313]: subst_parser(): ok, se is 0x7f9ca6e40320 > 0(5902) INFO: [ppcfg.c:82]: pp_subst_add(): ### added subst > expression: !MY_DOMAIN!callcntr.com.al!g > 0(5902) DEBUG: [cfg.lex:1690]: pp_define(): defining id: MY_DOMAIN > 0(5902) DEBUG: [cfg.lex:1776]: pp_define_set(): ### setting define > ID [MY_DOMAIN] value [callcntr.com.al] > 0(5902) DEBUG: [ppcfg.c:160]: pp_substdef_add(): ### added > substdef: [MY_DOMAIN]=[callcntr.com.al] (0) > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBUG: [re.c:313]: subst_parser(): ok, se is 0x7f9ca6e40658 > 0(5902) INFO: [ppcfg.c:82]: pp_subst_add(): ### added subst > expression: !MY_WS_PORT!8000!g > 0(5902) DEBUG: [cfg.lex:1690]: pp_define(): defining id: MY_WS_PORT > 0(5902) DEBUG: [cfg.lex:1776]: pp_define_set(): ### setting define > ID [MY_WS_PORT] value [8000] > 0(5902) DEBUG: [ppcfg.c:160]: pp_substdef_add(): ### added > substdef: [MY_WS_PORT]=[8000] (0) > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBUG: [re.c:436]: subst_run(): running. r=1 > 0(5902) DEBUG: [re.c:505]: subst_str(): no match > 0(5902) DEBU
Re: [SR-Users] Websocket Path Issues
Daniel, That's looks like it should get what I want, but is there any way to suppress the error message? It seems like a lot of noise for what would be a common occurrence. Best, Colin On Fri, Jul 15, 2016 at 3:01 AM Daniel-Constantin Mierla wrote: > Hello, > > see if this parameter gets what you are looking for: > > - > https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.p.failure_exec_mode > > Cheers, > Daniel > > On 14/07/16 19:34, Colin Morelli wrote: > > Hey all, > > I'm using Kamailio as an outbound edge proxy for websocket connections. > When my registrar calls out to Kamailio to forward to a websocket > connection that has since been killed, rather than just entering the > failure branch, it throws a few errors: > > 5(24) WARNING: [msg_translator.c:2760]: via_builder(): TCP/TLS > connection (id: 0) for WebSocket could not be found > 5(24) ERROR: [msg_translator.c:1978]: > build_req_buf_from_sip_req(): could not create Via header > 5(24) ERROR: tm [t_fwd.c:476]: prepare_new_uac(): could not build request > 5(24) ERROR: tm [t_fwd.c:1737]: t_forward_nonack(): ERROR: > t_forward_nonack: failure to add branches > 5(24) ERROR: sl [sl_funcs.c:363]: sl_reply_error(): ERROR: sl_reply_error > used: No error (2/SL) > > > Ultimately this means the proxy gets a 500 rather than a 430 flow failed, > and the registration sits around in the proxy when it should be removed. > > Am I missing something obvious to get this behavior? > > Best, > Colin > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing > listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlahttp://www.asipto.com - > http://www.kamailio.orghttp://twitter.com/#!/miconda - > http://www.linkedin.com/in/miconda > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Websocket Path Issues
Hey all, I'm using Kamailio as an outbound edge proxy for websocket connections. When my registrar calls out to Kamailio to forward to a websocket connection that has since been killed, rather than just entering the failure branch, it throws a few errors: 5(24) WARNING: [msg_translator.c:2760]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found 5(24) ERROR: [msg_translator.c:1978]: build_req_buf_from_sip_req(): could not create Via header 5(24) ERROR: tm [t_fwd.c:476]: prepare_new_uac(): could not build request 5(24) ERROR: tm [t_fwd.c:1737]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches 5(24) ERROR: sl [sl_funcs.c:363]: sl_reply_error(): ERROR: sl_reply_error used: No error (2/SL) Ultimately this means the proxy gets a 500 rather than a 430 flow failed, and the registration sits around in the proxy when it should be removed. Am I missing something obvious to get this behavior? Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] re-INVITE on IP Change with Outbound
Alright, After better understanding of the SIP spec it looks like even if I can solve this problem I shouldn't, because Route headers can't change once a dialog is established (if someone knows a reliable/supported way to make this happen - that would be great). However, as long as my client keeps an active TLS connection open to Kamailio, subsequent messages/responses are delivered over that same connection. So I'm having the client hold that connection open (and re-invite in the case that it's closed), and not using outbound on the invite and now things seem to be working. Best, Colin On Fri, Jul 8, 2016 at 10:32 AM Colin Morelli wrote: > Hey list, > > So I'm using the outbound module to ensure subsequent requests are > delivered over an active TCP connection established by the mobile client. > However, now I'm trying to add support for automatically responding to > network changes (WiFi <-> LTE), and it's creating problems. > > Primarily, the issue is that when the device sends a re-INVITE for the > call, its Route: header includes a flow-token corresponding to its *old* > socket > connection. Because the new request doesn't have the same source IP/port as > the old connection did Kamailio thinks that the next route hop it needs to > take is to pass the request over to the connection identified by the flow > token. So it actually tries to re-open a TCP connection back out to the > client even though I'm making the re-invite because that old transport is > no longer valid. > > Does anyone have a recommended way of handling this case? I can add > another header/param to the route header and manually remove it. Before > loose_routing. > > Essentially, on in-dialog INVITE requests I want to ignore the outbound > token on the originating side but I can't seem to find a way to do that > without re-writing the header before loose_routing. > > Best, > Colin > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] re-INVITE on IP Change with Outbound
Hey list, So I'm using the outbound module to ensure subsequent requests are delivered over an active TCP connection established by the mobile client. However, now I'm trying to add support for automatically responding to network changes (WiFi <-> LTE), and it's creating problems. Primarily, the issue is that when the device sends a re-INVITE for the call, its Route: header includes a flow-token corresponding to its *old* socket connection. Because the new request doesn't have the same source IP/port as the old connection did Kamailio thinks that the next route hop it needs to take is to pass the request over to the connection identified by the flow token. So it actually tries to re-open a TCP connection back out to the client even though I'm making the re-invite because that old transport is no longer valid. Does anyone have a recommended way of handling this case? I can add another header/param to the route header and manually remove it. Before loose_routing. Essentially, on in-dialog INVITE requests I want to ignore the outbound token on the originating side but I can't seem to find a way to do that without re-writing the header before loose_routing. Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Distributed Authentication
Hey all, I'm running a cluster of Kamailio instances as a proxy/registrar for another cluster of Freeswitch instances. I'm using http_async_client to make HTTP queries to my API to fetch credentials on auth challenges. Kamailio performs generating the header, and validating the result based on the data provided from my API. I'm fairly sure the answer is no, but I was wondering if Kamailio has any mechanism for getting access to the nonce/nc values in the challenges and responses so I can store them somewhere accessible to the whole cluster. Because my instances are transaction stateful, the request that is challenged and the subsequent request with the response may be routed to different instances and I want to validate the nonce correctly. I can move all of this into the API (the digest auth and verification), but my next question would be whether or not there are any APIs for getting access to this information in a structured format, or if I should just shove the whole digest auth header in the request to my API and parse/verify there. Thanks in advance. Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio Load Balancer Architecture
Daryn, That response was more general, not necessarily directed at you! DNS-based load balancing has always been problematic for clients. They tend to not properly balance across SRV records, or failover to secondary A records. However, I think the best solution would be something like what Daniel mentioned - to have multiple (maybe 2-4 but the number really depends on your availability and scalability requirements) Kamailio instances at the edge, each with a corresponding standby ready to take over that IP in a failover scenario. Combine that setup with rotating the A and SRV records in your DNS server (most DNS servers support automatically rotating the records in a response), and you should be able to support all kinds of clients. Best, Colin On Thu, Jun 30, 2016 at 11:49 AM Daniel Tryba wrote: > On Thu, Jun 30, 2016 at 05:15:19PM +0200, Giacomo Vacca wrote: > > Remember though that the Load Balancer will be > > your Single Point Of Failure. If the Load Balancer dies, for any reason, > > the service is not available. > ... > > Depending on the capabilities of the clients you may consider removing > the > > Load Balancer from the equation and perform DNS-based load balancing > across > > your Proxy/Registrar/PSTN Gw instances. You'd be removing a SPOF, use one > > fewer machine, and simplify the architecture. This is not always possible > > to achieve though, because it delegates load balancing and fail over to > the > > clients. > > Clients are to stupid to do this, you have to target the lowest common > denominator which only connect to a single ip. The loadbalancer is one > of the most simple possible config of kamailio possible (dispatcher and > path). > > So if you worry (rightly so) about a single point of failure in the > loadbalancer setup, make that one redundant by using a failover > mechanisme (heartbeat/keepalive/whatever). And having multiple instances > of this setup to use DNS based loadbalancing or simple primary/secondary > endpoints for the clients to connect to make any kind of failover > mechanisme for any type of client possible. The resources needed for a > loadbalancer are the least of all machines needed. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio Load Balancer Architecture
Maybe I'm missing something about the core infrastructure of Kamailio that makes this impossible, but why does it seem like nobody wants to run multiple Kamailio load balancers in a cluster? sip.yourcompany.com can have A/SRV records pointing to multiple IP addresses of separate Kamailio instances. As long as the edge proxies are either stateless, or transaction-stateful (i.e. not dialog stateful) this should provide both availability and scalability at the edge. Is there something that makes this infeasible in Kamailio? On Thu, Jun 30, 2016 at 11:15 AM Giacomo Vacca wrote: > Hi Daryn, > it may not be an overkill, depending on the constrains you have. For > example if the clients can possibly only be instructed to connect to a > single public IP address (5.5.5.5 in your example), while you want to be > able to scale the Kamailio architecture with multiple instances, then it > can be a viable approach. Remember though that the Load Balancer will be > your Single Point Of Failure. If the Load Balancer dies, for any reason, > the service is not available. > > There has been an interesting thread in this mailing list recently, on > techniques to provide active/stand-by redundancy to a Kamailio deployment: > "High Availability". > > Depending on the capabilities of the clients you may consider removing the > Load Balancer from the equation and perform DNS-based load balancing across > your Proxy/Registrar/PSTN Gw instances. You'd be removing a SPOF, use one > fewer machine, and simplify the architecture. This is not always possible > to achieve though, because it delegates load balancing and fail over to the > clients. > > Giacomo > > > On 30 June 2016 at 17:03, Daryn Johnson wrote: > >> I am interested in opinions and suggestions about load balancing with >> Kamailio. I work for an ITSP that currently uses Oracle & Broadsoft, and I >> am working to design and develop an open source solution using Kamailio >> (Proxy, Registrar, LB) & other Application/Media servers for more >> flexibility and freedom :) Thank you ALL for the work you have put in on >> Kamailio! >> >> After much reading and configuration I have a Kamailio 'proxy' setup, >> with endpoints registered using the Registrar module, and calls being >> sent/received to/from the PSTN. I am interested in separating the Load >> Balancers from the Registrars & logic, for security and in order to be able >> to scale appropriately. I will be using the dispatcher module for both >> load balancers and proxies using the following architecture: >> >> PublicIP = 5.5.5.5; Private IP = 192.168.1.0/24 >> >> USERS (Public Internet) ==> (public: 5.5.5.5) [ Kamailio (LoadBalancer, >> Firewall, Sanity Checks) ] (core:192.168.1.2) ==> [ Kamailio Registrar, >> Proxy, PSTN GW ] ==> AppServers or PSTN GW >> >> (we can access our PSTN gateways Via our Core using Private IPs) >> >> Questions: >> 1) Is it overkill to separate the LB & Proxy/Registrars? >> 2) Is this a common architecture & anyone configured this architecture >> successfully? >> >> Thanks in advance for your help! >> >> >> *Daryn Johnson* >> >> >> *Senior VoIP Engineer* >> >> >> >> >> ___ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio Iterate All Headers
I suppose there's a lot of subjectivity here - and it greatly depends on your configuration - but at least for my use case I don't quite agree with that statement. My API is already the component performing authentication and making routing decisions anyway, which means Kamailio is going to send the SIP traffic to wherever it says. Pushing a full list of headers to that endpoint doesn't compromise security any more than it already is by allowing the API to decide where that SIP message goes next. (In other words: my API is controlling SIP credentials, and if it really wanted access to the value of another header, it could simply redirect the SIP request to a server it controls). Additionally, this means that if I need to change the routing decisions that my API makes, I have to redeploy Kamailio with configuration changes to send the new header values. This leaks implementation details of my API into a layer that really doesn't need (or want) to concern itself with that work. Again - I fully understand that everyone's solutions here are different and this is just how it applies in my particular scenario. So I'm not intending to argue here, rather just suggesting that there are some valid use cases for it. In any case, thanks for the response! I'm sure I'll be back with more questions as I continue to work through this. Best, Colin On Mon, Jun 27, 2016 at 8:00 AM Alex Balashov wrote: > FWIW, I think that from a security and software quality perspective, > explicitly defining which headers you want to feed to the API is the much > better approach anyway. > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio Iterate All Headers
Yeah, I saw $mb as I was browsing through things. I was hoping to not have to re-parse the SIP message in the API since Kamailio has already done that work, and it would require some form of a SIP parser in my API. As a future feature request, I'll say that I think this would be a helpful addition (possibly even just a function that exports all headers names to an AVP which you can then iterate as you choose). Especially as applications continue to become more dynamic in nature. For now, I'll probably go the current route of just cherry-picking the headers that I need in my API and pushing those up. Thanks all! Best, Colin On Mon, Jun 27, 2016 at 7:49 AM Olle E. Johansson wrote: > > > On 26 Jun 2016, at 22:29, Colin Morelli wrote: > > > > Hey all, > > > > Back with more questions. > > > > I'm using Kamailio to make an HTTP call to my API to perform > authentication and message routing. Currently, I'm trying to build up the > post body that I send to my API to make those decisions. > > > > I've cherry picked a few of the headers that are important in my routing > decisions. But, ideally, I'd like to just iterate over all the SIP message > headers and append them as request parameters to my API call. Is this > possible with Kamailio? I've been looking through the docs and can't seem > to find a function to iterate the full list of headers. > > > > Thanks in advance. > > $mb > > will give you the full SIP message. > > /O > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio Iterate All Headers
Hey all, Back with more questions. I'm using Kamailio to make an HTTP call to my API to perform authentication and message routing. Currently, I'm trying to build up the post body that I send to my API to make those decisions. I've cherry picked a few of the headers that are important in my routing decisions. But, ideally, I'd like to just iterate over all the SIP message headers and append them as request parameters to my API call. Is this possible with Kamailio? I've been looking through the docs and can't seem to find a function to iterate the full list of headers. Thanks in advance. Best, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Public vs Internal IPs
Alright, I'll give both approaches a shot and see what comes up. Thanks for the fast response time, Alex! Best, Colin On Sat, Jun 25, 2016 at 7:07 PM Alex Balashov wrote: > It can work, but it's more trouble than the other approach, which is > essentially automagic. > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Public vs Internal IPs
Awesome, thank you. If I were to try to avoid opening another point, would it be sensible to call record_route_advertised_address() with the advertised address twice manually (once for the inbound and outbound legs with the appropriate IPs for each)? Internally I assume Kamailio's loose_route() would consume both of those on subsequent messages since they'd both be aliases for the local machine. Would that strategy be somewhat sensible as well? Best, Colin On Sat, Jun 25, 2016 at 6:54 PM Alex Balashov wrote: > Yep, you'll probably have to educate it as to which outbound interface to > choose, since they're on the same subnet (otherwise mhomed=1 would do the > trick). > > That's what the (writable) $fs pseudovar is for. > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Public vs Internal IPs
Thanks for the quick reply! Binding to two SIP ports isn't out of the question (though I'd like to avoid it if possible). However, with this approach, I assume somewhere I must have to instruct Kamailio which outbound interface to use (i.e. tell it to use 5080 for forwarded requests to internal hosts and 5060 for requests headed out?) How else would it know to cross over the interfaces? Best, Colin On Sat, Jun 25, 2016 at 6:43 PM Alex Balashov wrote: > Understood. I went through this a while back. > > As long as you're willing to bind to two different SIP ports (i.e. > different SIP port on your internal signalling), this is the solution: > > listen=udp:private.ip:5060 advertise public.ip:5060 > listen=udp:private.ip:5080 > > Combine with enable_double_rr, shake well, et voila! :-) > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Public vs Internal IPs
Hey Alex, Thanks for the response. This is the AWS scenario where there's a 1:1 NAT from the public to private IP. I've got as far as figuring out how to advertise the public IP. But, when I forward the request to another node inside the cluster, I assume I want to double-RR that request so that my internal SIP application sees the private IP of the instance. Similarly, for outbound traffic, I want to double-RR so the remote party sees the public IP of the host. That's the part I'm struggling with. Best, Colin On Sat, Jun 25, 2016 at 6:12 PM Alex Balashov wrote: > Is this the AWS NAT scenario where the public IP is actually not homed on > the host itself, or are you asking about a genuine two-interface scenario? > > Either way, look up the "advertise" option to the "listen" core > configuration directive. > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Public vs Internal IPs
Hey all, When using Kamailio at the edge - what's the best practice around how to advertise your Record-Route? I assume it's going to involve the use of a double-RR with both the public and private IPs. However, I'm running in AWS where the host doesn't have two interfaces with both a public and private IP. So, I set the host's public IP as the advertised address while Kamailio binds to the local IP. But now how do I get Kamailio to know that it needs to double-RR in this case? Thanks, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_on_failure route not being called
Sorry all - I've been staring a kamailio config files for too long.
The issue was obvious when I read log messages more closely: the
route[REROUTE] needed to be failure_route[REROUTE]. Everything works fine
now .
Best,
Colin
On Fri, Jun 24, 2016 at 3:01 PM Colin Morelli
wrote:
> Hey all,
>
> I'm using a combination of http_async_client and rtjson to query my API
> and retrieve a JSON target route set for an incoming SIP request that
> Kamailio will forward to. The HTTP portion of it works great. I'm able to
> hit my API and get back a JSON document.
>
> Additionally, the rtjson parsing appears to work, because the request is
> hitting my freeswitch instance. However, FS is responding with a 503 (I'm
> intentionally doing this for testing), and Kamailio isn't calling my
> t_on_failure route. I've pasted the relevant portion of my config below -
> would be great if anyone has any insights.
>
> tl;dr: the "REROUTE" route section below isn't being reached even when FS
> responds with a 503.
>
> Best,
> Colin
>
> route[ROUTING_REPLY] {
> if $http_ok && $http_rs == 200 {
> xlog("L_INFO", "$ci|log|loaded target route set from document
> $http_rb\n");
> rtjson_init_routes("$http_rb");
> rtjson_push_routes();
> xlog("L_INFO", "$ci|log|attempting to relay request towards $du\n");
> t_on_failure("REROUTE");
> t_set_fr(0, 1000);
> t_relay();
> } else {
> send_reply("480", "Temporarily Unavailable");
> }
> }
>
> route[REROUTE] {
> xlog("L_WARN", "$ci|log|relay to destination $du failed, checking next
> route\n");
> if (rtjson_next_route()) {
> xlog("L_INFO", "$ci|log|additional route found, directing request to
> $du\n");
> t_on_failure("REROUTE");
> t_set_fr(0, 1000);
> t_relay();
> } else {
> xlog("L_WARN", "$ci|log|route list exhausted, failing request\n");
> send_reply("480", "Temporarily Unavailable");
> exit;
> }
> }
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] t_on_failure route not being called
Hey all,
I'm using a combination of http_async_client and rtjson to query my API and
retrieve a JSON target route set for an incoming SIP request that Kamailio
will forward to. The HTTP portion of it works great. I'm able to hit my API
and get back a JSON document.
Additionally, the rtjson parsing appears to work, because the request is
hitting my freeswitch instance. However, FS is responding with a 503 (I'm
intentionally doing this for testing), and Kamailio isn't calling my
t_on_failure route. I've pasted the relevant portion of my config below -
would be great if anyone has any insights.
tl;dr: the "REROUTE" route section below isn't being reached even when FS
responds with a 503.
Best,
Colin
route[ROUTING_REPLY] {
if $http_ok && $http_rs == 200 {
xlog("L_INFO", "$ci|log|loaded target route set from document
$http_rb\n");
rtjson_init_routes("$http_rb");
rtjson_push_routes();
xlog("L_INFO", "$ci|log|attempting to relay request towards $du\n");
t_on_failure("REROUTE");
t_set_fr(0, 1000);
t_relay();
} else {
send_reply("480", "Temporarily Unavailable");
}
}
route[REROUTE] {
xlog("L_WARN", "$ci|log|relay to destination $du failed, checking next
route\n");
if (rtjson_next_route()) {
xlog("L_INFO", "$ci|log|additional route found, directing request to
$du\n");
t_on_failure("REROUTE");
t_set_fr(0, 1000);
t_relay();
} else {
xlog("L_WARN", "$ci|log|route list exhausted, failing request\n");
send_reply("480", "Temporarily Unavailable");
exit;
}
}
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio Behind TCP Load Balancer
Hi Daniel, Yes it is actually terminating and opening a new connection. I don't need HAProxy for anything at the moment, I was mentioning it for its support of the proxy protocol which enables applications to get source address information behind TCP load balancers. I'm not so much worried about the speed of kamailio - I'm confident it's quite fast. But for every piece of infrastructure I need to stand up, there's another opportunity for failure. Being able to use an ELB at the edge lets me place some of that hard work on Amazon, who has already thought of things like DNS load balancing, multi zone failover, etc. I think it'd be great if Kamailio could support something like proxy protocol to allow this scenario to work (it's just a single line sent right after a TCP connection is opened) Best, Colin On Thu, Jun 23, 2016 at 1:34 AM Daniel-Constantin Mierla wrote: > Hello, > > is the tcp load balancer changing the source address, like accepting the > connection from the phone and then opening one to kamailio? > > Do you need haproxy because of other reasons or only for sip? > > A kamailio load balancer (sip aware) is also quite fast. > Cheers, > Daniel > > > On 23/06/16 04:32, Colin Morelli wrote: > > Hey all, > > I'm looking to put Kamailio behind a TCP load balancer that is > SIP-unaware. My application is deployed in AWS and I'm tying to place > Kamailio behind an ELB. > > For the most part, everything is fine. For my specific implementation I'm > disabling UDP as a signaling transport and using only TLS. This enables me > to not have to worry about a SIP-aware LB at the edge because replies to an > incoming request will be sent over the existing established TCP socket > (avoiding any crazy routing requirements). > > However - this poses an issue with source addresses. Does Kamailio support > anything like the proxy protocol ( > http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt) for getting > TCP stream information from a load balancer? Do I need to go back to > exposing it directly to the world so that I can get source addresses? > > Thanks, > Colin > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing > listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlahttp://www.asipto.com - > http://www.kamailio.orghttp://twitter.com/#!/miconda - > http://www.linkedin.com/in/miconda > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio Behind TCP Load Balancer
Hey all, I'm looking to put Kamailio behind a TCP load balancer that is SIP-unaware. My application is deployed in AWS and I'm tying to place Kamailio behind an ELB. For the most part, everything is fine. For my specific implementation I'm disabling UDP as a signaling transport and using only TLS. This enables me to not have to worry about a SIP-aware LB at the edge because replies to an incoming request will be sent over the existing established TCP socket (avoiding any crazy routing requirements). However - this poses an issue with source addresses. Does Kamailio support anything like the proxy protocol ( http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt) for getting TCP stream information from a load balancer? Do I need to go back to exposing it directly to the world so that I can get source addresses? Thanks, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamilio as Scalable Registrar + Proxy
Hello, I currently have Freeswitch acting as a B2BUA, handling registrations, routing, etc for a prototype voice application I have built. Now I'm at the point where it's time to actually scale it out, and I'm looking at a few different options for the SIP proxy + registration later. Essentially, what I would like to have (I think), is: 1) Stateless SIP proxy with consistent hashing to route to: 2) Transaction-stateful SIP proxy handling registrations and initial routing Ideally, the only thing that's stored across the cluster (if possible) would be registrations, in something like memcache/redis. Then, of course, each node might have its own internal state of transactions that it's tracking. I'd prefer the only thing to care about dialog state to be Freeswitch. Finally, the decisions about which FS instance to route to would be made by my application as well, based on runtime rules. Is this something people here have done before? Are there other suggestions on how to scale out kamailio to multiple instances. Thanks in advance, Colin ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
