Update: Disabling the topoh module on the proxy which produces the error
seems to stop the failure from manifesting. I'll try using topos_redis
instead, but should this be treated as a bug?
BR,
George
On Wed, 8 Jul 2020 at 12:37, George Diamantopoulos <georgediam(a)gmail.com>
wrote:
> Hello again,
>
> Indeed $mb seems to contain garbage:
>
> SCRIPT_MB: ACK <BC><EA><8F> SIP/2.0#015#012Via: SIP/2.0/UDP
> 172.30.154.189;TH=dcv;branch=z9hG4bK629b.6af9302cd78dc58dffe817e60124f4ed.0#015#012Route:
> <sip:RJ2U2c7mrFzQjgG5SSvyE8RVS9omgAA=@172.30.155.1
> ;lr;received=sip:2.2.2.2:32768
> ;ob;r2=on>,<sip:RJ2U2c7mrFzQjgG5SSvyE8RVS9omgAA=@3.3.3.3
> ;lr;received=sip:2.2.2.2:32768;ob;r2=on>#015#012Max-Forwards:
> 68#015#012From: "Anonymous" <sip:unknown@voip.domain.com>;tag=as4bc9e324#015#012To:
> <sip:voip-test-user-02@voip.domain.com>;tag=jw7z5s0zvc#015#012Call-ID:
> 0138c6370346d1dd7f1b47f604b01f92(a)voip.domain.com#015#012CSeq
> <http://0138c6370346d1dd7f1b47f604b01f92@voip.domain.com#015%23012CSeq>:
> 102 ACK#015#012Content-Length: 0#015#012TH: dch#015#012#015#012
>
> How can this be possible? Capturing traffic on wire shows the RURI I
> pasted in my original message and there are no script operations on the
> RURI before sanity_check() (message buffer above is printed just before
> sanity_check() is run in REQINIT).
>
> BR,
> George
>
> On Wed, 8 Jul 2020 at 11:18, George Diamantopoulos <georgediam(a)gmail.com>
> wrote:
>
>> I'll post the message buffer ASAP, but in the meantime I don't see how
>> config operations could affect the RURI. Here's everything that's happening
>> until the sanity check involved:
>>
>> request_route {
>>
>> if(is_method("KDMQ")) {
>> dmq_handle_message();
>> }
>>
>> # no connect for sending replies
>> set_reply_no_connect();
>>
>> if($ua =~ "friendly-scanner|sipcli|sipvicious|VaxSIPUserAgent") {
>> # silent drop for scanners - uncomment next line if want to reply
>> # sl_send_reply("200", "OK");
>> exit;
>> }
>>
>> if (!mf_process_maxfwd_header("10")) {
>> force_rport();
>> sl_send_reply("483","Too Many Hops");
>> exit;
>> }
>>
>> # OPTIONS and NOTIFYs directed to myself
>> if(is_method("OPTIONS|NOTIFY") && uri==myself && $rU==$null) {
>> force_rport();
>> sl_send_reply("200","Keepalive");
>> exit;
>> }
>>
>> # All keep-alive methods regardless of destination
>> if ( $hdr(Event) == "keep-alive") {
>> force_rport();
>> sl_send_reply("200","Keepalive");
>> exit;
>> }
>>
>> if(!sanity_check("17895", "7")) {
>> xlog("Malformed SIP request from $si:$sp\n");
>> exit;
>> }
>>
>> BR,
>> George
>>
>> On Wed, 8 Jul 2020 at 10:58, Daniel-Constantin Mierla <miconda(a)gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> check your config operations, because the R-URI seems to be the next
>>> string (without quotes): "<BC><EA><8F>"
>>>
>>> You can try to print $mb in such case to see the entire SIP message
>>> buffer.
>>>
>>> Cheers,
>>> Daniel
>>> On 08.07.20 09:48, George Diamantopoulos wrote:
>>>
>>> Hello Daniel,
>>>
>>> Thanks for the reply. Indeed there is, not sure how I managed to miss
>>> that. And it wasn't about the schema after all:
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - <core>
>>> [core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<BC><EA><8F>>
>>> (3)
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - <core>
>>> [core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<BC><EA><8F>>
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING:
>>> {1 <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>> [sanity.c:282]: check_ruri_scheme(): failed to parse request uri
>>> [<BC><EA><8F>]
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - <script>: Malformed
>>> SIP request from 172.30.154.189:5060
>>>
>>> Still, not sure what the problem is though...
>>>
>>> BR,
>>> George
>>>
>>> On Wed, 8 Jul 2020 at 09:30, Daniel-Constantin Mierla <miconda(a)gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> when the ruri scheme check fails, there should be another debug message
>>>> saying that. Have you pasted all log messages for the failure case?
>>>>
>>>> Cheers,
>>>> Daniel
>>>> On 07.07.20 22:23, George Diamantopoulos wrote:
>>>>
>>>> Sorry, I realised I copy pasted wrong log messages for Call 1. Here's
>>>> the relevant part showing success for call 1 in contrast with Call 2:
>>>>
>>>> grep 2a859fcc4e1c8f840191a81d7c16e76d kamailio.log | egrep
>>>> 'check_ruri_scheme|w_sanity_check' | grep ACK
>>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
>>>> {1 <null> 172.30.154.189 102 ACK
>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
>>>> {1 <null> 172.30.154.189 102 ACK
>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>> [sanity.c:297]: check_ruri_scheme(): check_ruri_scheme passed
>>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
>>>> {1 <null> 172.30.154.189 102 ACK
>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1
>>>>
>>>> On Tue, 7 Jul 2020 at 21:34, George Diamantopoulos <
>>>> georgediam(a)gmail.com> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I'm not 100% sure this is the only culprit in an issue I'm
>>>>> investigating, but superficially it appears that RURI scheme sanity module
>>>>> checks from the default config (flags 17895 in REQINIT) fail if the
>>>>> RURI in an ACK following a 487 includes parameters. Example from two calls
>>>>> from a kamailio instance acting as registrar/usrloc server, INVITE RURIs
>>>>> are after usrloc lookup:
>>>>>
>>>>> Call 1: INVITE sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
>>>>> Call 2: INVITE sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08
>>>>> SIP/2.0
>>>>>
>>>>> These INVITEs produce no complaints. Later, the same registrar
>>>>> produces ACKs to acknowledge 487 (thus, same transaction ACKs) responses
>>>>> from the next proxy in the path following a CANCEL:
>>>>>
>>>>> Call 1: ACK sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
>>>>> Call 2: ACK sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08
>>>>> SIP/2.0
>>>>>
>>>>> The next proxy (which produced/relayed the 487) processes the ACK for
>>>>> Call 1 successfully, but sanity_check at the proxy drops the request for
>>>>> Call 2 with:
>>>>>
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>>>> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>>>> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
>>>>>
>>>>> whereas Call 1 seems OK:
>>>>>
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>>> [sanity.c:305]: check_required_headers(): check_required_headers entered
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>>> [sanity.c:313]: check_required_headers(): check_required_headers passed
>>>>>
>>>>> Could this be a bug in sanity module? Is there anything one can do in
>>>>> config which could result in illegal ACKs being produced for hop-by-hop
>>>>> transactions? schema appears to be sip: in both cases...
>>>>>
>>>>> Thank you. Best regards,
>>>>> George
>>>>>
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>> --
>>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>> Funding: https://www.paypal.me/dcmierla
>>>>
>>>> --
>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Funding: https://www.paypal.me/dcmierla
>>>
>>>
Hello all,
I'm not 100% sure this is the only culprit in an issue I'm investigating,
but superficially it appears that RURI scheme sanity module checks from the
default config (flags 17895 in REQINIT) fail if the RURI in an ACK
following a 487 includes parameters. Example from two calls from a kamailio
instance acting as registrar/usrloc server, INVITE RURIs are after usrloc
lookup:
Call 1: INVITE sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
Call 2: INVITE sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0
These INVITEs produce no complaints. Later, the same registrar produces
ACKs to acknowledge 487 (thus, same transaction ACKs) responses from the
next proxy in the path following a CANCEL:
Call 1: ACK sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
Call 2: ACK sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0
The next proxy (which produced/relayed the 487) processes the ACK for Call
1 successfully, but sanity_check at the proxy drops the request for Call 2
with:
DEBUG: {1 <null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity [sanity.c:277]:
check_ruri_scheme(): check_ruri_scheme entered
DEBUG: {1 <null> 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
whereas Call 1 seems OK:
DEBUG: {1 <null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity [sanity.c:305]:
check_required_headers(): check_required_headers entered
DEBUG: {1 <null> 172.30.154.189 102 ACK
2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity [sanity.c:313]:
check_required_headers(): check_required_headers passed
Could this be a bug in sanity module? Is there anything one can do in
config which could result in illegal ACKs being produced for hop-by-hop
transactions? schema appears to be sip: in both cases...
Thank you. Best regards,
George
I have been using a sample code of PCSCF<https://github.com/kamailio/kamailio/blob/master/misc/examples/ims/pcscf/ro…>, where a function "pcscf_assert_identity" is used but it's not defined in module ims_registrar_pcscf documentation. Can you please explain its functionality. The same way other functions are not defined in the documentation.
pcscf_assert_called_identity
reginfo_handle_notify
pcscf_unregister
Regards
Hamid R. Hashmi
Hello there,
Kamailio is terminating with signal 11 and is generating a coredump file.
I opened the core file generated by it and it seems to be related to the
module http_async_client.
In the following link you can find the output of core dump backtrace full:
https://pastebin.com/rapPZy9N
Below is the http_async_client config that I have:
modparam("http_async_client", "workers", 2)
modparam("http_async_client", "connection_timeout", 500)
modparam("http_async_client", "hash_size", 2048)
modparam("http_async_client", "curl_verbose", 0)
modparam("http_async_client", "memory_manager", "shm")
If the information provided is not enough to troubleshoot this issue let me
know.
Many thanks
Best Regards
--
Cumprimentos
José Seabra
Hello
I would like to ask if someone already tried to build Kamailio for the
Embedded Distribution Buildroot. I tried it myself but it looks like
Kamailio is not that easy to cross compile.
Thanks
Benjamin
Hi all,
I've been assigned a task to investigate why hepic doesn't generate MOS
scores ever since we changed the kamailio interface MTU from 9001 -> 1500.
During my investigation, this is what I have found out so far:
- Putting MTU back to 9001 removes this condition where no MOS was
generated.
- I did a tcpdump of port 9063 which is the port used to send data to Hepic
capture server and saw it reports packets are fragmented:
3:48:55.895505 IP (tos 0x68, ttl 64, id 38049, offset 0, flags [+], proto
UDP (17), length 1500)
206.81.181.40.5060 > 10.225.88.239.9063: SIP
13:48:55.896451 IP (tos 0x68, ttl 64, id 38050, offset 0, flags [+], proto
UDP (17), length 1500)
206.81.181.40.5060 > 10.225.88.239.9063: SIP
- Hepic support also caused by using 1500 MTU on the interface.
- I tried using the following core parameters to see if they could remedy
this issue but didn't seem to work:
## MTU related core settings
udp4_raw=-1
udp4_raw_mtu=1500
I can't seem to find any parameters in the siptrace module that controls
fragmentation of the packets to Hepic.
Any suggestions on how else to troubleshoot this?
Thanks.
--
Andy Chen
Sr. Telephony Lead Engineer
achen@ <achen(a)thinkingphones.com>fuze.com
--
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
Hello.
I'd like to keep one registration per device in usrloc table, for other
cases I want to store and maintain one contact per AoR.
Does kamailio support it out of the box?
For second case save("location", "0x01"); working fine. But how about first
case? for example, if one of device located at home, and second located at
office. - there are two different network and NAT - how I can make both
devices ringing when INVITE is sent? If I do classic multiAor scenario - it
can lead to issues caused by multiple contacts in 200OK response for a
single device and devices are confusing sometimes.
So, what I did now:
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
fix_nated_register();
add_contact_alias();
}
[REGISTRAR] {
if (nat_uac_test(64)) {
if (!save("location", "0x04")) {
sl_reply_error();
}
} else {
if (!save("location")) {
sl_reply_error();
}
}
}
modparam("usrloc", "db_url", DBURL)
modparam("usrloc", "db_mode", 3)
modparam("usrloc", "use_domain", MULTIDOMAIN)
modparam("usrloc", "xavp_contact", "usrlocattrs")
modparam("usrloc", "desc_time_order", 1)
modparam("usrloc", "db_timer_clean", 1)
modparam("usrloc", "close_expired_tcp", 1)
modparam("usrloc", "db_insert_update", 1)
modparam("usrloc", "expires_type", 1)
modparam("usrloc", "matching_mode", 1)
modparam("registrar", "method_filtering", 1)
modparam("registrar", "max_expires", 3530)
modparam("registrar", "min_expires", 1800)
modparam("registrar", "received_avp", "$avp(s:rcv)")
modparam("registrar", "gruu_enabled", 0)
modparam("registrar", "use_path", 1)
modparam("registrar", "path_check_local", 1)
modparam("registrar", "path_mode", 1)
modparam("path", "use_received", 1)
How do u think, maybe modparam("registrar", "append_branches", 0) will make
some help?
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
Hi!
I am new to kamailio so please forgive me if I write some errors.
I am configuring some kamailio instances in different environments to
handle big traffic and I have a problem with usrloc + db + nathelper.
What have I done:
1. Configured a kamailio instance to handle sip registers with usrloc to
database with database mode 2 (memory + db), disabled nathelper pings. This
is ok and performs well;
2. Configured a kamailio instance to handle nathelper ping. Same usrloc +
db + nathelper config from 1 except that I use db mode 3 (only db) and that
I enabled natping_interval .
My problem is that it seems that the second kamailio instance does not send
pings. The second one connects correctly to db (if I lookup from kamcmd a
user registered from the first kamailio I can find it) but it seems that
does not read all locations.
Can you help me?
Many many thanks
Angelo
Hello guys,
I have rtpengine running on a box with ips like this:
external: 172.10.0.10 (advertise 10.10.10.1)
internal: 172.10.0.11
Both Ips are on the same network.
When i do rtpengine_manage i set "direction=external direction=internal",
and the SDP offer is correct.
The problem I'm having is that when rtp tried to send to the internal
network, the OS (i believe) selects the first interface (external) ip
172.10.0.10 to reach the internal network.
This I suppose is not a great deal, but I would like to separate them and
only use the internal for internal proxying.
Help is appreciated!
Thanks!
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337