[SR-Users] topos with mask_callid

[Marrold via sr-users]

Hi all,

I am using Kamailio 5.8.1 on a Debian 12 machine with topos and topoh
hiding the topology.

I have observed with modparam("topos", "mask_callid", 1), in-dialog
requests are relayed with the incorrect caller-id.

In the scenario, A calls B. The call is set up and the call-id for the
B-Leg is successfully masked. Then, when A sends a BYE, the BYE is
incorrectly relayed to B with the call-id of the A leg, and B replies with
a 481

If I disable masking the call-id, or disable topos/topoh entirely,
everything looks and works as it should. I have tested with 5.7.4 and the
behaviour is the same.

Does anyone have any ideas for where I should start looking?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Missing newline in dbtext tables causes crash and core dump

[Marrold via sr-users]

Hi all,

I am using Kamailio 5.7.4 on a Debian 12 machine. I used ansible to
template some files, and a newline was omitted at the end of the uacreg
table due to a templating issue.

This caused kamailio to crash on start up, with the error:

20(27) CRITICAL:  [core/pass_fd.c:281]: receive_fd(): EOF on 24

Even with debug enabled it still wasn't clear the issue was caused by the
uac module. I had to do a gdb backtrace to figure it out.

Whilst the mistake was on my part, I wondered if this should be handled
more cleanly?

Cheers
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Using uac_replace_to when forwarding call to another endpoint

[Marrold via sr-users]

After digging through old mailing posts I've been able to resolve this by
applying the changes in the BRANCH route. This fixes the corruption,
although the logs still show a warning for applying it twice.

Cheers

On Thu, 7 Mar 2024 at 09:23, Benoit Panizzon  wrote:

> Hi Matthew
>
> > However in my scenario I wish to first try one endpoint and then if it
> gets
> > a 4XX response forward it to another UAC, and update the TO accordingly.
> >
> > Currently trying to call  uac_replace_to twice shows an error and
> corrupts
> > the TO header. Is there a work around for this?
>
> I have no solution, but the same issue. (at the moment more or less
> solved by heavily using dialog variables).
>
> Example scenario showing the issue: Numbers are in e164 format, but
> towards the customer, shall be translated in localized format and
> privacy observed. Assume customer has Call forward on busy active.
>
> So the steps towards the issue are:
>
> * Translate numbers from e164 to local
> * If privacy: id replace numbers and display name with 'anonymous'
> * branch to customer
> * uac_replace
> * Manage reply: 486 busy
> ** Add diversion header ;reason=busy
> ** Add CFW destination RURI
> ** dispatch back to routing core.
>
> Towards core, I would need to revert uac_replace and use the original
> headers again.
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Using uac_replace_to when forwarding call to another endpoint

[Marrold via sr-users]

Hi all,

I am using uac_replace_to to replace the TO header on requests. I
understand it can only be called once per message and the recommendation is
to store the updated value in a pvar and apply it in the branch route.

However in my scenario I wish to first try one endpoint and then if it gets
a 4XX response forward it to another UAC, and update the TO accordingly.

Currently trying to call  uac_replace_to twice shows an error and corrupts
the TO header. Is there a work around for this?

Thanks again
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: rtimer intermittent failures

[Marrold via sr-users]

Hi Richard,

Thanks for the tip, I had indeed overlooked the return value.

Cheers
Matthew

On Tue, 5 Mar 2024 at 05:34, Richard Chan  wrote:

> In the method can you put
>
> return 1
>
> at the end. KEMI python is very strict on an int return value.
>
> On Tue, 5 Mar 2024, 07:08 Marrold via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
>> Hi all,
>>
>> I am using Kamailio 5.7.4 on a Debian 12 machine, with a Python Kemi
>> based config. I am seeing some intermittent failures when accessing an
>> instance variable within a function called by rtimer.
>>
>> I'm using the rtimer module with the following parameters:
>>
>> modparam("rtimer", "timer", "name=hello;interval=5;mode=0;")
>> modparam("rtimer", "exec", "timer=hello;route=ksr_route_hello")
>>
>> I initialise the kamailio class, and instance variable like this:
>>
>> class kamailio:
>> def __init__(self):
>>
>> self.hello = "hi"
>>
>> Within the class I have the following route  function:
>>
>> def ksr_route_hello(self, msg, evname):
>>
>> KSR.info("Running ksr_route_hello\n")
>> KSR.info(f"Hello? {self.hello}\n")
>>
>> Then in the logs I see it sometimes works, and sometimes fails:
>>
>>  9(15) INFO:  [core/kemi.c:106]: sr_kemi_core_info(): Running
>> ksr_route_hello
>>  9(15) INFO:  [core/kemi.c:106]: sr_kemi_core_info(): Hello? hi
>>
>>  9(15) INFO:  [core/kemi.c:106]: sr_kemi_core_info(): Running
>> ksr_route_hello
>>  9(15) ERROR: app_python3 [python_support.c:167]:
>> python_handle_exception(): apy_exec: ksr_route_hello(rtimer): Unhandled
>> exception in the Python code:
>> TypeError: 'NoneType' object cannot be interpreted as an integer
>>
>> The above exception was the direct cause of the following exception:
>>
>> Traceback (most recent call last):
>>   File "/etc/kamailio/kamailio.py", line 1007, in ksr_route_hello
>> KSR.info("Running ksr_route_hello\n")
>> SystemError:  returned a result with an exception
>> set
>>
>> Does anyone know where I'm going wrong?
>>
>> Thanks
>> Matthew
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] rtimer intermittent failures

[Marrold via sr-users]

Hi all,

I am using Kamailio 5.7.4 on a Debian 12 machine, with a Python Kemi based
config. I am seeing some intermittent failures when accessing an instance
variable within a function called by rtimer.

I'm using the rtimer module with the following parameters:

modparam("rtimer", "timer", "name=hello;interval=5;mode=0;")
modparam("rtimer", "exec", "timer=hello;route=ksr_route_hello")

I initialise the kamailio class, and instance variable like this:

class kamailio:
def __init__(self):

self.hello = "hi"

Within the class I have the following route  function:

def ksr_route_hello(self, msg, evname):

KSR.info("Running ksr_route_hello\n")
KSR.info(f"Hello? {self.hello}\n")

Then in the logs I see it sometimes works, and sometimes fails:

 9(15) INFO:  [core/kemi.c:106]: sr_kemi_core_info(): Running
ksr_route_hello
 9(15) INFO:  [core/kemi.c:106]: sr_kemi_core_info(): Hello? hi

 9(15) INFO:  [core/kemi.c:106]: sr_kemi_core_info(): Running
ksr_route_hello
 9(15) ERROR: app_python3 [python_support.c:167]:
python_handle_exception(): apy_exec: ksr_route_hello(rtimer): Unhandled
exception in the Python code:
TypeError: 'NoneType' object cannot be interpreted as an integer

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/etc/kamailio/kamailio.py", line 1007, in ksr_route_hello
KSR.info("Running ksr_route_hello\n")
SystemError:  returned a result with an exception
set

Does anyone know where I'm going wrong?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: sips to sip

[Marrold via sr-users]

> I have this setup where one side is TLS and the other UDP. Normally this
works fine, but we have this provider sending sips

In theory SIPS should be TLS end-to-end. Some UAs will reject the call or
misbehave if it's not.

I'm not sure this is the issue you're experiencing but it's worth keeping
in mind.

Cheers
Matthew


On Mon, 20 Nov 2023, 19:37 Social Boh via sr-users, <
sr-users@lists.kamailio.org> wrote:

> Hello DAvid,
>
> can you attach a pcap file about one example call?
>
> Regards
>
> ---
> I'm SoCIaL, MayBe
>
> El 20/11/2023 a las 1:44 p. m., David Villasmil via sr-users escribió:
>
> Hello guys,
>
> I have this setup where one side is TLS and the other UDP. Normally this
> works fine, but we have this provider sending sips as the schema everywhere
> (from, to, rr, contacts), kamailio sends the same sips to the upstream usp
> freeswitch.
>
> My problem is when FS sends back a 200OK and kamailio forwards it back to
> the provider, the provider sends an ACK and kamailio can't match it with
> the dialog and doesn't know where to forward it.
>
> i think this is happening because FS when is sees SIPS is setting the
> contact port as 5081 instead of the usual 5080...
>
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: TOPOS + Forcing the send socket

[Marrold via sr-users]

Thanks Henning I'll give that a try.


For additional context this happens when a single call traverses the
system, fresh after a restart, so if there's a memory leak it seems to
happen rapidly whilst processing a single SIP message

Cheers
Matthew

On Thu, 19 Oct 2023, 07:37 Henning Westerholt,  wrote:

> Hello,
>
>
>
> this is quite too much, then you are probably having a memory leak. Have a
> look e.g. to this for debugging help:
>
> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Marrold 
> *Sent:* Donnerstag, 19. Oktober 2023 02:05
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> Hi Henning,
>
> I bumped the PKG memory up to 24MB all the way up to 128MB and I still get
> the same issue.
>
> Thanks
> Matthew
>
>
>
> On Wed, Oct 18, 2023 at 10:18 AM Henning Westerholt  wrote:
>
> Hello,
>
>
>
> you are running out of private memory. Please try to increase the PKG
> memory pool (e.g. by changing /etc/default/kamailio or similar). You can
> verify with “ps aux”.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Marrold via sr-users 
> *Sent:* Mittwoch, 18. Oktober 2023 10:21
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Marrold 
> *Subject:* [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> Hi Both,
>
>
>
> Thanks for the input. I'm now doing it the proper way:
>
>
>
> modparam("topoh", "use_mode", 1)
> modparam("topos", "mask_callid", 1)
>
>
>
> But it's not masking the caller-id and the logs are full of errors:
>
>
> 18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]:
> qm_free(): BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called
> from core: core/data_lump.c: free_lump(470) - ignoring
>  5(11) ERROR:  [core/msg_translator.c:2241]:
> build_req_buf_from_sip_req(): could not allocate private memory from pkg
> pool
>  5(11) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
> memory for new message
>  5(11) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
> pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
> free_lump(470) - ignoring
>  5(11) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
> message too short: 0 []
>  5(11) ERROR:  [core/parser/parse_fline.c:271]: parse_first_line():
> parse_first_line: bad message (offset: 0)
>  5(11) ERROR:  [core/parser/msg_parser.c:748]: parse_msg(): ERROR:
> parse_msg: message=<>
>  5(11) ERROR:  [core/receive.c:376]: receive_msg(): core parsing of
> SIP message failed (172.24.0.21:5070/1)
>  3(9) ERROR:  [core/msg_translator.c:2241]:
> build_req_buf_from_sip_req(): could not allocate private memory from pkg
> pool
>  3(9) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
> memory for new message
>  3(9) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
> pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
> free_lump(470) - ignoring
>  3(9) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
> message too short: 0 []
>
>
>
> On Wed, 18 Oct 2023, 09:13 Henning Westerholt via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
> Hello,
>
>
>
> actually, there is now a mode where you can use both modules together,
> e.g. refer to the docs:
>
>
> https://kamailio.org/docs/modules/5.7.x/modules/topos.html#topos.p.mask_callid
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Yuriy G via sr-users 
> *Sent:* Mittwoch, 18. Oktober 2023 09:03
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Yuriy G 
> *Subject:* [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> In the header of the topic you talking about topos, but inside the
> messages you talking about topoh.
>
> They are 2 different modules. If you usr them together - they can
> conflictin case how they affect message. Try use or just topoh, or just
> topos.
>
>
>
> On Wed, 18 Oct 2023, 00:45 Marrold via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
> Hi all,
>
> I've dug into this a b

[SR-Users] Re: TOPOS + Forcing the send socket

[Marrold via sr-users]

Hi Henning,

I bumped the PKG memory up to 24MB all the way up to 128MB and I still get
the same issue.

Thanks
Matthew

On Wed, Oct 18, 2023 at 10:18 AM Henning Westerholt  wrote:

> Hello,
>
>
>
> you are running out of private memory. Please try to increase the PKG
> memory pool (e.g. by changing /etc/default/kamailio or similar). You can
> verify with “ps aux”.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Marrold via sr-users 
> *Sent:* Mittwoch, 18. Oktober 2023 10:21
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Marrold 
> *Subject:* [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> Hi Both,
>
>
>
> Thanks for the input. I'm now doing it the proper way:
>
>
>
> modparam("topoh", "use_mode", 1)
> modparam("topos", "mask_callid", 1)
>
>
>
> But it's not masking the caller-id and the logs are full of errors:
>
>
> 18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]:
> qm_free(): BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called
> from core: core/data_lump.c: free_lump(470) - ignoring
>  5(11) ERROR:  [core/msg_translator.c:2241]:
> build_req_buf_from_sip_req(): could not allocate private memory from pkg
> pool
>  5(11) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
> memory for new message
>  5(11) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
> pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
> free_lump(470) - ignoring
>  5(11) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
> message too short: 0 []
>  5(11) ERROR:  [core/parser/parse_fline.c:271]: parse_first_line():
> parse_first_line: bad message (offset: 0)
>  5(11) ERROR:  [core/parser/msg_parser.c:748]: parse_msg(): ERROR:
> parse_msg: message=<>
>  5(11) ERROR:  [core/receive.c:376]: receive_msg(): core parsing of
> SIP message failed (172.24.0.21:5070/1)
>  3(9) ERROR:  [core/msg_translator.c:2241]:
> build_req_buf_from_sip_req(): could not allocate private memory from pkg
> pool
>  3(9) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
> memory for new message
>  3(9) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
> pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
> free_lump(470) - ignoring
>  3(9) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
> message too short: 0 []
>
>
>
> On Wed, 18 Oct 2023, 09:13 Henning Westerholt via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
> Hello,
>
>
>
> actually, there is now a mode where you can use both modules together,
> e.g. refer to the docs:
>
>
> https://kamailio.org/docs/modules/5.7.x/modules/topos.html#topos.p.mask_callid
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Yuriy G via sr-users 
> *Sent:* Mittwoch, 18. Oktober 2023 09:03
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Yuriy G 
> *Subject:* [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> In the header of the topic you talking about topos, but inside the
> messages you talking about topoh.
>
> They are 2 different modules. If you usr them together - they can
> conflictin case how they affect message. Try use or just topoh, or just
> topos.
>
>
>
> On Wed, 18 Oct 2023, 00:45 Marrold via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
> Hi all,
>
> I've dug into this a bit more. Firstly I enabled debug logs and spotted
> the following record-route header being loaded from redis:
>
> 21(28) DEBUG: PY3 {ACK}: topos_redis [topos_redis_storage.c:1079]:
> tps_redis_load_dialog(): r[5]: s[<
> sip:172.24.0.10:5070;sn=internal;r2=on;lr;ftag=202310172234552;did=c1f.18b1;nat=yes
> >,<
> sip:127.0.0.8;line=sr-N6IAzBFlWJZLWxP7WBN7z.VXN6ZQNUKJoSIBzwVLHRQ7z6fLz6g43RNQMByLMlFAM.NLMBM4W.jAMxyAMB1qCRPQ3ltEOBFZ3BFXoEt4H9IINA**
> >]
>
> 127.0.0.8 is the wrong IP which explains why the ACK was not being
> forwarded correctly. A quick look in the source shows it's related to topoh.
>
> I had modparam("topoh", "mask_callid", 1) in my config so I disabled it
> and sure enough the ACK worked as expected which gets me a bit closer to
> finding the issue.
>
> Looking at the docs for topos and topoh it looks like things have changed
> since I used it last and I should be using the following instead:
>
> m

[SR-Users] Re: TOPOS + Forcing the send socket

[Marrold via sr-users]

Hi Both,

Thanks for the input. I'm now doing it the proper way:

modparam("topoh", "use_mode", 1)
modparam("topos", "mask_callid", 1)

But it's not masking the caller-id and the logs are full of errors:

18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]: qm_free():
BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called from core:
core/data_lump.c: free_lump(470) - ignoring
 5(11) ERROR:  [core/msg_translator.c:2241]:
build_req_buf_from_sip_req(): could not allocate private memory from pkg
pool
 5(11) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
memory for new message
 5(11) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
free_lump(470) - ignoring
 5(11) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
message too short: 0 []
 5(11) ERROR:  [core/parser/parse_fline.c:271]: parse_first_line():
parse_first_line: bad message (offset: 0)
 5(11) ERROR:  [core/parser/msg_parser.c:748]: parse_msg(): ERROR:
parse_msg: message=<>
 5(11) ERROR:  [core/receive.c:376]: receive_msg(): core parsing of
SIP message failed (172.24.0.21:5070/1)
 3(9) ERROR:  [core/msg_translator.c:2241]:
build_req_buf_from_sip_req(): could not allocate private memory from pkg
pool
 3(9) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
memory for new message
 3(9) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
free_lump(470) - ignoring
 3(9) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
message too short: 0 []


On Wed, 18 Oct 2023, 09:13 Henning Westerholt via sr-users, <
sr-users@lists.kamailio.org> wrote:

> Hello,
>
>
>
> actually, there is now a mode where you can use both modules together,
> e.g. refer to the docs:
>
>
> https://kamailio.org/docs/modules/5.7.x/modules/topos.html#topos.p.mask_callid
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Yuriy G via sr-users 
> *Sent:* Mittwoch, 18. Oktober 2023 09:03
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Yuriy G 
> *Subject:* [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> In the header of the topic you talking about topos, but inside the
> messages you talking about topoh.
>
> They are 2 different modules. If you usr them together - they can
> conflictin case how they affect message. Try use or just topoh, or just
> topos.
>
>
>
> On Wed, 18 Oct 2023, 00:45 Marrold via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
> Hi all,
>
> I've dug into this a bit more. Firstly I enabled debug logs and spotted
> the following record-route header being loaded from redis:
>
> 21(28) DEBUG: PY3 {ACK}: topos_redis [topos_redis_storage.c:1079]:
> tps_redis_load_dialog(): r[5]: s[<
> sip:172.24.0.10:5070;sn=internal;r2=on;lr;ftag=202310172234552;did=c1f.18b1;nat=yes
> >,<
> sip:127.0.0.8;line=sr-N6IAzBFlWJZLWxP7WBN7z.VXN6ZQNUKJoSIBzwVLHRQ7z6fLz6g43RNQMByLMlFAM.NLMBM4W.jAMxyAMB1qCRPQ3ltEOBFZ3BFXoEt4H9IINA**
> >]
>
> 127.0.0.8 is the wrong IP which explains why the ACK was not being
> forwarded correctly. A quick look in the source shows it's related to topoh.
>
> I had modparam("topoh", "mask_callid", 1) in my config so I disabled it
> and sure enough the ACK worked as expected which gets me a bit closer to
> finding the issue.
>
> Looking at the docs for topos and topoh it looks like things have changed
> since I used it last and I should be using the following instead:
>
> modparam("topoh", "use_mode", 1)
> modparam("topos", "mask_callid", 1)
>
> But with those configured things go really wrong:
>
> 18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]:
> qm_free(): BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called
> from core: core/data_lump.c: free_lump(470) - ignoring
>  5(11) ERROR:  [core/msg_translator.c:2241]:
> build_req_buf_from_sip_req(): could not allocate private memory from pkg
> pool
>  5(11) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
> memory for new message
>  5(11) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
> pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
> free_lump(470) - ignoring
>  5(11) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
> message too short: 0 []
>  5(11) ERROR:  [core/parser/parse_fline.c:271]: parse_first_line():
> parse_first_line: bad message (offset: 0)
>  5(11) ERROR:  [core/parser/msg_pars

[SR-Users] Re: TOPOS + Forcing the send socket

[Marrold via sr-users]

Hi all,

I've dug into this a bit more. Firstly I enabled debug logs and spotted the
following record-route header being loaded from redis:

21(28) DEBUG: PY3 {ACK}: topos_redis [topos_redis_storage.c:1079]:
tps_redis_load_dialog(): r[5]: s[,]

127.0.0.8 is the wrong IP which explains why the ACK was not being
forwarded correctly. A quick look in the source shows it's related to topoh.

I had modparam("topoh", "mask_callid", 1) in my config so I disabled it and
sure enough the ACK worked as expected which gets me a bit closer to
finding the issue.

Looking at the docs for topos and topoh it looks like things have changed
since I used it last and I should be using the following instead:

modparam("topoh", "use_mode", 1)
modparam("topos", "mask_callid", 1)

But with those configured things go really wrong:

18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]: qm_free():
BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called from core:
core/data_lump.c: free_lump(470) - ignoring
 5(11) ERROR:  [core/msg_translator.c:2241]:
build_req_buf_from_sip_req(): could not allocate private memory from pkg
pool
 5(11) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
memory for new message
 5(11) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
free_lump(470) - ignoring
 5(11) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
message too short: 0 []
 5(11) ERROR:  [core/parser/parse_fline.c:271]: parse_first_line():
parse_first_line: bad message (offset: 0)
 5(11) ERROR:  [core/parser/msg_parser.c:748]: parse_msg(): ERROR:
parse_msg: message=<>
 5(11) ERROR:  [core/receive.c:376]: receive_msg(): core parsing of
SIP message failed (172.24.0.21:5070/1)
 3(9) ERROR:  [core/msg_translator.c:2241]:
build_req_buf_from_sip_req(): could not allocate private memory from pkg
pool
 3(9) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
memory for new message
 3(9) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
free_lump(470) - ignoring
 3(9) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
message too short: 0 []

Does anyone have any ideas what's going on here?

Thanks
Matthew



On Tue, Oct 17, 2023 at 6:30 PM Marrold  wrote:

> Hi all,
>
> I am using Kamailio (5.7.2, Debian 11, Python KEMI) in a
> mutli-homed environment with the topos module to hide the topology.
>
> I have noticed that when I use `set_send_socket` or `$fsn` to force the
> socket it's sent from, it breaks topos and the ACK is not proxied to the
> other leg of the call. I am calling record_route() *after* forcing the
> socket.
>
> If I disable TOPOS the ACK works as expected, and the signalling looks
> correct.
> Or, with TOPOS enabled, if I comment out set_send_socket TOPOS works as
> expected.
> If I disable enable_double_rr, TOPOS works as expected and the ACK is
> forwarded, but without the double RR subsequent in-dialog requests use the
> wrong socket.
>
> One other observation, when I change the send socket I also see these
> warnings in the logs:
>
> 24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1348]: dlg_onroute():
> tight matching failed for ACK with
> callid='!!:MByLMlFAM.NfWxFAM.cAMxyfWjyLz.yAO.y6MxF1MxVZWG4ZMy**'/55,
> ftag='2023101714101800015'/19,
> ttag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36 and direction=0
> 24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1355]: dlg_onroute():
> dialog identification elements are
> callid='2023101714101800015@2900-0601-0284-80'/37, caller
> tag='2023101714101800015'/19, callee
> tag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36
>
> Is anyone using TOPOS + forcing the socket, or could someone advise where
> I am going wrong?
>
> Thanks in advance
> Matthew
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] TOPOS + Forcing the send socket

[Marrold via sr-users]

Hi all,

I am using Kamailio (5.7.2, Debian 11, Python KEMI) in a
mutli-homed environment with the topos module to hide the topology.

I have noticed that when I use `set_send_socket` or `$fsn` to force the
socket it's sent from, it breaks topos and the ACK is not proxied to the
other leg of the call. I am calling record_route() *after* forcing the
socket.

