Hello guys,
In my config i have:
# ----- dispatcher params -----
modparam("dispatcher", "db_url", DBURL)
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
modparam("dispatcher", "dstid_avp", "$avp(dsdstid)")
modparam("dispatcher", "attrs_avp", "$avp(dsattrs)")
# PVs for hashing
modparam("dispatcher", "hash_pvar", "$fU@$ci")
# PVs to store results when calling ds_is_from_list
modparam("dispatcher", "setid_pvname", "$var(setid)")
modparam("dispatcher", "attrs_pvname", "$var(attrs)")
# method to probe the gateways
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_from", "
sip:dispatcher@proxy.voice-proxy.singlecommand.com")
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshold", 1)
modparam("dispatcher", "ds_ping_reply_codes","class=2")
modparam("dispatcher", "ds_probing_mode", 1)
# size of hash table storing data for call load dispatching, power of two
modparam("dispatcher", "ds_hash_size", 10)
# expiration time in seconds to remove the load on a destination if no BYE
was received
modparam("dispatcher", "ds_hash_expire", 3600)
# expiration time in seconds to remove the load on a destination if no 200
OK for INVITE was received
# and state updated with ds_load_update
modparam("dispatcher", "ds_hash_initexpire", 60)
modparam("dispatcher", "ds_hash_check_interval", 30)
But i'm getting on startup:
ds_warn_fixup(): failover functions used, but required AVP parameters are
NULL -- feature disabled
What avp am I missing?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
Hi All,
I managed to solve my need to re-write NOTIFY packets with help from this thread: https://www.mail-archive.com/sr-users@lists.kamailio.org/msg08088.html
This seems to work well. I am re-writing the packets as shown below… I guess my only question is, is this relatively safe/smart to do? I basically copied what our standalone Asterisk PBXes are doing in my captures, so I guess so? But I’m not confident enough to say it won’t cause some weird edge case issues. I can only say it works fine with the Snom and Yealink handsets I am testing with. I’m just concerned because it feels a bit like a hack.
For SUBSCRIBE I re-write:
* Request URI and To header from 101@ sent by the handset to tenant101@ (to match the SIP username of the handset - tenant101@)
For NOTIFY I re-write:
* From and Contact header to remove the tenant prefix, to go back to 101@ to match the BLF key configuration on the handsets.
Any advice would be appreciated on if this is a bad idea, and there’s a better way.
Thanks!
Rhys Hanrahan
Chief Information Officer
Nexus One Pty Ltd
E: support(a)nexusone.com.au<mailto:support@nexusone.com.au>
P: +61 2 9191 0606
W: http://www.nexusone.com.au/
M: PO Box 127, Royal Exchange NSW 1225
A: Level 12 227 Elizabeth St, Sydney NSW 2000
From: sr-users <sr-users-bounces(a)lists.kamailio.org> on behalf of Rhys Hanrahan <rhys(a)nexusone.com.au>
Reply-To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
Date: Tuesday, 26 March 2019 at 8:56 pm
To: "sr-users(a)lists.kamailio.org" <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] Adding presentity_uri prefix for multi-tenanted presence/dialoginfo configuration
Hi Everyone,
I’ve recently just started working with Kamailio – thanks everyone for this amazing software.
Like many people, I’m in the process of trying to put Kamailio in-front of Asterisk to allow it to scale out, and my plan is for Kamailio to take over registrations, usrloc and presence/dialoginfo, as we’ve had issues where handsets are failing to get BLF updates/notifys, so I am hoping a couple of Kamailio boxes can scale better in this regard. DMQ is particularly exciting in how it will allow me to build a truly distributed platform. But I’m struggling to get presence to work the way I need it to.
Our environment is multi-tenanted, but we do not (and can’t really) use multi-domains. Instead, we prefix the SIP usernames with the “tenant name” such as tenanta101 and tenantb101. My problem is that all the BLFs are configured for 101@PBX with no tenant name in the User part of the URI so that internal dialing and call pickup will work. Because in Asterisk we use “subscribecontext” this hasn’t been a problem in the past – Asterisk knows for subscriptions coming from that handset that it belongs to that tenant’s context in the dialplan and they are “isolated”, so having handsets subscribe as 101@ in their request URI was never a problem. Of course, with Kamailio I don’t have subscribecontext, and my main issue is that the “presentity_uri” being stored is 101@ while each of the SIP accounts of the handsets are registered as tenenata101@, and as such, no NOTIFYs are sent by Kamailio because it thinks that there are no watchers for the presentity_uri.
If I change the SIP account username to 101 to match the BLF key, NOTIFYs are sent as expected. But then this breaks call pickup and internal dialing using the BLF keys. I would rather handle this in Kamailio than in Asterisk and having to re-configure the BLF keys for hundreds of handsets.
I need to do something like:
* When a SUBSCRIBE comes in, I need to prefix presentity_uri with the tenant name so the subscription changes from 101@ to tenanta101@ in the active_watchers table.
* When Kamailio generates a NOTIFY, the notify would be built based on presentity_uri and would come out as tenanta101@, but the phone’s BLFs are configured for 101@ so I would need to *remove* the tenant prefix before sending out the notify.
Is there a good, or recommended way to handle this scenario? Maybe something entirely different to changing the presentity_uri?
I’ve written the following config to re-write the request URI and To field in any incoming subscribe requests, and successfully got the active_watchers table to store a presentity_uri containing my tenant prefix. But the problem I am having is that I can’t figure out how to modify the NOTIFY packets before they are sent – and looking at cfgtrace, it seems I might not be able to?
My “standard” presence + dialoginfo configuration was taken from here as a starting point: https://kb.asipto.com/kamailio:presence:k43-blf
Here is what I have so far in terms of trying to make my modifications – any guidance would be greatly appreciated. It feels like there’s probably a better way to do this than re-writing critical headers like To and Request URI?
@@ -466,6 +467,8 @@ request_route {
# authentication
route(AUTH);
+ route(REWRITE_PRESENCE);
+
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
# Presence server processing
route[PRESENCE] {
if(!is_method("PUBLISH|SUBSCRIBE")) return;
if(is_method("SUBSCRIBE") && $hdr(Event)=="message-summary") {
# Asterisk is our voicemail
route(TOASTERISK);
# returns here if no voicemail server is configured
sl_send_reply("404", "No voicemail service");
exit;
}
#!ifdef WITH_PRESENCE
if (!t_newtran()) {
sl_reply_error();
exit;
}
if(is_method("PUBLISH")) {
handle_publish();
t_release();
} else if(is_method("SUBSCRIBE")) {
# See REWRITE_PRESENCE - this should have been executed before we get here.
handle_subscribe();
t_release();
}
exit;
#!endif
+route[REWRITE_PRESENCE] {
+ if (is_method("SUBSCRIBE")) {
+ xlog("Re-writing subscribe to include tenant prefix\n");
+ # The default presentity_uri needs to be prefixed with
+ # the tenant name
+ # So re-write the To header
+ route(TENANTINFO);
+ # Now grab the tenant name.
+ $var(subscribe_ru) = "sip:" + $var(tenant_name) + $rU + "@" + $rd;
+ xlog("Re-writing SUBSCRIBE To header as: $var(subscribe_ru)\n");
+ insert_hf("To: $var(subscribe_ru)\r\n", "From");
+ $ru = $var(subscribe_ru);
+ # Force change immediately:
+ # http://www.kamailio.org/wiki/tutorials/faq/main#why_changes_made_to_headers…
+ msg_apply_changes();
+ } else if (is_method("NOTIFY")) {
+ xlog("Re-writing NOTIFY to remove tenant prefix\n"); # This code block does not get executed right now.
+ # We are storing the presentity_uri with a tenant prefix
+ # handsets do not expect this, only 101@, 102@ etc... In their BLF configs
+ # So this tenant prefix must be removed when building the reply.
+ route(TENANTINFO);
+ $var(notify_ru) = "sip:" + $(rU{s.substr,$(var(tenant_name){s.len}),0}) + "@" + $rd;
+ xlog("Re-writng NOTIFY to use: $var(notify_ru)\n");
+ insert_hf("To: $var(notify_ru)\r\n", "From");
+ $ru = $var(notify_ru);
+ # Force change immediately:
+ # http://www.kamailio.org/wiki/tutorials/faq/main#why_changes_made_to_headers…
+ msg_apply_changes();
+ }
+}
Thanks for your time.
Rhys Hanrahan
Chief Information Officer
Nexus One Pty Ltd
E: support(a)nexusone.com.au<mailto:support@nexusone.com.au>
P: +61 2 9191 0606
W: http://www.nexusone.com.au/
M: PO Box 127, Royal Exchange NSW 1225
A: Level 12 227 Elizabeth St, Sydney NSW 2000
[ttp://quintus.nexusone.com.au/~rhys/nexus1-email-sig.jpg]
Hello,
I am currently debugging a strange issue related to the usage of
uac_replace_from/to() after msg_apply_changes(). It works all fine, but in a
Re-INVITE case it inserts the wrong headers for the 100 - Trying case. The
calle side gets then a reply with wrong From/To. This happens all the time
with this particular cfg.
I already checked for the usual issues:
- msg_apply_changes() called several times
- msg_apply_changes() called after transactions created/async processing etc..
Any ideas what else could be the problem?
The msg_apply_changes() is needed for some SDP filtering logic in the cfg.
Thanks and regards,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
Hi all,
I’m interested in extending the ENUM module to add support for draft-ietf-enum-cnam-08 CNAM queries using ENUM. I’m looking for high level guidance as to the best way to implement this and any feedback on naming of exported functions and parameters. Maybe something like enum_cnam_query("pvar", "destination", [,"suffix" [,"service"]]) ?
Best regards,
Spencer
Hello,
we continue our tradition to give away 3 free passes to students and
underrepresented people at Kamailio World Conference
(www.kamailioworld.com) – thanks to the sponsors, we are able to offer
them in 2019 as well. The passes cover the entire registration fee for
all three days and the social networking events – costs with travel and
accommodation have to be covered by the participants.
Anyone enrolled in an academic activity (including master and PhD
programs) as well as underrepresented people can apply for one of the
passes via email to me or to:
* conference [at] kamailioworld.com
or by contacting us via web form at:
* https://www.kamailioworld.com/k07/contact-us/
Applications done until April 15, 2019, will be selected by April 18,
2019. Afterwards, if there are still available passes, they will be
allocated in the first come first served policy.
The details for most of the presentations were published, the full
agenda is expected to be ready in a matter of a few days. You can see
more details at:
* https://www.kamailioworld.com/k07/schedule/
Looking forward to meeting many of you in Berlin, at Kamailio World
2019! It’s going to be another great event about open source real time
communications!
* https://www.kamailioworld.com/k07/registration/
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Hi all, i was using kamailio 4.2.1 located in 2 networks
> listen = tcp:MY_ADDR:5060 advertise MY_ADDR:5060
> listen = tls:MY_ADDR:5061 advertise PUBLIC_NAT_ADDR:5061
when the call made from the inside network to out side, running
`record_route()` resulted in 2 Record-Route headers added
(enable_double_rr=1)
Record-Route: PUBLIC_NAT_ADDR:5061;transport=tls;lr
> Record-Route: MY_ADDR;transport=tcp;lr
That was totally fine omitting the port in the first Record-Route when
using tcp (or udp) on the first realm, but when i start switching to tls,
it caused trouble
Record-Route: PUBLIC_NAT_ADDR:5061;transport=tls;lr
> Record-Route: MY_ADDR;transport=tls;lr
The client is then told to send ACK/BYE to `MY_ADDR;transport=tls` located
at `MY_ADDR:5061` as per rfc3263, then the call would failed.
I had another try with
`record_route_preset("PUBLIC_NAT_ADDR:5061;transport=tls",
"MY_ADDR:5060;transport=tls");`, it really did add what i want with
explicit 5060 port on RR, `ACK/BYE` travel on the correct path, but
`loose_route()` only consumes the local `Route` header (it should consume
2). So my assumption is to stick with `record_route()` function to make
`loose_route()` work properly.
I tried using another port on the local realm, e.g: 5062 and the port is
explicitly added to the Record-Route header `MY_ADDR:5062;transport=tls;lr`
So is `5060` couldn't be explicitly added to the inbound Record-Route, or i
just missed something?
Any help will be appreciated.
P/S: I also tried 4.4.7 and it still omit my 5060 port in the RR.
rgds,
Loi Dang Thanh
Phone : +84. 774.735.448
Email : loi.dangthanh(a)gmail.com
Hi!
Was looking on some way to compress SIP signalling between internal servers. But found out, there are no some pre-defined or recommended mechanism of doing this.
Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info.
What I googled is
SigComp
Compact Header form
As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented.
For Compact Header form - is there any way of using Kamailio to compress message this way?
Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime?
All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not.
To whom can be of assistance,
I’m am working towards enabling presence on my Kamailio proxy but have hit a bit of a brick wall. I’m seeing dialogues being created and persisted to the database, subscriptions are being handled and rows are being written to the active_watchers table but no PUBLISH is ever being received by the server to kickoff the sending of NOTIFY to the active watchers. Further, I’m never seeing a row in the watchers table though I don’t know that this isn’t expect behavior. I’ve attached my current config for review. Any help will be greatly appreciated!
Thank in advance!
Hello,
I am trying to implement the following network setup using Kamailio and RTPProxy, but was not able to find any recent documentation or blog posts with hints:
> local_net1 : local_net2
> 10.250.10.* : 10.250.11.*
> :
> (1) (2) :
> +-------------+ +--------------+ +--------------+
> ! !.11 .12 ! Proxy !.21 ! Debian Host !.22
> ! Starface !---------------! + Kamailio !<<--------------! + Linphone !.23
> ! ! ! + RTPProxy ! ! !
> +-------------+ +--------------+ +--------------+
> eth0 : eth1
> :
> :
>
As you can see, the proxy has two interfaces and its purpose is to forward traffic from the client's network to the Starface's network.
Has anyone experience to share or got any other hints where to start?
Thank you very much for your help :)
Kind regards,
Lauritz