[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] Re: Question for RFC junkies / kamailio modifying message bodies

[Henning Westerholt via sr-users]

Hello Christoph,

Kamailio is providing a lot of different functions. Some of these functions 
could be used to implement a network element with features which are forbidden 
in the RFC 3261 and/or other relevant RFCs.
One of the most prominent examples is e.g., rewriting of From and To headers. 
It is in the end the responsibility of the implementing person to ensure that 
the relevant standards in the specific environments are observed.

Cheers,

Henning

From: Valentin Christoph via sr-users 
Sent: Mittwoch, 6. März 2024 12:20
To: Kamailio (SER) - Users Mailing List 
Cc: Onic Roman ; Scherney Theodor 
; Friedrich Peter ; 
Wolfgang Gleinser ; Valentin Christoph 

Subject: [SR-Users] Question for RFC junkies / kamailio modifying message bodies

Hi all,

it might be a minor issue, or it might not be an issue at all, but I stumbled 
over following statements in RFC 3261:

Chapter 16.6 Request Forwarding (of a proxy)


  1. Copy request



 The proxy starts with a copy of the received request.  The copy

 MUST initially contain all of the header fields from the

 received request.  Fields not detailed in the processing

 described below MUST NOT be removed.  The copy SHOULD maintain

 the ordering of the header fields as in the received request.

 The proxy MUST NOT reorder field values with a common field

 name (See Section 
7.3.1).  The proxy 
MUST NOT add to, modify,

 or remove the message body.



 An actual implementation need not perform a copy; the primary

 requirement is that the processing for each next hop begin with

 the same request.

Chapter 16.7 Response Processing (at a proxy)


  9.  Forward response



 After performing the processing described in steps "Aggregate

 Authorization Header Field Values" through "Record-Route", the

 proxy MAY perform any feature specific manipulations on the

 selected response.  The proxy MUST NOT add to, modify, or

 remove the message body.  Unless otherwise specified, the proxy

 MUST NOT remove any header field values other than the Via

 header field value discussed in Section 
16.7 Item 3.  In

 particular, the proxy MUST NOT remove any "received" parameter

On the other hand, everywhere in the Internet (starting with stackoverflow), 
you can read it is OK, if a SIP proxy modifies a body, and also kamailio allows 
it.

Might be a question for the coffee break.

All the best
Christoph
__
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] Kamailio closing tcp connection on downstream responses

[Kjartan S via sr-users]

Trying to setup Kamailio with MS Teams Direct Routing.
I am familiar with the integration steps required by Microsoft (using contact 
header as FQDN, certified CA for certificate) aswell as the famous guide; 
https://skalatan.de/en/blog/kamailio-sbc-teams + 
https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip

Sending any SIP requests (Invite, ACK, BYE) toward MS is working fine (with 
provisional response received in Kamailio) - so there is obviously a working 
connection between Kamailio <-> MS Direct Routing environment. 

HOWEVER, once Kamailio is forwarding SIP responses to MS (provisional 
responses/200 OK received from UAS), then Kamailio is closing the TCP 
connection.
Please see attached logs below.

Any idea why Kamailio is closing the connection when trying to send provisional 
responses to MS?

- Using t_realy on original invite from MS 
- tcp_reuse_port=yes, tcp_rd_buf_size = 16384, tcp_connection_lifetime=3605, 
children=8, socket_workers=4
- No override rules in firewall
- OS; debian:11.7
- Notice that TLS connection is made on port :26627 - however, MS sends port 
:5061 in VIA header (on first Invite). This seems to me to be a conflict in 
ports.
https://www.kamailio.org/wiki/cookbooks/5.4.x/core#reply_route
"There is no network route that can be enforced for a SIP reply - it is sent 
based on Via header, according to SIP RFC3261"

-

Handshake complete for 52.114.76.76:26627

19(43) DEBUG: tls [tls_domain.c:818]: sr_ssl_ctx_info_callback(): SSL handshake 
done
19(43) DEBUG: tls [tls_server.c:473]: tls_accept(): TLS accept successful
19(43) DEBUG: tls [tls_server.c:476]: tls_accept(): tls_accept: new connection 
from 52.114.76.76:26627 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256
19(43) DEBUG: tls [tls_server.c:480]: tls_accept(): tls_accept: local socket: 
10.129.0.91:5061
19(43) DEBUG: tls [tls_server.c:420]: tls_dump_cert_info(): tls_accept: client 
certificate subject:/C=US/ST=WA/L=Redmond/O=Microsoft 
Corporation/CN=sip.pstnhub.microsoft.com
19(43) DEBUG: tls [tls_server.c:424]: tls_dump_cert_info(): tls_accept: client 
certificate issuer:/C=US/O=Microsoft Corporation/CN=Microsoft Azure RSA TLS 
Issuing CA 04

-

Kamailio trying to forward SIP response "183" to MS (response received from 
UAS).
Kamailio finds active connection by ID 13 / 0x7f4ecad0be08

20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}  
[core/tcp_main.c:1722]: _tcpconn_find(): found connection by id: 13
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}  
[core/tcp_main.c:2627]: tcpconn_send_put(): tcp connection found 
(0x7f4ecad0be08), acquiring fd
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}  
[core/tcp_main.c:2637]: tcpconn_send_put(): c=0x7f4ecad0be08, n=16
23(47) DEBUG:  [core/tcp_main.c:3982]: handle_ser_child(): read response= 
7f4ecad0be08, 2, fd -1 from 20 (44)
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}  
[core/tcp_main.c:2665]: tcpconn_send_put(): after receive_fd: c= 0x7f4ecad0be08 
n=8 fd=12
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}  
[core/tcp_main.c:2842]: tcpconn_do_send(): sending...
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}  
[core/tcp_main.c:2878]: tcpconn_do_send(): after real write: c= 0x7f4ecad0be08 
n=1191 fd=12