If I disable TOPOS the ACK works as expected, and the signalling looks
correct.
Or, with TOPOS enabled, if I comment out set_send_socket TOPOS works as
expected.
If I disable enable_double_rr, TOPOS works as expected and the ACK is
forwarded, but without the double RR subsequent in-dialog requests use the
wrong socket.

One other observation, when I change the send socket I also see these
warnings in the logs:

24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1348]: dlg_onroute():
tight matching failed for ACK with
callid='!!:MByLMlFAM.NfWxFAM.cAMxyfWjyLz.yAO.y6MxF1MxVZWG4ZMy**'/55,
ftag='2023101714101800015'/19,
ttag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36 and direction=0
24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1355]: dlg_onroute():
dialog identification elements are
callid='2023101714101800015@2900-0601-0284-80'/37, caller
tag='2023101714101800015'/19, callee
tag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36

Is anyone using TOPOS + forcing the socket, or could someone advise where I
am going wrong?

Thanks in advance
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] uac_auth() in KEMI Python - Drop 401 sent to caller

[Marrold]

Hi all,

I'm attempting to use the uac module in KEMI (Python) to authenticate
outbound requests. When the downstream replies with a 401 the proxy
correctly re-sends the request with a Authorization header, but the 401 is
also relayed to the caller.

As far as I can tell I've converted the example to KEMI correctly, but no
matter what I try the 401 is still sent to the caller. Any ideas?

The config I'm using is below - The avps are set when the request is sent
so aren't visible here.

Thanks


def ksr_failure_manage(self, msg):

if self.ksr_route_natmanage(msg)==-255 : return 1

if KSR.tm.t_is_canceled()>0 :
return 1

if KSR.tm.t_check_status("401|407") >0 :

KSR.info(f"Got a 40X, should attempt authentication")

if KSR.uac.uac_auth()>0:
KSR.tm.t_relay()

KSR.info (f"Dropping further replies")
KSR.set_drop()
exit()

return 1
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Creating CDRs for Missed and failed calls

[Marrold]

Hi Henning,

Apologies for the late reply, I've just spotted this. I'll give it a try.

Thanks
Matthew

On Tue, Sep 12, 2023 at 3:19 PM Henning Westerholt  wrote:
>
> Hello,
>
> the ACC module needs transaction stateful sending of messages to work 
> correctly.
>
> Have e.g., a look to the default configuration, there is a stateful 404 send 
> in a similar scenario for (also) this reason in location lookup phase.
>
> Cheers,
>
> Henning
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://gilawa.com
>
> > -Original Message-
> > From: Marrold 
> > Sent: Montag, 11. September 2023 23:54
> > To: Kamailio (SER) - Users Mailing List 
> > Subject: [SR-Users] Creating CDRs for Missed and failed calls
> >
> > Hi all,
> >
> > I'm using the acc module along with postgres to generate CDRs. For connected
> > calls the CDRs are created as expected, but in the scenario where a lookup()
> > fails and Kamailio sends a stateless 404 there's no CDR logged.
> >
> > I'm setting the FLT_ACCMISSED and FLT_ACCFAILED flags in the initial request
> > route, but perhaps I have a misunderstanding of how these work?
> >
> > Thanks
> > Matthew
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
> > send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to the
> > sender!
> > Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Creating CDRs for Missed and failed calls

[Marrold]

Hi all,

I'm using the acc module along with postgres to generate CDRs. For
connected calls the CDRs are created as expected, but in the scenario
where a lookup() fails and Kamailio sends a stateless 404 there's no
CDR logged.

I'm setting the FLT_ACCMISSED and FLT_ACCFAILED flags in the initial
request route, but perhaps I have a misunderstanding of how these
work?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Re: [SR-Users] TOPOH is generating new Call-ID for BYE

[Marrold]

Hi Daniel,

Thanks for the suggestion. I was able to fix it by enabling  `append_fromtag`
- it's disabled in the example config, although it is on by default.

modparam("rr", "append_fromtag", 1)

Thanks
Matthew

On Thu, Mar 24, 2022 at 12:59 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> check if the call-id value is not somehow changed by the endpoints, then
> also direction has to be detected properly (check from/to/rr tags).
>
> Cheers,
> Daniel
> On 23.03.22 16:05, Marrold wrote:
>
> Hi,
>
> I have enabled the TOPOH module  with mask_callid enabled, but it's
> generating a new Call-ID for a BYE which gets rejected with a 481
> downstream. If I disable the TOPOH module it works as expected.
>
> Does anyone know where I should start looking? SIP-wise the initial BYE
> seems compliant.
>
> This is Kamailio 5.5.3 on Debian 11
>
> Thanks
> Matthew
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
>   March 28-31, 2022 (Europe Timezone)
>   * https://www.asipto.com/sw/kamailio-advanced-training-online/
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] TOPOH is generating new Call-ID for BYE

[Marrold]

Hi,

I have enabled the TOPOH module  with mask_callid enabled, but it's
generating a new Call-ID for a BYE which gets rejected with a 481
downstream. If I disable the TOPOH module it works as expected.

Does anyone know where I should start looking? SIP-wise the initial BYE
seems compliant.

This is Kamailio 5.5.3 on Debian 11

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Can Kamailio send an ACK to a final response?

[Marrold]

Hello,

I'm exploring using Kamailio as a dumb edge proxy, and as such I want to
keep things as lean as possible.

In some scenarios I would like the "core" proxies to signal to the edge
that a request should be dropped without a response. This could be with a
custom header in the reply or perhaps a 444 response ( nginx uses this
internally to drop a request without responding )

I have discovered that if I drop the response in the reply_route, the edge
proxy doesn't send an ACK and keeps retransmitting the request until it
times out, at which point it sends a 408 back to the UA.

Is there any way to ACK the response from the core and destroy the
transaction?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] help to configure topos module configuration

[Marrold]

Hi,

I recently looked into this and I don't believe it's possible.

As a work around I used split DNS and an FQDN in the contact.

Thanks
Matthew

On Fri, Mar 18, 2022 at 8:44 AM Patrick Karton 
wrote:

>
> Caller <--> (internal_IP) Kamailio (external_IP) <---> Callee
>
>
> I have this set up of kamailio with 2 interfaces.
>
> i use topos module for topology hiding and what i want to do is to
> send  external_IP in Contact Header of request relayed to Callee and
> internal_IP
> in Contact Header of response relayed to Caller.
>
> i noticed that :
> when i use topos module with contact_mode to 0
> all Record-Route and Caller Via Header are removed and thats great.
> but i dont find way to put 2 different  ip addresses in Request and
> Response Contact Header?
>
> when i use contact_mode to 2 Record-Route and Caller Via Header are not
> anymore removed thats bad for
> topology hiding. And its seems we can not use $xavu(_tps_=>contact_host)
>  parameter of module
> to put 2 different  ip addresses in Request and Response Contact Header.
>
>
> What i want is :
>
> - remove all Record-Route and Caller Via Header for request like when
> contact_mode to 0
>
> - and put 2 different  ip addresses in Request and Response Contact Header
>
> is it possible to achieve it ?
>
> Thanks.
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio + RADCLI

[Marrold]

Thanks Daniel. I should have updated sorry - the issue went away after
re-compiling the packages. Unfortunately I'm not sure what we got wrong /
missed, but it's working now.

Cheers
Matthew

On Fri, Mar 11, 2022 at 1:02 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> rather old email, but if it was not sorted out, then looks like some
> issues with setting the radius dictionaries for the library. Here is an
> aged tutorial, but there could still be useful details:
>
>   * https://www.kamailio.org/docs/openser-radius-1.0.x.html
>
> Cheers,
> Daniel
>
> On 23.02.22 09:58, Marrold wrote:
> > Hi,
> >
> > We're currently testing Kamailio 5.5.3 on Debian 11 compiled with
> > RADCLI and we're experiencing an issue with radius authentication:
> >
> > Feb 23 08:54:22 redacted /sbin/kamailio[817172]: WARNING: 

Re: [SR-Users] Kamailio + KEMI + topos + change_reply_status

[Marrold]

Hi Karsten,

That was originally an issue, and when I spotted it I thought I'd solved
the problem but apparently not. In this instance KSR.pv.get("$rs") returns
an int.

I see the log line, and even the message being updated in the debug logs,
but then topos does it's thing and the change is overwritten.

Thanks
Matthew


On Wed, Mar 9, 2022 at 12:11 AM Karsten Horsmann 
wrote:

> Hi Marrold,
>
> not tested but could it be that you check an string with an int?
>
> Kind regards
> Karsten Horsmann
>
> Marrold  schrieb am Di., 8. März 2022, 23:46:
>
>> Hi,
>>
>> I'm using Kamailio 5.5.3 with a KEMI / Python based configuration on
>> Debian 11.
>>
>> In my reply route I am trying to convert a 183 to a 180 with: 
>> KSR.textopsx.change_reply_status(180,
>> "Ringing")
>>
>> I've noticed with TOPOS enabled, it doesn't work and I still see a 183 go
>> out. But with it disabled, it works as expected and it's converted to a
>> 180. I get the same behaviour with / without msg_apply_changes()
>>
>> Config looks like this:
>>
>> def ksr_onreply_manage(self, msg):
>>
>> KSR.info(f"ksr_onreply_manage\r\n")
>>
>> scode = KSR.pv.get("$rs")
>>
>> if KSR.permissions.allow_source_address_group()<0:
>> if scode == 183:
>>KSR.info(f"ksr_onreply_manage: Converting 183 to 180\r\n")
>>KSR.textopsx.change_reply_status(180, "Ringing")
>>KSR.textopsx.msg_apply_changes()
>>
>> if scode>100 and scode<299 :
>> self.ksr_route_natmanage(msg)
>>
>> return 1
>>
>> The debug log doesn't reveal anything too obvious, I can share if its of
>> any use.
>>
>> Does anyone have any suggestions?
>>
>> Thanks
>> Matthew
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio + KEMI + topos + change_reply_status

[Marrold]

Hi,

I'm using Kamailio 5.5.3 with a KEMI / Python based configuration on Debian
11.

In my reply route I am trying to convert a 183 to a 180 with:
KSR.textopsx.change_reply_status(180,
"Ringing")

I've noticed with TOPOS enabled, it doesn't work and I still see a 183 go
out. But with it disabled, it works as expected and it's converted to a
180. I get the same behaviour with / without msg_apply_changes()

Config looks like this:

def ksr_onreply_manage(self, msg):

KSR.info(f"ksr_onreply_manage\r\n")

scode = KSR.pv.get("$rs")

if KSR.permissions.allow_source_address_group()<0:
if scode == 183:
   KSR.info(f"ksr_onreply_manage: Converting 183 to 180\r\n")
   KSR.textopsx.change_reply_status(180, "Ringing")
   KSR.textopsx.msg_apply_changes()

if scode>100 and scode<299 :
self.ksr_route_natmanage(msg)

return 1

The debug log doesn't reveal anything too obvious, I can share if its of
any use.

Does anyone have any suggestions?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] topos xavu_field_contact_host kamailio 5.5

[Marrold]

Hi Jonathan,

Were you able to solve this problem? I'm running Kamailio in docker and
need to write a different contact in each direction based on the flow - i.e
the contact in the leg to the end device should be the external address,
but the leg to another back end running in docker should be the internal
address.

You mentioned previously fixing something like this with hash tables, I'm
assuming you're rewriting the contact before sending, storing the original
into a hash table and then over-writing any response and calling
msg_apply_changes before the TOPOS processing?

Thanks
Matthew

On Fri, Dec 3, 2021 at 9:44 PM Jonathan Hunter 
wrote:

> Hi Karsten,
>
>
>
> Ok cool thanks for that I am testing now.
>
>
>
> I also have the fun on a NAT’d interface so I am playing with setting
> advertised address as well!
>
>
>
> Makes sense thank you for the reply.
>
>
>
> Jon
>
>
>
> Sent from Mail  for
> Windows
>
>
>
> *From: *Karsten Horsmann 
> *Sent: *03 December 2021 21:13
> *To: *Kamailio (SER) - Users Mailing List 
> *Subject: *Re: [SR-Users] topos xavu_field_contact_host kamailio 5.5
>
>
>
> Hi Jonathan,
>
>
>
>
>
> I placed a new route and set the user part
>
>
>
> $xavu(_tps_=>a_contact) = "sbc_a";$xavu(_tps_=>b_contact)
> = "sbc_b";
>
> And for special cases I set the to user part to the To user for some silly
> pbx boxes.
>
> Can also be that in this mode without setting a/b_contact the normal
> contact user part passes through, didn't test that.
>
>
>
>
>
> Kind regards
>
> Karsten Horsmann
>
>
>
> Jonathan Hunter  schrieb am Fr., 3. Dez. 2021,
> 20:03:
>
> Hi Karsten,
>
>
>
> Thank you for your reply.
>
>
>
> Thats interesting I will test it, so I see in the documentation it states;
>
>
>
>
>
> $xavu(_tps_=>a_contact) = "...";
>
>
>
> In your case what did you enter so that it just sets the user part?
>
>
>
> I assume I could just set it to $sel(contact.uri.user) for example and it
> would then add that and the appropriate listen/ socket value ?
>
>
>
> Many thanks!
>
>
>
> Jon
>
> Sent from Mail
> 
> for Windows
>
>
>
> *From: *Karsten Horsmann 
> *Sent: *03 December 2021 18:49
> *To: *Kamailio (SER) - Users Mailing List 
> *Subject: *Re: [SR-Users] topos xavu_field_contact_host kamailio 5.5
>
>
>
> Hi Jonathan,
>
>
>
>
>
>
>
> I use topos in mode 2 (rewrite user part)
>
> and then it sets the domain part to the listen / socket value AFAIK if you
> only set user part and did not specify the contact host.
>
>
>
>
>
>
>
> #!ifdef WITH_TOPOS
>
> modparam("topos", "storage", "redis")
>
> modparam("topos_redis", "serverid", "CFG_REDIS_NAME")
>
> modparam("topos", "branch_expire", 14400) modparam("topos",
> "dialog_expire", 14400)
>
> modparam("topos", "clean_interval", 60)
>
> #!ifdef WITH_TOPOS_CONTACTmodparam("topos",
> "contact_mode", 2)
>
> modparam("topos", "xavu_cfg", "_tps_")modparam("topos",
> "xavu_field_contact_host", "contact_host")
> modparam("topos", "xavu_field_a_contact", "a_contact")
>
> modparam("topos", "xavu_field_b_contact", "b_contact")
>
> #!endif
>
> #!endif
>
>
>
>
>
> Jonathan Hunter  schrieb am Fr., 3. Dez. 2021,
> 10:50:
>
> Hello Henning,
>
>
>
> Ok appreciate the confirmation, could this be a possible option moving
> forwards with the module?
>
>
>
> In the meantime I assume other approach is hash tables as I have done
> before?
>
>
>
> Thanks again appreciate your response.
>
>
>
> Jon
>
>
>
> Sent from Mail
> 
> for Windows
>
>
>
> *From: *Henning Westerholt 
> *Sent: *03 December 2021 09:36
> *To: *Kamailio (SER) - Users Mailing List 
> *Cc: *Jonathan Hunter 
> *Subject: *RE: topos xavu_field_contact_host kamailio 5.5
>
>
>
> Hello Jonathan,
>
>
>
> I see, so you want basically configure different contact addresses for
> A-side and B-side of the call.
>
> This is probably not supported from topos right now, its only possible for
> the user name.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* Jonathan Hunter 
> *Sent:* Friday, December 3, 2021 10:07 AM
> *To:* Henning Westerholt ; Kamailio (SER) - Users Mailing
> List 
> *Subject:* RE: topos xavu_field_contact_host kamailio 5.5
>
>
>
> Hello Henni

[SR-Users] Kamailio + RADCLI

[Marrold]

Hi,

We're currently testing Kamailio 5.5.3 on Debian 11 compiled with RADCLI
and we're experiencing an issue with radius authentication:

Feb 23 08:54:22 redacted /sbin/kamailio[817172]: WARNING: 

[SR-Users] allow_source_address_group in failure route

[Marrold]

Hello,

I'm using Kamailio as a proxy between several voice gateways and if the
call fails for whatever reason (far end is busy etc) I am forwarding to an
Asterisk box to play an announcement.

Within the failure route I am using  allow_source_address_group() to ascertain
if the failure response was from a Voice Gateway or Asterisk itself,
however it appears to return the group for the first branch when the reply
is from the second branch to Asterisk.

To handle the failure I am adding some headers, and setting a new
destination indirectly with ds_select_dst before t_relay. I am using 5.5.3
on Debian 11, using KEMI / Python.

Does anyone have any ideas?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Comunication between devices RTP/SRTP and viceversa

[Marrold]

Hi,

Unfortunately in my experience "Opportunistic SRTP" support is broken in
many UAs. There are (at least) two ways of doing it covered indirectly in
RFC3264  and the second explicitly in
RFC8643  and devices seem to
handle them differently. I've seen end devices that *can *support SRTP
choose to use standard RTP when offered the wrong type of SDP body.

One thing I considered (but haven't tested so far) is using a late offer to
discover what format the end device expects before sending an offer, but
that might cause interop problems of its own.

Cheers

On Thu, Jan 27, 2022 at 10:54 PM Social Boh  wrote:

> I can examine the request but how examine the answer if is a Error?
> Using a failure route?
>
> Regards
>
> ---
> I'm SoCIaL, MayBe
>
> El 27/01/2022 a las 5:39 p. m., Alex Balashov escribió:
> > Does an examination of the SDP offer and answer respectively not divine
> the issue?
> >
> >> On Jan 27, 2022, at 5:35 PM, Social Boh  wrote:
> >>
> >> I'm trying to configure Kamailio to permit communication between
> devices:
> >>
> >> some use TLS and SRTP
> >>
> >> some UDP and RTP
> >>
> >> with RTPEngine in the middle.
> >>
> >> A priori I don't know if the device support SRTP or RTP so in the
> routing I have to detect on the fly how to act. The problem is this:
> >>
> >> Call from RTP to SRTP device: 488 Not Acceptable here
> >>
> >> Call from SRTP to RTP device: 415 Unsupported Media Type
> >>
> >> Any hint?
> >>
> >> Thank you
> >>
> >>   Regards
> >>
> >> --
> >> ---
> >> I'm SoCIaL, MayBe
> >>
> >>
> >> __
> >> Kamailio - Users Mailing List - Non Commercial Discussions
> >> * sr-users@lists.kamailio.org
> >> Important: keep the mailing list in the recipients, do not reply only
> to the sender!
> >> Edit mailing list options or unsubscribe:
> >> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] wireshark decode kamailio / rtpengine ng messages

[Marrold]

Hi Karsten,

The term they use is a "dissector" if that helps with your search. If
you're just parsing info from one packet statelessly (I.E no relation to
any other packet) it's fairly straightforward to throw something together.

Thanks
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Catching websocket / TCP errors

[Marrold]

That makes sense, thanks Arsen. We're already catching it then we just
sl_reply_error() - I'll add some special handling for this scenario

Thanks again

On Wed, Oct 20, 2021 at 12:58 PM Arsen Semenov  wrote:

> Hi,
>
> Yes, you can handle return codes from t_relay(). It should return -1 in
> case of network failure.
>
> On Wed, 20 Oct 2021 at 4:39 PM, Marrold  wrote:
>
>> Hi all,
>>
>> Is there any way of catching these errors before sending a 500 No error
>> (2/SL) ?
>>
>> Thanks
>>
>> On Tue, Oct 5, 2021 at 5:01 PM Marrold  wrote:
>>
>>> Hi Arsen
>>>
>>> That looks perfect, except we're still using 4.3.X on some of our
>>> proxies ( I should have mentioned, sorry) . We plan on upgrading very
>>> soon...
>>>
>>> Thanks
>>>
>>>
>>> On Tue, Oct 5, 2021 at 4:58 PM Arsen Semenov 
>>> wrote:
>>>
>>>> Hi,
>>>> have you tried this param?
>>>>
>>>> https://kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.db_clean_tcp
>>>>
>>>> On Tue, Oct 5, 2021 at 8:49 PM Marrold  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We're currently implementing WebRTC (SIP over a websocket) on our
>>>>> Kamailio proxies and we're experiencing a minor issue after a restart.
>>>>>
>>>>> We write all USRLOC entries to a shared database to implement HA.
>>>>> These are then loaded on a restart, which leaves us with entries with TCP
>>>>> connections that no longer exist. When a call attempt is made the proxy
>>>>> can't find the connection ID and immediately rejects the call with a "500
>>>>> No error (2/SL)" -
>>>>>
>>>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: WARNING: 
>>>>> [core/msg_translator.c:2861]: via_builder(): TCP/TLS connection (id: 0) 
>>>>> for
>>>>> WebSocket could not be found
>>>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: 
>>>>> [core/msg_translator.c:2038]: build_req_buf_from_sip_req(): could not
>>>>> create Via header
>>>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm
>>>>> [t_fwd.c:479]: prepare_new_uac(): could not build request
>>>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm
>>>>> [t_fwd.c:1759]: t_forward_nonack(): failure to add branches
>>>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: sl
>>>>> [sl_funcs.c:414]: sl_reply_error(): stateless error reply used: No error
>>>>> (2/SL)
>>>>>
>>>>> How can we catch this error to avoid terminating the call prematurely?
>>>>> Or should we flush these TCP connections on start up?
>>>>>
>>>>> Thanks
>>>>> Matthew
>>>>>
>>>>> __
>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>>   * sr-users@lists.kamailio.org
>>>>> Important: keep the mailing list in the recipients, do not reply only
>>>>> to the sender!
>>>>> Edit mailing list options or unsubscribe:
>>>>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>
>>>>
>>>> --
>>>> Arsen Semenov
>>>>
>>>> __
>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>   * sr-users@lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply only
>>>> to the sender!
>>>> Edit mailing list options or unsubscribe:
>>>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Sent from Gmail Mobile
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Catching websocket / TCP errors

[Marrold]

Hi all,

Is there any way of catching these errors before sending a 500 No error
(2/SL) ?

Thanks

On Tue, Oct 5, 2021 at 5:01 PM Marrold  wrote:

> Hi Arsen
>
> That looks perfect, except we're still using 4.3.X on some of our proxies
> ( I should have mentioned, sorry) . We plan on upgrading very soon...
>
> Thanks
>
>
> On Tue, Oct 5, 2021 at 4:58 PM Arsen Semenov  wrote:
>
>> Hi,
>> have you tried this param?
>>
>> https://kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.db_clean_tcp
>>
>> On Tue, Oct 5, 2021 at 8:49 PM Marrold  wrote:
>>
>>> Hi,
>>>
>>> We're currently implementing WebRTC (SIP over a websocket) on our
>>> Kamailio proxies and we're experiencing a minor issue after a restart.
>>>
>>> We write all USRLOC entries to a shared database to implement HA. These
>>> are then loaded on a restart, which leaves us with entries with TCP
>>> connections that no longer exist. When a call attempt is made the proxy
>>> can't find the connection ID and immediately rejects the call with a "500
>>> No error (2/SL)" -
>>>
>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: WARNING: 
>>> [core/msg_translator.c:2861]: via_builder(): TCP/TLS connection (id: 0) for
>>> WebSocket could not be found
>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: 
>>> [core/msg_translator.c:2038]: build_req_buf_from_sip_req(): could not
>>> create Via header
>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm [t_fwd.c:479]:
>>> prepare_new_uac(): could not build request
>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm
>>> [t_fwd.c:1759]: t_forward_nonack(): failure to add branches
>>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: sl
>>> [sl_funcs.c:414]: sl_reply_error(): stateless error reply used: No error
>>> (2/SL)
>>>
>>> How can we catch this error to avoid terminating the call prematurely?
>>> Or should we flush these TCP connections on start up?
>>>
>>> Thanks
>>> Matthew
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>   * sr-users@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>> --
>> Arsen Semenov
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Catching websocket / TCP errors

[Marrold]

Hi Arsen

That looks perfect, except we're still using 4.3.X on some of our proxies (
I should have mentioned, sorry) . We plan on upgrading very soon...

Thanks


On Tue, Oct 5, 2021 at 4:58 PM Arsen Semenov  wrote:

> Hi,
> have you tried this param?
>
> https://kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.db_clean_tcp
>
> On Tue, Oct 5, 2021 at 8:49 PM Marrold  wrote:
>
>> Hi,
>>
>> We're currently implementing WebRTC (SIP over a websocket) on our
>> Kamailio proxies and we're experiencing a minor issue after a restart.
>>
>> We write all USRLOC entries to a shared database to implement HA. These
>> are then loaded on a restart, which leaves us with entries with TCP
>> connections that no longer exist. When a call attempt is made the proxy
>> can't find the connection ID and immediately rejects the call with a "500
>> No error (2/SL)" -
>>
>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: WARNING: 
>> [core/msg_translator.c:2861]: via_builder(): TCP/TLS connection (id: 0) for
>> WebSocket could not be found
>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: 
>> [core/msg_translator.c:2038]: build_req_buf_from_sip_req(): could not
>> create Via header
>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm [t_fwd.c:479]:
>> prepare_new_uac(): could not build request
>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm [t_fwd.c:1759]:
>> t_forward_nonack(): failure to add branches
>> Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: sl
>> [sl_funcs.c:414]: sl_reply_error(): stateless error reply used: No error
>> (2/SL)
>>
>> How can we catch this error to avoid terminating the call prematurely? Or
>> should we flush these TCP connections on start up?
>>
>> Thanks
>> Matthew
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Arsen Semenov
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Catching websocket / TCP errors

[Marrold]

Hi,

We're currently implementing WebRTC (SIP over a websocket) on our Kamailio
proxies and we're experiencing a minor issue after a restart.

We write all USRLOC entries to a shared database to implement HA. These are
then loaded on a restart, which leaves us with entries with TCP connections
that no longer exist. When a call attempt is made the proxy can't find the
connection ID and immediately rejects the call with a "500 No error (2/SL)"
-

Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: WARNING: 
[core/msg_translator.c:2861]: via_builder(): TCP/TLS connection (id: 0) for
WebSocket could not be found
Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: 
[core/msg_translator.c:2038]: build_req_buf_from_sip_req(): could not
create Via header
Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm [t_fwd.c:479]:
prepare_new_uac(): could not build request
Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm [t_fwd.c:1759]:
t_forward_nonack(): failure to add branches
Oct  5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: sl [sl_funcs.c:414]:
sl_reply_error(): stateless error reply used: No error (2/SL)

How can we catch this error to avoid terminating the call prematurely? Or
should we flush these TCP connections on start up?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Fwd: Catching an overall timeout after dropping replies

[Marrold]

Hi,

This is partially related to a previous thread -
https://lists.kamailio.org/pipermail/sr-users/2021-August/113128.html

We are using the TSILO module to suspend transactions whilst we wait for
mobile app users to register after receiving a push notification.

In the time we are waiting for the app to register, other UAs might reject
the call (DND, Busy, etc). To avoid this failure response being relayed to
the caller, we use t_drop_replies in the failure_route.

Eventually if all devices have rejected the call Kamailio times out and
sends a 408 Request Timeout. Is there any way we can catch this error, and
replace it with the last response we got from an actual UA?

t_is_expired() and t_branch_timeout() don't seem to apply as they're on the
*called* side. Is there another option to catch this overall timeout?

As a side note, failure_route is quite limited in the actions that can take
place there. Is it safe to access variables and update a htable?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to drop negative final response and send ACK

[Marrold]

Hi Koray,

I'm glad you mentioned this, I'm currently working on a similar
configuration and tested your scenario and found the same thing. I'm
assuming you're using TSILO?

I just quickly tried this in the failure_route and it appears to be working
but I'm sure there's still some optimisations to be done. It might need
adapting for your situation.

if ($sht(tsilo=>active_branch::$tU) &&
t_check_status("[456][0-9][0-9]") ) {
t_drop_replies();
t_suspend();
xlog("suspended transaction [$T(id_index):$T(id_label)] $fU
=> $rU\n");
$sht(tsilo=>suspended::$tU) = "" + $T(id_index) + ":" +
$T(id_label);
exit;
}

One obvious issue currently is when the mobile client registers it resumes
the suspended transaction and does another look up on the location table,
and then sends a new INVITE to the device that previously rejected the
call. If that's a user that manually rejected a call it will be quite
annoying.

I'll follow up tomorrow when I've spent more time on this, but hopefully it
gets you started.

Thanks
Matthew



On Mon, Aug 16, 2021 at 4:04 PM Koray Vatansever 
wrote:

> Hi,
>
> I have a problem with the following scenario:
>
> I have web and mobile sip clients for the same username.
>
> If both clients are idle, INVITE is forked and both clients ring.
> If web client is busy and mobile client is online and registered, the
> mobile client rings and the caller hears ringback tone.
> If web client is busy and mobile client is offline, before the mobile
> client receives push notification and registers, web client sends 486 busy
> response and caller hears busy tone.
>
> In this last scenario, I want to wait some time for the mobile client to
> register and ring.
> I tried to drop 486 response in onreply_route[x], but I found that final
> responses cannot be dropped in this route.
> I dropped 486 in reply_route, but I couldn't send an ACK for this
> transaction.
>
> Is there a way to implement this scenario?
>
> I would appreciate if you have any suggestions.
>
> Thanks,
> Koray
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Issues with TOPOS when not relaying an in-dialog request

[Marrold]

> for me, it seems you don't handle subscribe as other requests and it
> changes IP which came at the Contact header. Then this address is used for
> for the rest of the requests in this dialog.
>

Yes that's correct. For the SUBSCRIBE I *sl_send_reply* and exit without
relaying the message. Everything else gets relayed. If I relay the
SUBSCRIBE like other messages, the subsequent BYE is sent to the correct IP
and everything works as expected.

Thanks



>
> чт, 5 авг. 2021 г. в 14:27, Marrold :
>
>> Hi Henning,
>>
>> I realised as soon as I sent the message I'd forgotten that important
>> detail. It's 5.5.1 on Debian 10 from the repos.
>>
>> Thanks!
>>
>> On Thu, Aug 5, 2021 at 8:53 AM Henning Westerholt  wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> Others might be able to comment in more detail, but quick question:
>>> which version of Kamailio you are using?
>>>
>>> For 5.5.x branch some extensions were added to the topos module for
>>> SUBSCRIBEs:
>>>
>>>
>>>
>>> +This module is designed to work for presence
>>> (SUBSCRIBE-based) dialogs too.
>>>
>>> +   The REGISTER and PUBLISH requests are skipped from
>>> processing
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Henning
>>>
>>>
>>>
>>> --
>>>
>>> Henning Westerholt – https://skalatan.de/blog/
>>>
>>> Kamailio services – https://gilawa.com
>>>
>>>
>>>
>>> *From:* sr-users  *On Behalf Of *
>>> Marrold
>>> *Sent:* Wednesday, August 4, 2021 10:15 PM
>>> *To:* Kamailio (SER) - Users Mailing List 
>>> *Subject:* [SR-Users] Issues with TOPOS when not relaying an in-dialog
>>> request
>>>
>>>
>>>
>>> Hi,
>>>
>>> I am currently using TOPOS to make Kamailio behave more like a B2BUA
>>> from the clients perspective. It's working well, however I have discovered
>>> a scenario where it fails.
>>>
>>> To aid with some interoperability I am sending (sl_send_reply) 200 OK to
>>> an in-dialog SUBSCRIBE request during a call. Once this has happened, the
>>> subsequent BYE from the B leg goes to the incorrect (Private) IP. If I
>>> disable this SUBSCRIBE, or relay it to the B leg, the BYE goes to the
>>> expected IP address.
>>>
>>>
>>>
>>> Does anyone know where I am going wrong? I have tried not calling
>>> record_route() for these messages but the result is the same.
>>>
>>>
>>>
>>> I've attached the ladder diagram of the call below. Note the subscribe
>>> is not relayed in this scenario.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Issues with TOPOS when not relaying an in-dialog request

[Marrold]

Hi,

It's a crude proof of concept at the moment and isn't working entirely as
expected - but to enable it was mostly just a case of including the TOPOS
module with MySQL backend (Redis is probably better for high traffic
environment) and adding a couple of record_routes() for non-dialog messages.

Once I get to the bottom of this issue I'll try to share something.

Thanks

On Thu, Aug 5, 2021 at 2:45 PM mohsen khashei  wrote:

> Hi marrold can you share your config . I an trying to use kamailio as
> b2bua with no success may be seeing some config help me.
> Thanks
>
> On Thu, Aug 5, 2021, 4:55 PM Marrold  wrote:
>
>> Hi Henning,
>>
>> I realised as soon as I sent the message I'd forgotten that important
>> detail. It's 5.5.1 on Debian 10 from the repos.
>>
>> Thanks!
>>
>> On Thu, Aug 5, 2021 at 8:53 AM Henning Westerholt  wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> Others might be able to comment in more detail, but quick question:
>>> which version of Kamailio you are using?
>>>
>>> For 5.5.x branch some extensions were added to the topos module for
>>> SUBSCRIBEs:
>>>
>>>
>>>
>>> +This module is designed to work for presence
>>> (SUBSCRIBE-based) dialogs too.
>>>
>>> +   The REGISTER and PUBLISH requests are skipped from
>>> processing
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Henning
>>>
>>>
>>>
>>> --
>>>
>>> Henning Westerholt – https://skalatan.de/blog/
>>>
>>> Kamailio services – https://gilawa.com
>>>
>>>
>>>
>>> *From:* sr-users  *On Behalf Of *
>>> Marrold
>>> *Sent:* Wednesday, August 4, 2021 10:15 PM
>>> *To:* Kamailio (SER) - Users Mailing List 
>>> *Subject:* [SR-Users] Issues with TOPOS when not relaying an in-dialog
>>> request
>>>
>>>
>>>
>>> Hi,
>>>
>>> I am currently using TOPOS to make Kamailio behave more like a B2BUA
>>> from the clients perspective. It's working well, however I have discovered
>>> a scenario where it fails.
>>>
>>> To aid with some interoperability I am sending (sl_send_reply) 200 OK to
>>> an in-dialog SUBSCRIBE request during a call. Once this has happened, the
>>> subsequent BYE from the B leg goes to the incorrect (Private) IP. If I
>>> disable this SUBSCRIBE, or relay it to the B leg, the BYE goes to the
>>> expected IP address.
>>>
>>>
>>>
>>> Does anyone know where I am going wrong? I have tried not calling
>>> record_route() for these messages but the result is the same.
>>>
>>>
>>>
>>> I've attached the ladder diagram of the call below. Note the subscribe
>>> is not relayed in this scenario.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Issues with TOPOS when not relaying an in-dialog request

[Marrold]

Hi Henning,

I realised as soon as I sent the message I'd forgotten that important
detail. It's 5.5.1 on Debian 10 from the repos.

Thanks!

On Thu, Aug 5, 2021 at 8:53 AM Henning Westerholt  wrote:

> Hello,
>
>
>
> Others might be able to comment in more detail, but quick question: which
> version of Kamailio you are using?
>
> For 5.5.x branch some extensions were added to the topos module for
> SUBSCRIBEs:
>
>
>
> +This module is designed to work for presence
> (SUBSCRIBE-based) dialogs too.
>
> +   The REGISTER and PUBLISH requests are skipped from
> processing
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *
> Marrold
> *Sent:* Wednesday, August 4, 2021 10:15 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* [SR-Users] Issues with TOPOS when not relaying an in-dialog
> request
>
>
>
> Hi,
>
> I am currently using TOPOS to make Kamailio behave more like a B2BUA from
> the clients perspective. It's working well, however I have discovered a
> scenario where it fails.
>
> To aid with some interoperability I am sending (sl_send_reply) 200 OK to
> an in-dialog SUBSCRIBE request during a call. Once this has happened, the
> subsequent BYE from the B leg goes to the incorrect (Private) IP. If I
> disable this SUBSCRIBE, or relay it to the B leg, the BYE goes to the
> expected IP address.
>
>
>
> Does anyone know where I am going wrong? I have tried not calling
> record_route() for these messages but the result is the same.
>
>
>
> I've attached the ladder diagram of the call below. Note the subscribe is
> not relayed in this scenario.
>
>
>
> Thanks!
>
>
>
>
>
>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Converting Cisco SIP NOTIFY DTMF to SIP INFO (Binary operations)

[Marrold]

Hi,

I am using an old Cisco 2811 with an FXS card and trying to get it to
convert between POTS and SIP. Mostly for "fun". For the most part it works,
however there are some problems with DTMF in the call.

Because the end device uses pulse dialling it seems that only the Cisco
Proprietary SIP NOTIFY method of sending DTMF is supported. It sends 4
bytes in the message body that indicate the DTMF digit sent. I'd like to
convert it to the more standard SIP INFO method. The docs about the
encoding are here -
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-dtmf.html#GUID-773FBE1F-004E-411B-ABD2-23AA60ED6E84

I looked at the transformations but couldn't find anything relevant. Is it
possible to extract the binary from the body and decode it?

Thanks
Matthew
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Setting $conid per branch

[Marrold]

Hi,

Apologies for the delay updating this one - it took longer than expected to
get our test platform upgraded to the latest kamailio version that included
the newer TCPOPS functions.

I can confirm that using tcp_get_conid() and tcp_set_otcpid() appears to
work around the issue. I'm still curious why Kamailio is intermittently
getting the wrong connection ID internally.

Thinking about it some more, the issue is actually occuring on the
*main* branch
when we set the following vars from the output of reg_fetch_contacts, as
it's only returning a single contact during testing.

$ru = $var(addr);
$du = $var(received);
$bf = $var(cflags);
$fs = $var(socket);

Thanks


On Tue, Mar 30, 2021 at 12:08 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> can you try with master branch to use sbranch-related functions from pv
> module along with the result from reg_fetch_contact().
>
> Cheers,
> Daniel
> On 19.03.21 11:13, Marrold wrote:
>
> We don't see the issue when using the standard lookup() function, only
> when we start manually appending branches with the results
> from  reg_fetch_contact()
>
> Thanks
> Matthew
>
> On Wed, Mar 17, 2021 at 7:18 AM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>>
>> On 11.03.21 10:55, Marrold wrote:
>>
>> Hi Daniel,
>>
>> I didn't spot those TCPOPs functions, I'll give them a try and let you
>> know how I get on.
>>
>> Do you have any idea why Kamailio is intermittently selecting the wrong
>> connection using ID vs peer address?
>>
>>
>> have you tried and got that with lookup("location") or only with your
>> script-based reg_fetch_contact()?
>>
>> Cheers,
>> Daniel
>>
>>
>> Thanks for the suggestions.
>> Matthew
>>
>> On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla <
>> mico...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> a while ago I did some work to make possible to specify the outgoing tcp
>>> connection id, see:
>>>
>>>   *
>>> https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.tcp_set_otcpid
>>>
>>> And the next function after it.
>>>
>>> However, the testing was minimal, maybe not verifying the entire chain
>>> with t_relay()/forward(). Even more, the specifying of the outbound tcp
>>> connection was supposed to be done internally by the lookup("location"),
>>> the functions from tcpops being added for more config flexibility, suitable
>>> for single branch forwarding or branch_route blocks.
>>>
>>> However, in your seem to do manual processing with reg_fetch_contacts(),
>>> not rely on lookup location. You can test with master and use $sbranch(...)
>>> and corresponding functions from pv module, instead of setting the r-uri
>>> and append_branch().
>>>
>>> Cheers,
>>> Daniel
>>> On 10.03.21 06:00, Marrold wrote:
>>>
>>> Hi,
>>>
>>> I've done a bit more digging and realised that $conid is read-only, and
>>> only available for an inbound connection - so I dont think it will achieve
>>> what I need.
>>>
>>> I did a bit more troubleshooting and observed the differences in the
>>> debug log between two identical calls:
>>>
>>> This example failed - the INVITEs went out to the incorrect endpoint /
>>> TCP connection. The "ulc_conid" from the location table for the TCP
>>> endpoint is 13:
>>>
>>> Mar  9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: 

Re: [SR-Users] Bad config - you can not call 'handle_publish' function (db_url not set)

[Marrold]

Hi Daniel,

That fixed the issue, thanks as always.

On Wed, May 12, 2021 at 5:18 PM Daniel-Constantin Mierla 
wrote:

> Hello,
> On 12.05.21 18:01, Marrold wrote:
>
> Hi All,
>
> I've performed some crude troubleshooting and managed to replicate the
> issue with the Debian packages and standard installation
> <https://kamailio.org/docs/tutorials/devel/kamailio-install-guide-deb/>
> with example configuration, the only changes to kamailio.cfg are:
>
> #!define WITH_MYSQL
> #!define WITH_PRESENCE
>
> modparam("presence", "local_log_facility", "LOG_LOCAL3")
>
> When the "local_log_facility" parameter is defined as per the
> documentation
> <https://kamailio.org/docs/modules/5.4.x/modules/presence.html#presence.p.local_log_facility>,
> Kamailio will fail to start with the following error:
>
> May 12 15:48:41 kamailio /usr/sbin/kamailio[13050]: ERROR: presence
> [presence.c:656]: fixup_presence(): Bad config - you can not call
> 'handle_publish' function (db_url not set)
> May 12 15:48:41 kamailio /usr/sbin/kamailio[13050]: ERROR: 
> [core/route.c:1166]: fix_actions(): fixing failed (code=-1) at
> cfg:/etc/kamailio/kamailio.cfg:769
> May 12 15:48:41 kamailio /usr/sbin/kamailio[13050]: ERROR: 
> [core/route.c:1166]: fix_actions(): fixing failed (code=-1) at
> cfg:/etc/kamailio/kamailio.cfg:775
>
> If I set it as the following, Kamailio starts up without error:
>
> modparam("presence", "local_log_facility", "3")
>
> can you try with the patch from the next commit?
>
>   *
> https://github.com/kamailio/kamailio/commit/5f4662a95a97d5224bf03745a9a354a41925706c
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
>   * https://www.asipto.com/sw/kamailio-advanced-training-online/
>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Bad config - you can not call 'handle_publish' function (db_url not set)

[Marrold]

Hi All,

I've performed some crude troubleshooting and managed to replicate the
issue with the Debian packages and standard installation
<https://kamailio.org/docs/tutorials/devel/kamailio-install-guide-deb/>
with example configuration, the only changes to kamailio.cfg are:

#!define WITH_MYSQL
#!define WITH_PRESENCE

modparam("presence", "local_log_facility", "LOG_LOCAL3")

When the "local_log_facility" parameter is defined as per the documentation
<https://kamailio.org/docs/modules/5.4.x/modules/presence.html#presence.p.local_log_facility>,
Kamailio will fail to start with the following error:

May 12 15:48:41 kamailio /usr/sbin/kamailio[13050]: ERROR: presence
[presence.c:656]: fixup_presence(): Bad config - you can not call
'handle_publish' function (db_url not set)
May 12 15:48:41 kamailio /usr/sbin/kamailio[13050]: ERROR: 
[core/route.c:1166]: fix_actions(): fixing failed (code=-1) at
cfg:/etc/kamailio/kamailio.cfg:769
May 12 15:48:41 kamailio /usr/sbin/kamailio[13050]: ERROR: 
[core/route.c:1166]: fix_actions(): fixing failed (code=-1) at
cfg:/etc/kamailio/kamailio.cfg:775

If I set it as the following, Kamailio starts up without error:

modparam("presence", "local_log_facility", "3")

Thanks









On Tue, May 11, 2021 at 8:12 PM Marrold  wrote:

> Hi Both,
>
> Juha - Thanks for sharing your config , I tweaked the values in my config
> but still experience the same issue.
>
> Daniel - We're not using the utils module, although we are using siputils
> and cfgutils. OS is stock Debian 10 and GCC is version 8.3.0
>
> For what it's worth I edited the "Bad config - you can not call
> 'handle_publish' function" log line to include the value for 
> *pres_library_mode
> *and it appears to be set to 10. Where that's coming from, I have no idea.
>
> Thanks again
>
>
>
> On Mon, May 10, 2021 at 6:10 PM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> do you use utils module? If yes, what is your operating system and the
>> compiler version (if you compiled from sources, not installing from
>> packages)?
>>
>> Cheers,
>> Daniel
>> On 10.05.21 15:01, Marrold wrote:
>>
>> Hi,
>>
>> We're trying to upgrade from 5.3.X to 5.4.5 however kamailio will not
>> start and produces the following error, despite the db_url being set in the
>> config and printed in the logs:
>>
>> Bad config - you can not call 'handle_publish' function (db_url not set)
>>
>> Looking at the code this error only seems plausible if the
>> *pres_library_mode* is set to 1 here
>> <https://github.com/kamailio/kamailio/blob/cc2a9518207e36b7b18aef5c8714f0c21da3dd95/src/modules/presence/presence.c#L296>
>>  but
>> we don't see the corresponding "switch to library mode" message in the
>> debug logs which leaves me a bit stuck - I've included the grepped logs at
>> the bottom of the message.
>>
>> Does anyone have any ideas what is causing this issue? I've seen a
>> previous issue relating to interactions between presence and presence_xml
>> which we're also using, but it looks like this was fixed in an older
>> version.
>>
>> Any suggestions appreciated.
>>
>> # - presence params -
>> modparam("presence", "db_url", DBURL)
>> modparam("presence", "db_update_period", 20)
>> modparam("presence", "clean_period", 60)
>> modparam("presence", "local_log_facility", "LOG_LOCAL3")
>> modparam("presence", "max_expires", 14430)
>>
>> # - presence_xml params -
>> modparam("presence_xml", "db_url", DBURL)
>> modparam("presence_xml", "force_active", 1)
>>
>> root@kamailio:/etc/kamailio# grep -i "presence"
>> /var/log/kamailio/kamailio.log
>> May 10 12:44:14 kamailio /sbin/kamailio[23729]: ERROR: presence
>> [presence.c:656]: fixup_presence(): Bad config - you can not call
>> 'handle_publish' function (db_url not set)
>> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
>> yyparse(): loading module presence.so
>> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
>> load_module(): trying to load 
>> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/kemi.c:2927]:
>> sr_kemi_modules_add(): adding module: presence
>> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:287]:
>> register_module(): register PV from: presence
>> May 10 12:44:41

Re: [SR-Users] Bad config - you can not call 'handle_publish' function (db_url not set)

[Marrold]

Hi Both,

Juha - Thanks for sharing your config , I tweaked the values in my config
but still experience the same issue.

Daniel - We're not using the utils module, although we are using siputils
and cfgutils. OS is stock Debian 10 and GCC is version 8.3.0

