[SR-Users] Re: How to make a branch trigger persistent (still being active after failure route is triggered)?

2022-12-20 Thread Kaufman
> Does this make he variable more 'constant'? :-)

No - without quotes you're declaring it as though it were a constant.  Put it 
in quotes to indicate that it is a variable.

Kaufman

-Original Message-
From: Benoît Panizzon  
Sent: Tuesday, December 20, 2022 11:05 AM
To: Kaufman 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Re: How to make a branch trigger persistent (still 
being active after failure route is triggered)?

Hi

> Try quoting the pseudovariable?
> 
>t_on_branch("$avp(broute_trigger)");

Does this make he variable more 'constant'? :-)

I already built a switch/case contruct around it on a REARM_B_TRIGGER route 
which I now call in every failure route.

--
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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  
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.imp.ch%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C498395d08d6d4f85273108dae2ac66d0%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638071527335909559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uaf1Fk6P2x41%2FYuyaCOaNE9o7fbYuNBhTAAy9bWMXbE%3D&reserved=0
__
__
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: How to make a branch trigger persistent (still being active after failure route is triggered)?

2022-12-20 Thread Benoît Panizzon
Hi

> Try quoting the pseudovariable?
> 
>t_on_branch("$avp(broute_trigger)");

Does this make he variable more 'constant'? :-)

I already built a switch/case contruct around it on a
REARM_B_TRIGGER route which I now call in every failure route.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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] Re: How to make a branch trigger persistent (still being active after failure route is triggered)?

2022-12-20 Thread Kaufman
Try quoting the pseudovariable?

   t_on_branch("$avp(broute_trigger)");


Kaufman

-Original Message-
From: Benoît Panizzon  
Sent: Friday, December 16, 2022 10:28 AM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Re: How to make a branch trigger persistent (still being 
active after failure route is triggered)?

I tought I had found the solution:

 request_route
{

$avp(dispgroup) = 2001;
$avp(broute_trigger) = "BR_TO_NATIONAL";
t_on_branch($avp(broute_trigger));
route(DISPATCHCALL);

[...]

$avp(dispgroup) = 2002;
$avp(broute_trigger) = "BR_TO_INT";
t_on_branch($avp(broute_trigger));
route(DISPATCHCALL);
}

failure_route[DISPATCH_FAILURE]
{
[...]
# Set desired Branch Trigger again to try next
# dispatcher in list.
t_on_branch($avp(broute_trigger));
route(RELAY);
exit;
}

But no...

function t_on_branch: parameter 1 is not constant

Any 'tricks'?

--
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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  
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.imp.ch%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C7e7160292c034f881bea08dadfb3ad50%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638068260065887727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yfhnAfcj91Mk3cX7VwgpD9qIx3gZl0NEUTuLK%2Fy8HPo%3D&reserved=0
__
__
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: Topoh module not decoding the BYE received from the callee

2022-12-20 Thread Michel Pelletier
Hi,
Thank you for your response.  No error messages in the kamailio logs.  It's
like topoh is missing the request completely.  Guess I will have to jump in
the source code and see what exactly topoh is expecting to see, which would
explain why the 'unhiding' operation doesn't get triggered.
Cheers,
Michel Pelletier


On Mon, Dec 19, 2022 at 4:01 AM Henning Westerholt  wrote:

> Hello,
>
>
>
> are you able to observe some irregularities related to this BYEs from the
> callee, e.g. with sngrep?
>
> Any error log messages in the kamailio.log related to topoh?
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Michel Pelletier 
> *Sent:* Friday, December 16, 2022 4:52 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* [SR-Users] Topoh module not decoding the BYE received from the
> callee
>
>
>
> Hello,
>
>
>
> I am using the topoh module and it works fine except for the BYE requests
> coming from the callee (the person receiving the call).  When a BYE is
> received from the destination of the call, then Kamailio relays it to the
> dummy IP 127.0.0.8.  This is exemplified in the topoh:msg-outgoing
> and topoh:msg-sending events where the $sndto(ip) is set to 127.0.0.8.
>
>
>
> I am using all default modparams with topoh.  The only modparam I have is
> for setting the event_callback.  I am using Kamailio 5.6.2 with Kemi using
> python3.
>
>
> Michel Pelletier
>
__
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: Topoh module not decoding the BYE received from the callee

