[SR-Users] Kamailio 5.4.4 and Siptrace

[pwerspire]

Hello,

I captured a tcpdump on this scenario and saw that in fact, the siptrace is
sending the 403 Forbidden towards Homer.
The issue is that for this local reply, Kamailio instead of using the
private interface as it does for the other messages, is choosing the public
interface, so the local reply doesn't arrive on heplify side.

After forcing the socket with send_sock_addr, the reply appears on Homer.
modparam("siptrace", "send_sock_addr", "sip:x.x.x.x:xxxx")

>From the documentation, I saw that if we don't use the send_sock_addr
Kamailio will choose the interface, but shouldn't it choose always the same
interface?

Thanks for the help finding the issue.
Regards,
Tiago


Daniel-Constantin Mierla <miconda at gmail.com> escreveu no dia segunda,
3/05/2021 à(s) 21:58:

> Hello,
>
> logs indicate that the siptrace is engaged when the reply is sent out:
>
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: siptrace
> [siptrace_hep.c:496]: pipport2su(): the port string is 5060
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: siptrace
> [siptrace_hep.c:496]: pipport2su(): the port string is 58530
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: <core>
> [core/proxy.c:264]: mk_proxy(): doing DNS lookup...
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: siptrace
> [siptrace_hep.c:184]: trace_send_hep3_duplicate(): setting up the
> socket_info
>
> Can you watch the network traffic with ngrep/wireshark and check if the
> reply is actually sent over?
>
> Cheers,
> Daniel
> On 03.05.21 19:16, pwerspire wrote:
>
> Hello,
>
> So I tested with the following configuration:
>
> modparam("siptrace", "duplicate_uri", "sip:x.x.x.x:9060")
> modparam("siptrace", "hep_mode_on", 1)
> modparam("siptrace", "trace_to_database", 0)
> #modparam("siptrace", "trace_flag", FLT_SIPTRACE)
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_mode", 1)
> modparam("siptrace", "hep_version", 3)
> modparam("siptrace", "hep_capture_id", 2040)
>
> I can see this on the logs:
>
> May 03 15:40:30  kamailio[6259]: ) 5(6267) DEBUG: sl [sl_funcs.c:554]:
> sl_run_callbacks(): execute callback for event type 1
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: siptrace
> [siptrace.c:1842]: trace_sl_onreply_out(): trace off...
> May 03 15:40:30 kamailio[6259]:  5(6267) DEBUG: <core>
> [core/parser/msg_parser.c:620]: parse_msg(): SIP Reply  (status):
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: <core>
> [core/parser/msg_parser.c:622]: parse_msg():  version: <SIP/2.0>
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: <core>
> [core/parser/msg_parser.c:624]: parse_msg():  status:  <403>
> May 03 15:40:30  kamailio[6259]:  5(6267) DEBUG: <core>
> [core/parser/msg_parser.c:626]: parse_msg():  reason:  <Forbidden>
>
> In attach is the log, I changed some of the values to mask the original
> values.
>
>
> Thanks,
> Regards,
> Tiago
>
>
> Daniel-Constantin Mierla <miconda at gmail.com> escreveu no dia segunda,
> 3/05/2021 à(s) 17:25:
>
>> Hello,
>>
>> local replies should be captured with trace_mode=1. Run with debug=3 in
>> kamailio.cfg and attach all log/debug messages printed by Kamailio for such
>> case (from the INVITE to the ACK processing).
>>
>> Cheers,
>> Daniel
>> On 03.05.21 16:31, pwerspire wrote:
>>
>> Hi,
>>
>> Thanks for your reply.
>>
>> We had the modparam("siptrace", "trace_mode", 1) but the issue with that
>> is that local error answers from kamailio doesn't appear.
>>
>> For example, when Kamailio receives the INVITE and replies with a
>> forbidden, the Invite and the ACK is there but the Forbidden is not.
>>
>> So with "trace_mode" 1 , everything works fine except this messages
>> missing and this was the problem that we tried to solve messing around with
>> the functions and flags.
>>
>> Regards,
>> Tiago
>>
>> Daniel-Constantin Mierla <miconda at gmail.com> escreveu no dia segunda,
>> 3/05/2021 à(s) 15:39:
>>
>>> Hello,
>>>
>>> On 03.05.21 11:02, pwer spire wrote:
>>> > Hi,
>>> >
>>> > Any one have some idea about this? Or how it should be configured in
>>> order to still have the original response received in kamailio instead of
>>> the mapping one?
>>>
>>> If you want all the traffic mirrored, then look at:
>>>
>>>   *
>>>
>>> https://www.kamailio.org/docs/modules/stable/modules/siptrace.html#siptrace.p.trace_mode
>>>
>>> It is simpler that the use of functions and flags to select what
>>> messages should be mirrored.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> --
>>> Daniel-Constantin Mierla -- www.asipto.com
>>> www.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 at 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
>> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
>>   * https://www.asipto.com/sw/kamailio-advanced-training-online/
>>
>> --
> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210504/cbe62232/attachment.htm>