For what it's worth I edited the "Bad config - you can not call
'handle_publish' function" log line to include the value for *pres_library_mode
*and it appears to be set to 10. Where that's coming from, I have no idea.

Thanks again



On Mon, May 10, 2021 at 6:10 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> do you use utils module? If yes, what is your operating system and the
> compiler version (if you compiled from sources, not installing from
> packages)?
>
> Cheers,
> Daniel
> On 10.05.21 15:01, Marrold wrote:
>
> Hi,
>
> We're trying to upgrade from 5.3.X to 5.4.5 however kamailio will not
> start and produces the following error, despite the db_url being set in the
> config and printed in the logs:
>
> Bad config - you can not call 'handle_publish' function (db_url not set)
>
> Looking at the code this error only seems plausible if the
> *pres_library_mode* is set to 1 here
> <https://github.com/kamailio/kamailio/blob/cc2a9518207e36b7b18aef5c8714f0c21da3dd95/src/modules/presence/presence.c#L296>
>  but
> we don't see the corresponding "switch to library mode" message in the
> debug logs which leaves me a bit stuck - I've included the grepped logs at
> the bottom of the message.
>
> Does anyone have any ideas what is causing this issue? I've seen a
> previous issue relating to interactions between presence and presence_xml
> which we're also using, but it looks like this was fixed in an older
> version.
>
> Any suggestions appreciated.
>
> # - presence params -
> modparam("presence", "db_url", DBURL)
> modparam("presence", "db_update_period", 20)
> modparam("presence", "clean_period", 60)
> modparam("presence", "local_log_facility", "LOG_LOCAL3")
> modparam("presence", "max_expires", 14430)
>
> # - presence_xml params -
> modparam("presence_xml", "db_url", DBURL)
> modparam("presence_xml", "force_active", 1)
>
> root@kamailio:/etc/kamailio# grep -i "presence"
> /var/log/kamailio/kamailio.log
> May 10 12:44:14 kamailio /sbin/kamailio[23729]: ERROR: presence
> [presence.c:656]: fixup_presence(): Bad config - you can not call
> 'handle_publish' function (db_url not set)
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
> yyparse(): loading module presence.so
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
> load_module(): trying to load 
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/kemi.c:2927]:
> sr_kemi_modules_add(): adding module: presence
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:287]:
> register_module(): register PV from: presence
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
> pp_define(): defining id: MOD_presence
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
> yyparse(): loading module presence_xml.so
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
> load_module(): trying to load 
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/kemi.c:2927]:
> sr_kemi_modules_add(): adding module: presence_xml
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
> pp_define(): defining id: MOD_presence_xml
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
> yyparse(): loading module presence_mwi.so
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
> load_module(): trying to load 
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
> pp_define(): defining id: MOD_presence_mwi
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
> yyparse(): loading module presence_dialoginfo.so
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
> load_module(): trying to load
> 
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
> pp_define(): defining id: MOD_presence_dialoginfo
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:107]:
> set_mod_param_regex(): 'presence' matches module 'presence'
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:744]:
> find_param_export(): found  in module presence
> [/lib64/kamailio/modules/presence.so]
> May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:123]:
> set_mod_param_regex(): found  in module presence
> [/lib64/ka

[SR-Users] Bad config - you can not call 'handle_publish' function (db_url not set)

[Marrold]

Hi,

We're trying to upgrade from 5.3.X to 5.4.5 however kamailio will not start
and produces the following error, despite the db_url being set in the
config and printed in the logs:

Bad config - you can not call 'handle_publish' function (db_url not set)

Looking at the code this error only seems plausible if the
*pres_library_mode* is set to 1 here

but
we don't see the corresponding "switch to library mode" message in the
debug logs which leaves me a bit stuck - I've included the grepped logs at
the bottom of the message.

Does anyone have any ideas what is causing this issue? I've seen a previous
issue relating to interactions between presence and presence_xml which
we're also using, but it looks like this was fixed in an older version.

Any suggestions appreciated.

# - presence params -
modparam("presence", "db_url", DBURL)
modparam("presence", "db_update_period", 20)
modparam("presence", "clean_period", 60)
modparam("presence", "local_log_facility", "LOG_LOCAL3")
modparam("presence", "max_expires", 14430)

# - presence_xml params -
modparam("presence_xml", "db_url", DBURL)
modparam("presence_xml", "force_active", 1)

root@kamailio:/etc/kamailio# grep -i "presence"
/var/log/kamailio/kamailio.log
May 10 12:44:14 kamailio /sbin/kamailio[23729]: ERROR: presence
[presence.c:656]: fixup_presence(): Bad config - you can not call
'handle_publish' function (db_url not set)
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
yyparse(): loading module presence.so
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
load_module(): trying to load 
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/kemi.c:2927]:
sr_kemi_modules_add(): adding module: presence
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:287]:
register_module(): register PV from: presence
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
pp_define(): defining id: MOD_presence
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
yyparse(): loading module presence_xml.so
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
load_module(): trying to load 
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/kemi.c:2927]:
sr_kemi_modules_add(): adding module: presence_xml
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
pp_define(): defining id: MOD_presence_xml
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
yyparse(): loading module presence_mwi.so
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
load_module(): trying to load 
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
pp_define(): defining id: MOD_presence_mwi
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.y:1810]:
yyparse(): loading module presence_dialoginfo.so
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:525]:
load_module(): trying to load

May 10 12:44:41 kamailio kamailio: DEBUG:  [core/cfg.lex:1796]:
pp_define(): defining id: MOD_presence_dialoginfo
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:107]:
set_mod_param_regex(): 'presence' matches module 'presence'
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:744]:
find_param_export(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:123]:
set_mod_param_regex(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:107]:
set_mod_param_regex(): 'presence' matches module 'presence'
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:744]:
find_param_export(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:123]:
set_mod_param_regex(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:107]:
set_mod_param_regex(): 'presence' matches module 'presence'
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:744]:
find_param_export(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:123]:
set_mod_param_regex(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:107]:
set_mod_param_regex(): 'presence' matches module 'presence'
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/sr_module.c:744]:
find_param_export(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:123]:
set_mod_param_regex(): found  in module presence
[/lib64/kamailio/modules/presence.so]
May 10 12:44:41 kamailio kamailio: DEBUG:  [core/modparam.c:107]:
set_mod_param_regex(): 'presence' matches module 'presence'
May 10 12:44:41 kamailio kamailio: DEB

Re: [SR-Users] geting $conid on outbound INVITE

[Marrold]

Hi David,

I've previously looked at $conid and I was under the impression it was only
available as the *source* connection ID for received messages, not the
destination connection ID. Some experiments confirmed this, although I
didn't dig too deeply into the code.

It's inferred in the docs

that it's only for messages arriving at Kamailio: "The TCP connection ID of
the connection the current message *arrived* on for TCP, TLS, WS, and WSS.
Set to $null for SCTP and UDP."

There is however tcp_get_conid

available
in the TCPOPS module in 5.3 and up which will retrieve the destination
connection ID.

Cheers