2022-12-20 Thread Henning Westerholt
Hello,

the necessary information is stored in the headers, which can be configured via 
module parameter. Refer to the module README for details.

Maybe you can compare a working to a non-working BYE in a trace.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Michel Pelletier 
Sent: Tuesday, December 20, 2022 2:47 PM
To: Henning Westerholt 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Topoh module not decoding the BYE received from the 
callee

Hi,
Thank you for your response.  No error messages in the kamailio logs.  It's 
like topoh is missing the request completely.  Guess I will have to jump in the 
source code and see what exactly topoh is expecting to see, which would explain 
why the 'unhiding' operation doesn't get triggered.
Cheers,
Michel Pelletier


On Mon, Dec 19, 2022 at 4:01 AM Henning Westerholt 
mailto:h...@gilawa.com>> wrote:
Hello,

are you able to observe some irregularities related to this BYEs from the 
callee, e.g. with sngrep?
Any error log messages in the kamailio.log related to topoh?

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Michel Pelletier 
mailto:michelpelletie...@gmail.com>>
Sent: Friday, December 16, 2022 4:52 PM
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Topoh module not decoding the BYE received from the callee

Hello,

I am using the topoh module and it works fine except for the BYE requests 
coming from the callee (the person receiving the call).  When a BYE is received 
from the destination of the call, then Kamailio relays it to the dummy IP 
127.0.0.8.  This is exemplified in the topoh:msg-outgoing and topoh:msg-sending 
events where the $sndto(ip) is set to 127.0.0.8.

I am using all default modparams with topoh.  The only modparam I have is for 
setting the event_callback.  I am using Kamailio 5.6.2 with Kemi using python3.

Michel Pelletier
__
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: Proxy edge

2022-12-20 Thread M S
In WebRTC (websocket) the contact header always has invalid URI, so, you
MUST either use path module OR add contact alias for both REGISTER and
SUBSCRIBE requests otherwise any subsequent incoming SIP requests such as
INVITE and NOTIFY won't be routed to endpoint (SIP client).

See websocket module documentation which has an example configuration
script for handling these requests.

Kind regards,

--
Muhammad Shahzad Shafi
Tel: +49 176 99 83 10 85


On Tue, Dec 20, 2022, 13:40 Giovanni Iamonte  wrote:

> Dear List
>
> We have configured kamailio to work as a proxy edge and register.
>
> As a proxy edge cfg file we have used the example *edge_websocket.cfg.*
>
> We are developing two different client the first one based on *PJSIP* and
> the other one based *JsSIP*.
>
> Client PJSIP (no websockets)
> everything work perfectly, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE,
> INVITE
>
> Client JsSIP (with websockets)
> The REGISTER, SUBSCRIBE works, the NOTIFY does not work.
> In more in details we have:
>
>BrowserProxy EdgeRegister
> Client JsSIP   Websocket
>   |||
>   |||
>   | --Register---> | ---Register--> |
>   | <--200 OK  --- | <--200 OK  --- |
>   |||
>   | --Subscribe--> | ---Subscribe-> |
>   | <--200 OK  --- | <--200 OK  --- |
>   |||
>   |  X<--- | <--NOTIFY  --- |
>   |||
>
>
> As you can see the NOTIFY start from Register and reach the proxy, beloe
> the Register log file and the sip messages.
>
> Could somebody put me in the right direction.
>
> Thanks
>
> Bye
>
>
> *Log File*
>
> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: 
> [core/tcp_read.c:1533]: tcp_read_req(): content-length=0
> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: 
> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 2
> (reply(status)) flags 1
> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: 
> [core/parser/msg_parser.c:689]: parse_msg(): SIP Reply  (status):
> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: 
> [core/parser/msg_parser.c:690]: parse_msg():  version: 
> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: 
> [core/parser/msg_parser.c:692]: parse_msg():  status:  <478>
> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: 
> [core/parser/msg_parser.c:694]: parse_msg():  reason:   destination (478/SL)>
> Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG: 
> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header
> name [Via] type 1
>
> *Sip Messages*
>
> *REGISTER* sip:sip-register.quintetto.it SIP/2.0
> Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK7825787
> Max-Forwards: 69
> To: 
> 
> From: "quintetto00" 
> ;tag=2tnuk9btmp
> Call-ID: unrnseei8924hf67khoi3g
> CSeq: 2 REGISTER
> Authorization: Digest algorithm=MD5, username="quintetto00", realm="
> sip-register.quintetto.it", nonce="Y6GUq2Ohk3//HTza7ZYMfd85XMdavgnc",
> uri="sip:sip-register.quintetto.it",
> response="c9cc56d2d5e36b0a68873c1d5258d062"
> Contact: 
> 
> ;+sip.ice;reg-id=1;+sip.instance="";expires=3600
> Expires: 3600
> Allow:
> INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH
> Supported: path,gruu,outbound
> User-Agent: JsSIP 3.10.0
> Content-Length: 0
>
>
> SIP/2.0 *200 OK*
> Via: SIP/2.0/WSS
> 13569868356.invalid;rport=37566;received=192.168.100.192;branch=z9hG4bK7825787
> To: 
> 
> ;tag=2b789d0fa67ad6c2da65f0cce35dd60b.71a84df9
> From: "quintetto00" 
> ;tag=2tnuk9btmp
> Call-ID: unrnseei8924hf67khoi3g
> CSeq: 2 REGISTER
> Contact: 
> 
> ;expires=3600;+sip.instance="";reg-id=1
> Server: kamailio (5.6.2 (x86_64/linux))
> Content-Length: 0
>
>
>
> *SUBSCRIBE* sip:quintett...@sip-register.quintetto.it SIP/2.0
> Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK3648599
> Max-Forwards: 69
> To: 
> 
> From: "quintetto00" 
> ;tag=o261bh2uh7
> Call-ID: 4beh90hur8hdhptnbjt8
> CSeq: 5813 SUBSCRIBE
> Proxy-Authorization: Digest algorithm=MD5, username="quintetto00", realm="
> sip-register.quintetto.it", nonce="Y6GU+mOhk86y3fnrMzoKgiVAdkaTvBId", uri=
> "sip:quintett...@sip-register.quintetto.it"
> ,
> response="04ca6d83661ac338810baa95ffaa568b"
> Event: presence
> Expires: 3600
> Accept: application/pidf+xml, application/xpidf+xml
> Contact: 
> 
> Content-Type: application/pidf+xml
> Allow:
> INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH
> Supported: outbound
> User-Agent: JsSIP 3.10.0
> Content-Length: 35
>
>
>
> SIP/2.0 *200 OK*
>

[SR-Users] Re: dialog_vars accumulating in database?

2022-12-20 Thread Henning Westerholt
Hello,

thanks for the additional information. It should certainly expire the dialog 
after some time, even if it's synchronized from DMQ to the first instance.

Maybe you can try it with a small dialog timeout variable in a test setup, if 
possible. If its not expiring, an issue could be opened about it.

Cheers,

Henning

-- 
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

-Original Message-
From: Benoit Panizzon  
Sent: Tuesday, November 15, 2022 3:07 PM
To: Henning Westerholt 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] dialog_vars accumulating in database?

Hmm, I have a suspicion how this happens...

I could more or less reproduce the issue:

2 Kamailio instances, synced with DMQ.
Both store dialog_vars in a local database for performance.

While a dialog is ongoing, stop instance 2. This instance 2 probably has stored 
dialog information in it's local database.

End the dialog. Instance 1 propperly removes dialog_vars from it's local 
database and forgets about it.

Restart Instance 2.

No longer existing dialog data from instance 2 is getting DMQ synced to 
Instance 1. This dialog is sticking around on both instances and never expiring.


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] Proxy edge

2022-12-20 Thread Giovanni Iamonte

Dear List

We have configured kamailio to work as a proxy edge and register.

As a proxy edge cfg file we have used the example *edge_websocket.cfg.**
*
We are developing two different client the first one based on *PJSIP* 
and the other one based *JsSIP*.


Client PJSIP (no websockets)
everything work perfectly, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, 
MESSAGE, INVITE


Client JsSIP (with websockets)
The REGISTER, SUBSCRIBE works, the NOTIFY does not work.
In more in details we have:

   Browser            Proxy Edge                     Register
Client JsSIP       Websocket
  |                                |                         |
  |                                |                         |
  | --Register---> | ---Register--> |
  | <--200 OK  --- | <--200 OK  --- |
  |    |    |
  | --Subscribe--> | ---Subscribe-> |
  | <--200 OK  --- | <--200 OK  --- |
  |                                |                         |
  |                X<--- | <--NOTIFY  --- |
  |                                |                         |


