[SR-Users] How to retrieve local socket that will be used to send a message from the branch route
Hello list, Hope you are all doing well! I am trying to figure out a way to retrieve the local socket the t_relay() has decided to use in a mhomed=1 env. Is there a way to do that? I couldn't find any variable other than the $snd ones that maybe have this info, but I am not using onsend_route anyway. I am after this value because this is what I can use to figure out if I need to engage RTPEngine with parameters "external, internal", "external, external", "internal, external" or "internal, internal". In my case, my server is in between two networks, and calls can traverse or can be routed back to the same interface depending on what was decide by the LCR module. Signalling is fine, but engaging the RTPEngine must be done with the correct parameters to get the correct IPs in the SDP, other else I get one way audio in the call. Any help is much appreciated! Thank you! Kind regards, Patrick Wakano ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Re-use TCP connections on different transactions
Hello,
I added to the config file:
tcp_no_connect=yes
And with that param, the same test results in a different behavior, but
still not working:
"message":" DEBUG: {1 12583750 BYE RVXZVMHKop}
[core\/msg_translator.c:161]: check_via_address(): (198.1.54.228,
198.1.54.228, 0)"}
"message":" ERROR: {1 12583750 BYE RVXZVMHKop} tm
[..\/..\/core\/forward.h:292]: msg_send_buffer(): tcp_send failed"}
"message":" DEBUG: {1 12583750 BYE RVXZVMHKop} tm [t_fwd.c:1537]:
t_send_branch(): send to 35.191.9.20:56470 (3) failed"}
"message":" WARNING: {1 12583750 BYE RVXZVMHKop} tm [t_fwd.c:1557]:
t_send_branch(): sending request on branch 0 failed"}
"message":" DEBUG: {1 12583750 BYE RVXZVMHKop} tm [t_funcs.c:336]:
t_relay_to(): t_forward_nonack returned error -1 (-477)"}
"message":" DEBUG: {1 12583750 BYE RVXZVMHKop} tm [t_funcs.c:354]:
t_relay_to(): -477 error reply generation delayed "}
Although, netstats says the connection is active:
root@sbc-gslb-test-1:~# netstat -putan | grep 56470
tcp0 0 10.116.15.237:443 35.191.9.20:56470
ESTABLISHED 3920/kamailio
root@sbc-gslb-test-1:~#
Anyone?
On Wed, Nov 20, 2019 at 9:26 AM Joel Serrano wrote:
> Bumping this thread up!
>
> I did some more tests trying to narrow down the problem and this is what I
> found...:
>
> On the INVITE, I add the TCP connection information I want to save (for
> later reuse). Snippets:
>
> ...(found this in the misc/examples/pkg/sip-router-oob.cfg, but I haven't
> noticed any changes to the headers or anything)...
>
> # Force response to received connection
> force_rport();
> if (proto==TCP || proto == TLS) {
> force_tcp_alias();
> xlog("L_NOTICE", "force_tcp_alias() done");
> }
> ...
>
> ...(I also have this)...
>
> if (is_first_hop()) {
> xlog("L_NOTICE", "Adding LB info to contact - M=$rm ID=$ci\n");
> add_contact_alias("$tcp(c_si)", "$tcp(c_sp)", "tls");
> }
> ...
>
> Which effectively makes the contact look like:
>
> ;alias=35.191.9.21~50705~3;transport=tls>
>
> ..180..
> ..200 OK..
> ..ACK..
>
> Then, callee ends the call (so the BYE comes from callee to caller), when
> I run handle_ruri_alias() I see in the logs that the everything is handled
> correctly:
>
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} nathelper
> [nathelper.c:1144]: handle_ruri_alias(): setting dst_uri to
> "}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} nathelper
> [nathelper.c:1166]: handle_ruri_alias(): rewriting r-uri to
> "}
>
> But then, Kamalio won't reuse the existing TCP connection and tries to
> create a new one:
>
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:1328]:
> t_newtran(): msg (0x7f85883b14c8) id=27\/1974 global id=25\/1974 T
> start=0x"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:497]:
> t_lookup_request(): start searching: hash=63128, isACK=0"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:455]:
> matching_3261(): RFC3261 transaction matching failed - via branch
> [z9hG4bK896f.dc04734743b0f0997f39c4fff07c0fbb.0]"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:675]:
> t_lookup_request(): no transaction found"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_hooks.c:336]:
> run_reqin_callbacks_internal(): trans=0x7f8583b17208, callback type 1, id 0
> entered"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
> [core\/crypto\/md5utils.c:67]: MD5StringArray(): MD5 calculated:
> 71c229aff3c0b4f6e9e77c4990b74e5e"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} siputils [checks.c:123]:
> has_totag(): totag found"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} rr [loose.c:1095]:
> check_route_param(): route params checking against
> [;r2=on;lr=on;ftag=tAsjXhyIX;did=7d1.e6a2;nat=yes] (orig:
> [r2=on;lr=on;ftag=tAsjXhyIX;did=7d1.e6a2;nat=yes])"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} rr [loose.c:1101]:
> check_route_param(): params are
> <;r2=on;lr=on;ftag=tAsjXhyIX;did=7d1.e6a2;nat=yes>"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB} siputils [checks.c:123]:
> has_totag(): totag found"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
> [core\/msg_translator.c:161]: check_via_address(): (198.1.54.228,
> 198.1.54.228, 0)"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
> [core\/tcp_main.c:2060]: tcp_send(): no open tcp connection found, opening
> new one"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
> [core\/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection:
> 35.191.9.21"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
> [core\/tcp_main.c:1242]: tcpconn_new(): on port 50705, type 3"}
> "message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
> [core\/tcp_main.c:1561]: tcpconn_add(): hashes: 337:3545:0, 3"}
>
> Am I still missing anything?
>
> Is this a bug and I should open a GH issue?
>
> Any suggestions/comments/ideas are very welcome!
>
> Thanks,
> Joel.
>
>
> On Fri, Nov 1, 2019 at 11:46 AM Joel Serrano wrote:
>
>> Hi Yuriy,
>>
>> Thanks for
Re: [SR-Users] Re-use TCP connections on different transactions
Bumping this thread up!
I did some more tests trying to narrow down the problem and this is what I
found...:
On the INVITE, I add the TCP connection information I want to save (for
later reuse). Snippets:
...(found this in the misc/examples/pkg/sip-router-oob.cfg, but I haven't
noticed any changes to the headers or anything)...
# Force response to received connection
force_rport();
if (proto==TCP || proto == TLS) {
force_tcp_alias();
xlog("L_NOTICE", "force_tcp_alias() done");
}
...
...(I also have this)...
if (is_first_hop()) {
xlog("L_NOTICE", "Adding LB info to contact - M=$rm ID=$ci\n");
add_contact_alias("$tcp(c_si)", "$tcp(c_sp)", "tls");
}
...
Which effectively makes the contact look like:
..180..
..200 OK..
..ACK..
Then, callee ends the call (so the BYE comes from callee to caller), when I
run handle_ruri_alias() I see in the logs that the everything is handled
correctly:
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} nathelper
[nathelper.c:1144]: handle_ruri_alias(): setting dst_uri to
"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} nathelper
[nathelper.c:1166]: handle_ruri_alias(): rewriting r-uri to
"}
But then, Kamalio won't reuse the existing TCP connection and tries to
create a new one:
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:1328]:
t_newtran(): msg (0x7f85883b14c8) id=27\/1974 global id=25\/1974 T
start=0x"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:497]:
t_lookup_request(): start searching: hash=63128, isACK=0"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:455]:
matching_3261(): RFC3261 transaction matching failed - via branch
[z9hG4bK896f.dc04734743b0f0997f39c4fff07c0fbb.0]"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_lookup.c:675]:
t_lookup_request(): no transaction found"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} tm [t_hooks.c:336]:
run_reqin_callbacks_internal(): trans=0x7f8583b17208, callback type 1, id 0
entered"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
[core\/crypto\/md5utils.c:67]: MD5StringArray(): MD5 calculated:
71c229aff3c0b4f6e9e77c4990b74e5e"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} siputils [checks.c:123]:
has_totag(): totag found"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} rr [loose.c:1095]:
check_route_param(): route params checking against
[;r2=on;lr=on;ftag=tAsjXhyIX;did=7d1.e6a2;nat=yes] (orig:
[r2=on;lr=on;ftag=tAsjXhyIX;did=7d1.e6a2;nat=yes])"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} rr [loose.c:1101]:
check_route_param(): params are
<;r2=on;lr=on;ftag=tAsjXhyIX;did=7d1.e6a2;nat=yes>"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB} siputils [checks.c:123]:
has_totag(): totag found"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
[core\/msg_translator.c:161]: check_via_address(): (198.1.54.228,
198.1.54.228, 0)"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
[core\/tcp_main.c:2060]: tcp_send(): no open tcp connection found, opening
new one"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
[core\/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection:
35.191.9.21"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
[core\/tcp_main.c:1242]: tcpconn_new(): on port 50705, type 3"}
"message":" DEBUG: {1 12543376 BYE QQy-qagkcB}
[core\/tcp_main.c:1561]: tcpconn_add(): hashes: 337:3545:0, 3"}
Am I still missing anything?
Is this a bug and I should open a GH issue?
Any suggestions/comments/ideas are very welcome!
Thanks,
Joel.
On Fri, Nov 1, 2019 at 11:46 AM Joel Serrano wrote:
> Hi Yuriy,
>
> Thanks for your suggestion, I've tried tcp_accept_aliases=yes in config
> and I added force_tcp_alias() in the request route, but I haven't seen any
> changes.
>
> All the VIA headers look exactly the same, and I still get this in the
> logs:
>
> "message":" DEBUG: {1 11762916 BYE d2T9-YOxYk}
> [core\/tcp_main.c:2060]: tcp_send(): no open tcp connection found, opening
> new one"}
>
>
> The docs say:
>
> "force_tcp_alias(port)
>
> adds a tcp port alias for the current connection (if tcp). Useful if you
> want to send all the trafic to port_alias through the same connection this
> request came from [it could help for firewall or nat traversal]. With no
> parameters adds the port from the message via as the alias. When the
> “aliased” connection is closed (e.g. it's idle for too much time), all the
> port aliases are removed."
>
> I tried also using force_tcp_alias(5353) as an example, just to see if I
> find "5353" added to any headers, but no luck, it wasn't added anywhere..
>
>
> Any other suggestions? Am I missing something?
>
>
> Thanks,
>
> Joel.
>
> On Thu, Oct 31, 2019 at 10:53 PM Yuriy Gorlichenko
> wrote:
>
>> You have to use
>> tcp_accept_aliases=yes
>> But this is not enough as this param will be triggered by function
>> force_tcp_alias() you need to use in the route for request ( for example
>> record_route or subroutes)
>> It will add param paramname= (I Don't remember
Re: [SR-Users] Beginner Help: Relay vs Forward
Hello, adding few notes ... Like Alex said in another response, the get_out_socket() error is when Kamailio doesn't find a IP routing path between its listen socket and target address (sip:192.168.86.110:5061). Then, to your initial message: t_relay() does not create/track dialogs, only SIP transactions (request-to-final-response). If you just need to route SIP traffic without re-routing, accounting, etc... then forward() (stateless mode) is ok. If you forward REGISTER via intermediary proxy, then you have to do Path handling (see path module). Then, just for information, port 5061 is typically associated with TLS, however there is no restriction to use it for udp. Cheers, Daniel On 20.11.19 13:55, Michael Iedema wrote: > I’ve switched from a Dockerized Kamailio instance to a native installation. > Here is my most recent trace when trying to forward traffic: > > 0(70677) INFO:
Re: [SR-Users] Beginner Help: Relay vs Forward
Hi Michael,
First, the "no corresponding socket" issue is the result of a
determination by Kamailio that it has no outgoing listener (the
combination of transport protocol, IP address and port) interface that
can reach the destination network of the next hop.
The way that Kamailio makes this determination is influenced by this
setting -- not sure if you have it on.
https://www.kamailio.org/wiki/cookbooks/5.3.x/core#mhomed
Keep in mind that the entire triplet - (transport, address, port) -
matters.
Second, I noticed your comment
# ORIGINATOR sent us something
and considered this condition:
if ( $(ct{nameaddr.uri}{uri.port}) == PORT_ORIGINATOR )
it's probably worth keeping in mind that Contact is a fairly cosmetic
value and can be set to just about anything, and most importantly, can
be spoofed. So, if you are using this to determine whether a given
component of your infrastructure sent you something, you might want to
operate on the real source address and port of the SIP message instead:
https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#si_-_source_ip_address
https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#sp_-_source_port
Third: this is by way of philosophical commentary only, and under the
aegis of "helping newbies" :-) -- others may disagree, and are free to
do so.
Early on in my experience with Kamailio (then OpenSER), I was
responsible for some rather unfortunately baroque platform architecture
designs involving many specialised Kamailio proxies performing esoteric
functions. This was based on a consistent tendency to underestimate how
much traffic Kamailio can actually handle and how much work it can do.
I've designed platforms with a dedicated registrar, dedicated business
logic / call processing logic, and a carrier-facing element, separated
into multiple instances, all deployed with redundant mates, etc.
Some of them I still have to support, and they're a nightmare, and most
importantly of all, from a technical point of view they're completely
unnecessary. In hindsight, it was all a mistake, and can easily be done
with a single Kamailio element 99% of the time (as long as the config is
manageable in its organisation), and I regret it all deeply. Cloud
orchestration / deployment tooling that did not exist in those days
might have made it a little easier, but also in many respects more
complicated due to all the service discovery required.
I was thinking about this in the context of:
> Originator:
> - reachable on port 5060
> - originates all traffic to the services
>
> Service A:
> - reachable on port 5061
> - handles REGISTER
>
> Service B:
> - reachable on port 5062
> - handles INVITE
>
> Service C:
> - reachable on port 5063
> - handles MESSAGE
I could be wrong, and you might have very credible reasons for such a
design, but at first glance it reminds me of some massively
overcomplicated things I built when I first got started with Kamailio.
:-) As I said, they were all based on a perception that this or that
element can only handle so much, but it turns out one element can handle
it all - and 20x more.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Beginner Help: Relay vs Forward
Hi Michael,
the mostly used model AFAIK is dispatcher cos you can define groups (also
with only one member). That's more flexible if you scale up the backend
services.
Also an docker newbie the macvlan driver gives you native ip access within
the container.
The socket error message shows up an socket in Kamailio config like listen
directive that is not available but the config generates an request for
that.
can't fwd to af 2, proto 1 (no corresponding listening socket)
Did you switch protocols from udp to tcp or vice versa? Then you need also
udp AND tcp enabled in Kamailio.
Cheers
Karsten Horsmann
Michael Iedema schrieb am Di., 19. Nov. 2019, 10:30:
> Hi all,
>
> I am trying to place Kamailio between several SIP services which are
> differentiated by port and by the type of message they handle. To be
> concrete, here are the services:
>
> Originator:
> - reachable on port 5060
> - originates all traffic to the services
>
> Service A:
> - reachable on port 5061
> - handles REGISTER
>
> Service B:
> - reachable on port 5062
> - handles INVITE
>
> Service C:
> - reachable on port 5063
> - handles MESSAGE
>
> The services, originator and Kamailio instance may all be run on the same
> IP or may be split onto different addresses. Previously, the originator
> needed to know the address and port of each service. Now I want to make
> Kamailio responsible for that task so it can be done more intelligently.
>
> To start though I simply want to get traffic flowing between the services
> and this is where I’m struggling to climb the learning curve. In my test
> setup the originator and all services are on the same IP with only Kamailio
> running on a different IP.
>
> Address 1Address 2
>
> Originator <--> Kamailio:6060
>|
>|
> Service A <---> |
> Service B <---> |
> Service C <---> |
>
>
> My first attempt at the logic looks like this:
>
> # HOST DEFINITIONS
> #!substdef "/HOST_ORIGINATOR/192.168.86.110/"
> #!substdef "/HOST_REGISTER/192.168.86.110/“
> #!substdef "/HOST_INVITE/192.168.86.110/"
> #!substdef "/HOST_MESSAGE/192.168.86.110/"
>
> # PORT DEFINITIONS
> #!substdef “/PORT_ORIGINATOR/5060/"
> #!substdef "/PORT_REGISTER/5061/“
> #!substdef "/PORT_INVITE/5062/"
> #!substdef "/PORT_MESSAGE/5063/"
>
> # ROUTE LOGIC
> route {
>
> # ORIGINATOR sent us something
> if ( $(ct{nameaddr.uri}{uri.port}) == HOST_ORIGINATOR ) {
>
> xlog("L_INFO", "ORIGINATOR: sent $rm\n”);
>
> if (is_method("REGISTER")) {
> $du = "sip: HOST_REGISTER:PORT_REGISTER";
> xlog("L_INFO", "ORIGINATOR -> REGISTER: Destination URI is now
> $du\n");
> t_relay();
> exit;
> }
> }
> …
>
> END SNIPPET
>
>
> My very newbie questions are:
> - Am I even on the right track here? I understand that t_relay()
> establishes a stateful dialog handler between the originator and register
> services.
> - Can I accomplish this bi-directional path statelessly with forward()?
> - Do I need to add logic to handle the messages from the REGISTER service
> back to ORIGINATOR?
>
> This config currently fails because of "no corresponding socket found”
> when the relay triggers. I believe this is because I’m running the Kamailio
> instance in a Docker container so my first step today is to set up a native
> install.
>
> I also looked at the dispatcher module which seems very close to what I
> want to do. Maybe that’s a more natural way to go?
>
>
>
> Anyway, apologies for the lengthy explanation. I hope it is at least clear
> what I intend to do. I will gladly research and do trial and error to solve
> this but need to know I’m going down roughly the right path. I’m not sure
> what I should even be googling even of the time :-)
>
>
> Thanks as always for your time and the great software!
>
> Regards,
> -Michael
>
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Beginner Help: Relay vs Forward
I’ve switched from a Dockerized Kamailio instance to a native installation. Here is my most recent trace when trying to forward traffic: 0(70677) INFO:
Re: [SR-Users] kamailio Dispatcher error
hi
thank you so much for this information
my issue is resolved
On Wed, Nov 20, 2019 at 3:51 PM Markus Bönke wrote:
> … and it’s now an xavp, to log contents you can use something like:
>
> xlog("L_INFO","Socket: {$xavp(AVP_SOCK)}\n");
> xlog("L_INFO","Destination: {$xavp(AVP_DST)=>sock}\n");
> xlog("L_INFO","Number of destinations: {$avp(AVP_CNT)}\n");
> xlog("L_INFO","All destinations: {$(avp(AVP_DST)[*])}\n");
> xlog("L_INFO","All attributes: {$(avp(AVP_ATTRS)[*])}\n");
>
> Am 20.11.2019 um 11:12 schrieb Markus Bönke :
>
> If you are using version 5.2+ you need to put the name of the avp, not
> $avp... like
>
> ...
> modparam("dispatcher", "xavp_dst", "AVP_DST")
> modparam("dispatcher", "xavp_dst_mode", 0)
> modparam("dispatcher", "xavp_ctx", "AVP_CTX")
> …
>
> Best regards,
>
> Markus
>
> Am 20.11.2019 um 11:04 schrieb Karsten Horsmann :
>
> Hi Gaurav,
>
> check your config file Syntax with kamailio -DD -c -f
> /etc/kamailio/kamailio.cfg
>
> That should show you what's wrong.
>
> And your Kamailio version is needed for help.
>
> The dispatcher avps changed during some 5.x versions. Take a look at the
> dispatcher module documentation for your specific version.
>
> Kind regards
> Karsten Horsmann
>
>
> Gaurav Bmotra schrieb am Mi., 20. Nov. 2019,
> 10:57:
>
>> hi
>> i want to use dispatcher Module and following is the config..
>>
>> ---
>> loadmodule "dispatcher.so"
>> --
>> modparam("dispatcher", "db_url", "
>> mysql://kamailio:kamailiorw@localhost/kamailio")
>> 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", "ds_hash_size", 2)
>> --
>>
>>
>> but when i hit $ kamailio
>> out put:
>> ERROR: bad config file (4 errors)
>> --
>> logs :
>>
>> kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server
>>Loaded: loaded (/lib/systemd/system/kamailio.service; enabled; vendor
>> preset: enabled)
>>Active: failed (Result: exit-code) since Wed 2019-11-20 15:16:34 IST;
>> 16s ago
>> Process: 25747 ExecStart=/usr/sbin/kamailio -P
>> /var/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u
>> $USER -g $GROUP (code=exited, status=255/EXCEPTION)
>>
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service:
>> Service RestartSec=100ms expired, scheduling restart.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service:
>> Scheduled restart job, restart counter is at 5.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Stopped Kamailio
>> (OpenSER) - the Open Source SIP Server.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Start
>> request repeated too quickly.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service:
>> Failed with result 'exit-code'.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Failed to start
>> Kamailio (OpenSER) - the Open Source SIP Server.
>> -
>>
>> plz help me
>>
>>
>>
>> --
>>
>>
>>
>>
>> Thank you
>>
>>
>>
>> *Regards:*
>> Gaurav Kumar
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
--
*Regards:*
Gaurav Kumar
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dynamic routing and REGISTER
Hi Igor, I would then more test dmq and dmq_usrloc modules. Therefore you can hold the register state on multiple Kamailio at the same time. https://kamailio.org/docs/modules/devel/modules/dmq_usrloc.html Cheers Karsten Igor Olhovskiy schrieb am Di., 19. Nov. 2019, 15:34: > Actually same as dynamic routing of calls, but have same time-based > routing in a case of internal servers set. > Like if we have planned maintenance and use time-based rules upfront. > And to have sort of strip/add functions in one place. > > Regards, Igor > 19 нояб. 2019 г., 15:05 +0100, Alex Balashov , > писал: > > But what business need drives the desire for “complex scenarios” with > registration routing? > > — > Sent from mobile, with due apologies for brevity and errors. > > On Nov 19, 2019, at 9:01 AM, Igor Olhovskiy > wrote: > > > It’s more proof-of-concept, than other. > Like what else ways I have built-in to get complex scenarios. > > Regards, Igor > 19 нояб. 2019 г., 14:52 +0100, Alex Balashov , > писал: > > Well, what is the nature of the dynamic routing you seek to accomplish? I > cannot imagine dynamic distribution of registrations being very complex, or > informed by the kinds of LCR-type weights and metrics that drive the need > for drouting and friends... > > — > Sent from mobile, with due apologies for brevity and errors. > > On Nov 19, 2019, at 8:35 AM, Igor Olhovskiy > wrote: > > > Hi! > > I’m trying to get `drouting` module working for REGISTER. But seems it’s > not passing one of internal checks, cause in REGISTER R-URI does not > contains username and I’m getting errors > > drouting [drouting.c:567]: build_ruri(): stripping 0 makes username <> null > drouting [drouting.c:970]: do_routing(): failed to build ruri > > So, as I got, this module is mainly for calls (means INVITE) routing, > rather than to use it like one more dispatcher, or it’s also a way to > handle this part here? > > Thanks, Igor > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio Dispatcher error
… and it’s now an xavp, to log contents you can use something like:
xlog("L_INFO","Socket: {$xavp(AVP_SOCK)}\n");
xlog("L_INFO","Destination: {$xavp(AVP_DST)=>sock}\n");
xlog("L_INFO","Number of destinations: {$avp(AVP_CNT)}\n");
xlog("L_INFO","All destinations: {$(avp(AVP_DST)[*])}\n");
xlog("L_INFO","All attributes: {$(avp(AVP_ATTRS)[*])}\n");
> Am 20.11.2019 um 11:12 schrieb Markus Bönke :
>
> If you are using version 5.2+ you need to put the name of the avp, not
> $avp... like
>
> ...
> modparam("dispatcher", "xavp_dst", "AVP_DST")
> modparam("dispatcher", "xavp_dst_mode", 0)
> modparam("dispatcher", "xavp_ctx", "AVP_CTX")
> …
>
> Best regards,
>
> Markus
>
>> Am 20.11.2019 um 11:04 schrieb Karsten Horsmann > >:
>>
>> Hi Gaurav,
>>
>> check your config file Syntax with kamailio -DD -c -f
>> /etc/kamailio/kamailio.cfg
>>
>> That should show you what's wrong.
>>
>> And your Kamailio version is needed for help.
>>
>> The dispatcher avps changed during some 5.x versions. Take a look at the
>> dispatcher module documentation for your specific version.
>>
>> Kind regards
>> Karsten Horsmann
>>
>>
>> Gaurav Bmotra > > schrieb am Mi., 20. Nov. 2019, 10:57:
>> hi
>> i want to use dispatcher Module and following is the config..
>>
>> ---
>> loadmodule "dispatcher.so"
>> --
>> modparam("dispatcher", "db_url",
>> "mysql://kamailio:kamailiorw@localhost/kamailio
>> ")
>> 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", "ds_hash_size", 2)
>> --
>>
>>
>> but when i hit $ kamailio
>> out put:
>> ERROR: bad config file (4 errors)
>> --
>> logs :
>>
>> kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server
>>Loaded: loaded (/lib/systemd/system/kamailio.service; enabled; vendor
>> preset: enabled)
>>Active: failed (Result: exit-code) since Wed 2019-11-20 15:16:34 IST; 16s
>> ago
>> Process: 25747 ExecStart=/usr/sbin/kamailio -P
>> /var/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u
>> $USER -g $GROUP (code=exited, status=255/EXCEPTION)
>>
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Service
>> RestartSec=100ms expired, scheduling restart.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service:
>> Scheduled restart job, restart counter is at 5.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Stopped Kamailio (OpenSER)
>> - the Open Source SIP Server.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Start
>> request repeated too quickly.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Failed
>> with result 'exit-code'.
>> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Failed to start Kamailio
>> (OpenSER) - the Open Source SIP Server.
>> -
>>
>> plz help me
>>
>>
>>
>> --
>>
>>
>>
>>
>> Thank you
>>
>>
>>
>> Regards:
>> Gaurav Kumar
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio Dispatcher error
If you are using version 5.2+ you need to put the name of the avp, not $avp...
like
...
modparam("dispatcher", "xavp_dst", "AVP_DST")
modparam("dispatcher", "xavp_dst_mode", 0)
modparam("dispatcher", "xavp_ctx", "AVP_CTX")
…
Best regards,
Markus
> Am 20.11.2019 um 11:04 schrieb Karsten Horsmann :
>
> Hi Gaurav,
>
> check your config file Syntax with kamailio -DD -c -f
> /etc/kamailio/kamailio.cfg
>
> That should show you what's wrong.
>
> And your Kamailio version is needed for help.
>
> The dispatcher avps changed during some 5.x versions. Take a look at the
> dispatcher module documentation for your specific version.
>
> Kind regards
> Karsten Horsmann
>
>
> Gaurav Bmotra > schrieb am Mi., 20. Nov. 2019, 10:57:
> hi
> i want to use dispatcher Module and following is the config..
>
> ---
> loadmodule "dispatcher.so"
> --
> modparam("dispatcher", "db_url",
> "mysql://kamailio:kamailiorw@localhost/kamailio")
> 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", "ds_hash_size", 2)
> --
>
>
> but when i hit $ kamailio
> out put:
> ERROR: bad config file (4 errors)
> --
> logs :
>
> kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server
>Loaded: loaded (/lib/systemd/system/kamailio.service; enabled; vendor
> preset: enabled)
>Active: failed (Result: exit-code) since Wed 2019-11-20 15:16:34 IST; 16s
> ago
> Process: 25747 ExecStart=/usr/sbin/kamailio -P
> /var/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u
> $USER -g $GROUP (code=exited, status=255/EXCEPTION)
>
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Service
> RestartSec=100ms expired, scheduling restart.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Scheduled
> restart job, restart counter is at 5.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Stopped Kamailio (OpenSER)
> - the Open Source SIP Server.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Start
> request repeated too quickly.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Failed
> with result 'exit-code'.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Failed to start Kamailio
> (OpenSER) - the Open Source SIP Server.
> -
>
> plz help me
>
>
>
> --
>
>
>
>
> Thank you
>
>
>
> Regards:
> Gaurav Kumar
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio Dispatcher error
hi Johansson thank you for reply i got this in logs kamailio-c ... 0(26418) ERROR: [core/modparam.c:140]: set_mod_param_regex(): parameter of type <1> not found in module 0(26418) CRITICAL: [core/cfg.y:3510]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 304, column 50: Can't set module parameter 0(26418) ERROR: [core/modparam.c:140]: set_mod_param_regex(): parameter of type <1> not found in module 0(26418) CRITICAL: [core/cfg.y:3510]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 305, column 50: Can't set module parameter 0(26418) ERROR: [core/modparam.c:140]: set_mod_param_regex(): parameter of type <1> not found in module 0(26418) CRITICAL: [core/cfg.y:3510]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 306, column 50: Can't set module parameter 0(26418) ERROR: [core/modparam.c:140]: set_mod_param_regex(): parameter of type <1> not found in module 0(26418) CRITICAL: [core/cfg.y:3510]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 307, column 52: Can't set module parameter ERROR: bad config file (4 errors) 0(26418) INFO: [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized On Wed, Nov 20, 2019 at 3:33 PM Olle E. Johansson wrote: > > > On 20 Nov 2019, at 10:55, Gaurav Bmotra > wrote: > > ERROR: bad config file (4 errors) > > > Check the syslog for details on these four errors or start kamailio in the > foreground with "kamailio -c” to see them. > > /O > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- *Regards:* Gaurav Kumar ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio Dispatcher error
Hi Gaurav,
check your config file Syntax with kamailio -DD -c -f
/etc/kamailio/kamailio.cfg
That should show you what's wrong.
And your Kamailio version is needed for help.
The dispatcher avps changed during some 5.x versions. Take a look at the
dispatcher module documentation for your specific version.
Kind regards
Karsten Horsmann
Gaurav Bmotra schrieb am Mi., 20. Nov. 2019,
10:57:
> hi
> i want to use dispatcher Module and following is the config..
>
> ---
> loadmodule "dispatcher.so"
> --
> modparam("dispatcher", "db_url", "mysql://kamailio:kamailiorw@localhost
> /kamailio")
> 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", "ds_hash_size", 2)
> --
>
>
> but when i hit $ kamailio
> out put:
> ERROR: bad config file (4 errors)
> --
> logs :
>
> kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server
>Loaded: loaded (/lib/systemd/system/kamailio.service; enabled; vendor
> preset: enabled)
>Active: failed (Result: exit-code) since Wed 2019-11-20 15:16:34 IST;
> 16s ago
> Process: 25747 ExecStart=/usr/sbin/kamailio -P
> /var/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u
> $USER -g $GROUP (code=exited, status=255/EXCEPTION)
>
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service:
> Service RestartSec=100ms expired, scheduling restart.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service:
> Scheduled restart job, restart counter is at 5.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Stopped Kamailio
> (OpenSER) - the Open Source SIP Server.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Start
> request repeated too quickly.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Failed
> with result 'exit-code'.
> Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Failed to start Kamailio
> (OpenSER) - the Open Source SIP Server.
> -
>
> plz help me
>
>
>
> --
>
>
>
>
> Thank you
>
>
>
> *Regards:*
> Gaurav Kumar
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio Dispatcher error
> On 20 Nov 2019, at 10:55, Gaurav Bmotra wrote: > > ERROR: bad config file (4 errors) Check the syslog for details on these four errors or start kamailio in the foreground with "kamailio -c” to see them. /O___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] kamailio Dispatcher error
hi
i want to use dispatcher Module and following is the config..
---
loadmodule "dispatcher.so"
--
modparam("dispatcher", "db_url", "mysql://kamailio:kamailiorw@localhost
/kamailio")
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", "ds_hash_size", 2)
--
but when i hit $ kamailio
out put:
ERROR: bad config file (4 errors)
--
logs :
kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server
Loaded: loaded (/lib/systemd/system/kamailio.service; enabled; vendor
preset: enabled)
Active: failed (Result: exit-code) since Wed 2019-11-20 15:16:34 IST;
16s ago
Process: 25747 ExecStart=/usr/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u
$USER -g $GROUP (code=exited, status=255/EXCEPTION)
Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Service
RestartSec=100ms expired, scheduling restart.
Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service:
Scheduled restart job, restart counter is at 5.
Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Stopped Kamailio
(OpenSER) - the Open Source SIP Server.
Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Start
request repeated too quickly.
Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: kamailio.service: Failed
with result 'exit-code'.
Nov 20 15:16:34 gaurav-Latitude-E7240 systemd[1]: Failed to start Kamailio
(OpenSER) - the Open Source SIP Server.
-
plz help me
--
Thank you
*Regards:*
Gaurav Kumar
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