On Tue, May 4, 2021 at 2:50 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Hello guys,
>
> Ok i got this with (WITHINDLG):
>
> if ($du == "") {
> if (!handle_ruri_alias()) {
> xlog("L_ERR", "[$ci][$rm]: bad alias <$ru>");
> sl_send_reply("400", "Bad Request");
> exit;
> } else {
> $var(tmp) = $(du{s.replace,sip:,}{re.subst,/;.*//});
> xlog("L_ERR", "[$ci][$rm]: Packet is going to
> <$var(tmp)>");
> if(tcp_get_conid("$var(tmp)", "$var(conid)")) {
> xlog("connection id is: $var(conid)\n");
> }
> }
> }
>
>
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Tue, May 4, 2021 at 2:16 PM David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
>> Hello guys,
>>
>> I don't have a lot of experience with webrtc (websocket).
>> I'm trying to get $conid when i receive an INVITE via UDP which is GOING
>> to a ws, how do i do that?
>>
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.w...@gmail.com
>> phone: +34669448337
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Setting $conid per branch

[Marrold]

We don't see the issue when using the standard lookup() function, only when
we start manually appending branches with the results
from  reg_fetch_contact()

Thanks
Matthew

On Wed, Mar 17, 2021 at 7:18 AM Daniel-Constantin Mierla 
wrote:

> Hello,
>
>
> On 11.03.21 10:55, Marrold wrote:
>
> Hi Daniel,
>
> I didn't spot those TCPOPs functions, I'll give them a try and let you
> know how I get on.
>
> Do you have any idea why Kamailio is intermittently selecting the wrong
> connection using ID vs peer address?
>
>
> have you tried and got that with lookup("location") or only with your
> script-based reg_fetch_contact()?
>
> Cheers,
> Daniel
>
>
> Thanks for the suggestions.
> Matthew
>
> On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> a while ago I did some work to make possible to specify the outgoing tcp
>> connection id, see:
>>
>>   *
>> https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.tcp_set_otcpid
>>
>> And the next function after it.
>>
>> However, the testing was minimal, maybe not verifying the entire chain
>> with t_relay()/forward(). Even more, the specifying of the outbound tcp
>> connection was supposed to be done internally by the lookup("location"),
>> the functions from tcpops being added for more config flexibility, suitable
>> for single branch forwarding or branch_route blocks.
>>
>> However, in your seem to do manual processing with reg_fetch_contacts(),
>> not rely on lookup location. You can test with master and use $sbranch(...)
>> and corresponding functions from pv module, instead of setting the r-uri
>> and append_branch().
>>
>> Cheers,
>> Daniel
>> On 10.03.21 06:00, Marrold wrote:
>>
>> Hi,
>>
>> I've done a bit more digging and realised that $conid is read-only, and
>> only available for an inbound connection - so I dont think it will achieve
>> what I need.
>>
>> I did a bit more troubleshooting and observed the differences in the
>> debug log between two identical calls:
>>
>> This example failed - the INVITEs went out to the incorrect endpoint /
>> TCP connection. The "ulc_conid" from the location table for the TCP
>> endpoint is 13:
>>
>> Mar  9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: 

Re: [SR-Users] Setting $conid per branch

[Marrold]

Hi Daniel,

I didn't spot those TCPOPs functions, I'll give them a try and let you know
how I get on.

Do you have any idea why Kamailio is intermittently selecting the wrong
connection using ID vs peer address?

Thanks for the suggestions.
Matthew

On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> a while ago I did some work to make possible to specify the outgoing tcp
> connection id, see:
>
>   *
> https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.tcp_set_otcpid
>
> And the next function after it.
>
> However, the testing was minimal, maybe not verifying the entire chain
> with t_relay()/forward(). Even more, the specifying of the outbound tcp
> connection was supposed to be done internally by the lookup("location"),
> the functions from tcpops being added for more config flexibility, suitable
> for single branch forwarding or branch_route blocks.
>
> However, in your seem to do manual processing with reg_fetch_contacts(),
> not rely on lookup location. You can test with master and use $sbranch(...)
> and corresponding functions from pv module, instead of setting the r-uri
> and append_branch().
>
> Cheers,
> Daniel
> On 10.03.21 06:00, Marrold wrote:
>
> Hi,
>
> I've done a bit more digging and realised that $conid is read-only, and
> only available for an inbound connection - so I dont think it will achieve
> what I need.
>
> I did a bit more troubleshooting and observed the differences in the debug
> log between two identical calls:
>
> This example failed - the INVITEs went out to the incorrect endpoint / TCP
> connection. The "ulc_conid" from the location table for the TCP endpoint is
> 13:
>
> Mar  9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: 

Re: [SR-Users] Setting $conid per branch

[Marrold]

Hi,

I've done a bit more digging and realised that $conid is read-only, and
only available for an inbound connection - so I dont think it will achieve
what I need.

I did a bit more troubleshooting and observed the differences in the debug
log between two identical calls:

This example failed - the INVITEs went out to the incorrect endpoint / TCP
connection. The "ulc_conid" from the location table for the TCP endpoint is
13:

Mar  9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: 

[SR-Users] Setting $conid per branch

[Marrold]

Hi all,

I'm currently adding a feature to our Kamailio configuration to fork calls
based on user agent.

To do so I'm getting the registered endpoints with reg_fetch_contacts()
iterating through and matching on them, then using seturi() /
append_branch() and setting the dst-uri and flags as required.

However, calls are intermittently going to the wrong TCP connection,
despite the logs showing the correct destination IP and port in the ONSEND
route.

Looking in the location table I can see each registration has a
connection_id, and the debug log indicates it's finding the connection by
ID:

 DEBUG:  [core/tcp_main.c:1651]: _tcpconn_find(): found connection by
id: 3

Is there a way to set the conid per branch? Is it necessary?

We're using kamailio 5.3.3 on Debian 10.

Thanks
Matthew
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dispatcher - Force one end point active

[Marrold]

Hi Dmitri,

Thanks for the suggestion. I tested this and it's working as expected - not
sure how I missed it before.

Thanks again

Matthew

On Tue, Aug 21, 2018 at 5:25 PM, Dmitri Savolainen 
wrote:

> Did you try:
> ds_probing_mode = 3; you problem host in "AX" (flag=0) and others in "AP"
> (flag 8)
>
>
> On 21 August 2018 at 14:23, Marrold  wrote:
>
>> Hi,
>>
>> We are currently using the dispatcher module and probing end points with
>> OPTIONS, and making them active / inactive depending on the response:
>>
>> modparam("dispatcher", "ds_ping_method", "OPTIONS")
>> modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=3;code=404")
>> modparam("dispatcher", "ds_ping_from", "[REDACTED]")
>> modparam("dispatcher", "ds_ping_interval", 20)
>> modparam("dispatcher", "ds_probing_threshold", 1)
>> modparam("dispatcher", "ds_probing_mode", 1)
>>
>> One of our suppliers endpoints doesn't respond to SIP OPTIONS, is it
>> possible to force a single endpoint as active, but continue probing the
>> rest?
>>
>> I've tried various settings - both globally and flags for the individual
>> end point, but I couldn't seem to find the correct combination.
>>
>> Thanks
>>
>> Matthew
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
> Savolainen Dmitri
>
> ___
> 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

[SR-Users] Dispatcher - Force one end point active

[Marrold]

Hi,

We are currently using the dispatcher module and probing end points with
OPTIONS, and making them active / inactive depending on the response:

modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=3;code=404")
modparam("dispatcher", "ds_ping_from", "[REDACTED]")
modparam("dispatcher", "ds_ping_interval", 20)
modparam("dispatcher", "ds_probing_threshold", 1)
modparam("dispatcher", "ds_probing_mode", 1)

One of our suppliers endpoints doesn't respond to SIP OPTIONS, is it
possible to force a single endpoint as active, but continue probing the
rest?

I've tried various settings - both globally and flags for the individual
end point, but I couldn't seem to find the correct combination.

Thanks

Matthew
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Re-write From URI Domain ($fd) with source IP or relayed message

[Marrold]

Thanks Daniel, if that's the case we will re-write the from domain earlier
in the logic


On Wed, Jul 4, 2018 at 11:07 AM, Daniel Tryba  wrote:

> On Tue, Jul 03, 2018 at 11:21:50PM +0100, Marrold wrote:
> > For interoperability reasons I need to re-write the From URI Domain ($fd)
> > in requests proxied by Kamailio to the source IP (socket) that Kamailio
> > will send them via.
> >
> > I have experimented with onsend_route and can successfully discover the
> > snd_ip, however it seems I am unable to rewrite the $fd, presumably
> because
> > I am too late in the logic.
>
> Take a look at uac_replace_from:
> https://www.kamailio.org/docs/modules/5.1.x/modules/uac.
> html#uac.f.uac_replace_from
>
> onsend_route is to late for this modification, you'll need to figure out
> what the ip is in request_route of branche routes.
>
> ___
> 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

[SR-Users] Re-write From URI Domain ($fd) with source IP or relayed message

[Marrold]

Hi All,

For interoperability reasons I need to re-write the From URI Domain ($fd)
in requests proxied by Kamailio to the source IP (socket) that Kamailio
will send them via.

I have experimented with onsend_route and can successfully discover the
snd_ip, however it seems I am unable to rewrite the $fd, presumably because
I am too late in the logic.

Is this possible? I can hardcode IPs if required but would rather keep it
dynamic if I can.

Thanks in advance,

Matthew
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Invalid JSON when dumping htable with JSONRPC-S

[Marrold]

Hi All,

I am currently trying to retrieve the contents of a htable using the
JSONRPC-S module over HTTP, however I have observed if a slot contains
multiple values, the JSON returned has duplicate keys which could be
considered invalid.

Here are the relevant lines from kamailio.cfg -

event_route[xhttp:request] {
if ($hu =~ "^/carrier") {
jsonrpc_exec('{"jsonrpc": "2.0", "method": "htable.dump", "params"
: {"htable": "carrier"}, "id": 1}');
xhttp_reply("200", "OK", "text/html", "$jsonrpl(body)");
}
}

And the output, showing a slot with two items-


{
"entry": 5,
"size": 2,
"slot": {
"item": {
"name": "carrierA",
"value": "90",
"type": "str"
},
"item": {
"name": "carrierB",
"value": "190",
"type": "str"
}
}
}

And the same from `kamcmd -s unix:/tmp/kamailio_ctl htable.dump carrier` -

{
entry: 5
size: 2
slot: {
item: {
name: carrierA
value: 90
type: str
}
item: {
name: carrierB
value: 190
type: str
}
}
}

Would it be possible to change it to something like the following -

{
"entry": 5,
"size": 2,
"slot": [
{
"name": "carrierA",
"value": "90",
"type": "str"
},
{
"name": "carrierB",
"value": "190",
"type": "str"
}
]
}

Any other suggestions or work arounds would be appreciated,

Thanks
Matthew
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Having kamailio bind to a VRF device

[Marrold]

Hi George,

Did you have any luck getting VRFs working with Kamailio?

Thanks

Matthew

On Thu, Oct 12, 2017 at 8:06 PM, Mark Boyce  wrote:

> Hi
>
> I *think* I may have found it … although still not sure what’s doing the
> filtering.
>
> If I force the sending IP to be the the VPN interface on the sender by
> adding;
>
> modparam("siptrace", "force_send_sock", "sip:10.0.0.2:5060”)
>
> So packets now arrive at the receiver from the 10. IP rather than from the
> public IP of the sender
>
> … and magically it starts working.
>
> So something in Ubuntu 16.04 / zerotier is “filtering” packets which
> arrive on the VPN interface but with a no VPN IP
>
> Cheers
>
> Mark
>
>
> On 12 Oct 2017, at 19:59, Sergey Safarov  wrote:
>
> This may be NAT/iptables issue if used some type of virtualization
> Check UNDEPLIED connection using conntrack
>
> Sergey
>
> чт, 12 окт. 2017 г. в 20:27, Mark Boyce :
>
>> Hi
>>
>> Now using listen=udp:0.0.0.0:9060
>>
>> net stat agrees;
>>
>> netstat -plunt | grep kamailio
>> udp0  0 0.0.0.0:90600.0.0.0:*
>> 20486/kamailio
>>
>>
>> TCPDump of Sending / Receiving to zero tier port
>>
>> 17:06:19.617467 IP sbc-1.white-label.com.sip > 10.0.0.1.9060: SIP
>> 0x:  4510 04f1 a504  4011 904e 894a abd8  E...@
>> ..N.J..
>> 0x0010:  0a05 0172 13c4 2364 04dd 261b 0110 0211  ...r..#d..&.
>> 0x0020:  13c4 13d8 894a abd8 894a abd8 494e 5649  .J...J..INVI
>> 0x0030:  5445 2073 6970 3a32 4073 6263 2d31 2e77  TE.sip:
>> 2@sbc-1.w
>>
>> Nothing in Kamailio Logs
>>
>> Swap to using the real IP and I’m seeing the log line from the top of the
>> main route;
>>
>> Oct 12 19:09:32 vps465590 homer[20491]: ERROR: 

Re: [SR-Users] Inserting local path into shared USRLOC table.

[Marrold]

msg_apply_changes()  worked nicely, thanks guys

On Wed, Oct 11, 2017 at 10:45 AM, Charles Chance <
charles.cha...@sipcentric.com> wrote:

> Hello,
>
>
> On 11 Oct 2017 10:16 a.m., "Daniel Tryba"  wrote:
>
> On Tue, Oct 10, 2017 at 11:36:56PM +0100, Marrold wrote:
> > I've included add_path_received() in my REGISTRAR routing block, however
> I
> > see 'Path: [not set]' in the USRLOC table.
> >
> > Is it possible to force the insertion of the local proxy into the path
> > field?
>
> Like Daniel already mentioned, add the header and msg_apply_changes()
> For example:
> https://lists.kamailio.org//pipermail/sr-users/2015-April/087872.html
>
> > One additional question, in the case of NAT keepalives, is it possible to
> > only send these from the proxy the received the register request?
>
> I decided to not use kamailio itself for sending these OPTIONS but to
> use a simple script that queries the database and simply opens a
> connection to the local kamailio. Mainly because I needed to monitor
> some UAC and alert when it wasn't reachable (even though it is present
> in location). In your case select the approriate UACs on Path.
>
>   while($location=mysql_fetch_assoc($res))
>   {
> usleep(1000);
> $branch=uniqid();
> $send[$location['id']]=0;
> $dst=preg_replace('/.*@([^;]+);.*/',"$1",$location['path']);
> $dst=explode(':',$dst);
> if(count($dst)<2)
> {
>   $dst[1]=5060;
> }
> $str=<< OPTIONS {$location['contact']} SIP/2.0\r
> Via: SIP/2.0/UDP 127.0.1.1:$listenport;branch=$branch;rport;alias\r
> Route: {$location['path']}\r
> From: sip:pinger@localhost;tag={$location['ruid']}\r
> To: {$location['contact']}\r
> Call-ID: {$location['id']}-$listenport-$uid@localhost\r
> CSeq: 1 OPTIONS\r
> Content-Length: 0\r
> \r
>
> EOS;
> socket_sendto($sock,$str,strlen($str),MSG_EOR,$dst[0],$dst[1]);
>
>
>
> Just to add, another option is to use the nat_traversal module:
> https://kamailio.org/docs/modules/stable/modules/nat_traversal.html. We
> use it for this very reason.
>
> Cheers,
>
> Charles
>
>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
>
> ___
> 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

[SR-Users] Inserting local path into shared USRLOC table.

[Marrold]

Hi All,

I am wondering if the following is possible. For simplicity imagine two
asterisk boxes and two kamailio proxies. Kamailio on the edge, asterisk in
the 'core'

Kamailio <=> AsteriskAsterisk <=> Kamailio

A user may register to either kamailio proxy, and a call may originate from
either Asterisk box where it will be sent to its *local *Kamailio proxy.
>From there I'd like Kamailio to forward the request to the AoR, following
the same path the registration took if it registered to the other proxy, to
avoid NAT issues.

I think this requires a shared USRLOC table, and also for the proxy that
handled the registration to insert itself in the path of the USRLOC table.

The registrar module has the 'path_check_local' parameter which sounds
relevant, ignoring the path if the first hop is local.

I've included add_path_received() in my REGISTRAR routing block, however I
see 'Path: [not set]' in the USRLOC table.

Is it possible to force the insertion of the local proxy into the path
field?

One additional question, in the case of NAT keepalives, is it possible to
only send these from the proxy the received the register request?

Thanks in advance,

Matthew
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users