As you can see the NOTIFY start from Register and reach the proxy, beloe 
the Register log file and the sip messages.


Could somebody put me in the right direction.

Thanks

Bye


*Log File*

Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG:  
[core/tcp_read.c:1533]: tcp_read_req(): content-length=0
Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG:  
[core/parser/parse_fline.c:249]: parse_first_line(): first line type 2 
(reply(status)) flags 1
Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG:  
[core/parser/msg_parser.c:689]: parse_msg(): SIP Reply  (status):
Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG:  
[core/parser/msg_parser.c:690]: parse_msg(): version: 
Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG:  
[core/parser/msg_parser.c:692]: parse_msg(): status:  <478>
Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG:  
[core/parser/msg_parser.c:694]: parse_msg(): reason:  destination (478/SL)>
Dec 20 10:51:58 kr-server /usr/sbin/kamailio[87875]: DEBUG:  
[core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header 
name [Via] type 1


*Sip Messages*

*REGISTER* sip:sip-register.quintetto.it SIP/2.0
Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK7825787
Max-Forwards: 69
To: 
From: "quintetto00" 
;tag=2tnuk9btmp

Call-ID: unrnseei8924hf67khoi3g
CSeq: 2 REGISTER
Authorization: Digest algorithm=MD5, username="quintetto00", 
realm="sip-register.quintetto.it", 
nonce="Y6GUq2Ohk3//HTza7ZYMfd85XMdavgnc", 
uri="sip:sip-register.quintetto.it", 
response="c9cc56d2d5e36b0a68873c1d5258d062"
Contact: 
;+sip.ice;reg-id=1;+sip.instance="";expires=3600

Expires: 3600
Allow: 
INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH

Supported: path,gruu,outbound
User-Agent: JsSIP 3.10.0
Content-Length: 0


SIP/2.0 *200 OK*
Via: SIP/2.0/WSS 
13569868356.invalid;rport=37566;received=192.168.100.192;branch=z9hG4bK7825787
To: 
;tag=2b789d0fa67ad6c2da65f0cce35dd60b.71a84df9
From: "quintetto00" 
;tag=2tnuk9btmp

Call-ID: unrnseei8924hf67khoi3g
CSeq: 2 REGISTER
Contact: 
;expires=3600;+sip.instance="";reg-id=1

Server: kamailio (5.6.2 (x86_64/linux))
Content-Length: 0



*SUBSCRIBE* sip:quintett...@sip-register.quintetto.it SIP/2.0
Via: SIP/2.0/WSS 13569868356.invalid;branch=z9hG4bK3648599
Max-Forwards: 69
To: 
From: "quintetto00" 
;tag=o261bh2uh7

Call-ID: 4beh90hur8hdhptnbjt8
CSeq: 5813 SUBSCRIBE
Proxy-Authorization: Digest algorithm=MD5, username="quintetto00", 
realm="sip-register.quintetto.it", 
nonce="Y6GU+mOhk86y3fnrMzoKgiVAdkaTvBId", 
uri="sip:quintett...@sip-register.quintetto.it", 
response="04ca6d83661ac338810baa95ffaa568b"

Event: presence
Expires: 3600
Accept: application/pidf+xml, application/xpidf+xml
Contact: 
Content-Type: application/pidf+xml
Allow: 
INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY,SUBSCRIBE,PUBLISH

Supported: outbound
User-Agent: JsSIP 3.10.0
Content-Length: 35



SIP/2.0 *200 OK*
Record-Route: 
Record-Route: 
Via: SIP/2.0/WSS 
13569868356.invalid;rport=37566;received=192.168.100.192;branch=z9hG4bK3648599
To: 
;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec
From: "quintetto00" 
;tag=o261bh2uh7

Call-ID: 4beh90hur8hdhptnbjt8
CSeq: 5813 SUBSCRIBE
Expires: 3600
Contact: 
Server: kamailio (5.6.2 (x86_64/linux))
Content-Length: 0



*NOTIFY*.sip:quintetto00@13569868356.invalid;transport=ws.SIP/2.0
Via:.SIP/2.0/TCP.1 92.168.100.23:15 
006;branch=z9hG4bK28ad.a5d3bdf6.0

To: ;tag=o261bh2uh7
From: 
;tag=c906ce7d8b5c7cc84a3505ebe369640b-e45527ec

CSeq : 2 NOTIFY
Call-ID:.4beh90hur8h dhptnbjt8
Route : ,.8.100.24:16005;transport=ws;r2=on;lr>

Content-Length:.0
User-Agent: kamailio.(5.6.2.(x86_64/li nux))
Max-Forward

[SR-Users] Re: How to unset_dlg_profile in request_route or react more quickly to CANCEL?

2022-12-20 Thread Henning Westerholt
Hello,

maybe I do not fully understand the task. But my understanding of the dialog 
profiles is that they actually use the dialog tracking functionality to 
maintain its internal state. That means there should be no need to remove the 
dialog manually from the dialog profile that tracks it.

If the user agent does not reply correctly to the CANCEL, maybe the user agent 
should be fixed?

Cheers,

Henning

-- 
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

-Original Message-
From: Benoit Panizzon  
Sent: Monday, December 19, 2022 4:43 PM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] How to unset_dlg_profile in request_route or react more 
quickly to CANCEL?

Hi List

Testing failure situations, I discovered unset_dlg_profile can not be used in 
request_route:

I count the channels per customer in a dlg_profile to know when they are busy. 
Residential POTS customer have 1 channel.

Now this situation (Trying to mimik POTS behavior)

Kamailio <=> CPE of 'John-Doe'

=> INVITE
set_dlg_profile of John-Doe is 0: Not busy set_dlg_profile of John-Doe +1 <= 
100 trying <= 180 ringing

== LINK to CPE DISRUPTED ==

X<= 200 OK (not reaching kamailio)
CPE is sending 200 a couple of times and fails.
Caller is still hearing ringing tone as it never got 200 OK.

The caller does not want to wait longer and hangs up =>X CANCEL (NOT 
reaching CPE)

This is the moment, on which I would like to unset_dlg_profile of John-Doe to 
mark his channel available again.

But the CPE is never going to acknowledge this CANCEL with 487.

Unfortunately: unset_dlg_profile(): dialog delete profile cannot be used in 
request route

Only when kamailio has sent CANCEL a couple of times and the failure_route for 
this CANCEL is triggered, I can remove the call from the dlg_profile of that 
customer within failure_route.

If I am unlucky, in the meantime other calls get 'busy' instead of being 
re-routed to the configured backup number of that customer.

Agreed, after a couple of seconds, the call goes to the failure route and the 
dialogue is ending thus calls work as expected.
But wouldn't it be nice to be able to unset the dlg_profile upon receiving the 
CANCEL instead on when the CANCEL transaction is successful?

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:
__
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: How to unset_dlg_profile in request_route or react more quickly to CANCEL?

2022-12-20 Thread Benoît Panizzon
Hi Henning

> If the user agent does not reply correctly to the CANCEL, maybe the
> user agent should be fixed?

As mentioned. I was testing various fail situation, like disconnecting
the user agent while in dialog or while in transaction to see what
happes.

But agreed, that is probably not a situation which occurs often so
having the CANCEL to time out and only then removing the dialogue is
probably acceptable.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
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] Re: DNS Host-Names in Via and Record-Route for more redundancy?

2022-12-20 Thread Henning Westerholt
Hello,

yes, User Agents or ALGs can make this approach difficult unfortunately.

If you can handle it technically and also from a complexity point of view, an 
IP anycast setup could be used. Some people use that, especially for larger 
platforms. 
The usual IP failover approach can be also used for smaller platforms.

Cheers,

Henning

-- 
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

-Original Message-
From: Benoit Panizzon  
Sent: Monday, December 19, 2022 2:24 PM
To: Rick Barenthin 
Cc: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Re: DNS Host-Names in Via and Record-Route for more 
redundancy?

Hello World and Rick

> A quick update. Now it works. I guess the newly added DNS hostname was 
> not yet fully propagated to all DNS caches.

I start doubting, this was a clever idea...

I wonder what solutions other have come up to.

After some testing I noticed: SIP ALG on NAT devices do work by IP, not by 
hostname. So getting traffic from the kamailio instance they were not talking 
too before (or did not register to) breaks on NAT situations.

Also SBC do not seem to respect the Via header and always sending traffic back 
to the IP it received traffic from.

How do other build redundant, high available platforms with kamailio avoiding 
those pitfalls?

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