-

Kamailio immediately closes the connection due to EOF.

19(43) DEBUG:  [core/tcp_read.c:280]: tcp_read_data(): EOF on connection 
0x7f4ecad0be08 (state: 0, flags: 4018) - FD 10, bytes 0, rd-flags 1 
([52.114.76.76]:26627 -> [52.114.76.76]:5061)19(43) DEBUG:  
[core/tcp_read.c:1544]: tcp_read_req(): EOF
19(43) DEBUG:  [core/io_wait.h:597]: io_watch_del(): DBG: io_watch_del 
(0x555b3cf20260, 10, -1, 0x10) fd_no=2 called
19(43) DEBUG:  [core/tcp_read.c:1927]: handle_io(): removing from list 
0x7f4ecad0be08 id 13 fd 10, state 2, flags 4018, main fd 57, refcnt 2 
([52.114.76.76]:26627 -> [52.114.76.76]:5061)
19(43) DEBUG:  [core/tcp_read.c:1702]: release_tcpconn(): releasing con 
0x7f4ecad0be08, state -1, fd=10, id=13 ([52.114.76.76]:26627 -> 
[52.114.76.76]:5061)
__
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: Question for RFC junkies / kamailio modifying message bodies

[Alex Balashov via sr-users]

The RFCs are correct; strictly speaking, a proxy should not alter the 
encapsulated message body, or most other SIP message attributes.

Kamailio is a huge toolbox with many capabilities, not unlike a programming 
language. It gives one the power to do a great many things. 

Some of these things aren't standards-compliant, and that's okay. The ends 
justify the means. Other times--many times--call for judicious restraint, as 
just because Kamailio can do something doesn't mean that you should do it, or 
that using a tool Kamailio offers to do something bluntly is a good substitute 
for doing something delicately.

Knowing the difference is the soul of experience. :-)

-- Alex

> On 6 Mar 2024, at 06:19, Valentin Christoph via sr-users 
>  wrote:
> 
> Hi all,
>  it might be a minor issue, or it might not be an issue at all, but I 
> stumbled over following statements in RFC 3261:
>  Chapter 16.6 Request Forwarding (of a proxy)
>1. Copy request
>  
>  The proxy starts with a copy of the received request.  The copy
>  MUST initially contain all of the header fields from the
>  received request.  Fields not detailed in the processing
>  described below MUST NOT be removed.  The copy SHOULD maintain
>  the ordering of the header fields as in the received request.
>  The proxy MUST NOT reorder field values with a common field
>  name (See Section 7.3.1).  The proxy MUST NOT add to, modify,
>  or remove the message body.
>  
>  An actual implementation need not perform a copy; the primary
>  requirement is that the processing for each next hop begin with
>  the same request.
>  Chapter 16.7 Response Processing (at a proxy)
>9.  Forward response
>  
>  After performing the processing described in steps "Aggregate
>  Authorization Header Field Values" through "Record-Route", the
>  proxy MAY perform any feature specific manipulations on the
>  selected response.  The proxy MUST NOT add to, modify, or
>  remove the message body.  Unless otherwise specified, the proxy
>  MUST NOT remove any header field values other than the Via
>  header field value discussed in Section 16.7 Item 3.  In
>  particular, the proxy MUST NOT remove any "received" parameter
>  On the other hand, everywhere in the Internet (starting with stackoverflow), 
> you can read it is OK, if a SIP proxy modifies a body, and also kamailio 
> allows it.
>  Might be a question for the coffee break.
>  All the best
> Christoph
> __
> 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:


-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
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] Question for RFC junkies / kamailio modifying message bodies

[Valentin Christoph via sr-users]

Hi all,

it might be a minor issue, or it might not be an issue at all, but I stumbled 
over following statements in RFC 3261:

Chapter 16.6 Request Forwarding (of a proxy)


  1. Copy request



 The proxy starts with a copy of the received request.  The copy

 MUST initially contain all of the header fields from the

 received request.  Fields not detailed in the processing

 described below MUST NOT be removed.  The copy SHOULD maintain

 the ordering of the header fields as in the received request.

 The proxy MUST NOT reorder field values with a common field

 name (See Section 
7.3.1).  The proxy 
MUST NOT add to, modify,

 or remove the message body.



 An actual implementation need not perform a copy; the primary

 requirement is that the processing for each next hop begin with

 the same request.

Chapter 16.7 Response Processing (at a proxy)


  9.  Forward response



 After performing the processing described in steps "Aggregate

 Authorization Header Field Values" through "Record-Route", the

 proxy MAY perform any feature specific manipulations on the

 selected response.  The proxy MUST NOT add to, modify, or

 remove the message body.  Unless otherwise specified, the proxy

 MUST NOT remove any header field values other than the Via

 header field value discussed in Section 
16.7 Item 3.  In

 particular, the proxy MUST NOT remove any "received" parameter

On the other hand, everywhere in the Internet (starting with stackoverflow), 
you can read it is OK, if a SIP proxy modifies a body, and also kamailio allows 
it.

Might be a question for the coffee break.

All the best
Christoph
__
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: RADIUS ACC - Interim Updates

[Duarte Rocha via sr-users]

Thanks for the help.

I've ended up creating a route invoked by rtimer module where i check all 
active dialogs and for each of them sent a radius accounting update.

Cheers,

Duarte
__
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: