From ascanio.alba7 at gmail.com  Tue Dec  1 08:53:35 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Tue, 1 Dec 2020 15:53:35 +0800
Subject: [SR-Users] Kamailio behind HAProxy
In-Reply-To: <CAMtXxQnvadkUwy5aaYC6kOeGHLf4cSrATBsbKYqAsNfOMG7khA@mail.gmail.com>
References: <4636b203-e500-4fb3-9afe-86a0af431ab3@Spark>
 <9f440793-f273-4f56-bf8d-57d577baa0db@Spark>
 <CAHtxdDdu-w7mqWy4R06QMBehOJkcKHwe211e7b6EnGFdkxzcqg@mail.gmail.com>
 <6b76acfc-842b-474f-af9e-91b8f1c152ab@Spark>
 <CAHtxdDdxVp6TPt9F80XeGPVW0XSPyX7Qn_bJXEnSAuTjgujMTg@mail.gmail.com>
 <8286c30c-613f-4ad0-9a16-ae2f80825bf2@Spark>
 <CAHtxdDd6g+ZuSPonvr_jiAOuA9YdkAfnN5+C1L-fG1JEHkcLAw@mail.gmail.com>
 <89c33bb9-867e-4a76-b147-8e4ac3945ee2@Spark>
 <CAHtxdDeGOxvYEr+1TaRgcoH+k3cA=JO8sEh5QfsnLYLauOOkfg@mail.gmail.com>
 <c4f1125d-e72e-452a-a9cf-ce215515c1b6@Spark>
 <AM0PR05MB6595CDC4F6D1E660371949B3C5E80@AM0PR05MB6595.eurprd05.prod.outlook.com>
 <052cfeb8-ad16-b56c-2b4b-af5d0ce837e7@evaristesys.com>
 <CAMtXxQnvadkUwy5aaYC6kOeGHLf4cSrATBsbKYqAsNfOMG7khA@mail.gmail.com>
Message-ID: <CADkWibeH3tDZsDhwNgk9DYuKGUPJs-9oUtrgbWo84aYfA81mzg@mail.gmail.com>

Hi Joel,

1. kamailio will think that the UA src-ip/port is the incoming
connection from haproxy, is that what you want?

2. Is the real src-ip/port available to haproxy from the cloud SSL terminator?
Otherwise won't haproxy think the incoming src-ip/port is the leg from
the SSL terminator?

3. I have tried haproxy as a dumb(not PROXY protocol) SSL-terminator
proxying TLS to TCP/kamailio (without Path header).
It works as expected, all the Contact addresses are that of the
haproxy device. When the UA REGISTERs, some
are smart (too smart?), that their Contact address and Via are already
changed to the received/rport from the Via.

4. If I need the "real" address for logging, it is collected
separately. Also the first REGISTER from a UA usually has the
"real" src-ip/port as it hasn't cached the received/rport parameters yet.

Cheers
Anthony






On Thu, Nov 12, 2020 at 10:21 AM Joel Serrano <joel at textplus.com> wrote:
>
> In one case, it was to take advantage of the SSL offloading from the cloud provided load balancer (among other features, but that was the main one). I never got it fully working though..
>
> See: https://github.com/kamailio/kamailio/issues/2103 and the thread https://lists.kamailio.org/pipermail/sr-users/2019-November/107222.html
>
> So it could end up being useful for something like:
>
> UA <-> TCP load balancer (that *proxies* the connection but doesn't talk SIP) <-> Kamailio -> destination.
>
>
> I'm also curious to know if/how the rest are using it..
>
>
>
>
>
> On Wed, Nov 11, 2020 at 9:24 AM Alex Balashov <abalashov at evaristesys.com> wrote:
>>
>> The motive is still a bit of a mystery to me. Yes, it allows Kamailio to
>> discover the true source IP/port of a message, but given the function
>> performed by HAProxy for TCP connections, it seems generally useful to
>> think of HAProxy as the other endpoint of the connection? Moreover, it
>> makes it that much more complicated to send requests to reach the client
>> _via_ HAProxy (e.g. following a lookup()), since HAProxy isn't a SIP
>> proxy and doesn't add a Path hop.
>>
>> Am I missing something vital about the nature of HAProxy + Kamailio
>> deployments?
>>
>> -- Alex
>>
>> On 11/11/20 8:23 AM, Henning Westerholt wrote:
>> > Hello,
>> >
>> > bascially this allows Kamailio to understand the HAProxy protocol to be
>> > used behind this particular proxy. Some discussion can be found at the
>> > list and also at https://github.com/kamailio/kamailio/pull/1765
>> >
>> > Cheers,
>> >
>> > Henning
>> >
>> > --
>> >
>> > Henning Westerholt ? https://skalatan.de/blog/
>> >
>> > Kamailio services ? https://gilawa.com <https://gilawa.com/>
>> >
>> > *From:* sr-users <sr-users-bounces at lists.kamailio.org> *On Behalf Of
>> > *Joey Golan
>> > *Sent:* Wednesday, November 11, 2020 1:47 PM
>> > *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
>> > *Subject:* Re: [SR-Users] Kamailio behind HAProxy
>> >
>> > Thanks Sergey.
>> >
>> > Can anyone please explain how and why to use tcp_accept_haproxy?
>> >
>> > On 11 Nov 2020, 10:39 +0200, Sergey Safarov <s.safarov at gmail.com
>> > <mailto:s.safarov at gmail.com>>, wrote:
>> >
>> >     Now I not use pike.
>> >
>> >     On Wed, Nov 11, 2020 at 10:21 AM Joey Golan <joeygo at gmail.com
>> >     <mailto:joeygo at gmail.com>> wrote:
>> >
>> >         So on your AWS deployment are you working without ANTIFLOOD(pike)?
>> >
>> >         I still don?t  understand how and why to use tcp_accept_haproxy.
>> >
>> >         On 9 Nov 2020, 11:49 +0200, Sergey Safarov <s.safarov at gmail.com
>> >         <mailto:s.safarov at gmail.com>>, wrote:
>> >
>> >             In AWS I now use the network load balancer without enabled
>> >             HAproxy protocol.
>> >
>> >             On EC2 instances used two ENI.
>> >
>> >             First for traffic via NLB for Inbound traffic.
>> >
>> >             And second ENI for outbound traffic.
>> >
>> >             This works but, maybe complex to implement.
>> >
>> >             Now I looking to:
>> >
>> >             1) enable TCP + HAproxy protocol support in Kamailio;
>> >
>> >             2) add UDP + HAproxy protocol feature support;
>> >
>> >             3) add connection support "with" and "without" HAproxy protocol.
>> >
>> >             But I am not a developer and cannot say when it implemented.
>> >
>> >             If your usage case, is business requirements and need
>> >             extended HAproxy implementation in Kamailio, then your
>> >             company can hire devs from the community.
>> >
>> >             On Mon, Nov 9, 2020 at 11:22 AM Joey Golan <joeygo at gmail.com
>> >             <mailto:joeygo at gmail.com>> wrote:
>> >
>> >                 Maybe I miss understood you.
>> >                 For local installations you mean HAProxy with
>> >                 transparent mode?
>> >
>> >                 I have a functioning setup without proxy protocol
>> >                 enabled but without anitflood enabled because all
>> >                 traffic comes from same HAProxy address.
>> >
>> >                 I?m not sure I understand the purpose of
>> >                 tcp_accept_haproxy. When and how this parameter should
>> >                 be used?
>> >
>> >                 Thanks,
>> >                 Joey.
>> >
>> >                 On 9 Nov 2020, 0:27 +0200, Sergey Safarov
>> >                 <s.safarov at gmail.com <mailto:s.safarov at gmail.com>>, wrote:
>> >
>> >                     Why you cannot use this in the local installation?
>> >
>> >                     On AWS I have multiple kamailio servers behind ELB.
>> >
>> >                     Why you do not use a network load-balancer? NLB also
>> >                     offers HAproxy protocol support (TCP and UDP).
>> >
>> >                     In AWS installation you can use dedicated Kamailio
>> >                     groups for inbound connections and SIP clients with
>> >                     registration.
>> >
>> >                     And use other Kamailio group for outbound
>> >                     connections like carriers.
>> >
>> >
>> >                     Sergey
>> >
>> >                     On Sun, Nov 8, 2020 at 9:07 PM Joey Golan
>> >                     <joeygo at gmail.com <mailto:joeygo at gmail.com>> wrote:
>> >
>> >                         It doesn?t make much sense to me.
>> >                         On local installations (on-premise) I have 1
>> >                         HAProxy and multiple kamailio servers.
>> >                         On AWS I have multiple kamailio servers behind ELB.
>> >
>> >                         On 8 Nov 2020, 19:45 +0200, Sergey Safarov
>> >                         <s.safarov at gmail.com
>> >                         <mailto:s.safarov at gmail.com>>, wrote:
>> >
>> >                             you can try place haproxy + NAT on your own
>> >                             Linux router.
>> >
>> >                             In this case inbound connections with be
>> >                             delivered via HAproxy.
>> >                             Outbound connections will be NAT-ed on the
>> >                             same host, to the same IP.
>> >
>> >                             On Sun, Nov 8, 2020 at 6:31 PM Joey Golan
>> >                             <joeygo at gmail.com <mailto:joeygo at gmail.com>>
>> >                             wrote:
>> >
>> >                                 Hello,
>> >                                 I have a kamailio server running behind
>> >                                 HAProxy with proxy protocol v2 enabled.
>> >                                 In Kamailio I have set the parameter
>> >                                 tcp_accept_haproxy=yes and loaded tcpops
>> >                                 module.
>> >                                 UEs are registered using TLS and
>> >                                 kamailio sees that the message has
>> >                                 received from their real ip address +
>> >                                 port and not HAProxy ip + port.
>> >                                 When UE A calls UE B, kamailio is trying
>> >                                 to reach UE B using his real ip address
>> >                                 and port instead of HAProxy IP address +
>> >                                 port.
>> >
>> >                                 I know I can get the tcp ip and port of
>> >                                 HAProxy using $tcp(c_si) and $tcp(c_sp)
>> >                                 but I can?t make it work.
>> >                                 What is the right way to do this? How
>> >                                 should I use these variables properly in
>> >                                 order to establish the call successfully?
>> >
>> >                                 Thanks,
>> >                                 Joey.
>> >
>> >                                 _______________________________________________
>> >                                 Kamailio (SER) - Users Mailing List
>> >                                 sr-users at lists.kamailio.org
>> >                                 <mailto:sr-users at lists.kamailio.org>
>> >                                 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >                             _______________________________________________
>> >                             Kamailio (SER) - Users Mailing List
>> >                             sr-users at lists.kamailio.org
>> >                             <mailto:sr-users at lists.kamailio.org>
>> >                             https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >                         _______________________________________________
>> >                         Kamailio (SER) - Users Mailing List
>> >                         sr-users at lists.kamailio.org
>> >                         <mailto:sr-users at lists.kamailio.org>
>> >                         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >                     _______________________________________________
>> >                     Kamailio (SER) - Users Mailing List
>> >                     sr-users at lists.kamailio.org
>> >                     <mailto:sr-users at lists.kamailio.org>
>> >                     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >                 _______________________________________________
>> >                 Kamailio (SER) - Users Mailing List
>> >                 sr-users at lists.kamailio.org
>> >                 <mailto:sr-users at lists.kamailio.org>
>> >                 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >             _______________________________________________
>> >             Kamailio (SER) - Users Mailing List
>> >             sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> >             https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >         _______________________________________________
>> >         Kamailio (SER) - Users Mailing List
>> >         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> >         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >     _______________________________________________
>> >     Kamailio (SER) - Users Mailing List
>> >     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> >     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >
>> > _______________________________________________
>> > Kamailio (SER) - Users Mailing List
>> > sr-users at lists.kamailio.org
>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> >
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>>
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


From miconda at gmail.com  Tue Dec  1 09:35:19 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 1 Dec 2020 09:35:19 +0100
Subject: [SR-Users] vscode-kamailio-syntax - issue with empty comment
 line
In-Reply-To: <AM4PR0202MB282004DE31130EF0443B854EE6F50@AM4PR0202MB2820.eurprd02.prod.outlook.com>
References: <AM4PR0202MB28205314D0E82DAA647DF2A5E6F50@AM4PR0202MB2820.eurprd02.prod.outlook.com>
 <8634d75d-3a7e-f27f-42b2-dd8c8d0b4adb@gmail.com>
 <AM4PR0202MB282004DE31130EF0443B854EE6F50@AM4PR0202MB2820.eurprd02.prod.outlook.com>
Message-ID: <c69f93a5-a895-54ca-644f-7265d48d5a9f@gmail.com>

Fixed and published a new version of the extension, since I took the
time to add detection of indexes and transformations for pseudo-variables:

? *
https://www.kamailio.org/w/2020/12/vscode-syntax-highlighting-for-kamailio-cfg-v1-0-8/

Cheers,
Daniel

On 30.11.20 10:23, Chaigneau, Nicolas wrote:
> Done:
> https://github.com/miconda/vscode-kamailio-syntax/issues/5
>
> Thanks for your time. :)
>
>
> Regards,
> Nicolas.
>
>>  
>> can you open an issue on the tracker of the projects, not to be forgotten -- I will try to look at it when I get some spare time:
>>
>> ? * https://github.com/miconda/vscode-kamailio-syntax/issues
>>
>> Cheers,
>> Daniel
>>
>>> One issue I've noticed:
>>> If you have an empty comment line (just # on a single line), then the next line is wrongly highlighted as comments.
>>>
>>> For example:
>>>
>>> #
>>> loadmodule "db_postgres.so"
>>>
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From ascanio.alba7 at gmail.com  Tue Dec  1 09:36:13 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Tue, 1 Dec 2020 16:36:13 +0800
Subject: [SR-Users] How to msg_apply_changes in a branch route?
Message-ID: <CADkWibextRWWhqwTd3f7LT1_-R=r=ydY3jjh59gjXzfXD1sApQ@mail.gmail.com>

Is there a way to obtain the effect of msg_apply_changes in a branch route?

I want to do:

route[BRANCHMANAGE] {

rtpengine_manage()
msg_apply_changes()
 // further mangle the SDP with textops for
// obtuse UAs

}

The reason for this, is that after forking, I have some UAs that are
extremely picky about SDP, and I need to mangle the body to make them
happy. (4000 char limit, 68 attribute limit on SDP body - ever seen
that? Compared with the absolutely gigantic OFFERs from WebRTC
signalling libraries...)

Now rtpengine_manage() and textops are working on separate copies of
the msg body and the results don't stack correctly.

Cheers
Anthony Alba


From hw at skalatan.de  Tue Dec  1 11:05:01 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Tue, 1 Dec 2020 10:05:01 +0000
Subject: [SR-Users] Kamailio Failover
In-Reply-To: <CAO7FpHTeG-f3ZKZarbgimD+d-k9hPjL+V5NsrSJ=xXKiHBanbA@mail.gmail.com>
References: <CAO7FpHTeG-f3ZKZarbgimD+d-k9hPjL+V5NsrSJ=xXKiHBanbA@mail.gmail.com>
Message-ID: <AM0PR05MB65955F65525B9A1EAB0DE0CEC5F40@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hi Rolly,

Hard to say without more details, but have a look to the SDP for the problematic calls, so see if everything is rewritten or inserted correctly.

Cheers,

Henning

--
Henning Westerholt ? https://skalatan.de/blog/
Kamailio services ? https://gilawa.com<https://gilawa.com/>

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Rolly Casuga Jr.
Sent: Wednesday, November 25, 2020 5:32 AM
To: sr-users at lists.kamailio.org
Subject: [SR-Users] Kamailio Failover

Hi,

I am having a problem on fail overing my master kamailio server and slave kamailio server.
I use kamailio as a load balancer for my asterisk servers.  And it is working with calls, but when I added failover with keepalived to the slave, there is no audio during calls.

Thank you,
Rolly


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201201/5a24bd11/attachment.htm>

From hw at skalatan.de  Tue Dec  1 11:07:01 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Tue, 1 Dec 2020 10:07:01 +0000
Subject: [SR-Users] [sr-dev] kamailio SIP and RTP proxy
In-Reply-To: <CAGXL1Pn2d7X_r94d61vsbUU52bom6jmqBoGoDV0W-hZRGAwZPg@mail.gmail.com>
References: <CAGXL1Pn2d7X_r94d61vsbUU52bom6jmqBoGoDV0W-hZRGAwZPg@mail.gmail.com>
Message-ID: <AM0PR05MB65954E1C4065E54E8F92C85BC5F40@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hi Patrick,

better to contact our sr-users list with the usage related questions, added to CC.

Have a look to the SDP of the SIP packets to see if it contains the correct IP would be one idea to debug this further.

Feel free to ask again on sr-users after you have got more details.

Cheers,

Henning

--
Henning Westerholt ? https://skalatan.de/blog/
Kamailio services ? https://gilawa.com<https://gilawa.com/>

From: sr-dev <sr-dev-bounces at lists.kamailio.org> On Behalf Of Patrick Leybag
Sent: Wednesday, November 25, 2020 6:26 AM
To: sr-dev at lists.kamailio.org
Subject: [sr-dev] kamailio SIP and RTP proxy

Hi, Can someone help me?
I self host a kamailio using my raspberry pi as a load balancer for my two asterisk servers and get a did number. when I call to my DID number it points to my kamailio and kamailio will distribute to asterisk server but the call has no audio. I tried port forwarding ports 5060 for SIP and 10000-20000 for RTP but it still does not work.

Any help is much appreciated. Thank you in advance







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201201/016b5d6a/attachment.htm>

From ceo at teo-en-ming.com  Tue Dec  1 16:17:19 2020
From: ceo at teo-en-ming.com (Turritopsis Dohrnii Teo En Ming)
Date: Tue, 01 Dec 2020 23:17:19 +0800
Subject: [SR-Users] How to DIY/Setup An Open Source IP PBX Appliance/Server?
Message-ID: <c64798c86a8f7ecfe0e4a646e5dddf4c@teo-en-ming.com>

Subject: How to DIY/Setup An Open Source IP PBX Appliance/Server?

Good day from Singapore,

After reading recent reviews, I gather that Asterisk is the gold 
standard when it comes to open source VoIP systems and it is the most 
famous open source PBX out there.

Article: Compare the Top 10 Best Open Source PBX Software of 2020
Link: 
https://www.voipreview.org/business-voip/best-open-source-pbx-software

Article: Top 10 Free Open Source PBX Software Solutions
Link: https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/

The following is an excerpt from Wikipedia:

"Asterisk is a core component in many commercial products and 
open-source projects. Some of the commercial products are hardware and 
software bundles, for which the manufacturer supports and releases the 
software with an open-source distribution model.

AskoziaPBX, a fork of the m0n0wall project, uses Asterisk PBX software 
to realize all telephony functions.

AstLinux is a "Network Appliance for Communications" open-source 
software distribution.[15]

FreePBX, an open-source graphical user interface, bundles Asterisk as 
the core of its FreePBX Distro[16]

LinuxMCE bundles Asterisk to provide telephony; there is also an 
embedded version of Asterisk for OpenWrt routers.

PBX in a Flash/Incredible PBX and trixbox are software PBXes based on 
Asterisk.

Elastix previously used Asterisk, HylaFAX, Openfire and Postfix to offer 
PBX, fax, instant messaging and email functions, respectively, before 
switching to 3CX.

Issabel is an open-source Unified Communications software which uses 
Asterisk for telephony functions. It was forked from the open-source 
versions of Elastix when 3CX acquired it.

*astTECS uses Asterisk in its VoIP and mobile gateways."

Link: https://en.wikipedia.org/wiki/Asterisk_(PBX)

I would like to DIY/setup an IP PBX appliance/server using free open 
source projects.
Which free open source project, mentioned in the list and links above, 
would you recommend to DIY my IP PBX appliance/server?

Should I buy a desktop computer or get one of those appliances listed in 
the link below to serve as my IP PBX appliance/server?

Link: 
https://www.lazada.sg/products/pfsense-iron-metal-case-fanless-intel-celeron-j1800-dual-core-mini-pc-firewall-soft-router-with-ddr3l-msata-ssd-4-gigabit-lan-rj45-com-port-i449270007-s1196780479.html?spm=a2o42.searchlist.list.89.100857d22PjCYx&search=1

Please also refer me to very good, detailed and well explained 
guides/tutorials/manuals on setting up open source IP PBX 
appliances/servers.

Lastly, please recommend a cheap and affordable IP phone (suggest brand 
and model) to go along with my DIY open source IP PBX appliance/server.

Mr. Turritopsis Dohrnii Teo En Ming, 42 years as of 1st December 2020 
Tuesday, is a TARGETED INDIVIDUAL (TI) living in Singapore.

Thank you very much.







-----BEGIN EMAIL SIGNATURE-----

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link: 
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html

********************************************************************************************

Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's 
Academic
Qualifications as at 14 Feb 2019 and refugee seeking attempts at the 
United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 
2019) and Australia (25 Dec 2019 to 9 Jan 2020):

[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-----END EMAIL SIGNATURE-----


From oej at edvina.net  Tue Dec  1 16:26:13 2020
From: oej at edvina.net (Olle E. Johansson)
Date: Tue, 1 Dec 2020 16:26:13 +0100
Subject: [SR-Users] How to DIY/Setup An Open Source IP PBX
 Appliance/Server?
In-Reply-To: <c64798c86a8f7ecfe0e4a646e5dddf4c@teo-en-ming.com>
References: <c64798c86a8f7ecfe0e4a646e5dddf4c@teo-en-ming.com>
Message-ID: <FF652D0F-030F-4003-9E2E-B6A26508A582@edvina.net>

If you want to discuss Asterisk, I recommend that you use the Asterisk mailing lists.
This is not it.

/O

> On 1 Dec 2020, at 16:17, Turritopsis Dohrnii Teo En Ming <ceo at teo-en-ming.com> wrote:
> 
> Subject: How to DIY/Setup An Open Source IP PBX Appliance/Server?
> 
> Good day from Singapore,
> 
> After reading recent reviews, I gather that Asterisk is the gold standard when it comes to open source VoIP systems and it is the most famous open source PBX out there.
> 
> Article: Compare the Top 10 Best Open Source PBX Software of 2020
> Link: https://www.voipreview.org/business-voip/best-open-source-pbx-software
> 
> Article: Top 10 Free Open Source PBX Software Solutions
> Link: https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/
> 
> The following is an excerpt from Wikipedia:
> 
> "Asterisk is a core component in many commercial products and open-source projects. Some of the commercial products are hardware and software bundles, for which the manufacturer supports and releases the software with an open-source distribution model.
> 
> AskoziaPBX, a fork of the m0n0wall project, uses Asterisk PBX software to realize all telephony functions.
> 
> AstLinux is a "Network Appliance for Communications" open-source software distribution.[15]
> 
> FreePBX, an open-source graphical user interface, bundles Asterisk as the core of its FreePBX Distro[16]
> 
> LinuxMCE bundles Asterisk to provide telephony; there is also an embedded version of Asterisk for OpenWrt routers.
> 
> PBX in a Flash/Incredible PBX and trixbox are software PBXes based on Asterisk.
> 
> Elastix previously used Asterisk, HylaFAX, Openfire and Postfix to offer PBX, fax, instant messaging and email functions, respectively, before switching to 3CX.
> 
> Issabel is an open-source Unified Communications software which uses Asterisk for telephony functions. It was forked from the open-source versions of Elastix when 3CX acquired it.
> 
> *astTECS uses Asterisk in its VoIP and mobile gateways."
> 
> Link: https://en.wikipedia.org/wiki/Asterisk_(PBX)
> 
> I would like to DIY/setup an IP PBX appliance/server using free open source projects.
> Which free open source project, mentioned in the list and links above, would you recommend to DIY my IP PBX appliance/server?
> 
> Should I buy a desktop computer or get one of those appliances listed in the link below to serve as my IP PBX appliance/server?
> 
> Link: https://www.lazada.sg/products/pfsense-iron-metal-case-fanless-intel-celeron-j1800-dual-core-mini-pc-firewall-soft-router-with-ddr3l-msata-ssd-4-gigabit-lan-rj45-com-port-i449270007-s1196780479.html?spm=a2o42.searchlist.list.89.100857d22PjCYx&search=1
> 
> Please also refer me to very good, detailed and well explained guides/tutorials/manuals on setting up open source IP PBX appliances/servers.
> 
> Lastly, please recommend a cheap and affordable IP phone (suggest brand and model) to go along with my DIY open source IP PBX appliance/server.
> 
> Mr. Turritopsis Dohrnii Teo En Ming, 42 years as of 1st December 2020 Tuesday, is a TARGETED INDIVIDUAL (TI) living in Singapore.
> 
> Thank you very much.
> 
> 
> 
> 
> 
> 
> 
> -----BEGIN EMAIL SIGNATURE-----
> 
> The Gospel for all Targeted Individuals (TIs):
> 
> [The New York Times] Microwave Weapons Are Prime Suspect in Ills of
> U.S. Embassy Workers
> 
> Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html
> 
> ********************************************************************************************
> 
> Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic
> Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020):
> 
> [1] https://tdtemcerts.wordpress.com/
> 
> [2] https://tdtemcerts.blogspot.sg/
> 
> [3] https://www.scribd.com/user/270125049/Teo-En-Ming
> 
> -----END EMAIL SIGNATURE-----
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



From nicolas.chaigneau at capgemini.com  Tue Dec  1 17:01:09 2020
From: nicolas.chaigneau at capgemini.com (Chaigneau, Nicolas)
Date: Tue, 1 Dec 2020 16:01:09 +0000
Subject: [SR-Users] vscode-kamailio-syntax - issue with empty comment
 line
In-Reply-To: <c69f93a5-a895-54ca-644f-7265d48d5a9f@gmail.com>
References: <AM4PR0202MB28205314D0E82DAA647DF2A5E6F50@AM4PR0202MB2820.eurprd02.prod.outlook.com>
 <8634d75d-3a7e-f27f-42b2-dd8c8d0b4adb@gmail.com>
 <AM4PR0202MB282004DE31130EF0443B854EE6F50@AM4PR0202MB2820.eurprd02.prod.outlook.com>
 <c69f93a5-a895-54ca-644f-7265d48d5a9f@gmail.com>
Message-ID: <AM4PR0202MB28201BF8C21443E21715BB62E6F40@AM4PR0202MB2820.eurprd02.prod.outlook.com>

Great! :)

Thanks Daniel.


> Fixed and published a new version of the extension, since I took the time to add detection of indexes and transformations for pseudo-variables:
>
> https://www.kamailio.org/w/2020/12/vscode-syntax-highlighting-for-kamailio-cfg-v1-0-8/
>
> Cheers,
> Daniel

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

From miconda at gmail.com  Tue Dec  1 18:57:12 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 1 Dec 2020 18:57:12 +0100
Subject: [SR-Users] How to msg_apply_changes in a branch route?
In-Reply-To: <CADkWibextRWWhqwTd3f7LT1_-R=r=ydY3jjh59gjXzfXD1sApQ@mail.gmail.com>
References: <CADkWibextRWWhqwTd3f7LT1_-R=r=ydY3jjh59gjXzfXD1sApQ@mail.gmail.com>
Message-ID: <d8eee118-0b77-f784-4f09-028135f27a93@gmail.com>

Hello,

at this moment, msg_apply_changes() works before the transaction is
created. Transaction itself is rather big structure and handling it is
done with a complex state machine (lifetime timers, retransmissions,
callbacks, ...). If someone wants to work on such enhancement, is more
than welcome, just make it configurable and as much as possible not
intrusive. For the moment, obviously branch processing is done in the
context of transaction.

On the other hand, if you need it in relation with rtpengine, there are
variables that you can use to set/get the sdp exchanged with rtpengine:

? *
https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.p.read_sdp_pv

Then you can change what is returned and use set_body().

Cheers,
Daniel

On 01.12.20 09:36, Anthony Alba wrote:
> Is there a way to obtain the effect of msg_apply_changes in a branch route?
>
> I want to do:
>
> route[BRANCHMANAGE] {
>
> rtpengine_manage()
> msg_apply_changes()
>  // further mangle the SDP with textops for
> // obtuse UAs
>
> }
>
> The reason for this, is that after forking, I have some UAs that are
> extremely picky about SDP, and I need to mangle the body to make them
> happy. (4000 char limit, 68 attribute limit on SDP body - ever seen
> that? Compared with the absolutely gigantic OFFERs from WebRTC
> signalling libraries...)
>
> Now rtpengine_manage() and textops are working on separate copies of
> the msg body and the results don't stack correctly.
>
> Cheers
> Anthony Alba
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From david.villasmil.work at gmail.com  Wed Dec  2 00:26:21 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Tue, 1 Dec 2020 23:26:21 +0000
Subject: [SR-Users] How to DIY/Setup An Open Source IP PBX
 Appliance/Server?
In-Reply-To: <FF652D0F-030F-4003-9E2E-B6A26508A582@edvina.net>
References: <c64798c86a8f7ecfe0e4a646e5dddf4c@teo-en-ming.com>
 <FF652D0F-030F-4003-9E2E-B6A26508A582@edvina.net>
Message-ID: <CAFGRPVpE6d3eKJ8NDdRCjrd+S+bHuqzV72uksx-304ouFvMqkA@mail.gmail.com>

+1
And Personally I like FS much much more. :)

On Tue, 1 Dec 2020 at 15:29, Olle E. Johansson <oej at edvina.net> wrote:

> If you want to discuss Asterisk, I recommend that you use the Asterisk
> mailing lists.
> This is not it.
>
> /O
>
> > On 1 Dec 2020, at 16:17, Turritopsis Dohrnii Teo En Ming <
> ceo at teo-en-ming.com> wrote:
> >
> > Subject: How to DIY/Setup An Open Source IP PBX Appliance/Server?
> >
> > Good day from Singapore,
> >
> > After reading recent reviews, I gather that Asterisk is the gold
> standard when it comes to open source VoIP systems and it is the most
> famous open source PBX out there.
> >
> > Article: Compare the Top 10 Best Open Source PBX Software of 2020
> > Link:
> https://www.voipreview.org/business-voip/best-open-source-pbx-software
> >
> > Article: Top 10 Free Open Source PBX Software Solutions
> > Link: https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/
> >
> > The following is an excerpt from Wikipedia:
> >
> > "Asterisk is a core component in many commercial products and
> open-source projects. Some of the commercial products are hardware and
> software bundles, for which the manufacturer supports and releases the
> software with an open-source distribution model.
> >
> > AskoziaPBX, a fork of the m0n0wall project, uses Asterisk PBX software
> to realize all telephony functions.
> >
> > AstLinux is a "Network Appliance for Communications" open-source
> software distribution.[15]
> >
> > FreePBX, an open-source graphical user interface, bundles Asterisk as
> the core of its FreePBX Distro[16]
> >
> > LinuxMCE bundles Asterisk to provide telephony; there is also an
> embedded version of Asterisk for OpenWrt routers.
> >
> > PBX in a Flash/Incredible PBX and trixbox are software PBXes based on
> Asterisk.
> >
> > Elastix previously used Asterisk, HylaFAX, Openfire and Postfix to offer
> PBX, fax, instant messaging and email functions, respectively, before
> switching to 3CX.
> >
> > Issabel is an open-source Unified Communications software which uses
> Asterisk for telephony functions. It was forked from the open-source
> versions of Elastix when 3CX acquired it.
> >
> > *astTECS uses Asterisk in its VoIP and mobile gateways."
> >
> > Link: https://en.wikipedia.org/wiki/Asterisk_(PBX)
> >
> > I would like to DIY/setup an IP PBX appliance/server using free open
> source projects.
> > Which free open source project, mentioned in the list and links above,
> would you recommend to DIY my IP PBX appliance/server?
> >
> > Should I buy a desktop computer or get one of those appliances listed in
> the link below to serve as my IP PBX appliance/server?
> >
> > Link:
> https://www.lazada.sg/products/pfsense-iron-metal-case-fanless-intel-celeron-j1800-dual-core-mini-pc-firewall-soft-router-with-ddr3l-msata-ssd-4-gigabit-lan-rj45-com-port-i449270007-s1196780479.html?spm=a2o42.searchlist.list.89.100857d22PjCYx&search=1
> >
> > Please also refer me to very good, detailed and well explained
> guides/tutorials/manuals on setting up open source IP PBX
> appliances/servers.
> >
> > Lastly, please recommend a cheap and affordable IP phone (suggest brand
> and model) to go along with my DIY open source IP PBX appliance/server.
> >
> > Mr. Turritopsis Dohrnii Teo En Ming, 42 years as of 1st December 2020
> Tuesday, is a TARGETED INDIVIDUAL (TI) living in Singapore.
> >
> > Thank you very much.
> >
> >
> >
> >
> >
> >
> >
> > -----BEGIN EMAIL SIGNATURE-----
> >
> > The Gospel for all Targeted Individuals (TIs):
> >
> > [The New York Times] Microwave Weapons Are Prime Suspect in Ills of
> > U.S. Embassy Workers
> >
> > Link:
> https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html
> >
> >
> ********************************************************************************************
> >
> > Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's
> Academic
> > Qualifications as at 14 Feb 2019 and refugee seeking attempts at the
> United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019)
> and Australia (25 Dec 2019 to 9 Jan 2020):
> >
> > [1] https://tdtemcerts.wordpress.com/
> >
> > [2] https://tdtemcerts.blogspot.sg/
> >
> > [3] https://www.scribd.com/user/270125049/Teo-En-Ming
> >
> > -----END EMAIL SIGNATURE-----
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201201/1f3217eb/attachment.htm>

From me.projects at yahoo.com  Wed Dec  2 09:58:43 2020
From: me.projects at yahoo.com (me.projects at yahoo.com)
Date: Wed, 2 Dec 2020 08:58:43 +0000 (UTC)
Subject: [SR-Users] MSTeams Kamailio with PBX Hold Refer issue
References: <1620937435.3504796.1606899523387.ref@mail.yahoo.com>
Message-ID: <1620937435.3504796.1606899523387@mail.yahoo.com>

Hi, I have been trying to integrate MSTeams with PBX Through Kamailio. Calls are working now. Hold has Issues. MSTeams uses REFER to manage this all with NOTIFY.?
I am sending t_send_reply("202", "Accepted");
when receive Refer now I need to send NOTIFY I think I can use?t_uac_send() NOTIFY I am unable to send t_uac_send properly on when?recertifications refer from MSTeams.
Any one with the?experience on this ?
Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201202/30c80773/attachment.htm>

From adi.tabacioiu at c-s.ro  Wed Dec  2 10:22:39 2020
From: adi.tabacioiu at c-s.ro (Adrian Tabacioiu)
Date: Wed, 2 Dec 2020 11:22:39 +0200
Subject: [SR-Users] REGINFO events not sending
In-Reply-To: <AM0PR05MB65956A9ABAD02A38ECB32B0AC5F80@AM0PR05MB6595.eurprd05.prod.outlook.com>
References: <000001d6c3e5$8a057970$9e106c50$@c-s.ro>
 <AM0PR05MB65956A9ABAD02A38ECB32B0AC5F80@AM0PR05MB6595.eurprd05.prod.outlook.com>
Message-ID: <00d401d6c88c$ae5597f0$0b00c7d0$@c-s.ro>

Hello Henning,

 

I receive presence notifications are working, I activated presence using
"WITH_PRESENCE" define.

 

Is there anything else I should do for reginfo ?

On the internet I don't find other examples than smsops project which seams
very particular, and documentation is very thin.

 

Thanks,

Adrian

 

 

From: Henning Westerholt <hw at skalatan.de> 
Sent: Friday, November 27, 2020 9:58 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Cc: Adrian Tabacioiu <adi.tabacioiu at c-s.ro>
Subject: RE: [SR-Users] REGINFO events not sending

 

Hello Adrian,

 

are you also doing the usual presence stuff in your config, e.g. handling
subscriptions of the users?

 

The module documentation not much extensive, I would suggest to search for
some examples how to use it. There might be also something in the kamailio
repository or can be found on the net.

 

Cheers,

 

Henning

 

-- 

Henning Westerholt -  <https://skalatan.de/blog/> https://skalatan.de/blog/

Kamailio services -  <https://gilawa.com/> https://gilawa.com 

 

From: sr-users <sr-users-bounces at lists.kamailio.org
<mailto:sr-users-bounces at lists.kamailio.org> > On Behalf Of Adrian Tabacioiu
Sent: Thursday, November 26, 2020 12:16 PM
To: 'Kamailio (SER) - Users Mailing List' <sr-users at lists.kamailio.org
<mailto:sr-users at lists.kamailio.org> >
Subject: [SR-Users] REGINFO events not sending

 

Hello,

 

Does anybody has used with success the reginfo modules ?

I added lines bellow in configuration, and tried different variations, 

Even if my  subscribe for "reginfo" events  is accepted (with 202 OK), I
receive no notification when respective user registers.

Nor do I get the xml body in the first notification.

 

Added in my config:

 

 

loadmodule "presence_reginfo.so"

loadmodule "pua_reginfo.so"

 

modparam("pua_reginfo", "default_domain", "192.168.60.65")

modparam("pua_reginfo", "server_address", "sip:reginfo at 192.168.60.65")

modparam("pua_reginfo", "publish_reginfo", 1)

 

Thank you in advance,

Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201202/d150e393/attachment.htm>

From bastian.triller at gmail.com  Wed Dec  2 14:25:34 2020
From: bastian.triller at gmail.com (Bastian Triller)
Date: Wed, 2 Dec 2020 14:25:34 +0100
Subject: [SR-Users] Kamailio Remove Remove "Allow" features from header
In-Reply-To: <1846545269.1831326.1606395218275@mail.yahoo.com>
References: <1846545269.1831326.1606395218275.ref@mail.yahoo.com>
 <1846545269.1831326.1606395218275@mail.yahoo.com>
Message-ID: <CALJ8HB4p8HoARtOR-m-fsUiCh=ad_SZe1B3=YGxnTer+xidhbA@mail.gmail.com>

Try

exclude_hf_value("Allow", "REFER");

in your initial INVITE to Teams resp. your reply on initial INVITE from
Teams.

https://www.kamailio.org/docs/modules/devel/modules/textopsx.html#textopsx.f.exclude_hf_value


On Thu, Nov 26, 2020, 13:54 me.projects at yahoo.com <me.projects at yahoo.com>
wrote:

> Hi,
>
> I want to remove some "Allow" features from my Kamailio SBC like I want to
> keep following only
>
> *Allow: OPTIONS, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK,
> REGISTER,*
>
> How can I achieve that?
>
> Thanks,
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201202/01ac56b3/attachment.htm>

From llcfhllml at gmail.com  Wed Dec  2 15:36:28 2020
From: llcfhllml at gmail.com (beer Ll)
Date: Wed, 2 Dec 2020 15:36:28 +0100
Subject: [SR-Users] android client SIP TLS client autentication + kamailio
Message-ID: <CAL1qiZC0_saQpD43a0YmiVnR9ko0Osd5OgxFPU9fDRqSayGH8Q@mail.gmail.com>

Hello
Has anybody use a android SIP client with TLS client authentication enabled
with kamailio?
Do you have suggestion ?

Many thanks

Luca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201202/7837944c/attachment.htm>

From me.projects at yahoo.com  Wed Dec  2 16:17:59 2020
From: me.projects at yahoo.com (me.projects at yahoo.com)
Date: Wed, 2 Dec 2020 15:17:59 +0000 (UTC)
Subject: [SR-Users] android client SIP TLS client autentication +
 kamailio
In-Reply-To: <CAL1qiZC0_saQpD43a0YmiVnR9ko0Osd5OgxFPU9fDRqSayGH8Q@mail.gmail.com>
References: <CAL1qiZC0_saQpD43a0YmiVnR9ko0Osd5OgxFPU9fDRqSayGH8Q@mail.gmail.com>
Message-ID: <2144736997.3612856.1606922279877@mail.yahoo.com>

 Hi, I have used it. Some older version of Android I think before Android 4.0 but not sure, does not support TLS so you have to work with older version of TLS or SSL.
Security with HTTPS and SSL | Android Developers


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Security with HTTPS and SSL | Android Developers


 |

 |

 |

How to enable TLS 1.2 support in an Android application (running on Android 4.1 JB)


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
How to enable TLS 1.2 support in an Android application (running on Andr...

As per the docs in Android for SSLSocket and SSLContext, TLS v1.1 and v1.2 protocols are supported in API level ...
 |

 |

 |

Which Library you are using on Android ?






    On Wednesday, December 2, 2020, 07:37:02 PM GMT+5, beer Ll <llcfhllml at gmail.com> wrote:  
 
 HelloHas anybody use a android SIP client with TLS client authentication enabled with?kamailio?Do you have?suggestion ?
Many?thanks
Luca



_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201202/85bf2893/attachment.htm>

From jh at tutpro.com  Wed Dec  2 17:10:06 2020
From: jh at tutpro.com (Juha Heinanen)
Date: Wed, 2 Dec 2020 18:10:06 +0200
Subject: [SR-Users] android client SIP TLS client autentication + kamailio
In-Reply-To: <CAL1qiZC0_saQpD43a0YmiVnR9ko0Osd5OgxFPU9fDRqSayGH8Q@mail.gmail.com>
References: <CAL1qiZC0_saQpD43a0YmiVnR9ko0Osd5OgxFPU9fDRqSayGH8Q@mail.gmail.com>
Message-ID: <24519.48222.66595.301156@tutpro.com>

beer Ll writes:

> Has anybody use a android SIP client with TLS client authentication enabled
> with kamailio?

One possibility is baresip and baresip+ available from Play Store and
F-Droid.

-- Juha


From ascanio.alba7 at gmail.com  Thu Dec  3 00:53:40 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Thu, 3 Dec 2020 07:53:40 +0800
Subject: [SR-Users] kamailio not absorbing ACK to CANCEL when behind a Path
 proxy
Message-ID: <CADkWibd_f=B6ZA5+JCHSJWqvi9cnOZF2j=Np4QcA__UbZvO52Q@mail.gmail.com>

Folks,

I have a weird situation, when I enable Path header, kamailio behind a
Path proxy,
that kamailio doesn't recognise the ACK to CANCEL and tries to forward it.


Test scenario:
- voice.example.com is a stateless proxy with TLS/UDP bridging to kamailio.
- on the UDP leg to kamailio it will add a Path: header to REGISTER

UA1 = david is calling UA2 = charles and UA2 is sending 603

1 . UA1: preloaded route set (outbound proxy)
# this is the Path proxy
Route: sip:voice.example.com;transport=tls;lr

2. UA2: sends CANCEL 603
- kamailio immediately sends its (per-hop?) ACK
- kamailio forwards CANCEL to UA1

kamailio sent this (per-hop?) ACK
- the Route header is the internal UDP interface of the Path proxy

ACK sip:charles at 192.168.1.7:37309;transport=TCP;ob SIP/2.0
Via: SIP/2.0/UDP
192.168.122.99:5064;branch=z9hG4bK735d.6b27c8d09e40462ef47eccf90eb10823.0
Max-Forwards: 70
From: sip:david at voice.example.com;tag=i1acAHsitf2gcN9uHH-ZSyJ5OdT8O5M0
To: <sip:charles at voice.example.com>;tag=LmUY79rIdBQiiSakML4F0lHl271VdUn8
Call-ID: qM3W-fMrzPsvcjRSD1okEp5nbgHCF5Hu
CSeq: 16667 ACK
Route: <sip:192.168.122.100;lr>
Content-Length: 0


3. UA1 sends ACK
kamailio sees this
- top Via is path proxy
- 2nd Via is UA (caller)
- CSeq correctly matches the INVITE
- kamailio does not recognise this ACK from UA1(caller),
tries to forward it, and also resends 603 to UA1(caller) 3 times

ACK sip:charles at voice.example.com SIP/2.0
Via: SIP/2.0/UDP
192.168.122.100:5060;branch=z9hG4bKb3c9a7a3b6ec9e78d0144cda709f7047
Via: SIP/2.0/TLS
192.168.1.17:44925;rport=44925;branch=z9hG4bKPjFM-9gpaJEghJvN19TjnvScCwCoAGzwEc;alias;received=192.168.1.17
Max-Forwards: 70
From: sip:david at voice.example.com;tag=i1acAHsitf2gcN9uHH-ZSyJ5OdT8O5M0
To: sip:charles at voice.example.com;tag=LmUY79rIdBQiiSakML4F0lHl271VdUn8
Call-ID: qM3W-fMrzPsvcjRSD1okEp5nbgHCF5Hu
CSeq: 16667 ACK
Route: <sip:voice.example.com;transport=tls;lr>
Content-Length: 0

Now kamailio should absorb this ACK, as it has already sent its
per-hop ACK. Instead I see

ERROR: <core> [core/forward.c:541]: forward_request(): cannot forward
to af 2, proto 3 no corresponding listening socket

I don't expect kamailio to forward anything at this point. The route
block is route[WITHINDLG] and it calls t_relay() normally.

route[WITHINDLG] {
if (!has_totag()) return;

# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
} else if ( is_method("ACK") ) {
# ACK is forwarded statelessly
route(NATMANAGE);
} else if ( is_method("NOTIFY") ) {
# Add Record-Route for in-dialog NOTIFY as per RFC 6665.
record_route();
}
route(RELAY); # we should absorb this ACK, no?
exit;
}

4. If I remove the Path proxy and kamailio is the TLS proxy at
voice.example.com the call flow works perfectly.
The ACK from caller (david) is absorbed.

5. Regular calls, when UA2 accepts the call, work fine.  In-dialog
requests for BYE, from both UAs, work
correctly with this Path proxy. Each UA has the complete 5 element
route set( 2 x Path proxy + kamailio + 2 x Path proxy).
The working route set looks like this:

BYE sip:david at 192.168.1.17:44925;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TLS
192.168.1.7:37309;rport;branch=z9hG4bKPjHdUtaUL5AfRcV-SX1Puya4niJKOOQ4VQ;alias
Max-Forwards: 70
From: <sip:charles at voice.example.com>;tag=6zOt.H7w8NL5njV7klwGLlSJy.U5yBC9
To: <sip:david at voice.example.com>;tag=Pa0ORUxA-7lK0BnR4pLJ5n8rn2OvQrJy
Call-ID: 3gWy4Q7O.-zQ-I07lRKHyFyX6azyCSwG
CSeq: 12855 BYE
Route: <sip:voice.example.com;transport=tls;lr;r2=on>
Route: <sip:192.168.122.100;lr;r2=on>
Route: <sip:192.168.122.99:5064;lr>
Route: <sip:192.168.122.100;lr;r2=on>
Route: <sip:voice.example.com;transport=tls;lr;r2=on>
User-Agent: basesip 1.0.0
Content-Length:  0



Any ideas?

Anthony Alba


From david.villasmil.work at gmail.com  Thu Dec  3 01:31:24 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 3 Dec 2020 00:31:24 +0000
Subject: [SR-Users] kamailio51 installs 5.2.1?
Message-ID: <CAFGRPVrXd01KnNt7ebmv9WbMn+0k=H-7CLBuVNW-r9uxsNjLjw@mail.gmail.com>

Hello everyone,

On a debian buster i added the repo

deb     http://deb.kamailio.org/kamailio51 buster main
deb-src http://deb.kamailio.org/kamailio51 buster main

But when i install i get 5.2, is this right?

additional info:

# apt-cache showpkg kamailio
Package: kamailio
Versions:
5.2.1-1
(/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-i386_Packages)
(/var/lib/dpkg/status)
 Description Language:
                 File:
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-i386_Packages
                  MD5: df3e15f422439e08c305782f5650a98c
 Description Language: en
                 File:
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_i18n_Translation-en
                  MD5: df3e15f422439e08c305782f5650a98c

5.1.10.1+bpo10
(/var/lib/apt/lists/deb.kamailio.org_kamailio51_dists_buster_main_binary-i386_Packages)
 Description Language:
                 File:
/var/lib/apt/lists/deb.kamailio.org_kamailio51_dists_buster_main_binary-i386_Packages
                  MD5: ebddf40d0dfbfde1c479419970f978c7



Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201203/2a4ebd91/attachment.htm>

From daniel.donoghue at freespee.com  Wed Dec  2 17:04:15 2020
From: daniel.donoghue at freespee.com (Daniel Donoghue)
Date: Wed, 2 Dec 2020 17:04:15 +0100
Subject: [SR-Users] Kamailio 5.4 ndb_redis, selecting a database
Message-ID: <307DDA68-28B6-407D-9A20-2171248D5C5F@freespee.com>

Hello,

I note that I can use the ndb_redis server config parameter to specify connection details for my redis servers; I also note that the connection string can specify a ?db? parameter which can be set from 0 to 9, with the default being 0.

I am looking for a way to dynamically set the db parameter. I do not which to add the same server with different names N times just to select a different db and having N times more connections to it than necessary.

It looks as though I can call redis_cmd(?svrN?, ?SELECT dbN?, ?init?); but will that propagate properly and set the correct db for all connections to my redis server for the lifetime of the request?

Ideally, I?d like to be able to specify an avp for the db, or have a function to set the db per request.


With every blessing,
?
Daniel Donoghue



From g.wolzak at kazlow.nl  Thu Dec  3 10:04:31 2020
From: g.wolzak at kazlow.nl (Gertjan Wolzak)
Date: Thu, 3 Dec 2020 10:04:31 +0100
Subject: [SR-Users] Dialog profile not defined
Message-ID: <e90e3eae-f3a4-5a1f-6594-6f27434cb32c@kazlow.nl>

Hello Kamailions,

I am running into the following issue.

The same setup I had working on 5.0, now I am using a 5.4 version of 
Kamailio, but I do not believe it has to do with the version, more with 
my ability to make errors...

I am trying to limit incoming calls by using the dialog module. The max 
concurrent calls value I retrieve from a database.

But when I try to start Kamailio it will not because the dialog profile 
is not defined...

These are my configured Dialog parameters:

# ---- Dialog params -------------
modparam("dialog", "default_timeout", 7200)
modparam("dialog", "db_mode", 0)
modparam("dialog", "dlg_flag", DLG_FLAG)
modparam("dialog", "hash_size", 4096)
#modparam("dialog", "detect_spirals", 1)
modparam("dialog", "profiles_with_value", "callee")


My check on the concurrent inbound calls:

route[CONCURRENT_IN]
{
 ??????? #Add call to callee profile
 ??????? #Check if callee has not reached inbound call limit

 ??????? #Get max concurrent calls
 ??????? sql_query("cc", "select max_calls_in from calllimit where 
cust_id='$avp(custid)'", "ra");
 ??????? $avp(maxcalls)=$dbr(ra=>[0,0]);
 ??????? sql_result_free("ra");
 ??????? $avp(concurrent) = 0;
 ??????? get_profile_size("callee", "$avp(custid)", "$avp(concurrent)");
 ??????? if( $avp(concurrent) = $var(max) )
 ??????? {
 ??????????????? xlog("L_INFO"," Call limit reached for customer 
$avp(custid)\r\n ");
 ??????????????? sl_send_reply("503", "No Lines Available");
 ??????????????? exit;
 ??????? }

 ??????? set_dlg_profile("callee", "$avp(custid)");

 ??????? return;
}


And the kamailio log error:

Dec? 3 09:12:08 proxy01 kamailio[74102]: INFO: <core> [main.c:2833]: 
main(): processes (at least): 21 - shm size: 67108864 - pkg size: 8388608
Dec? 3 09:12:08 proxy01 kamailio[74102]: CRITICAL: dialog 
[dialog.c:391]: fixup_profile(): profile <callee> not defined
Dec? 3 09:12:08 proxy01 kamailio[74102]: ERROR: <core> 
[core/route.c:1166]: fix_actions(): fixing failed (code=-6) at 
cfg:/usr/local/etc/kamailio/kamailio.cfg:1576


Is someone able to see where I go wrong and point me in the right direction?

Thank you.

Rgds,

Gertjan Wolzak



From volodyaivanets at gmail.com  Thu Dec  3 13:38:58 2020
From: volodyaivanets at gmail.com (=?UTF-8?B?0JLQvtC70L7QtNC40LzQuNGAINCG0LLQsNC90LXRhtGM?=)
Date: Thu, 3 Dec 2020 14:38:58 +0200
Subject: [SR-Users] $TF pseudo variable can not be used
Message-ID: <CAOQgkjaYVQe7DmbPubYus=W2Ky3VeDw89oQo6EhczSCgto4bEA@mail.gmail.com>

Hello!

I'm using a $TF variable in my config for some logging purposes. It was
providing the correct string with Kamailio version 5.3.8 on CentOS 6 and 8.
After updating to Kamailio version 5.4.1, the variable started to show
something else.

I also tried versions 5.4.2 and development 5.5.0 on CentOS 6 and the
problem still persists. With version 5.5.0_dev3 this variable shows "pG?"
for me.

I was wondering if someone else is using it too with Kamailio version 5.4.1
or newer on different platforms and has this issue.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201203/e66dc405/attachment.htm>

From miconda at gmail.com  Thu Dec  3 14:10:51 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 3 Dec 2020 14:10:51 +0100
Subject: [SR-Users] $TF pseudo variable can not be used
In-Reply-To: <CAOQgkjaYVQe7DmbPubYus=W2Ky3VeDw89oQo6EhczSCgto4bEA@mail.gmail.com>
References: <CAOQgkjaYVQe7DmbPubYus=W2Ky3VeDw89oQo6EhczSCgto4bEA@mail.gmail.com>
Message-ID: <2788e072-1ec3-73a1-adea-6c8fb798d86f@gmail.com>

Hello,

I found a regression introduced when switching to thread-safe time
function. Can you test with master branch or with the patch from commit:

? *
https://github.com/kamailio/kamailio/commit/02fc919e4f177cc3ab9c5d53eb9ea2019c572bd9

If works ok, then I will backport.

Cheers,
Daniel

On 03.12.20 13:38, ????????? ??????? wrote:
> Hello!
>
> I'm using a?$TF variable in my config for some logging purposes. It
> was providing the correct string with Kamailio version 5.3.8 on CentOS
> 6 and 8. After updating to Kamailio version 5.4.1, the variable
> started to show something else.
>
> I also tried versions 5.4.2 and development 5.5.0 on CentOS 6 and the
> problem still persists. With version 5.5.0_dev3 this variable shows
> "pG?" for me.
>
> I was wondering if someone else is using it too with Kamailio version
> 5.4.1 or newer on different platforms and has this issue.
>
> Thanks!
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201203/0d6f29b0/attachment.htm>

From james at frideo.com  Thu Dec  3 15:06:49 2020
From: james at frideo.com (James Browne)
Date: Thu, 3 Dec 2020 14:06:49 +0000
Subject: [SR-Users] TOPOS replication with KDMQ
Message-ID: <CAEpCD+qrK7TgFKf2j-fZC8ryJtw=zZg+rC58WXJFoKcfmPVBUA@mail.gmail.com>

Has anyone ever implemented DMQ replication of TOPOS data between
kamailio servers?

I'm trying to find the easiest (to maintain) way to implement this
replication, possibly without using an external database.

James


From volodyaivanets at gmail.com  Thu Dec  3 15:46:52 2020
From: volodyaivanets at gmail.com (=?UTF-8?B?0JLQvtC70L7QtNC40LzQuNGAINCG0LLQsNC90LXRhtGM?=)
Date: Thu, 3 Dec 2020 16:46:52 +0200
Subject: [SR-Users] $TF pseudo variable can not be used
In-Reply-To: <2788e072-1ec3-73a1-adea-6c8fb798d86f@gmail.com>
References: <CAOQgkjaYVQe7DmbPubYus=W2Ky3VeDw89oQo6EhczSCgto4bEA@mail.gmail.com>
 <2788e072-1ec3-73a1-adea-6c8fb798d86f@gmail.com>
Message-ID: <CAOQgkjZ87AWd7=TK8zzTPLQqvZwRKsxKrB=khi=dkiuAEG+WbA@mail.gmail.com>

Hello Daniel,

Your patch worked.

Thank you!

??, 3 ????. 2020 ? 15:11 Daniel-Constantin Mierla <miconda at gmail.com> ????:

> Hello,
>
> I found a regression introduced when switching to thread-safe time
> function. Can you test with master branch or with the patch from commit:
>
>   *
> https://github.com/kamailio/kamailio/commit/02fc919e4f177cc3ab9c5d53eb9ea2019c572bd9
>
> If works ok, then I will backport.
>
> Cheers,
> Daniel
> On 03.12.20 13:38, ????????? ??????? wrote:
>
> Hello!
>
> I'm using a $TF variable in my config for some logging purposes. It was
> providing the correct string with Kamailio version 5.3.8 on CentOS 6 and 8.
> After updating to Kamailio version 5.4.1, the variable started to show
> something else.
>
> I also tried versions 5.4.2 and development 5.5.0 on CentOS 6 and the
> problem still persists. With version 5.5.0_dev3 this variable shows "pG?"
> for me.
>
> I was wondering if someone else is using it too with Kamailio version
> 5.4.1 or newer on different platforms and has this issue.
>
> Thanks!
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201203/436e5c02/attachment.htm>

From achen at fuze.com  Thu Dec  3 19:39:46 2020
From: achen at fuze.com (Andrew Chen)
Date: Thu, 3 Dec 2020 13:39:46 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate selection
Message-ID: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>

Hi all,

I was wondering if someone can help me understand how the ICE parameter
works in the rtpengine module works.

So basically our client does an ICE candidate lookup and grabs a list of
them and applies it to the INVITE that gets sent to the Kamailio.  The list
looks like this:

2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]:
a=candidate:3373280875 1 udp 2122262783
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0
network-id 2 network-cost 10
2020-12-03T18:05:46.456057+00:00 ashmainkama51 kamailio[22147]:
a=candidate:3040609428 1 udp 2122197247
2001:8a0:78fc:7000:d979:bf75:dbc0:69f 59828 typ host generation 0
network-id 3 network-cost 10
2020-12-03T18:05:46.456081+00:00 ashmainkama51 kamailio[22147]:
a=candidate:1681997092 1 udp 2122129151 192.168.1.66 59829 typ host
generation 0 network-id 1 network-cost 10
2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
a=candidate:2274611867 1 tcp 1518283007
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active generation
0 network-id 2 network-cost 10
2020-12-03T18:05:46.456131+00:00 ashmainkama51 kamailio[22147]:
a=candidate:4223662180 1 tcp 1518217471
2001:8a0:78fc:7000:d979:bf75:dbc0:69f 9 typ host tcptype active generation
0 network-id 3 network-cost 10
2020-12-03T18:05:46.456155+00:00 ashmainkama51 kamailio[22147]:
a=candidate:717406676 1 tcp 1518149375 192.168.1.66 9 typ host tcptype
active generation 0 network-id 1 network-cost 10
2020-12-03T18:05:46.456180+00:00 ashmainkama51 kamailio[22147]:
a=candidate:2130547417 1 udp 8199935 206.81.191.27 61165 typ relay raddr
85.247.0.121 rport 53091 generation 0 network-id 1 network-cost 10


In the rtpengine_offer, I have this:

rtpengine_offer("ICE=force DTLS=passive replace-session-connection
replace-origin external internal");

What i am trying to do is to tell the freeswitch endpoint to use rtpengine
as ICE candidate and I see in the SDP this is happening:

a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host generation
0

Btw..206.81.191.52 is a separate AWS instance running rtpengine binary.

On the rtpengine_answer, I tell the remote client side the same thing..use
rtpengine as your ICE candidate:

rtpengine_answer("ICE=force DTLS=passive replace-session-connection
replace-origin internal external");

and this is snippet from 200 OK:

a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host generation
0

Question:

Why does the rtpengine logs still show that it's trying to use
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 as RTP candidate in this scenario?

Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
[ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)

I thought ICE=force will handle such adjustments so that all rtp is handled
by the rtpengine to our client and bypass the STUN server?



Thanks.

-- 
Andy Chen
Sr. Telephony Lead Engineer
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201203/cf9f383b/attachment.htm>

From pojogas at gmail.com  Thu Dec  3 20:39:15 2020
From: pojogas at gmail.com (Sergiu Pojoga)
Date: Thu, 3 Dec 2020 14:39:15 -0500
Subject: [SR-Users] Dialog profile not defined
In-Reply-To: <e90e3eae-f3a4-5a1f-6594-6f27434cb32c@kazlow.nl>
References: <e90e3eae-f3a4-5a1f-6594-6f27434cb32c@kazlow.nl>
Message-ID: <CAJZsGCki_aiXoFNRz0W1FmAidRXJ6c+ywuJ2xtBT7Vg4TrrS=w@mail.gmail.com>

Hi Gertjan,

Probably unrelated, but you have a syntax error in the IF statement, has to
be double ==

if( $avp(concurrent) == $var(max) )

See if that helps. Otherwise, what's the line #1576?

Regards,
--Sergiu

On Thu, Dec 3, 2020 at 4:06 AM Gertjan Wolzak <g.wolzak at kazlow.nl> wrote:

> Hello Kamailions,
>
> I am running into the following issue.
>
> The same setup I had working on 5.0, now I am using a 5.4 version of
> Kamailio, but I do not believe it has to do with the version, more with
> my ability to make errors...
>
> I am trying to limit incoming calls by using the dialog module. The max
> concurrent calls value I retrieve from a database.
>
> But when I try to start Kamailio it will not because the dialog profile
> is not defined...
>
> These are my configured Dialog parameters:
>
> # ---- Dialog params -------------
> modparam("dialog", "default_timeout", 7200)
> modparam("dialog", "db_mode", 0)
> modparam("dialog", "dlg_flag", DLG_FLAG)
> modparam("dialog", "hash_size", 4096)
> #modparam("dialog", "detect_spirals", 1)
> modparam("dialog", "profiles_with_value", "callee")
>
>
> My check on the concurrent inbound calls:
>
> route[CONCURRENT_IN]
> {
>          #Add call to callee profile
>          #Check if callee has not reached inbound call limit
>
>          #Get max concurrent calls
>          sql_query("cc", "select max_calls_in from calllimit where
> cust_id='$avp(custid)'", "ra");
>          $avp(maxcalls)=$dbr(ra=>[0,0]);
>          sql_result_free("ra");
>          $avp(concurrent) = 0;
>          get_profile_size("callee", "$avp(custid)", "$avp(concurrent)");
>          if( $avp(concurrent) = $var(max) )
>          {
>                  xlog("L_INFO"," Call limit reached for customer
> $avp(custid)\r\n ");
>                  sl_send_reply("503", "No Lines Available");
>                  exit;
>          }
>
>          set_dlg_profile("callee", "$avp(custid)");
>
>          return;
> }
>
>
> And the kamailio log error:
>
> Dec  3 09:12:08 proxy01 kamailio[74102]: INFO: <core> [main.c:2833]:
> main(): processes (at least): 21 - shm size: 67108864 - pkg size: 8388608
> Dec  3 09:12:08 proxy01 kamailio[74102]: CRITICAL: dialog
> [dialog.c:391]: fixup_profile(): profile <callee> not defined
> Dec  3 09:12:08 proxy01 kamailio[74102]: ERROR: <core>
> [core/route.c:1166]: fix_actions(): fixing failed (code=-6) at
> cfg:/usr/local/etc/kamailio/kamailio.cfg:1576
>
>
> Is someone able to see where I go wrong and point me in the right
> direction?
>
> Thank you.
>
> Rgds,
>
> Gertjan Wolzak
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201203/b4df0828/attachment.htm>

From hw at skalatan.de  Thu Dec  3 20:59:15 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Thu, 3 Dec 2020 19:59:15 +0000
Subject: [SR-Users] TOPOS replication with KDMQ
In-Reply-To: <CAEpCD+qrK7TgFKf2j-fZC8ryJtw=zZg+rC58WXJFoKcfmPVBUA@mail.gmail.com>
References: <CAEpCD+qrK7TgFKf2j-fZC8ryJtw=zZg+rC58WXJFoKcfmPVBUA@mail.gmail.com>
Message-ID: <AM0PR05MB65956AAB3FA700EF487F5B3DC5F20@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hi James,

I am not aware of a public DMQ extension or module for topos. You coult create an enhancement request for this on our tracker for this. If you want to start to work on this by yourself, sending an e-mail to sr-dev list would be also good to discuss the implementation approach.

Cheers,

Henning

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

-----Original Message-----
From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of James Browne
Sent: Thursday, December 3, 2020 3:07 PM
To: sr-users at lists.kamailio.org
Subject: [SR-Users] TOPOS replication with KDMQ

Has anyone ever implemented DMQ replication of TOPOS data between kamailio servers?

I'm trying to find the easiest (to maintain) way to implement this replication, possibly without using an external database.

James

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


From pojogas at gmail.com  Thu Dec  3 21:31:43 2020
From: pojogas at gmail.com (Sergiu Pojoga)
Date: Thu, 3 Dec 2020 15:31:43 -0500
Subject: [SR-Users] Dialog profile not defined
In-Reply-To: <CAJZsGCki_aiXoFNRz0W1FmAidRXJ6c+ywuJ2xtBT7Vg4TrrS=w@mail.gmail.com>
References: <e90e3eae-f3a4-5a1f-6594-6f27434cb32c@kazlow.nl>
 <CAJZsGCki_aiXoFNRz0W1FmAidRXJ6c+ywuJ2xtBT7Vg4TrrS=w@mail.gmail.com>
Message-ID: <CAJZsGCntG3U0F_nSTtJ9JASc71csa=YUpRHcbczQd7tp8ppm6Q@mail.gmail.com>

Bonus: better replace that equal with >= comparison. There may be
conditions under which the dialog profile counting has already exceeded the
max limit, in which case the call would go through.

Regards,
--Sergiu

On Thu, Dec 3, 2020 at 2:39 PM Sergiu Pojoga <pojogas at gmail.com> wrote:

> Hi Gertjan,
>
> Probably unrelated, but you have a syntax error in the IF statement, has
> to be double ==
>
> if( $avp(concurrent) == $var(max) )
>
> See if that helps. Otherwise, what's the line #1576?
>
> Regards,
> --Sergiu
>
> On Thu, Dec 3, 2020 at 4:06 AM Gertjan Wolzak <g.wolzak at kazlow.nl> wrote:
>
>> Hello Kamailions,
>>
>> I am running into the following issue.
>>
>> The same setup I had working on 5.0, now I am using a 5.4 version of
>> Kamailio, but I do not believe it has to do with the version, more with
>> my ability to make errors...
>>
>> I am trying to limit incoming calls by using the dialog module. The max
>> concurrent calls value I retrieve from a database.
>>
>> But when I try to start Kamailio it will not because the dialog profile
>> is not defined...
>>
>> These are my configured Dialog parameters:
>>
>> # ---- Dialog params -------------
>> modparam("dialog", "default_timeout", 7200)
>> modparam("dialog", "db_mode", 0)
>> modparam("dialog", "dlg_flag", DLG_FLAG)
>> modparam("dialog", "hash_size", 4096)
>> #modparam("dialog", "detect_spirals", 1)
>> modparam("dialog", "profiles_with_value", "callee")
>>
>>
>> My check on the concurrent inbound calls:
>>
>> route[CONCURRENT_IN]
>> {
>>          #Add call to callee profile
>>          #Check if callee has not reached inbound call limit
>>
>>          #Get max concurrent calls
>>          sql_query("cc", "select max_calls_in from calllimit where
>> cust_id='$avp(custid)'", "ra");
>>          $avp(maxcalls)=$dbr(ra=>[0,0]);
>>          sql_result_free("ra");
>>          $avp(concurrent) = 0;
>>          get_profile_size("callee", "$avp(custid)", "$avp(concurrent)");
>>          if( $avp(concurrent) = $var(max) )
>>          {
>>                  xlog("L_INFO"," Call limit reached for customer
>> $avp(custid)\r\n ");
>>                  sl_send_reply("503", "No Lines Available");
>>                  exit;
>>          }
>>
>>          set_dlg_profile("callee", "$avp(custid)");
>>
>>          return;
>> }
>>
>>
>> And the kamailio log error:
>>
>> Dec  3 09:12:08 proxy01 kamailio[74102]: INFO: <core> [main.c:2833]:
>> main(): processes (at least): 21 - shm size: 67108864 - pkg size: 8388608
>> Dec  3 09:12:08 proxy01 kamailio[74102]: CRITICAL: dialog
>> [dialog.c:391]: fixup_profile(): profile <callee> not defined
>> Dec  3 09:12:08 proxy01 kamailio[74102]: ERROR: <core>
>> [core/route.c:1166]: fix_actions(): fixing failed (code=-6) at
>> cfg:/usr/local/etc/kamailio/kamailio.cfg:1576
>>
>>
>> Is someone able to see where I go wrong and point me in the right
>> direction?
>>
>> Thank you.
>>
>> Rgds,
>>
>> Gertjan Wolzak
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201203/29ac5453/attachment.htm>

From rfuchs at sipwise.com  Thu Dec  3 23:38:37 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Thu, 3 Dec 2020 17:38:37 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
Message-ID: <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>

On 03/12/2020 13.39, Andrew Chen wrote:
> Hi all,
>
> I was wondering if someone can help me understand how the ICE 
> parameter works in the rtpengine module works.
>
> So basically our client does an ICE candidate lookup and grabs a list 
> of them and applies it to the INVITE that gets sent to the Kamailio.? 
> The list looks like this:
>
> 2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]: 
> a=candidate:3373280875 1 udp 2122262783 
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0 
> network-id 2 network-cost 10
> 2020-12-03T18:05:46.456057+00:00 ashmainkama51 kamailio[22147]: 
> a=candidate:3040609428 1 udp 2122197247 
> 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 59828 typ host generation 0 
> network-id 3 network-cost 10
> 2020-12-03T18:05:46.456081+00:00 ashmainkama51 kamailio[22147]: 
> a=candidate:1681997092 1 udp 2122129151 192.168.1.66 59829 typ host 
> generation 0 network-id 1 network-cost 10
> 2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]: 
> a=candidate:2274611867 1 tcp 1518283007 
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active 
> generation 0 network-id 2 network-cost 10
> 2020-12-03T18:05:46.456131+00:00 ashmainkama51 kamailio[22147]: 
> a=candidate:4223662180 1 tcp 1518217471 
> 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 9 typ host tcptype active 
> generation 0 network-id 3 network-cost 10
> 2020-12-03T18:05:46.456155+00:00 ashmainkama51 kamailio[22147]: 
> a=candidate:717406676 1 tcp 1518149375 192.168.1.66 9 typ host tcptype 
> active generation 0 network-id 1 network-cost 10
> 2020-12-03T18:05:46.456180+00:00 ashmainkama51 kamailio[22147]: 
> a=candidate:2130547417 1 udp 8199935 206.81.191.27 61165 typ relay 
> raddr 85.247.0.121 rport 53091 generation 0 network-id 1 network-cost 10
>
>
> In the rtpengine_offer, I have this:
>
> rtpengine_offer("ICE=force DTLS=passive replace-session-connection 
> replace-origin external internal");
>
> What i am trying to do is to tell the freeswitch endpoint?to use 
> rtpengine as ICE candidate and I see in the SDP this is happening:
>
> a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host 
> generation 0
>
> Btw..206.81.191.52 is a separate AWS instance running rtpengine binary.
>
> On the rtpengine_answer, I tell the remote client side the same 
> thing..use rtpengine as your ICE candidate:
>
> rtpengine_answer("ICE=force DTLS=passive replace-session-connection 
> replace-origin internal external");
>
> and this is snippet from 200 OK:
>
> a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host 
> generation 0
>
> Question:
>
> Why does the rtpengine logs still show?that it's trying to use 
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 as RTP candidate in this scenario?
>
> Dec? 3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG: 
> [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint: 
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
>
> I thought ICE=force will handle such adjustments so that all rtp is 
> handled by the rtpengine to our client and bypass the STUN server?
>
Isn't that what's happening? Rtpengine receives media from one peer and 
forwards it to one of the ICE candidates (presumably the primary one 
that was negotiated) of the other peer. Or am I misunderstanding what 
you posted?

Cheers


From miconda at gmail.com  Fri Dec  4 08:56:15 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 4 Dec 2020 08:56:15 +0100
Subject: [SR-Users] TOPOS replication with KDMQ
In-Reply-To: <AM0PR05MB65956AAB3FA700EF487F5B3DC5F20@AM0PR05MB6595.eurprd05.prod.outlook.com>
References: <CAEpCD+qrK7TgFKf2j-fZC8ryJtw=zZg+rC58WXJFoKcfmPVBUA@mail.gmail.com>
 <AM0PR05MB65956AAB3FA700EF487F5B3DC5F20@AM0PR05MB6595.eurprd05.prod.outlook.com>
Message-ID: <1dd869b2-a3af-6917-e536-b05a06bf8aa0@gmail.com>

Hello,

topos was designed with a backend, being it db/sql-like using the db
connectors (e.g., mysql, postgres, ...) or with topos_redis, tailored
for it to use a redis (or variants) backend.

>From this perspective, there is nothing at this moment that dmq could
replicate. It would require to make first an in-memory storage, then
look at adding dmq layer.

However, the idea of using from beginning a backend like redis, mysql,
... was to leverage the replication mechanism offered by the backend.

Unlike topoh, note that persistence is needed for topos, otherwise
traffic for active dialogs cannot be routed anymore.

Cheers,
Daniel

On 03.12.20 20:59, Henning Westerholt wrote:
> Hi James,
>
> I am not aware of a public DMQ extension or module for topos. You coult create an enhancement request for this on our tracker for this. If you want to start to work on this by yourself, sending an e-mail to sr-dev list would be also good to discuss the implementation approach.
>
> Cheers,
>
> Henning
>
> -- 
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://gilawa.com 
>
> -----Original Message-----
> From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of James Browne
> Sent: Thursday, December 3, 2020 3:07 PM
> To: sr-users at lists.kamailio.org
> Subject: [SR-Users] TOPOS replication with KDMQ
>
> Has anyone ever implemented DMQ replication of TOPOS data between kamailio servers?
>
> I'm trying to find the easiest (to maintain) way to implement this replication, possibly without using an external database.
>
> James
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From ovoshlook at gmail.com  Fri Dec  4 09:31:17 2020
From: ovoshlook at gmail.com (Yuriy Gorlichenko)
Date: Fri, 4 Dec 2020 09:31:17 +0100
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
Message-ID: <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>

Hello
2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
a=candidate:2274611867 1 tcp 1518283007
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active generation
0 network-id 2 network-cost 10
is a local candidate sent in the offer from the client
ICE=force just says rtpengine: "when you will resend this offer  to the
receiver, remove all candidates sent by sender and put yourself as the only
candidate"
But rtpengine still has to follow the ICE check for the received candidates
as in that case rtpengine is the receiver and it can't just not check local
candidates. That is why you facing this behaviour from the rtpengine, which
is totally correct.

In other terms
Sender -----------> rtpengine :    rtpengine must follow ice procedure and
check availability of these local candidates to establish connection
between Sender and rtpengine
rtpengine ---------> Receiver:      rtpengine pretends to be a Sender for
the ICE agent of the receiver. but in this term, RTPengine will be the only
candidate for this part of the call, so this part is establishing a
connection between rtpengine and Receiver

??, 3 ???. 2020 ?. ? 23:40, Richard Fuchs <rfuchs at sipwise.com>:

> On 03/12/2020 13.39, Andrew Chen wrote:
> > Hi all,
> >
> > I was wondering if someone can help me understand how the ICE
> > parameter works in the rtpengine module works.
> >
> > So basically our client does an ICE candidate lookup and grabs a list
> > of them and applies it to the INVITE that gets sent to the Kamailio.
> > The list looks like this:
> >
> > 2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]:
> > a=candidate:3373280875 1 udp 2122262783
> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0
> > network-id 2 network-cost 10
> > 2020-12-03T18:05:46.456057+00:00 ashmainkama51 kamailio[22147]:
> > a=candidate:3040609428 1 udp 2122197247
> > 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 59828 typ host generation 0
> > network-id 3 network-cost 10
> > 2020-12-03T18:05:46.456081+00:00 ashmainkama51 kamailio[22147]:
> > a=candidate:1681997092 1 udp 2122129151 192.168.1.66 59829 typ host
> > generation 0 network-id 1 network-cost 10
> > 2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
> > a=candidate:2274611867 1 tcp 1518283007
> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active
> > generation 0 network-id 2 network-cost 10
> > 2020-12-03T18:05:46.456131+00:00 ashmainkama51 kamailio[22147]:
> > a=candidate:4223662180 1 tcp 1518217471
> > 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 9 typ host tcptype active
> > generation 0 network-id 3 network-cost 10
> > 2020-12-03T18:05:46.456155+00:00 ashmainkama51 kamailio[22147]:
> > a=candidate:717406676 1 tcp 1518149375 192.168.1.66 9 typ host tcptype
> > active generation 0 network-id 1 network-cost 10
> > 2020-12-03T18:05:46.456180+00:00 ashmainkama51 kamailio[22147]:
> > a=candidate:2130547417 1 udp 8199935 206.81.191.27 61165 typ relay
> > raddr 85.247.0.121 rport 53091 generation 0 network-id 1 network-cost 10
> >
> >
> > In the rtpengine_offer, I have this:
> >
> > rtpengine_offer("ICE=force DTLS=passive replace-session-connection
> > replace-origin external internal");
> >
> > What i am trying to do is to tell the freeswitch endpoint to use
> > rtpengine as ICE candidate and I see in the SDP this is happening:
> >
> > a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
> > generation 0
> >
> > Btw..206.81.191.52 is a separate AWS instance running rtpengine binary.
> >
> > On the rtpengine_answer, I tell the remote client side the same
> > thing..use rtpengine as your ICE candidate:
> >
> > rtpengine_answer("ICE=force DTLS=passive replace-session-connection
> > replace-origin internal external");
> >
> > and this is snippet from 200 OK:
> >
> > a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
> > generation 0
> >
> > Question:
> >
> > Why does the rtpengine logs still show that it's trying to use
> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 as RTP candidate in this scenario?
> >
> > Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
> > [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
> >
> > I thought ICE=force will handle such adjustments so that all rtp is
> > handled by the rtpengine to our client and bypass the STUN server?
> >
> Isn't that what's happening? Rtpengine receives media from one peer and
> forwards it to one of the ICE candidates (presumably the primary one
> that was negotiated) of the other peer. Or am I misunderstanding what
> you posted?
>
> Cheers
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/f39cc6d8/attachment.htm>

From aatif.shaikh at ecosmob.com  Fri Dec  4 09:41:44 2020
From: aatif.shaikh at ecosmob.com (Aatif Shaikh)
Date: Fri, 4 Dec 2020 14:11:44 +0530
Subject: [SR-Users] presence not work proper with subs_db_mode = 2
Message-ID: <CAM12s76Hfr_2w8DgBJ=PVVyVyYjJXUOnnX_NQjw36jL1eQQx7w@mail.gmail.com>

Hello, all have a problem with Kamailio presence, I have configured my
kamailio.cfg to handle dialog presence and facing issue in case of
subs_db_mode = 2 in case of mode 2 facing the following presence issue.

   1. after hangup presence is still up
   2. sometimes stuck in a ringing state
   3. sometimes presence not came..etc

but in the case of subs_db_mode = 3 (DB ONLY) mode presence working fine
not facing any issue with this mode.

I noticed that sometimes Kamailio will throw the following message during
PUBLISH processing and it will not generate appropriate NOTIFY I also
verify inactive watcher subscription is there for that user and also a
proper entry in the dialog table.

MSG during PUBLISH processesing and it will not generate appropriate NOTIFY

Oct 30 07:42:10 NC-HOSTED-1 /usr/local/sbin/kamailio[2409]: DEBUG: presence
[notify.c:1444]: publ_notify(): Could not find subs_dialog

kamailio.cfg param

modparam("pua", "db_url", DBURL_KAMAILIO)
modparam("pua", "db_mode", 2)
modparam("pua", "update_period", 100)
modparam("pua", "dlginfo_increase_version", 1)
modparam("pua", "default_expires", 3600)
modparam("pua", "fetch_rows", 1000)
modparam("pua", "outbound_proxy", SERVER_IP)

modparam("dialog", "db_url", DBURL_KAMAILIO )
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_update_period", 260)
modparam("dialog", "db_fetch_rows", 500)

modparam("pua_dialoginfo", "include_callid", 1)
modparam("pua_dialoginfo", "send_publish_flag", 8)
modparam("pua_dialoginfo", "caller_confirmed", 0)
modparam("pua_dialoginfo", "include_tags", 1)
modparam("pua_dialoginfo", "use_pubruri_avps", 1)
modparam("pua_dialoginfo", "include_localremote", 1)
modparam("pua_dialoginfo", "override_lifetime", 300)
modparam("pua_dialoginfo", "pubruri_caller_avp", "$avp(s:puburis_caller)")
modparam("pua_dialoginfo", "pubruri_caller_dlg_var", "pubruri_caller")
modparam("pua_dialoginfo", "pubruri_callee_dlg_var", "pubruri_callee")
modparam("pua_dialoginfo", "pubruri_callee_avp", "$avp(s:puburis_callee)")

modparam("presence_dialoginfo", "force_single_dialog", 1)
modparam("presence", "db_table_lock_type", 0)
modparam("presence", "db_url", DBURL_KAMAILIO)
modparam("presence", "db_update_period", 5)
modparam("presence", "send_fast_notify", 1)
modparam("presence", "clean_period", 100)
modparam("presence", "subs_db_mode", 2)
//modparam("presence", "subs_db_mode", 3)
modparam("presence", "timeout_rm_subs", 1) //new/
//modparam("presence", "notifier_processes", 2) //new//
modparam("presence", "notifier_poll_rate", 20) //new//
modparam("presence", "waitn_time",1)
modparam("presence", "fetch_rows", 1000)
modparam("presence", "presentity_table", "presentity")
modparam("presence", "active_watchers_table", "active_watchers")
modparam("presence", "watchers_table", "watchers")
modparam("presence", "max_expires", 3600)

modparam("presence_xml", "db_url", DBURL_KAMAILIO)
modparam("presence_xml", "force_active", 1)

logic for presence

request_route {

    if(is_method("PUBLISH") || is_method("SUBSCRIBE")) {
            route(HANDLE_PRESENCE);
    }

}

route[HANDLE_PRESENCE] {

    if (! t_newtran())
    {
            sl_reply_error();
            exit;
    }

    if(is_method("PUBLISH"))
    {
           handle_publish();
           t_release();
    } else if( is_method("SUBSCRIBE")) {
           handle_subscribe();
       t_release();
    }
    exit;

}

route[RELAY] {

    if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
            $avp(t_ext) = $tU ;
            $avp(domain) = $fd ;
            $avp(et) = $_s(sip:$avp(t_ext)@$avp(domain)) ;
            $avp(s:puburis_callee) = $avp(et);
            setflag(8);
            dlg_manage();
    }

}
I already report this issue in Kamailio git
https://github.com/kamailio/kamailio/issues/2540


-- 
-- 

Regards,

*Aatif Shaikh *| Software Developer

+91 9033976268Hangout: aatif.shaikh at ecosmob.comSkype :
aatif.shaikh at ecosmob.com
*Ecosmob Technologies Pvt. Ltd. *
https://www.ecosmob.com
VoIP | Web | Mobile | IoT | Big Data
<https://twitter.com/ecosmob>  <https://www.facebook.com/Ecosmob>
<https://plus.google.com/+Ecosmob>
<https://www.linkedin.com/company/ecosmob>
<https://in.pinterest.com/ecosmob/>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
Ecosmob Technologies is not responsible for errors or omissions in this
message and denies any responsibility for any damage arising from the use
of e-mail. Any opinion and other statement contained in this message and
any attachment are solely those of the author and do not necessarily
represent those of the company.

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.


*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/a98d2fa9/attachment.htm>

From james at frideo.com  Fri Dec  4 13:37:07 2020
From: james at frideo.com (James Browne)
Date: Fri, 4 Dec 2020 12:37:07 +0000
Subject: [SR-Users] TOPOS replication with KDMQ
In-Reply-To: <1dd869b2-a3af-6917-e536-b05a06bf8aa0@gmail.com>
References: <CAEpCD+qrK7TgFKf2j-fZC8ryJtw=zZg+rC58WXJFoKcfmPVBUA@mail.gmail.com>
 <AM0PR05MB65956AAB3FA700EF487F5B3DC5F20@AM0PR05MB6595.eurprd05.prod.outlook.com>
 <1dd869b2-a3af-6917-e536-b05a06bf8aa0@gmail.com>
Message-ID: <CAEpCD+oz6uR94nZvY68AcwTtM82a78ARPXXO7eLrzeaW+_J48A@mail.gmail.com>

Thanks, Daniel
That explains it perfectly. I was thinking that this would be a huge
undertaking to implement it in DMQ, anyway, and now I know that this
would be the wrong way to approach it. As it happens, TOPOH (with no
storage needed) was unsuitable due to a UA requirement to avoid using
routesets.

Thanks, Henning
That makes sense, but that's probably beyond my skill level for now. I
was hoping to find out either that it's never been done or that
someone would just hand me the solution, so I'm satisfied with the
answers.

Thanks for the quick responses,
James

On Fri, 4 Dec 2020 at 07:57, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>
> Hello,
>
> topos was designed with a backend, being it db/sql-like using the db
> connectors (e.g., mysql, postgres, ...) or with topos_redis, tailored
> for it to use a redis (or variants) backend.
>
> From this perspective, there is nothing at this moment that dmq could
> replicate. It would require to make first an in-memory storage, then
> look at adding dmq layer.
>
> However, the idea of using from beginning a backend like redis, mysql,
> ... was to leverage the replication mechanism offered by the backend.
>
> Unlike topoh, note that persistence is needed for topos, otherwise
> traffic for active dialogs cannot be routed anymore.
>
> Cheers,
> Daniel
>
> On 03.12.20 20:59, Henning Westerholt wrote:
> > Hi James,
> >
> > I am not aware of a public DMQ extension or module for topos. You coult create an enhancement request for this on our tracker for this. If you want to start to work on this by yourself, sending an e-mail to sr-dev list would be also good to discuss the implementation approach.
> >
> > Cheers,
> >
> > Henning
> >
> > --
> > Henning Westerholt - https://skalatan.de/blog/
> > Kamailio services - https://gilawa.com
> >
> > -----Original Message-----
> > From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of James Browne
> > Sent: Thursday, December 3, 2020 3:07 PM
> > To: sr-users at lists.kamailio.org
> > Subject: [SR-Users] TOPOS replication with KDMQ
> >
> > Has anyone ever implemented DMQ replication of TOPOS data between kamailio servers?
> >
> > I'm trying to find the easiest (to maintain) way to implement this replication, possibly without using an external database.
> >
> > James
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


From g.wolzak at kazlow.nl  Fri Dec  4 13:48:59 2020
From: g.wolzak at kazlow.nl (Gertjan Wolzak)
Date: Fri, 4 Dec 2020 13:48:59 +0100
Subject: [SR-Users] Dialog profile not defined
Message-ID: <8573b9c1-c676-ab39-cf5f-e6f21cd32be2@kazlow.nl>

Hello Sergiu,

Thank you for the pointer, the line 1576 is:

    get_profile_size("callee", "$avp(custid)", "$avp(concurrent)");


That is where Kamailio refuses to start....

And as you mentioned my error in the IF statement after correction you 
pointed out, Kamailio still refuses on the fact that the profile 
<callee> was not defined...

Dec? 4 13:42:50 proxy01 /usr/local/sbin/kamailio[75008]: CRITICAL: 
dialog [dialog.c:391]: fixup_profile(): profile <callee> not defined
Dec? 4 13:42:50 proxy01 /usr/local/sbin/kamailio[75008]: ERROR: <core> 
[core/route.c:1166]: fix_actions(): fixing failed (code=-6) at 
cfg:/usr/local/etc/kamailio/kamailio.cfg:1576
Dec? 4 13:42:50 proxy01 systemd[1]: kamailio.service: Main process 
exited, code=exited, status=255/n/a
Dec? 4 13:42:50 proxy01 systemd[1]: kamailio.service: Failed with result 
'exit-code'.

Does anyone else maybe have an idea on where I go wrong?

Rgds,

Gertjan






From duarterocha91 at gmail.com  Fri Dec  4 14:21:50 2020
From: duarterocha91 at gmail.com (Duarte Rocha)
Date: Fri, 4 Dec 2020 13:21:50 +0000
Subject: [SR-Users] Fix Sdp Error
Message-ID: <CAAJJHZj9vyjMfPGPZ=2z9Z9f27nZkv3JM_YUWc3wU5=OhV5OXQ@mail.gmail.com>

Hello,

I noticed that when i do calls behind NAT i'm getting this error when i
call fix_nated_sdp() :

    "nathelper [nathelper.c:1659]: replace_sdp_ip(): can't extract 'a=rtcp'
IP from the SDP"

As far as i can see, all the ips on SDP are correctly replaced to a public
IP, so i don't understand the origin of this error.

This is the SDP received by Kamailio :

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 3421914885 1 IN IP4 192.168.24.89
    Session Name (s): SIPPER for PhonerLite
    Connection Information (c): IN IP4 192.168.24.89
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 5062 RTP/AVP 107 8 0 2 3
97 110 111 9 18 11 118 101
    Media Attribute (a): rtpmap:107 opus/48000/2
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): rtpmap:0 PCMU/8000
    Media Attribute (a): rtpmap:2 G726-32/8000
    Media Attribute (a): rtpmap:3 GSM/8000
    Media Attribute (a): rtpmap:97 iLBC/8000
    Media Attribute (a): rtpmap:110 speex/8000
    Media Attribute (a): rtpmap:111 speex/16000
    Media Attribute (a): rtpmap:9 G722/8000
    Media Attribute (a): rtpmap:18 G729/8000
    Media Attribute (a): fmtp:18 annexb=yes
    Media Attribute (a): rtpmap:11 L16/44100
    Media Attribute (a): rtpmap:118 L16/16000
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-16
    Media Attribute (a): ssrc:2716178988
    Media Attribute (a): sendrecv

And this is the SDP sent by Kamailio after NAT being treated :


    Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 3421914885 1 IN IP4 1.1.1.1 (Public IP)
    Session Name (s): SIPPER for PhonerLite
    Connection Information (c): IN IP4 1.1.1.1 (Public IP)
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 5062 RTP/AVP 107 8 0 2 3
97 110 111 9 18 11 118 101
    Media Attribute (a): rtpmap:107 opus/48000/2
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): rtpmap:0 PCMU/8000
    Media Attribute (a): rtpmap:2 G726-32/8000
    Media Attribute (a): rtpmap:3 GSM/8000
    Media Attribute (a): rtpmap:97 iLBC/8000
    Media Attribute (a): rtpmap:110 speex/8000
    Media Attribute (a): rtpmap:111 speex/16000
    Media Attribute (a): rtpmap:9 G722/8000
    Media Attribute (a): rtpmap:18 G729/8000
    Media Attribute (a): fmtp:18 annexb=yes
    Media Attribute (a): rtpmap:11 L16/44100
    Media Attribute (a): rtpmap:118 L16/16000
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-16
    Media Attribute (a): ssrc:2716178988
    Media Attribute (a): sendrecv
    Media Attribute (a): oldmediaip:192.168.24.89
    Media Attribute (a): oldmediaip:192.168.24.89


Is there something failing in the SDP fix?

Best Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/986de9f9/attachment.htm>

From achen at fuze.com  Fri Dec  4 15:11:02 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 09:11:02 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
Message-ID: <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>

So for Yuriy's comment:

I did issue ICE=force parameter but, as you can see my paste, it's still
sending RTP sequence packets to the ICE candidate, which is not what I want
to do.

Richard,

So our current setup is this:

SIP
client -> kamailio -> freeswitch
RTP
client -> freeswitch

What I want to accomplish is this:

SIP
client -> kamailio -> freeswitch
RTP (bypass ICE)
client -> rtpengine -> freeswitch



On Fri, Dec 4, 2020 at 3:34 AM Yuriy Gorlichenko <ovoshlook at gmail.com>
wrote:

> Hello
> 2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
> a=candidate:2274611867 1 tcp 1518283007
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active generation
> 0 network-id 2 network-cost 10
> is a local candidate sent in the offer from the client
> ICE=force just says rtpengine: "when you will resend this offer  to the
> receiver, remove all candidates sent by sender and put yourself as the only
> candidate"
> But rtpengine still has to follow the ICE check for the received
> candidates as in that case rtpengine is the receiver and it can't just not
> check local candidates. That is why you facing this behaviour from the
> rtpengine, which is totally correct.
>
> In other terms
> Sender -----------> rtpengine :    rtpengine must follow ice procedure and
> check availability of these local candidates to establish connection
> between Sender and rtpengine
> rtpengine ---------> Receiver:      rtpengine pretends to be a Sender for
> the ICE agent of the receiver. but in this term, RTPengine will be the only
> candidate for this part of the call, so this part is establishing a
> connection between rtpengine and Receiver
>
> ??, 3 ???. 2020 ?. ? 23:40, Richard Fuchs <rfuchs at sipwise.com>:
>
>> On 03/12/2020 13.39, Andrew Chen wrote:
>> > Hi all,
>> >
>> > I was wondering if someone can help me understand how the ICE
>> > parameter works in the rtpengine module works.
>> >
>> > So basically our client does an ICE candidate lookup and grabs a list
>> > of them and applies it to the INVITE that gets sent to the Kamailio.
>> > The list looks like this:
>> >
>> > 2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]:
>> > a=candidate:3373280875 1 udp 2122262783
>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0
>> > network-id 2 network-cost 10
>> > 2020-12-03T18:05:46.456057+00:00 ashmainkama51 kamailio[22147]:
>> > a=candidate:3040609428 1 udp 2122197247
>> > 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 59828 typ host generation 0
>> > network-id 3 network-cost 10
>> > 2020-12-03T18:05:46.456081+00:00 ashmainkama51 kamailio[22147]:
>> > a=candidate:1681997092 1 udp 2122129151 192.168.1.66 59829 typ host
>> > generation 0 network-id 1 network-cost 10
>> > 2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
>> > a=candidate:2274611867 1 tcp 1518283007
>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active
>> > generation 0 network-id 2 network-cost 10
>> > 2020-12-03T18:05:46.456131+00:00 ashmainkama51 kamailio[22147]:
>> > a=candidate:4223662180 1 tcp 1518217471
>> > 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 9 typ host tcptype active
>> > generation 0 network-id 3 network-cost 10
>> > 2020-12-03T18:05:46.456155+00:00 ashmainkama51 kamailio[22147]:
>> > a=candidate:717406676 1 tcp 1518149375 192.168.1.66 9 typ host tcptype
>> > active generation 0 network-id 1 network-cost 10
>> > 2020-12-03T18:05:46.456180+00:00 ashmainkama51 kamailio[22147]:
>> > a=candidate:2130547417 1 udp 8199935 206.81.191.27 61165 typ relay
>> > raddr 85.247.0.121 rport 53091 generation 0 network-id 1 network-cost 10
>> >
>> >
>> > In the rtpengine_offer, I have this:
>> >
>> > rtpengine_offer("ICE=force DTLS=passive replace-session-connection
>> > replace-origin external internal");
>> >
>> > What i am trying to do is to tell the freeswitch endpoint to use
>> > rtpengine as ICE candidate and I see in the SDP this is happening:
>> >
>> > a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
>> > generation 0
>> >
>> > Btw..206.81.191.52 is a separate AWS instance running rtpengine binary.
>> >
>> > On the rtpengine_answer, I tell the remote client side the same
>> > thing..use rtpengine as your ICE candidate:
>> >
>> > rtpengine_answer("ICE=force DTLS=passive replace-session-connection
>> > replace-origin internal external");
>> >
>> > and this is snippet from 200 OK:
>> >
>> > a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
>> > generation 0
>> >
>> > Question:
>> >
>> > Why does the rtpengine logs still show that it's trying to use
>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 as RTP candidate in this scenario?
>> >
>> > Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
>> > [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
>> >
>> > I thought ICE=force will handle such adjustments so that all rtp is
>> > handled by the rtpengine to our client and bypass the STUN server?
>> >
>> Isn't that what's happening? Rtpengine receives media from one peer and
>> forwards it to one of the ICE candidates (presumably the primary one
>> that was negotiated) of the other peer. Or am I misunderstanding what
>> you posted?
>>
>> Cheers
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/595e1f96/attachment.htm>

From achen at fuze.com  Fri Dec  4 15:14:32 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 09:14:32 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
Message-ID: <CAEytwJ22CBmG62RWkeB6QOJy-du19iDVCwvtPzCTwNYeC6XpkA@mail.gmail.com>

Actually Yuriy's..sorry...I see what you are saying.

So my question should be, this means I don't have a choice but to use the
ICE candidate between client and kamailio?

On Fri, Dec 4, 2020 at 9:11 AM Andrew Chen <achen at fuze.com> wrote:

> So for Yuriy's comment:
>
> I did issue ICE=force parameter but, as you can see my paste, it's still
> sending RTP sequence packets to the ICE candidate, which is not what I want
> to do.
>
> Richard,
>
> So our current setup is this:
>
> SIP
> client -> kamailio -> freeswitch
> RTP
> client -> freeswitch
>
> What I want to accomplish is this:
>
> SIP
> client -> kamailio -> freeswitch
> RTP (bypass ICE)
> client -> rtpengine -> freeswitch
>
>
>
> On Fri, Dec 4, 2020 at 3:34 AM Yuriy Gorlichenko <ovoshlook at gmail.com>
> wrote:
>
>> Hello
>> 2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
>> a=candidate:2274611867 1 tcp 1518283007
>> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active generation
>> 0 network-id 2 network-cost 10
>> is a local candidate sent in the offer from the client
>> ICE=force just says rtpengine: "when you will resend this offer  to the
>> receiver, remove all candidates sent by sender and put yourself as the only
>> candidate"
>> But rtpengine still has to follow the ICE check for the received
>> candidates as in that case rtpengine is the receiver and it can't just not
>> check local candidates. That is why you facing this behaviour from the
>> rtpengine, which is totally correct.
>>
>> In other terms
>> Sender -----------> rtpengine :    rtpengine must follow ice procedure
>> and check availability of these local candidates to establish connection
>> between Sender and rtpengine
>> rtpengine ---------> Receiver:      rtpengine pretends to be a Sender for
>> the ICE agent of the receiver. but in this term, RTPengine will be the only
>> candidate for this part of the call, so this part is establishing a
>> connection between rtpengine and Receiver
>>
>> ??, 3 ???. 2020 ?. ? 23:40, Richard Fuchs <rfuchs at sipwise.com>:
>>
>>> On 03/12/2020 13.39, Andrew Chen wrote:
>>> > Hi all,
>>> >
>>> > I was wondering if someone can help me understand how the ICE
>>> > parameter works in the rtpengine module works.
>>> >
>>> > So basically our client does an ICE candidate lookup and grabs a list
>>> > of them and applies it to the INVITE that gets sent to the Kamailio.
>>> > The list looks like this:
>>> >
>>> > 2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]:
>>> > a=candidate:3373280875 1 udp 2122262783
>>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0
>>> > network-id 2 network-cost 10
>>> > 2020-12-03T18:05:46.456057+00:00 ashmainkama51 kamailio[22147]:
>>> > a=candidate:3040609428 1 udp 2122197247
>>> > 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 59828 typ host generation 0
>>> > network-id 3 network-cost 10
>>> > 2020-12-03T18:05:46.456081+00:00 ashmainkama51 kamailio[22147]:
>>> > a=candidate:1681997092 1 udp 2122129151 192.168.1.66 59829 typ host
>>> > generation 0 network-id 1 network-cost 10
>>> > 2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
>>> > a=candidate:2274611867 1 tcp 1518283007
>>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active
>>> > generation 0 network-id 2 network-cost 10
>>> > 2020-12-03T18:05:46.456131+00:00 ashmainkama51 kamailio[22147]:
>>> > a=candidate:4223662180 1 tcp 1518217471
>>> > 2001:8a0:78fc:7000:d979:bf75:dbc0:69f 9 typ host tcptype active
>>> > generation 0 network-id 3 network-cost 10
>>> > 2020-12-03T18:05:46.456155+00:00 ashmainkama51 kamailio[22147]:
>>> > a=candidate:717406676 1 tcp 1518149375 192.168.1.66 9 typ host tcptype
>>> > active generation 0 network-id 1 network-cost 10
>>> > 2020-12-03T18:05:46.456180+00:00 ashmainkama51 kamailio[22147]:
>>> > a=candidate:2130547417 1 udp 8199935 206.81.191.27 61165 typ relay
>>> > raddr 85.247.0.121 rport 53091 generation 0 network-id 1 network-cost
>>> 10
>>> >
>>> >
>>> > In the rtpengine_offer, I have this:
>>> >
>>> > rtpengine_offer("ICE=force DTLS=passive replace-session-connection
>>> > replace-origin external internal");
>>> >
>>> > What i am trying to do is to tell the freeswitch endpoint to use
>>> > rtpengine as ICE candidate and I see in the SDP this is happening:
>>> >
>>> > a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
>>> > generation 0
>>> >
>>> > Btw..206.81.191.52 is a separate AWS instance running rtpengine binary.
>>> >
>>> > On the rtpengine_answer, I tell the remote client side the same
>>> > thing..use rtpengine as your ICE candidate:
>>> >
>>> > rtpengine_answer("ICE=force DTLS=passive replace-session-connection
>>> > replace-origin internal external");
>>> >
>>> > and this is snippet from 200 OK:
>>> >
>>> > a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
>>> > generation 0
>>> >
>>> > Question:
>>> >
>>> > Why does the rtpengine logs still show that it's trying to use
>>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 as RTP candidate in this
>>> scenario?
>>> >
>>> > Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
>>> > [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
>>> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
>>> >
>>> > I thought ICE=force will handle such adjustments so that all rtp is
>>> > handled by the rtpengine to our client and bypass the STUN server?
>>> >
>>> Isn't that what's happening? Rtpengine receives media from one peer and
>>> forwards it to one of the ICE candidates (presumably the primary one
>>> that was negotiated) of the other peer. Or am I misunderstanding what
>>> you posted?
>>>
>>> Cheers
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Andy Chen
> Sr. Telephony Lead Engineer
> 415 516 5535 (M)
> achen@ <achen at thinkingphones.com>fuze.com
>
>

-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/7f76453e/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 15:17:19 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 09:17:19 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
Message-ID: <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>

On 04/12/2020 09.11, Andrew Chen wrote:
> So for Yuriy's comment:
>
> I did issue ICE=force parameter but, as you can see my paste, it's 
> still sending RTP sequence packets to the ICE candidate, which is not 
> what I want to do.
>
> Richard,
>
> So our current setup is this:
>
> SIP
> client -> kamailio -> freeswitch
> RTP
> client -> freeswitch
>
> What I want to accomplish is this:
>
> SIP
> client -> kamailio -> freeswitch
> RTP (bypass ICE)
> client -> rtpengine -> freeswitch

I still don't understand. What does "bypass ICE" mean?

If you see rtpengine forwarding media packets as per the log you posted, 
what makes you think that media is not going through rtpengine?

Cheers



From achen at fuze.com  Fri Dec  4 15:24:49 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 09:24:49 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
Message-ID: <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>

Hey Richard,

So it is true rtpengine is handling rtp between kamailio and receiver
(freeswitch).  I'm trying to understand if there is a way to not
forward rtp to any of the ICE candidates in the original INVITE request
from the client side.  In other words, have the client rtp forward directly
to the rtpengine and not any of the STUN servers (or ICE candidates).  i
honestly thought putting ICE=force in the rtpengine_answer would help in
this case...but I don't see this part working.

On Fri, Dec 4, 2020 at 9:20 AM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 09.11, Andrew Chen wrote:
> > So for Yuriy's comment:
> >
> > I did issue ICE=force parameter but, as you can see my paste, it's
> > still sending RTP sequence packets to the ICE candidate, which is not
> > what I want to do.
> >
> > Richard,
> >
> > So our current setup is this:
> >
> > SIP
> > client -> kamailio -> freeswitch
> > RTP
> > client -> freeswitch
> >
> > What I want to accomplish is this:
> >
> > SIP
> > client -> kamailio -> freeswitch
> > RTP (bypass ICE)
> > client -> rtpengine -> freeswitch
>
> I still don't understand. What does "bypass ICE" mean?
>
> If you see rtpengine forwarding media packets as per the log you posted,
> what makes you think that media is not going through rtpengine?
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/a62b01b7/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 15:33:29 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 09:33:29 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
Message-ID: <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>

On 04/12/2020 09.24, Andrew Chen wrote:
> Hey Richard,
>
> So it is true rtpengine is handling rtp between kamailio and receiver 
> (freeswitch).? I'm trying to understand if there is a way to not 
> forward?rtp to any of the ICE candidates in the original INVITE 
> request from the client side.? In other words, have the client rtp 
> forward directly to the rtpengine and not any of the STUN servers (or 
> ICE candidates).? i honestly thought putting ICE=force in the 
> rtpengine_answer would help in this case...but I don't see this part 
> working.

But that is what's happening, isn't it? What other media would rtpengine 
be sending to the client if not the media received from the other 
client? So your A client is sending to rtpengine, and rtpengine is 
forwarding that to B, while your B client is also sending to rtpengine, 
which then forwards it to A. Where do you not see that working?

Cheers



From achen at fuze.com  Fri Dec  4 15:40:42 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 09:40:42 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
Message-ID: <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>

Hey Richard,

So that's what I thought too until I saw this in rtpengine logs for one of
my test calls:

Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
[ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)

unless I misunderstood what this line means.

On Fri, Dec 4, 2020 at 9:34 AM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 09.24, Andrew Chen wrote:
> > Hey Richard,
> >
> > So it is true rtpengine is handling rtp between kamailio and receiver
> > (freeswitch).  I'm trying to understand if there is a way to not
> > forward rtp to any of the ICE candidates in the original INVITE
> > request from the client side.  In other words, have the client rtp
> > forward directly to the rtpengine and not any of the STUN servers (or
> > ICE candidates).  i honestly thought putting ICE=force in the
> > rtpengine_answer would help in this case...but I don't see this part
> > working.
>
> But that is what's happening, isn't it? What other media would rtpengine
> be sending to the client if not the media received from the other
> client? So your A client is sending to rtpengine, and rtpengine is
> forwarding that to B, while your B client is also sending to rtpengine,
> which then forwards it to A. Where do you not see that working?
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/82d4f703/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 16:17:36 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 10:17:36 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
Message-ID: <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>

On 04/12/2020 09.40, Andrew Chen wrote:
> Hey Richard,
>
> So that's what I thought too until I saw this in rtpengine logs for 
> one of my test calls:
>
> Dec? 3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG: 
> [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint: 
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
>
> unless I misunderstood what this line means.

I think you did. It means rtpengine has received a media packet from one 
side and has forwarded it to the other side. Of course it's one of the 
ICE candidates from the SDP because that's where the peer said it wants 
to receive the media from rtpengine.

Cheers



From pojogas at gmail.com  Fri Dec  4 16:35:25 2020
From: pojogas at gmail.com (Sergiu Pojoga)
Date: Fri, 4 Dec 2020 10:35:25 -0500
Subject: [SR-Users] Dialog profile not defined
In-Reply-To: <8573b9c1-c676-ab39-cf5f-e6f21cd32be2@kazlow.nl>
References: <8573b9c1-c676-ab39-cf5f-e6f21cd32be2@kazlow.nl>
Message-ID: <CAJZsGCmoCd3K7+ARjHw3jKcTZmBBqWX4XA2gs9ZivutPdT0ifg@mail.gmail.com>

Hmmm... if dialog params are wrapped in a ifdef condition, then do you have
something like #!define WITH_DIALOG at the top?

Otherwise the rest looks ok to me judging by the snippet that was provided.

On Fri, Dec 4, 2020 at 7:49 AM Gertjan Wolzak <g.wolzak at kazlow.nl> wrote:

> Hello Sergiu,
>
> Thank you for the pointer, the line 1576 is:
>
>     get_profile_size("callee", "$avp(custid)", "$avp(concurrent)");
>
>
> That is where Kamailio refuses to start....
>
> And as you mentioned my error in the IF statement after correction you
> pointed out, Kamailio still refuses on the fact that the profile
> <callee> was not defined...
>
> Dec  4 13:42:50 proxy01 /usr/local/sbin/kamailio[75008]: CRITICAL:
> dialog [dialog.c:391]: fixup_profile(): profile <callee> not defined
> Dec  4 13:42:50 proxy01 /usr/local/sbin/kamailio[75008]: ERROR: <core>
> [core/route.c:1166]: fix_actions(): fixing failed (code=-6) at
> cfg:/usr/local/etc/kamailio/kamailio.cfg:1576
> Dec  4 13:42:50 proxy01 systemd[1]: kamailio.service: Main process
> exited, code=exited, status=255/n/a
> Dec  4 13:42:50 proxy01 systemd[1]: kamailio.service: Failed with result
> 'exit-code'.
>
> Does anyone else maybe have an idea on where I go wrong?
>
> Rgds,
>
> Gertjan
>
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/05df13f6/attachment.htm>

From achen at fuze.com  Fri Dec  4 16:39:49 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 10:39:49 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
Message-ID: <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>

So my next question would be:

My 200 OK back to the client should have rtpengine as the only ICE
candidate.  Shouldn't it use that one instead?

On Fri, Dec 4, 2020 at 10:18 AM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 09.40, Andrew Chen wrote:
> > Hey Richard,
> >
> > So that's what I thought too until I saw this in rtpengine logs for
> > one of my test calls:
> >
> > Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
> > [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
> >
> > unless I misunderstood what this line means.
>
> I think you did. It means rtpengine has received a media packet from one
> side and has forwarded it to the other side. Of course it's one of the
> ICE candidates from the SDP because that's where the peer said it wants
> to receive the media from rtpengine.
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/0e75de13/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 17:24:06 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 11:24:06 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
Message-ID: <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>

On 04/12/2020 10.39, Andrew Chen wrote:
> So my next question would be:
>
> My 200 OK back to the client should have rtpengine as the only ICE 
> candidate.? Shouldn't it use that one instead?

Yes it should. And it probably does.

Cheers



From achen at fuze.com  Fri Dec  4 17:31:11 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 11:31:11 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
Message-ID: <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>

If that's the case then I don't know why this line doesn't show the ipv6
address of the client:

Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
[ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)

On Fri, Dec 4, 2020 at 11:25 AM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 10.39, Andrew Chen wrote:
> > So my next question would be:
> >
> > My 200 OK back to the client should have rtpengine as the only ICE
> > candidate.  Shouldn't it use that one instead?
>
> Yes it should. And it probably does.
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/7a52168b/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 17:37:14 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 11:37:14 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
Message-ID: <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>

On 04/12/2020 11.31, Andrew Chen wrote:
> If that's the case then I don't know why this line doesn't show the 
> ipv6 address of the client:
>
> Dec? 3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG: 
> [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint: 
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)

It doesn't?

2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:3373280875 1 udp 2122262783 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0 
network-id 2 network-cost 10

What is this then?

Cheers



From achen at fuze.com  Fri Dec  4 17:39:00 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 11:39:00 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
Message-ID: <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>

oh...that's the IPv6 address of the STUN server, not the ipv6 of the
rtpengine instance.

On Fri, Dec 4, 2020 at 11:38 AM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 11.31, Andrew Chen wrote:
> > If that's the case then I don't know why this line doesn't show the
> > ipv6 address of the client:
> >
> > Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
> > [ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
> > 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
>
> It doesn't?
>
> 2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]:
> a=candidate:3373280875 1 udp 2122262783
> 2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0
> network-id 2 network-cost 10
>
> What is this then?
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/d49a0395/attachment.htm>

From agiftel at gmail.com  Fri Dec  4 17:30:32 2020
From: agiftel at gmail.com (Agiftel)
Date: Fri, 4 Dec 2020 09:30:32 -0700 (MST)
Subject: [SR-Users] REFER from MS teams to Kamailio.
In-Reply-To: <CADihe3KhREAMv7pGZNYgrQaPXjUKG=ziB-S7+NU73oESFPkkGA@mail.gmail.com>
References: <CADihe3LVyw_zo28zrPSorvAyKJzD1V5ZO6B5vRJ9KTf+50GVqw@mail.gmail.com>
 <CAJZsGCkZwnvYArORxH+5FwFrDqA2qAR=A_4-uL20OawSr=jkhQ@mail.gmail.com>
 <CADihe3Lv7jz4TV258b+sxZvkRTtLvtY+=VjeZBSiKRd9O092-g@mail.gmail.com>
 <CAFGRPVrhQBDGDO_OTWxxHePkhK+BBMfO9PkZSkUDeUjNmdE2fw@mail.gmail.com>
 <CADihe3LKbWM1xz-9es8MZB6SQMTTpFfCeHrf=rS=DGFp3qLzvw@mail.gmail.com>
 <CAJZsGC=q6aDL0MbgxthJY8Bztkm_Qer+rRmeCW0MoMYpquAkNg@mail.gmail.com>
 <CADihe3JooRj+XYL7iJ0v5fH0oyz1u8OUhEHzGm1BSGWnZjC0eA@mail.gmail.com>
 <CAJZsGC=XOnk4YJhE_a67XQt_c__i8Ow9V5zUDv7p+1N-G-FTFA@mail.gmail.com>
 <CADihe3KhREAMv7pGZNYgrQaPXjUKG=ziB-S7+NU73oESFPkkGA@mail.gmail.com>
Message-ID: <1607099432839-0.post@n5.nabble.com>

Hi Yuriy,
regarding REFER, MS does not follow RFC at all!!!! I can tell you for sure.
In REFER-TO it pretend to have Request-URI IP address. So is not telling you
to who "REFER TO" but it telling you that it want to handle itself. Very
strange interpretation of RFS ;-)

Anyway, can you share your working code?
Thanks



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From rfuchs at sipwise.com  Fri Dec  4 17:48:54 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 11:48:54 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
Message-ID: <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>

On 04/12/2020 11.39, Andrew Chen wrote:
> oh...that's the IPv6 address of the STUN server, not the ipv6 of the 
> rtpengine instance.

Ok. From rtpengine's point of view, this is one of the client's IP 
addresses. The ICE candidate in the SDP is the client telling rtpengine: 
This is one of my own addresses (`typ host`) and I can receive media 
here. It is also listed (by the client who has sent the SDP) as the 
highest priority candidate, and this is why it's (presumably) negotiated 
as the candidate to use. This is why rtpengine is sending media there.

Cheers



From achen at fuze.com  Fri Dec  4 19:10:13 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 13:10:13 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
 <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
Message-ID: <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>

So from a SIP point of view, the 200 OK should of sent the final
negotiation of SDP once the client ACK's it right?

On Fri, Dec 4, 2020 at 11:49 AM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 11.39, Andrew Chen wrote:
> > oh...that's the IPv6 address of the STUN server, not the ipv6 of the
> > rtpengine instance.
>
> Ok. From rtpengine's point of view, this is one of the client's IP
> addresses. The ICE candidate in the SDP is the client telling rtpengine:
> This is one of my own addresses (`typ host`) and I can receive media
> here. It is also listed (by the client who has sent the SDP) as the
> highest priority candidate, and this is why it's (presumably) negotiated
> as the candidate to use. This is why rtpengine is sending media there.
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/2e193937/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 19:29:14 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 13:29:14 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
 <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
 <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>
Message-ID: <8dba05d3-ca82-43e6-bff0-4c8342b37db0@sipwise.com>

On 04/12/2020 13.10, Andrew Chen wrote:
> So from a SIP point of view, the 200 OK should of sent the final 
> negotiation of SDP once the client ACK's it right?

The requirement to send an updated offer once ICE has completed with the 
final negotiated candidates existed in the original ICE RFC, but I 
believe it has been removed in the newer ICE RFC (I'm not 100% sure 
about that though). For rtpengine that requirement certainly doesn't 
exist and it's happy to negotiate and conclude ICE without a final 
updated offer. Also rtpengine itself cannot trigger such an updated 
offer since it's not directly in the SIP path, so that would have to be 
left up to the clients. So in short, a single offer/answer exchange is 
enough to get ICE started and it can complete negotiation out of band 
without further signalling.

Cheers



From achen at fuze.com  Fri Dec  4 19:36:00 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 13:36:00 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <8dba05d3-ca82-43e6-bff0-4c8342b37db0@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <76490444-89b6-30d5-5fb0-30f1d46ae342@sipwise.com>
 <CABSP_VeNmXbNp-btnArKgNwXGBkLj8x8GUDzbqcz0g_1hhrPwA@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
 <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
 <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>
 <8dba05d3-ca82-43e6-bff0-4c8342b37db0@sipwise.com>
Message-ID: <CAEytwJ02TUs+6pThvHHiTcEBvMewsz3yJ4oUqOMXrre3utrPLw@mail.gmail.com>

Hmm..that's interesting.  You would guess that the rtpengine binary process
shouldn't start connecting ICE candidates once the SIP part is fully
negotiated, which should trigger the rtpengine module on the Kamailio to
tell rtpengine binary.."ok..you can start associating now..."

On Fri, Dec 4, 2020 at 1:30 PM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 13.10, Andrew Chen wrote:
> > So from a SIP point of view, the 200 OK should of sent the final
> > negotiation of SDP once the client ACK's it right?
>
> The requirement to send an updated offer once ICE has completed with the
> final negotiated candidates existed in the original ICE RFC, but I
> believe it has been removed in the newer ICE RFC (I'm not 100% sure
> about that though). For rtpengine that requirement certainly doesn't
> exist and it's happy to negotiate and conclude ICE without a final
> updated offer. Also rtpengine itself cannot trigger such an updated
> offer since it's not directly in the SIP path, so that would have to be
> left up to the clients. So in short, a single offer/answer exchange is
> enough to get ICE started and it can complete negotiation out of band
> without further signalling.
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/8501ab86/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 19:46:56 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 13:46:56 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ02TUs+6pThvHHiTcEBvMewsz3yJ4oUqOMXrre3utrPLw@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
 <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
 <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>
 <8dba05d3-ca82-43e6-bff0-4c8342b37db0@sipwise.com>
 <CAEytwJ02TUs+6pThvHHiTcEBvMewsz3yJ4oUqOMXrre3utrPLw@mail.gmail.com>
Message-ID: <55e0cdc8-fdc2-fa87-0366-c841495ee8f1@sipwise.com>

On 04/12/2020 13.36, Andrew Chen wrote:
> Hmm..that's interesting.? You would guess that the rtpengine binary 
> process shouldn't start connecting ICE candidates once the SIP part is 
> fully negotiated, which should trigger the rtpengine module on the 
> Kamailio to tell rtpengine binary.."ok..you can start associating now..."

Not really. Why would you think that? ICE and SIP are really largely 
unrelated, and ICE processing starts as soon as possible so that media 
can flow as soon as possible. Any delay in ICE processing leads to 
delays in establishing the call or the media flows. (Trickle ICE exists 
partly for that reason.) In particular early media would break if ICE 
had to wait for SIP to finish.

Cheers



From achen at fuze.com  Fri Dec  4 20:04:43 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 14:04:43 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <55e0cdc8-fdc2-fa87-0366-c841495ee8f1@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <CAEytwJ1z4eUOdwwp10gP4Y-w9tWpgUzEJWPY0T87ZhRmMNp66w@mail.gmail.com>
 <779e42d0-9149-42a1-c6b4-134979dea88d@sipwise.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
 <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
 <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>
 <8dba05d3-ca82-43e6-bff0-4c8342b37db0@sipwise.com>
 <CAEytwJ02TUs+6pThvHHiTcEBvMewsz3yJ4oUqOMXrre3utrPLw@mail.gmail.com>
 <55e0cdc8-fdc2-fa87-0366-c841495ee8f1@sipwise.com>
Message-ID: <CAEytwJ30ecTi=hktDvQQKhrBrP3Uq_g5pVEoowuixWhc4fL12Q@mail.gmail.com>

Sure...I understand ICE has its own setup workflow than SIP but it's also
important that rtpengine uses the rtp path that's negotiated in the SIP or
else it can cause confusion (to those who don't understand ICE very well
like me).

On Fri, Dec 4, 2020 at 1:47 PM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 13.36, Andrew Chen wrote:
> > Hmm..that's interesting.  You would guess that the rtpengine binary
> > process shouldn't start connecting ICE candidates once the SIP part is
> > fully negotiated, which should trigger the rtpengine module on the
> > Kamailio to tell rtpengine binary.."ok..you can start associating now..."
>
> Not really. Why would you think that? ICE and SIP are really largely
> unrelated, and ICE processing starts as soon as possible so that media
> can flow as soon as possible. Any delay in ICE processing leads to
> delays in establishing the call or the media flows. (Trickle ICE exists
> partly for that reason.) In particular early media would break if ICE
> had to wait for SIP to finish.
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/73cf19f8/attachment.htm>

From rfuchs at sipwise.com  Fri Dec  4 20:17:16 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Fri, 4 Dec 2020 14:17:16 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <CAEytwJ30ecTi=hktDvQQKhrBrP3Uq_g5pVEoowuixWhc4fL12Q@mail.gmail.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
 <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
 <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>
 <8dba05d3-ca82-43e6-bff0-4c8342b37db0@sipwise.com>
 <CAEytwJ02TUs+6pThvHHiTcEBvMewsz3yJ4oUqOMXrre3utrPLw@mail.gmail.com>
 <55e0cdc8-fdc2-fa87-0366-c841495ee8f1@sipwise.com>
 <CAEytwJ30ecTi=hktDvQQKhrBrP3Uq_g5pVEoowuixWhc4fL12Q@mail.gmail.com>
Message-ID: <947e6027-7db4-cac4-177c-ca1435a9d769@sipwise.com>

On 04/12/2020 14.04, Andrew Chen wrote:
> Sure...I understand ICE has its own setup workflow than SIP but it's 
> also important that rtpengine uses the rtp path that's negotiated in 
> the SIP or else it can cause confusion (to those who don't understand 
> ICE very well like me).

There is no RTP path negotiated through SIP. There is only a number of 
possible paths, which are compiled from the list of candidates that each 
side advertises. ICE then checks which paths work, and then finally 
chooses the one with the highest priority.

The only way to have a single media path that is negotiated through SIP 
is if you don't use ICE.

Cheers




From achen at fuze.com  Fri Dec  4 20:24:04 2020
From: achen at fuze.com (Andrew Chen)
Date: Fri, 4 Dec 2020 14:24:04 -0500
Subject: [SR-Users] question regarding rtpengine and ICE candidate
 selection
In-Reply-To: <947e6027-7db4-cac4-177c-ca1435a9d769@sipwise.com>
References: <CAEytwJ1H2v_mh8TpfuRu-RPQZozf8Q_posrXc92X8VS5HOqt4Q@mail.gmail.com>
 <CAEytwJ0Ji885v+gi1Cw7-=NGtq9h3pYcMCGSdzn3BNXc6zVgyQ@mail.gmail.com>
 <fd6eb20b-af37-5d02-b6da-bf20aa057f3d@sipwise.com>
 <CAEytwJ338Sm1jbVPUNUMCX9CTvf2TKsEpTmDpp-tAHAMHr5nQw@mail.gmail.com>
 <945ba353-f80c-fd57-a419-38098ae42eb8@sipwise.com>
 <CAEytwJ0dipJuhZeb5Mf0h7qqdR8TFjw_rGiBN+ha=S1QiJpbGg@mail.gmail.com>
 <74966b24-22bf-5722-a60a-4a33e14bebb4@sipwise.com>
 <CAEytwJ0vHD1LvxNVSpytJ4p4byZHQz-fNKtUiyWGGHosznVh-A@mail.gmail.com>
 <a9c08ae4-2cf3-ba44-b3a9-911361391f17@sipwise.com>
 <CAEytwJ3KixUfXGts7dDCM_8N2jCj3DMoELasp4KW+yQ2RHNLFw@mail.gmail.com>
 <0de451bb-fede-35b5-921a-9ca796224332@sipwise.com>
 <CAEytwJ3Rd6KGmHZdwDes8QDX6U_Osx+jsSsdyf47V8tUCNGsNw@mail.gmail.com>
 <8dba05d3-ca82-43e6-bff0-4c8342b37db0@sipwise.com>
 <CAEytwJ02TUs+6pThvHHiTcEBvMewsz3yJ4oUqOMXrre3utrPLw@mail.gmail.com>
 <55e0cdc8-fdc2-fa87-0366-c841495ee8f1@sipwise.com>
 <CAEytwJ30ecTi=hktDvQQKhrBrP3Uq_g5pVEoowuixWhc4fL12Q@mail.gmail.com>
 <947e6027-7db4-cac4-177c-ca1435a9d769@sipwise.com>
Message-ID: <CAEytwJ14MaE56ep0EB-6zwzhcQCs2khcrgXHM-BhXt7Gfz3NNA@mail.gmail.com>

Ok..that's interesting to know.  Thanks for your input Richard.  This helps
a lot.

On Fri, Dec 4, 2020 at 2:18 PM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 04/12/2020 14.04, Andrew Chen wrote:
> > Sure...I understand ICE has its own setup workflow than SIP but it's
> > also important that rtpengine uses the rtp path that's negotiated in
> > the SIP or else it can cause confusion (to those who don't understand
> > ICE very well like me).
>
> There is no RTP path negotiated through SIP. There is only a number of
> possible paths, which are compiled from the list of candidates that each
> side advertises. ICE then checks which paths work, and then finally
> chooses the one with the highest priority.
>
> The only way to have a single media path that is negotiated through SIP
> is if you don't use ICE.
>
> Cheers
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at thinkingphones.com>fuze.com

-- 
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/1d9f7e08/attachment.htm>

From gertjan.wolzak at upcmail.nl  Sat Dec  5 09:50:29 2020
From: gertjan.wolzak at upcmail.nl (Gertjan Wolzak)
Date: Sat, 5 Dec 2020 09:50:29 +0100
Subject: [SR-Users] Dialog profile not defined
Message-ID: <e25acbab-2b9f-b9f4-9fa1-519d192fad0e@upcmail.nl>

Thanks again Sergiu,

/Hmmm... if dialog params are wrapped in a ifdef condition, then do you 
have something like #!define WITH_DIALOG at the top?/

But the #!define WITH_DIALOG is to choose between loading module 
parameters or not loading module parameters...

When you do not add #!ifdef WITH_XXX before the parameters and #!endif 
after, then those parameters will be loaded when starting Kamailio.

So, I still have the issue that the profile is not being loaded.

I have tried renaming the profiles, in the route and the parameters, but 
that does not make a difference..


# ---- Dialog params -------------
modparam("dialog", "default_timeout", 7200)
modparam("dialog", "db_mode", 0)
modparam("dialog", "dlg_flag", DLG_FLAG)
modparam("dialog", "hash_size", 4096)
#modparam("dialog", "detect_spirals", 1)
modparam("dialog", "profiles_with_value", "inbound ; outbound")

route[CONCURRENT_IN]
{
 ??????? #Add call to customer profile
 ??????? #Check if customer has not reached inbound call limit

 ??????? #Get max concurrent calls
 ??????? sql_query("cc", "select max_calls_in from calllimit where 
cust_id='$avp(custid)'", "ra");
 ??????? $avp(maxcalls)=$dbr(ra=>[0,0]);
 ??????? sql_result_free("ra");
 ??????? $avp(concurrent) = 0;
 ??????? get_profile_size("inbound", "$avp(custid)", "$avp(concurrent)");
 ??????? if( $avp(concurrent) >= $var(max) )
 ??????? {
 ??????????????? xlog("L_INFO"," Call limit reached for customer 
$avp(custid)\r\n ");
 ??????????????? sl_send_reply("503", "No Lines Available");
 ??????????????? exit;
 ??????? }
 ??? set_dlg_profile("inbound", "$avp(custid)");

 ??????? return;
}

But this still results in:


Dec? 5 09:34:33 proxy01 /usr/local/sbin/kamailio[75755]: CRITICAL: 
dialog [dialog.c:391]: fixup_profile(): profile <inbound> not defined
Dec? 5 09:34:33 proxy01 /usr/local/sbin/kamailio[75755]: ERROR: <core> 
[core/route.c:1166]: fix_actions(): fixing failed (code=-6) at 
cfg:/usr/local/etc/kamailio/kamailio.cfg:1578


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201205/69ccd123/attachment.htm>

From joel at textplus.com  Sat Dec  5 18:54:04 2020
From: joel at textplus.com (Joel Serrano)
Date: Sat, 5 Dec 2020 09:54:04 -0800
Subject: [SR-Users] Dialog profile not defined
In-Reply-To: <e25acbab-2b9f-b9f4-9fa1-519d192fad0e@upcmail.nl>
References: <e25acbab-2b9f-b9f4-9fa1-519d192fad0e@upcmail.nl>
Message-ID: <CAMtXxQmN6sgwvjAHq27eJj-AF2QVccc_TU6gfxyZZVc4dmjb7w@mail.gmail.com>

Maybe it?s a copy paste error...

Try removing the spaces in the modparam ?profiles_with_value? setting



On Sat, Dec 5, 2020 at 00:51 Gertjan Wolzak <gertjan.wolzak at upcmail.nl>
wrote:

> Thanks again Sergiu,
>
> *Hmmm... if dialog params are wrapped in a ifdef condition, then do you have
> something like #!define WITH_DIALOG at the top?*
>
>
> But the #!define WITH_DIALOG is to choose between loading module
> parameters or not loading module parameters...
>
> When you do not add #!ifdef WITH_XXX before the parameters and #!endif
> after, then those parameters will be loaded when starting Kamailio.
>
> So, I still have the issue that the profile is not being loaded.
>
> I have tried renaming the profiles, in the route and the parameters, but
> that does not make a difference..
>
>
> # ---- Dialog params -------------
> modparam("dialog", "default_timeout", 7200)
> modparam("dialog", "db_mode", 0)
> modparam("dialog", "dlg_flag", DLG_FLAG)
> modparam("dialog", "hash_size", 4096)
> #modparam("dialog", "detect_spirals", 1)
> modparam("dialog", "profiles_with_value", "inbound ; outbound")
>
> route[CONCURRENT_IN]
> {
>         #Add call to customer profile
>         #Check if customer has not reached inbound call limit
>
>         #Get max concurrent calls
>         sql_query("cc", "select max_calls_in from calllimit where
> cust_id='$avp(custid)'", "ra");
>         $avp(maxcalls)=$dbr(ra=>[0,0]);
>         sql_result_free("ra");
>         $avp(concurrent) = 0;
>         get_profile_size("inbound", "$avp(custid)", "$avp(concurrent)");
>         if( $avp(concurrent) >= $var(max) )
>         {
>                 xlog("L_INFO"," Call limit reached for customer
> $avp(custid)\r\n ");
>                 sl_send_reply("503", "No Lines Available");
>                 exit;
>         }
>     set_dlg_profile("inbound", "$avp(custid)");
>
>         return;
> }
>
> But this still results in:
>
>
> Dec  5 09:34:33 proxy01 /usr/local/sbin/kamailio[75755]: CRITICAL: dialog
> [dialog.c:391]: fixup_profile(): profile <inbound> not defined
> Dec  5 09:34:33 proxy01 /usr/local/sbin/kamailio[75755]: ERROR: <core>
> [core/route.c:1166]: fix_actions(): fixing failed (code=-6) at
> cfg:/usr/local/etc/kamailio/kamailio.cfg:1578
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201205/aa4ba6f9/attachment.htm>

From g.wolzak at kazlow.nl  Sun Dec  6 15:23:26 2020
From: g.wolzak at kazlow.nl (Gertjan Wolzak)
Date: Sun, 6 Dec 2020 15:23:26 +0100
Subject: [SR-Users] Dialog profile not defined
Message-ID: <20cd0b36-c1ef-9f4a-0459-c9932f8e9841@kazlow.nl>

Thank you Joel for the tip.

But that is also not it.....

I tried of course, but when you look at the Dialog module documentation 
is says:

modparam("dialog", "profiles_with_value", "caller ; my_profile")

So there are spaces in the modparam config for the dialog profiles.

Its just so strange that when starting Kamailio I get the error that the 
Profile outbound is not configured, while it is...

Log line:

Dec? 6 15:04:04 proxy01 /usr/local/sbin/kamailio[76664]: CRITICAL: 
dialog [dialog.c:391]: fixup_profile(): profile <inbound> not defined

kamailo.cfg

# ---- Dialog params -------------
modparam("dialog", "default_timeout", 7200)
modparam("dialog", "db_mode", 0)
modparam("dialog", "dlg_flag", DLG_FLAG)
modparam("dialog", "hash_size", 4096)
#modparam("dialog", "detect_spirals", 1)
modparam("dialog", "profiles_with_value", "inbound")

Im starting to think that I am missing some configuration in the 
kamailio.cfg file...

Rgds,

Gertjan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201206/32cd1664/attachment.htm>

From hamid2kviii at hotmail.com  Sun Dec  6 20:13:48 2020
From: hamid2kviii at hotmail.com (Hamid Hashmi)
Date: Sun, 6 Dec 2020 19:13:48 +0000
Subject: [SR-Users] kamailio-5.2.0 Crash - udp_send failed
In-Reply-To: <AM0PR05MB659564ECE4CC900C49BB7B26C5370@AM0PR05MB6595.eurprd05.prod.outlook.com>
References: <PU1PR03MB2908EE0F77AD2172A76CB369E0360@PU1PR03MB2908.apcprd03.prod.outlook.com>,
 <AM0PR05MB659564ECE4CC900C49BB7B26C5370@AM0PR05MB6595.eurprd05.prod.outlook.com>
Message-ID: <PU1PR03MB2908CED08A344DAA6099A583E0CF0@PU1PR03MB2908.apcprd03.prod.outlook.com>

Hello

I have updated Kamailio from 5.2.0 to 5.4.2 but the service is still crashing with sig 11 and sig 6. Please find the attached 'bt full' traces.

Sig 11:

Core was generated by `/usr/local/sbin/kamailio -f /usr/local/etc/kamailio_pcscf/kamailio.cfg -P /var/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000006a16fc in timer_list_expire (t=1339518316, h=0x7facee484fd0, slow_l=0x7facee488208, slow_mark=7936) at core/timer.c:846
846                     _timer_rm_list(tl); /* detach */
(gdb) bt
#0  0x00000000006a16fc in timer_list_expire (t=1339518316, h=0x7facee484fd0, slow_l=0x7facee488208, slow_mark=7936) at core/timer.c:846
#1  0x00000000006a1c19 in timer_handler () at core/timer.c:922
#2  0x00000000006a20ba in timer_main () at core/timer.c:961
#3  0x000000000042ac0a in main_loop () at main.c:1753
#4  0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at main.c:2856

Sig 6:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/sbin/kamailio -f /usr/local/etc/kamailio_pcscf/kamailio.cfg -P /var/'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fad95f56c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007fad95f56c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fad95f5a028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x000000000041e39d in sig_alarm_abort (signo=14) at main.c:687
#3  <signal handler called>
#4  0x00007fad960183c7 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007fad6f5c024b in futex_get (lock=0x7facee70baa0) at ../../core/mem/../futexlock.h:121
#6  0x00007fad6f5c2167 in get_peer_by_fqdn (fqdn=0x7faceeb377b0) at peermanager.c:240
#7  0x00007fad6f5e6c31 in get_first_connected_route (cdp_session=0x7faceeb37768, r=0x7facee70a220, app_id=16777236, vendor_id=10415) at routing.c:110
#8  0x00007fad6f5ea8b2 in get_routing_peer (cdp_session=0x7faceeb37768, m=0x7facef617fb0) at routing.c:272
#9  0x00007fad6f5ac72d in AAASendMessage (message=0x7facef617fb0, callback_f=0x0, callback_param=0x0) at diameter_comm.c:137
#10 0x00007fad6ef05dbb in rx_send_str (rx_session_id=0x7facf0849d50) at rx_str.c:157
#11 0x00007fad6eeb25c4 in callback_dialog (dlg=0x7facf0036d70, type=8192, params=0x7fad72b2a1c0 <params>) at ims_qos_mod.c:453
#12 0x00007fad728973af in run_dlg_callbacks (type=8192, dlg=0x7facf0036d70, req=0x0, rpl=0x0, dir=0, dlg_data=0x0) at dlg_cb.c:274
#13 0x00007fad728d5315 in destroy_dlg (dlg=0x7facf0036d70) at dlg_hash.c:219
#14 0x00007fad728d5b1b in destroy_dlg_table () at dlg_hash.c:291
#15 0x00007fad7290b71e in mod_destroy () at ims_dialog.c:627
#16 0x0000000000616ae1 in destroy_modules () at core/sr_module.c:746
#17 0x000000000041ce17 in cleanup (show_status=1) at main.c:563
#18 0x000000000041e6ef in shutdown_children (sig=15, show_status=1) at main.c:706
#19 0x0000000000421755 in handle_sigs () at main.c:806
#20 0x000000000042bc85 in main_loop () at main.c:1817
#21 0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at main.c:2856

PS: I am using ubuntu 14.04.


Regards

Hamid R. Hashmi

________________________________
From: Henning Westerholt <hw at skalatan.de>
Sent: Saturday, September 26, 2020 12:04 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Cc: Hamid Hashmi <hamid2kviii at hotmail.com>
Subject: Re: kamailio-5.2.0 Crash - udp_send failed

Hello,

you are using a old and non released dev version of kamailio. These are meant only for development purposes.

Please update to a proper version (like the latest one based on 5.3 or 5.4 branch.

Then try to reproduce the bug again and report on the list or by creating an issue.

Cheers,

Henning


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

________________________________
From: sr-users <sr-users-bounces at lists.kamailio.org> on behalf of Hamid Hashmi <hamid2kviii at hotmail.com>
Sent: Friday, September 25, 2020 9:28:07 PM
To: sr-users at lists.kamailio.org <sr-users at lists.kamailio.org>
Subject: [SR-Users] kamailio-5.2.0 Crash - udp_send failed

I am using "kamailio 5.2.0-dev6 (x86_64/linux) 48ed62-dirty" what could be the reason of the crash

its usually crash with the following logs


Sep 25 16:58:41 pcscf [Proxy-CSCF][20771]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36eee8c560,418,0,10.100.227.202:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20771]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20771]: ERROR: tm [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20771]: WARNING: tm [t_reply.c:1581]: t_retransmit_reply(): send pr buffer failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20756]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8eb948,358,0,10.100.177.91:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20756]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20756]: ERROR: sl [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20744]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8b4a80,358,0,10.100.72.230:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20744]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20744]: ERROR: sl [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20783]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8ac740,416,0,10.100.72.230:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20783]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20783]: ERROR: tm [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20752]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8b5098,356,0,10.100.56.38:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20805]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8e8f18,416,0,10.100.177.91:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20805]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20805]: ERROR: tm [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20752]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20752]: ERROR: sl [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20777]: ERROR: <script>: Re-Transmit: REGISTER (sip:410060269353579 at ims.mnc006.mcc410.3gppnetwork.org (10.100.236.57:5060) to sip:410060269353579 at ims.mnc006.mcc410.3gppnetwork.org, 1SDq5cuY3iDYFKLATTp)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20761]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8e8a08,354,0,10.100.2.76:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20761]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20761]: ERROR: sl [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20767]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8ad100,360,0,10.100.144.137:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20767]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20767]: ERROR: sl [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:41 pcscf [Proxy-CSCF][20777]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock,0x7f36ef8eb860,360,0,10.100.140.226:5060,16): Invalid argument(22)
Sep 25 16:58:41 pcscf [Proxy-CSCF][20777]: CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net
Sep 25 16:58:41 pcscf [Proxy-CSCF][20777]: ERROR: sl [../../core/forward.h:219]: msg_send_buffer(): udp_send failed
Sep 25 16:58:43 pcscf [Proxy-CSCF][20861]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 77
Sep 25 16:58:44 pcscf [Proxy-CSCF][20853]: ERROR: <core> [core/tcp_read.c:301]: tcp_read_data(): error reading: Connection timed out (110) ([10.100.64.49]:32888 ->
Sep 25 16:58:44 pcscf [Proxy-CSCF][20853]: ERROR: <core> [core/tcp_read.c:302]: tcp_read_data(): -> [10.161.224.228]:5060)
Sep 25 16:58:44 pcscf [Proxy-CSCF][20853]: ERROR: <core> [core/tcp_read.c:1485]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f36a739fe78 r: 0x7f36a739fef8
Sep 25 16:58:44 pcscf [Proxy-CSCF][20742]: ALERT: <core> [main.c:748]: handle_sigs(): child process 20815 exited by a signal 11
Sep 25 16:58:44 pcscf [Proxy-CSCF][20742]: ALERT: <core> [main.c:751]: handle_sigs(): core was generated
Sep 25 16:58:44 pcscf kernel: [52607827.581845] net_ratelimit: 16 callbacks suppressed
Sep 25 16:58:44 pcscf [Proxy-CSCF][20742]: CRITICAL: cdp [diameter_peer.c:423]: diameter_peer_destroy(): destroy_diameter_peer(): Bye Bye from C Diameter Peer test
Sep 25 16:59:01 pcscf CRON[24805]: (root) CMD (/bin/bash /root/volumes/monitoring/src/services_status.sh -p http://10.161.224.25:9091 -s kamailio_pcscf,sems -n pcscf)
Sep 25 16:59:01 pcscf CRON[24804]: (CRON) info (No MTA installed, discarding output)
Sep 25 16:59:44 pcscf [Proxy-CSCF][20742]: CRITICAL: <core> [main.c:654]: sig_alarm_abort(): shutdown timeout triggered, dying...

but last time its also crashed with the following logs as well


Sep 25 18:39:59 pcscf [Proxy-CSCF][28015]: ERROR: <core> [core/tcp_read.c:301]: tcp_read_data(): error reading: Connection timed out (110) ([10.100.183.34]:39022 ->
Sep 25 18:39:59 pcscf [Proxy-CSCF][28015]: ERROR: <core> [core/tcp_read.c:302]: tcp_read_data(): -> [10.161.224.228]:5060)
Sep 25 18:39:59 pcscf [Proxy-CSCF][28015]: ERROR: <core> [core/tcp_read.c:1485]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f92ca8d0150 r: 0x7f92ca8d01d0
Sep 25 18:39:59 pcscf [Proxy-CSCF][28010]: ERROR: cdp [authstatemachine.c:404]: auth_client_statefull_sm_process(): auth_client_statefull_sm_process(): Received invalid event 6 while in state Open!
Sep 25 18:39:59 pcscf [Proxy-CSCF][28010]: ERROR: cdp [authstatemachine.c:404]: auth_client_statefull_sm_process(): auth_client_statefull_sm_process(): Received invalid event 6 while in state Open!
Sep 25 18:40:00 pcscf [Proxy-CSCF][28034]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 77
Sep 25 18:40:01 pcscf [Proxy-CSCF][28026]: ERROR: <core> [core/tcp_read.c:301]: tcp_read_data(): error reading: Connection timed out (110) ([10.100.100.218]:1337 ->
Sep 25 18:40:01 pcscf [Proxy-CSCF][28026]: ERROR: <core> [core/tcp_read.c:302]: tcp_read_data(): -> [10.161.224.228]:5060)
Sep 25 18:40:01 pcscf [Proxy-CSCF][28026]: ERROR: <core> [core/tcp_read.c:1485]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f92ca87f070 r: 0x7f92ca87f0f0
Sep 25 18:40:01 pcscf [Proxy-CSCF][27919]: ALERT: <core> [main.c:748]: handle_sigs(): child process 27989 exited by a signal 11
Sep 25 18:40:01 pcscf [Proxy-CSCF][27919]: ALERT: <core> [main.c:751]: handle_sigs(): core was generated
Sep 25 18:40:01 pcscf kernel: [52613904.372973] net_ratelimit: 29 callbacks suppressed
Sep 25 18:40:01 pcscf [Proxy-CSCF][27919]: CRITICAL: cdp [diameter_peer.c:423]: diameter_peer_destroy(): destroy_diameter_peer(): Bye Bye from C Diameter Peer test
Sep 25 18:40:01 pcscf CRON[30581]: (root) CMD (/bin/bash /root/volumes/monitoring/src/services_status.sh -p http://10.161.224.25:9091 -s kamailio_pcscf,sems -n pcscf)
Sep 25 18:40:01 pcscf CRON[30580]: (CRON) info (No MTA installed, discarding output)
Sep 25 18:40:02 pcscf sems[2858]: [#7f2080044700] [update_uac_request, trans_layer.cpp:2080] WARNING:  While sending 200 ACK: no matching transaction
Sep 25 18:41:01 pcscf [Proxy-CSCF][27919]: CRITICAL: <core> [main.c:654]: sig_alarm_abort(): shutdown timeout triggered, dying...

PS: Kamailio is not listening on localhost.


Regards

Hamid R. Hashmi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201206/b4d0df51/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sig6.txt
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201206/b4d0df51/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sig11.txt
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201206/b4d0df51/attachment-0001.txt>

From aatif.shaikh at ecosmob.com  Mon Dec  7 06:30:30 2020
From: aatif.shaikh at ecosmob.com (Aatif Shaikh)
Date: Mon, 7 Dec 2020 11:00:30 +0530
Subject: [SR-Users] SLA presence not working proper with (SCA module)
Message-ID: <CAM12s7499hTRi_Et8S07nX1ScbpVZMd7Ephmj0No1MvB5NRyyQ@mail.gmail.com>

Hello All
   I configure my kamailio.cfg to handle SLA using (SCA module) and shared
presence is working but still facing some issue in case of hold invite and
BYE and the reason behind of that issue is following error

Nov 26 07:38:40 SBC-4-1 /usr/local/sbin/kamailio[104107]: ERROR: sca
[sca_call_info.c:1008]: sca_call_info_invite_request_handler(): Failed to
update sip:4569 at test.sip.abcd.com appearance-index 0 to active

actually, in Kamailio appearances, I can see the entry for this call but
the index is 1 instead of 0, and Kamailio going to update with a 0 index

[root at SBC-4-1 ntcarfte-kamailio]# kamcmd sca.all_appearances
sip:4569 at test.sip.abcd.com 1 active 1606376289
sip:4569 at 10.xx.xx.xx:5070;transport=udp
sip:2003 at test.sip.abcd.com
186161_mobile-rel120MTQ5OTcyZjFhMjMyNmI1ZGE1MWY4ODc2M2RkN2VmZmQ 45dc18d8
H6cS9vecZ248B

if I manually update appearances using RPC command with index 1 then the
phone started blinking as I change state to held

# kamcmd sca.update_appearance sip:4569 at sc4test.sip.teledge.com 1 held
# kamcmd sca.all_appearances
sip:4569 at test.sip.abcd.com 1 held 1606376516
sip:4569 at 10.xx.xx.xx:5070;transport=udp
sip:2003 at test.sip.abcd.com
186161_mobile-rel120NzE5MDgyZDc1NjJiYjcwMWFlYmI3NzM3NjE2OTRhZjU 08f005cb
eK9ratm83g92e

kamailio.cfg


route[SCA] {
        if(is_method("SUBSCRIBE")) {

                if ($hdr(Event) == "call-info" || $hdr(Event) ==
"line-seize") {
                xlog("L_INFO","(MAIN) :HELLO ($avp(uuid)) : $avp(rsi)  $sp
$hdr(Event)");
                        xdbg("SCA: $hdr(Event) SUBSCRIBE $ru from $si:$sp");
                        sca_handle_subscribe();
                        exit;
                }
                return;
        }

        if (!is_method("BYE|CANCEL|INVITE|PRACK|REFER")) {
                return;
        }
                        sca_call_info_update();
}

route[RELAY_OUTBOUND_FS] {
        xlog("L_INFO","(RELAY_OUTBOUND_FS) : ($avp(uuid)) : INSIDE ROUTE ");

        if (!has_totag()){
                $avp(set_h) = 1;
        }

        t_on_reply("REPLY_OUTBOUND_FS");
        route(SCA);
        if (!t_relay()) {
                sl_reply_error();
        }
        exit;
}

route[RELAY_INBOUND_FS] {

        if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
                $avp(s:puburis_caller) = $fu;
                setflag(8);
                dlg_manage();
        }

        if(is_method("REGISTER")) {
            t_on_reply("REPLY_REGISTER");
        } else {
            t_on_reply("REPLY_INBOUND_FS");
        }
        route(SCA);
        if (!t_relay()) {
                sl_reply_error();
        }
        exit;
}

onreply_route[REPLY_INBOUND_FS] {
xdbg("incoming reply\n");

if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
   return;
}

route(SCA);
}

onreply_route[REPLY_OUTBOUND_FS] {
xdbg("incoming reply\n");

if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
   return;
}

route(SCA);
}

can someone help me with this Did I missed something to handle SLA?


-- 
-- 

Regards,

*Aatif Shaikh *| Software Developer

+91 9033976268Hangout: aatif.shaikh at ecosmob.comSkype :
aatif.shaikh at ecosmob.com
*Ecosmob Technologies Pvt. Ltd. *
https://www.ecosmob.com
VoIP | Web | Mobile | IoT | Big Data
<https://twitter.com/ecosmob>  <https://www.facebook.com/Ecosmob>
<https://plus.google.com/+Ecosmob>
<https://www.linkedin.com/company/ecosmob>
<https://in.pinterest.com/ecosmob/>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
Ecosmob Technologies is not responsible for errors or omissions in this
message and denies any responsibility for any damage arising from the use
of e-mail. Any opinion and other statement contained in this message and
any attachment are solely those of the author and do not necessarily
represent those of the company.

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.


*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/4c7cc48a/attachment.htm>

From miconda at gmail.com  Mon Dec  7 13:53:37 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 7 Dec 2020 13:53:37 +0100
Subject: [SR-Users] kamailio-5.2.0 Crash - udp_send failed
In-Reply-To: <PU1PR03MB2908CED08A344DAA6099A583E0CF0@PU1PR03MB2908.apcprd03.prod.outlook.com>
References: <PU1PR03MB2908EE0F77AD2172A76CB369E0360@PU1PR03MB2908.apcprd03.prod.outlook.com>
 <AM0PR05MB659564ECE4CC900C49BB7B26C5370@AM0PR05MB6595.eurprd05.prod.outlook.com>
 <PU1PR03MB2908CED08A344DAA6099A583E0CF0@PU1PR03MB2908.apcprd03.prod.outlook.com>
Message-ID: <180037fb-1d5d-6522-c372-5b029fda8f86@gmail.com>

Hello,


get also the output of "bt full" from gdb.


I see you use ims moudules, they are known to have some limitations for
various settings. Is this something that you can reproduce, or is
something that happens from time to time without any pattern?


Cheers,
Daniel


On 06.12.20 20:13, Hamid Hashmi wrote:
> Hello?
>
> I have updated Kamailio from 5.2.0 to 5.4.2 but the service is still
> crashing with sig 11 and sig 6. Please find the attached 'bt full' traces.
>
> Sig 11:
> |Core was generated by `/usr/local/sbin/kamailio -f
> /usr/local/etc/kamailio_pcscf/kamailio.cfg -P /var/'. Program
> terminated with signal SIGSEGV, Segmentation fault. #0
> ?0x00000000006a16fc in timer_list_expire (t=1339518316,
> h=0x7facee484fd0, slow_l=0x7facee488208, slow_mark=7936) at
> core/timer.c:846 846 ? ? ? ? ? ? ? ? ? ? _timer_rm_list(tl); /* detach
> */ (gdb) bt #0 ?0x00000000006a16fc in timer_list_expire (t=1339518316,
> h=0x7facee484fd0, slow_l=0x7facee488208, slow_mark=7936) at
> core/timer.c:846 #1 ?0x00000000006a1c19 in timer_handler () at
> core/timer.c:922 #2 ?0x00000000006a20ba in timer_main () at
> core/timer.c:961 #3 ?0x000000000042ac0a in main_loop () at main.c:1753
> #4 ?0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at
> main.c:2856|
> Sig 6:
> |Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by
> `/usr/local/sbin/kamailio -f
> /usr/local/etc/kamailio_pcscf/kamailio.cfg -P /var/'. Program
> terminated with signal SIGABRT, Aborted. #0 ?0x00007fad95f56c37 in
> raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0
> ?0x00007fad95f56c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1 ?0x00007fad95f5a028 in abort () from
> /lib/x86_64-linux-gnu/libc.so.6 #2 ?0x000000000041e39d in
> sig_alarm_abort (signo=14) at main.c:687 #3 ?<signal handler called>
> #4 ?0x00007fad960183c7 in syscall () from
> /lib/x86_64-linux-gnu/libc.so.6 #5 ?0x00007fad6f5c024b in futex_get
> (lock=0x7facee70baa0) at ../../core/mem/../futexlock.h:121 #6
> ?0x00007fad6f5c2167 in get_peer_by_fqdn (fqdn=0x7faceeb377b0) at
> peermanager.c:240 #7 ?0x00007fad6f5e6c31 in get_first_connected_route
> (cdp_session=0x7faceeb37768, r=0x7facee70a220, app_id=16777236,
> vendor_id=10415) at routing.c:110 #8 ?0x00007fad6f5ea8b2 in
> get_routing_peer (cdp_session=0x7faceeb37768, m=0x7facef617fb0) at
> routing.c:272 #9 ?0x00007fad6f5ac72d in AAASendMessage
> (message=0x7facef617fb0, callback_f=0x0, callback_param=0x0) at
> diameter_comm.c:137 #10 0x00007fad6ef05dbb in rx_send_str
> (rx_session_id=0x7facf0849d50) at rx_str.c:157 #11 0x00007fad6eeb25c4
> in callback_dialog (dlg=0x7facf0036d70, type=8192,
> params=0x7fad72b2a1c0 <params>) at ims_qos_mod.c:453 #12
> 0x00007fad728973af in run_dlg_callbacks (type=8192,
> dlg=0x7facf0036d70, req=0x0, rpl=0x0, dir=0, dlg_data=0x0) at
> dlg_cb.c:274 #13 0x00007fad728d5315 in destroy_dlg
> (dlg=0x7facf0036d70) at dlg_hash.c:219 #14 0x00007fad728d5b1b in
> destroy_dlg_table () at dlg_hash.c:291 #15 0x00007fad7290b71e in
> mod_destroy () at ims_dialog.c:627 #16 0x0000000000616ae1 in
> destroy_modules () at core/sr_module.c:746 #17 0x000000000041ce17 in
> cleanup (show_status=1) at main.c:563 #18 0x000000000041e6ef in
> shutdown_children (sig=15, show_status=1) at main.c:706 #19
> 0x0000000000421755 in handle_sigs () at main.c:806 #20
> 0x000000000042bc85 in main_loop () at main.c:1817 #21
> 0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at main.c:2856|
>
> PS: I am using ubuntu 14.04.??
>
> Regards
>
> *Hamid R. Hashmi*
>
> ------------------------------------------------------------------------
> *From:* Henning Westerholt <hw at skalatan.de>
> *Sent:* Saturday, September 26, 2020 12:04 PM
> *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
> *Cc:* Hamid Hashmi <hamid2kviii at hotmail.com>
> *Subject:* Re: kamailio-5.2.0 Crash - udp_send failed
> ?
> Hello,
>
> you are using a old and non released dev version of kamailio. These
> are meant only for development purposes.
>
> Please update to a proper version (like the latest one based on 5.3 or
> 5.4 branch.
>
> Then try to reproduce the bug again and report on the list or by
> creating an issue.
>
> Cheers,
>
> Henning
>
>
> -- 
> Henning Westerholt - https://skalatan.de/blog/ <https://skalatan.de/blog/>
> Kamailio services - https://skalatan.de/services
> <https://skalatan.de/services>
>
> ------------------------------------------------------------------------
> *From:* sr-users <sr-users-bounces at lists.kamailio.org> on behalf of
> Hamid Hashmi <hamid2kviii at hotmail.com>
> *Sent:* Friday, September 25, 2020 9:28:07 PM
> *To:* sr-users at lists.kamailio.org <sr-users at lists.kamailio.org>
> *Subject:* [SR-Users] kamailio-5.2.0 Crash - udp_send failed
> ?
> I am using "kamailio 5.2.0-dev6 (x86_64/linux) 48ed62-dirty" what
> could be the reason of the crash
>
> its usually crash with the following logs
>
> |Sep 25 16:58:41 pcscf [Proxy-CSCF][20771]: ERROR: <core>
> [core/udp_server.c:596]: udp_send():
> sendto(sock,0x7f36eee8c560,418,0,10.100.227.202:5060,16): Invalid
> argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20771]: CRITICAL:
> <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20771]: ERROR: tm [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20771]: WARNING: tm [t_reply.c:1581]:
> t_retransmit_reply(): send pr buffer failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20756]: ERROR: <core> [core/udp_server.c:596]:
> udp_send(): sendto(sock,0x7f36ef8eb948,358,0,10.100.177.91:5060,16):
> Invalid argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20756]:
> CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20756]: ERROR: sl [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20744]: ERROR: <core> [core/udp_server.c:596]:
> udp_send(): sendto(sock,0x7f36ef8b4a80,358,0,10.100.72.230:5060,16):
> Invalid argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20744]:
> CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20744]: ERROR: sl [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20783]: ERROR: <core> [core/udp_server.c:596]:
> udp_send(): sendto(sock,0x7f36ef8ac740,416,0,10.100.72.230:5060,16):
> Invalid argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20783]:
> CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20783]: ERROR: tm [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20752]: ERROR: <core> [core/udp_server.c:596]:
> udp_send(): sendto(sock,0x7f36ef8b5098,356,0,10.100.56.38:5060,16):
> Invalid argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20805]: ERROR:
> <core> [core/udp_server.c:596]: udp_send():
> sendto(sock,0x7f36ef8e8f18,416,0,10.100.177.91:5060,16): Invalid
> argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20805]: CRITICAL:
> <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20805]: ERROR: tm [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20752]: CRITICAL: <core> [core/udp_server.c:601]:
> udp_send(): invalid sendtoparameters#012one possible reason is the
> server is bound to localhost and#012attempts to send to the net Sep 25
> 16:58:41 pcscf [Proxy-CSCF][20752]: ERROR: sl
> [../../core/forward.h:219]: msg_send_buffer(): udp_send failed Sep 25
> 16:58:41 pcscf [Proxy-CSCF][20777]: ERROR: <script>: Re-Transmit:
> REGISTER (sip:410060269353579 at ims.mnc006.mcc410.3gppnetwork.org
> (10.100.236.57:5060) to
> sip:410060269353579 at ims.mnc006.mcc410.3gppnetwork.org,
> 1SDq5cuY3iDYFKLATTp) Sep 25 16:58:41 pcscf [Proxy-CSCF][20761]: ERROR:
> <core> [core/udp_server.c:596]: udp_send():
> sendto(sock,0x7f36ef8e8a08,354,0,10.100.2.76:5060,16): Invalid
> argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20761]: CRITICAL:
> <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20761]: ERROR: sl [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20767]: ERROR: <core> [core/udp_server.c:596]:
> udp_send(): sendto(sock,0x7f36ef8ad100,360,0,10.100.144.137:5060,16):
> Invalid argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20767]:
> CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20767]: ERROR: sl [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20777]: ERROR: <core> [core/udp_server.c:596]:
> udp_send(): sendto(sock,0x7f36ef8eb860,360,0,10.100.140.226:5060,16):
> Invalid argument(22) Sep 25 16:58:41 pcscf [Proxy-CSCF][20777]:
> CRITICAL: <core> [core/udp_server.c:601]: udp_send(): invalid
> sendtoparameters#012one possible reason is the server is bound to
> localhost and#012attempts to send to the net Sep 25 16:58:41 pcscf
> [Proxy-CSCF][20777]: ERROR: sl [../../core/forward.h:219]:
> msg_send_buffer(): udp_send failed Sep 25 16:58:43 pcscf
> [Proxy-CSCF][20861]: CRITICAL: <core> [core/pass_fd.c:277]:
> receive_fd(): EOF on 77 Sep 25 16:58:44 pcscf [Proxy-CSCF][20853]:
> ERROR: <core> [core/tcp_read.c:301]: tcp_read_data(): error reading:
> Connection timed out (110) ([10.100.64.49]:32888 -> Sep 25 16:58:44
> pcscf [Proxy-CSCF][20853]: ERROR: <core> [core/tcp_read.c:302]:
> tcp_read_data(): -> [10.161.224.228]:5060) Sep 25 16:58:44 pcscf
> [Proxy-CSCF][20853]: ERROR: <core> [core/tcp_read.c:1485]:
> tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f36a739fe78
> r: 0x7f36a739fef8 Sep 25 16:58:44 pcscf [Proxy-CSCF][20742]: ALERT:
> <core> [main.c:748]: handle_sigs(): child process 20815 exited by a
> signal 11 Sep 25 16:58:44 pcscf [Proxy-CSCF][20742]: ALERT: <core>
> [main.c:751]: handle_sigs(): core was generated Sep 25 16:58:44 pcscf
> kernel: [52607827.581845] net_ratelimit: 16 callbacks suppressed Sep
> 25 16:58:44 pcscf [Proxy-CSCF][20742]: CRITICAL: cdp
> [diameter_peer.c:423]: diameter_peer_destroy():
> destroy_diameter_peer(): Bye Bye from C Diameter Peer test Sep 25
> 16:59:01 pcscf CRON[24805]: (root) CMD (/bin/bash
> /root/volumes/monitoring/src/services_status.sh -p
> http://10.161.224.25:9091 -s kamailio_pcscf,sems -n pcscf) Sep 25
> 16:59:01 pcscf CRON[24804]: (CRON) info (No MTA installed, discarding
> output) Sep 25 16:59:44 pcscf [Proxy-CSCF][20742]: CRITICAL: <core>
> [main.c:654]: sig_alarm_abort(): shutdown timeout triggered, dying...|
> but last time its also crashed with the following logs as well
>
> |Sep 25 18:39:59 pcscf [Proxy-CSCF][28015]: ERROR: <core>
> [core/tcp_read.c:301]: tcp_read_data(): error reading: Connection
> timed out (110) ([10.100.183.34]:39022 -> Sep 25 18:39:59 pcscf
> [Proxy-CSCF][28015]: ERROR: <core> [core/tcp_read.c:302]:
> tcp_read_data(): -> [10.161.224.228]:5060) Sep 25 18:39:59 pcscf
> [Proxy-CSCF][28015]: ERROR: <core> [core/tcp_read.c:1485]:
> tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f92ca8d0150
> r: 0x7f92ca8d01d0 Sep 25 18:39:59 pcscf [Proxy-CSCF][28010]: ERROR:
> cdp [authstatemachine.c:404]: auth_client_statefull_sm_process():
> auth_client_statefull_sm_process(): Received invalid event 6 while in
> state Open! Sep 25 18:39:59 pcscf [Proxy-CSCF][28010]: ERROR: cdp
> [authstatemachine.c:404]: auth_client_statefull_sm_process():
> auth_client_statefull_sm_process(): Received invalid event 6 while in
> state Open! Sep 25 18:40:00 pcscf [Proxy-CSCF][28034]: CRITICAL:
> <core> [core/pass_fd.c:277]: receive_fd(): EOF on 77 Sep 25 18:40:01
> pcscf [Proxy-CSCF][28026]: ERROR: <core> [core/tcp_read.c:301]:
> tcp_read_data(): error reading: Connection timed out (110)
> ([10.100.100.218]:1337 -> Sep 25 18:40:01 pcscf [Proxy-CSCF][28026]:
> ERROR: <core> [core/tcp_read.c:302]: tcp_read_data(): ->
> [10.161.224.228]:5060) Sep 25 18:40:01 pcscf [Proxy-CSCF][28026]:
> ERROR: <core> [core/tcp_read.c:1485]: tcp_read_req(): ERROR:
> tcp_read_req: error reading - c: 0x7f92ca87f070 r: 0x7f92ca87f0f0 Sep
> 25 18:40:01 pcscf [Proxy-CSCF][27919]: ALERT: <core> [main.c:748]:
> handle_sigs(): child process 27989 exited by a signal 11 Sep 25
> 18:40:01 pcscf [Proxy-CSCF][27919]: ALERT: <core> [main.c:751]:
> handle_sigs(): core was generated Sep 25 18:40:01 pcscf kernel:
> [52613904.372973] net_ratelimit: 29 callbacks suppressed Sep 25
> 18:40:01 pcscf [Proxy-CSCF][27919]: CRITICAL: cdp
> [diameter_peer.c:423]: diameter_peer_destroy():
> destroy_diameter_peer(): Bye Bye from C Diameter Peer test Sep 25
> 18:40:01 pcscf CRON[30581]: (root) CMD (/bin/bash
> /root/volumes/monitoring/src/services_status.sh -p
> http://10.161.224.25:9091 -s kamailio_pcscf,sems -n pcscf) Sep 25
> 18:40:01 pcscf CRON[30580]: (CRON) info (No MTA installed, discarding
> output) Sep 25 18:40:02 pcscf sems[2858]: [#7f2080044700]
> [update_uac_request, trans_layer.cpp:2080] WARNING: ?While sending 200
> ACK: no matching transaction Sep 25 18:41:01 pcscf
> [Proxy-CSCF][27919]: CRITICAL: <core> [main.c:654]: sig_alarm_abort():
> shutdown timeout triggered, dying...|
>
> PS: Kamailio is not listening on localhost.?
>
> Regards
>
> *Hamid R. Hashmi*
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/c0982841/attachment.htm>

From abdoul.osseni at gmail.com  Mon Dec  7 14:30:19 2020
From: abdoul.osseni at gmail.com (=?UTF-8?Q?Abdoul_Oss=C3=A9ni?=)
Date: Mon, 7 Dec 2020 14:30:19 +0100
Subject: [SR-Users] Kamailio as an LCR based on prices but also signaling
 quality indicators
Message-ID: <CABc7nxurxvDPnLa_kyrUt0jUPNNn2DNFLvxyA_46-fXsBkdhog@mail.gmail.com>

Hello,

I am trying to configure kamailio as an LCR based on prices but also
signaling quality indicators like ASR and ACDR.

Can you please help me and tell me where to start?

Regards
Abdoul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/238f65fa/attachment.htm>

From abalashov at evaristesys.com  Mon Dec  7 15:07:58 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 7 Dec 2020 09:07:58 -0500
Subject: [SR-Users] Kamailio as an LCR based on prices but also
 signaling quality indicators
In-Reply-To: <CABc7nxurxvDPnLa_kyrUt0jUPNNn2DNFLvxyA_46-fXsBkdhog@mail.gmail.com>
References: <CABc7nxurxvDPnLa_kyrUt0jUPNNn2DNFLvxyA_46-fXsBkdhog@mail.gmail.com>
Message-ID: <664ABB38-D311-44AE-BB35-D79201ED79F4@evaristesys.com>

If it were that easy, we wouldn?t have a successful commercial software product. :-) You?re going to need a lot of logic.

?
Sent from mobile, with due apologies for brevity and errors.

> On Dec 7, 2020, at 8:30 AM, Abdoul Oss?ni <abdoul.osseni at gmail.com> wrote:
> 
> ?
> Hello,
> 
> I am trying to configure kamailio as an LCR based on prices but also signaling quality indicators like ASR and ACDR.
> 
> Can you please help me and tell me where to start?
> 
> Regards
> Abdoul
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/3ac33a38/attachment.htm>

From m at mokalife.ro  Mon Dec  7 16:05:45 2020
From: m at mokalife.ro (Mihai)
Date: Mon, 7 Dec 2020 17:05:45 +0200
Subject: [SR-Users] Kamilio dispatcher not registering with asterisk
Message-ID: <CANk_n4bJwTJ7JvnabTo+N_o9gngJ1R94rbzzSUMz4Eo2sndcrw@mail.gmail.com>

Hi all,

i have a problem with kamailio 5.3.x and asterisk 13, i basically forward
everything, but i cant manage to make it register.

The register arrives on asterisk see the capture bellow:
Any help is much appreciated!
----------------
REGISTER sip:oro.sips.nl;transport=UDP SIP/2.0
Via: SIP/2.0/UDP
104.201.100.15;branch=z9hG4bK4d5e.997621d931a2ad9f6423e2ac7782a319.1
Via: SIP/2.0/UDP 34.12.55.102:34626
;received=34.12.55.102;branch=z9hG4bK-524287-1---0a0bffd64bbd9941;rport=34626
Max-Forwards: 69
Contact: <sip:test-user1 at 34.12.55.102:34626
;transport=UDP;rinstance=85c33e976be3dad1>
To: <sip:test-user1 at oro.sips.nl;transport=UDP>
From: <sip:test-user1 at oro.sips.nl;transport=UDP>;tag=6d8fd914
Call-ID: h6lkViFgxurpVRkw4Ly-GQ..
CSeq: 1 REGISTER
Expires: 60
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
SUBSCRIBE
User-Agent: Z 5.4.9 rv2.10.11.7
Allow-Events: presence, kpml, talk
Content-Length: 0
Path: <sip:104.201.100.15;lr;received=sip:34.12.55.102:34626>

-------------------the config -------
# - flags
#   FLT_ - per transaction (message) flags
# FLB_ - per branch flags
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3

#!define FLT_FS 10

####### Global Parameters #########

debug=4
log_stderror=yes

memdbg=5
memlog=5

log_facility=LOG_LOCAL0

fork=yes
children=4

/* comment the next line to enable TCP */
disable_tcp=yes

/* uncomment the next line to disable the auto discovery of local aliases
   based on revers DNS on IPs (default on) */
auto_aliases=no

/* add local domain aliases */
# alias="mysipserver.com"

port=5060

/* uncomment and configure the following line if you want Kamailio to
   bind on a specific interface/port/proto (default bind on all available)
*/
# listen=udp:127.0.0.1:5060

sip_warning=no

####### Modules Section ########

# set module path
#mpath="/usr/local/lib/kamailio/modules/"

#loadmodule "db_mysql.so"
loadmodule "jsonrpcs.so"
loadmodule "kex.so"
loadmodule "corex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "textops.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "acc.so"
loadmodule "dispatcher.so"
loadmodule "path.so"

# ----------------- setting module-specific parameters ---------------


# ----- jsonrpcs params -----
modparam("jsonrpcs", "pretty_format", 1)


# ----- rr params -----
# add value to ;lr param to cope with most of the UAs
modparam("rr", "enable_full_lr", 1)
# do not append from tag to the RR (no need for this script)
modparam("rr", "append_fromtag", 0)


# ----- acc params -----
modparam("acc", "log_flag", FLT_ACC)
modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
modparam("acc", "log_extra",
"src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si")

# ----- tm params -----
modparam("tm", "fr_timer", 2000)
modparam("tm", "fr_inv_timer", 40000)

# ----- dispatcher params -----
#modparam("dispatcher", "db_url", DBURL)
#modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "xavp_dst", "_dsdst_")
modparam("dispatcher", "xavp_ctx", "_dsctx_")
modparam("dispatcher", "ds_ping_from", "sip:proxy at mykamailio")
modparam("dispatcher", "ds_ping_interval", 30)
modparam("dispatcher", "ds_probing_threshold", 10)
modparam("dispatcher", "ds_inactive_threshold", 5)
modparam("dispatcher", "ds_ping_reply_codes",
"class=2;code=403;code=488;class=3")
modparam("dispatcher", "ds_probing_mode", 1)

modparam("path", "use_received", 1)

####### Routing Logic ########


# main request routing logic

request_route {

# per request initial checks
route(REQINIT);

        if(ds_is_from_list()) {
       setflag(FLT_FS);
        }

# CANCEL processing
if (is_method("CANCEL")) {
if (t_check_trans()) {
route(RELAY);
}
exit;
}

# handle retransmissions
if (!is_method("ACK")) {
if(t_precheck_trans()) {
t_check_trans();
exit;
}
t_check_trans();
}

# handle requests within SIP dialogs
route(WITHINDLG);

        if (isflagset(FLT_FS)) {
                route(FROM_FS);
                exit;
        }

### only initial requests (no To tag)

# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE|SUBSCRIBE")) {
record_route();
}

# account only INVITEs
if (is_method("INVITE")) {
setflag(FLT_ACC); # do accounting
}

# handle presence related requests
route(PRESENCE);

# handle registrations
route(REGISTRAR);

if ($rU==$null) {
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}

# dispatch destinations
route(DISPATCH);
}

route[FROM_FS]
{
        record_route();
        route(RELAY);
        exit;
}

route[RELAY] {
if (!t_relay()) {
sl_reply_error();
}
exit;
}

# Per SIP request initial checks
route[REQINIT] {
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}

if(!sanity_check("1511", "7")) {
xlog("Malformed SIP message from $si:$sp\n");
exit;
}
}

# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
route(RELAY);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe requests
route(PRESENCE);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK;
# must be ACK after a 487 or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard.
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
}

# Handle SIP registrations
route[REGISTRAR] {
if(!is_method("REGISTER"))
return;
add_path_received();
        route(DISPATCH);
}

# Presence server route
route[PRESENCE] {
if(!is_method("PUBLISH|SUBSCRIBE"))
return;

sl_send_reply("404", "Not here");
exit;
}

# Dispatch requests
route[DISPATCH] {
# round robin dispatching on gateways group '1'
switch ($fd){
case "oro.sips.nl":
send_reply(483, "Ok, Skipper!");
if (!ds_select_dst("1", "4")) {
log("ERROR: no active destinations found!\n");
send_reply(503, "Service Unavailable");
exit;
}
ds_select_dst("1", "4");
log("---- flag value is $dd -- branch $fd \n");
xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");
break;
case "oro2.sips.nl":
send_reply(483, "Ok, Skipper!");
if (!ds_select_dst("2", "4")) {
log("ERROR: no active destinations found!\n");
send_reply(503, "Service Unavailable");
exit;
}
ds_select_dst("2", "4");
log("---- flag value is $dd -- branch $fd \n");
xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");
break;
default:
   log("unknow destination?");
   send_reply(503, "No service defined");
   exit;
}

xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}

# Try next destionations in failure route
failure_route[RTF_DISPATCH] {
if (t_is_canceled()) {
exit;
}
# next DST - only for 500 or local timeout
if (t_check_status("500")
or (t_branch_timeout() and !t_branch_replied())) {
if(ds_next_dst()) {
xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/718224dd/attachment.htm>

From sergio.charrua at voip.pt  Mon Dec  7 16:12:02 2020
From: sergio.charrua at voip.pt (Sergio Charrua)
Date: Mon, 7 Dec 2020 15:12:02 +0000
Subject: [SR-Users] Kamilio dispatcher not registering with asterisk
In-Reply-To: <CANk_n4bJwTJ7JvnabTo+N_o9gngJ1R94rbzzSUMz4Eo2sndcrw@mail.gmail.com>
References: <CANk_n4bJwTJ7JvnabTo+N_o9gngJ1R94rbzzSUMz4Eo2sndcrw@mail.gmail.com>
Message-ID: <CALZWR5wBwKjBE2RBqFw8es0McBTttpDvoNYTif6nM0E7B8Lt3A@mail.gmail.com>

Hi !

what is the "type" of your SIP Peer, on Asterisk? Friend, Peer or User? and
what about the "insecure" setting?

*S?rgio Charrua*


*www.voip.pt <http://www.voip.pt/>*
Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77

Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Mon, Dec 7, 2020 at 3:09 PM Mihai <m at mokalife.ro> wrote:

> Hi all,
>
> i have a problem with kamailio 5.3.x and asterisk 13, i basically forward
> everything, but i cant manage to make it register.
>
> The register arrives on asterisk see the capture bellow:
> Any help is much appreciated!
> ----------------
> REGISTER sip:oro.sips.nl;transport=UDP SIP/2.0
> Via: SIP/2.0/UDP
> 104.201.100.15;branch=z9hG4bK4d5e.997621d931a2ad9f6423e2ac7782a319.1
> Via: SIP/2.0/UDP 34.12.55.102:34626
> ;received=34.12.55.102;branch=z9hG4bK-524287-1---0a0bffd64bbd9941;rport=34626
> Max-Forwards: 69
> Contact: <sip:test-user1 at 34.12.55.102:34626
> ;transport=UDP;rinstance=85c33e976be3dad1>
> To: <sip:test-user1 at oro.sips.nl;transport=UDP>
> From: <sip:test-user1 at oro.sips.nl;transport=UDP>;tag=6d8fd914
> Call-ID: h6lkViFgxurpVRkw4Ly-GQ..
> CSeq: 1 REGISTER
> Expires: 60
> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
> SUBSCRIBE
> User-Agent: Z 5.4.9 rv2.10.11.7
> Allow-Events: presence, kpml, talk
> Content-Length: 0
> Path: <sip:104.201.100.15;lr;received=sip:34.12.55.102:34626>
>
> -------------------the config -------
> # - flags
> #   FLT_ - per transaction (message) flags
> # FLB_ - per branch flags
> #!define FLT_ACC 1
> #!define FLT_ACCMISSED 2
> #!define FLT_ACCFAILED 3
>
> #!define FLT_FS 10
>
> ####### Global Parameters #########
>
> debug=4
> log_stderror=yes
>
> memdbg=5
> memlog=5
>
> log_facility=LOG_LOCAL0
>
> fork=yes
> children=4
>
> /* comment the next line to enable TCP */
> disable_tcp=yes
>
> /* uncomment the next line to disable the auto discovery of local aliases
>    based on revers DNS on IPs (default on) */
> auto_aliases=no
>
> /* add local domain aliases */
> # alias="mysipserver.com"
>
> port=5060
>
> /* uncomment and configure the following line if you want Kamailio to
>    bind on a specific interface/port/proto (default bind on all available)
> */
> # listen=udp:127.0.0.1:5060
>
> sip_warning=no
>
> ####### Modules Section ########
>
> # set module path
> #mpath="/usr/local/lib/kamailio/modules/"
>
> #loadmodule "db_mysql.so"
> loadmodule "jsonrpcs.so"
> loadmodule "kex.so"
> loadmodule "corex.so"
> loadmodule "tm.so"
> loadmodule "tmx.so"
> loadmodule "sl.so"
> loadmodule "rr.so"
> loadmodule "pv.so"
> loadmodule "maxfwd.so"
> loadmodule "textops.so"
> loadmodule "siputils.so"
> loadmodule "xlog.so"
> loadmodule "sanity.so"
> loadmodule "ctl.so"
> loadmodule "acc.so"
> loadmodule "dispatcher.so"
> loadmodule "path.so"
>
> # ----------------- setting module-specific parameters ---------------
>
>
> # ----- jsonrpcs params -----
> modparam("jsonrpcs", "pretty_format", 1)
>
>
> # ----- rr params -----
> # add value to ;lr param to cope with most of the UAs
> modparam("rr", "enable_full_lr", 1)
> # do not append from tag to the RR (no need for this script)
> modparam("rr", "append_fromtag", 0)
>
>
> # ----- acc params -----
> modparam("acc", "log_flag", FLT_ACC)
> modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
> modparam("acc", "log_extra",
> "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si")
>
> # ----- tm params -----
> modparam("tm", "fr_timer", 2000)
> modparam("tm", "fr_inv_timer", 40000)
>
> # ----- dispatcher params -----
> #modparam("dispatcher", "db_url", DBURL)
> #modparam("dispatcher", "table_name", "dispatcher")
> modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
> modparam("dispatcher", "flags", 2)
> modparam("dispatcher", "xavp_dst", "_dsdst_")
> modparam("dispatcher", "xavp_ctx", "_dsctx_")
> modparam("dispatcher", "ds_ping_from", "sip:proxy at mykamailio")
> modparam("dispatcher", "ds_ping_interval", 30)
> modparam("dispatcher", "ds_probing_threshold", 10)
> modparam("dispatcher", "ds_inactive_threshold", 5)
> modparam("dispatcher", "ds_ping_reply_codes",
> "class=2;code=403;code=488;class=3")
> modparam("dispatcher", "ds_probing_mode", 1)
>
> modparam("path", "use_received", 1)
>
> ####### Routing Logic ########
>
>
> # main request routing logic
>
> request_route {
>
> # per request initial checks
> route(REQINIT);
>
>         if(ds_is_from_list()) {
>        setflag(FLT_FS);
>         }
>
> # CANCEL processing
> if (is_method("CANCEL")) {
> if (t_check_trans()) {
> route(RELAY);
> }
> exit;
> }
>
> # handle retransmissions
> if (!is_method("ACK")) {
> if(t_precheck_trans()) {
> t_check_trans();
> exit;
> }
> t_check_trans();
> }
>
> # handle requests within SIP dialogs
> route(WITHINDLG);
>
>         if (isflagset(FLT_FS)) {
>                 route(FROM_FS);
>                 exit;
>         }
>
> ### only initial requests (no To tag)
>
> # record routing for dialog forming requests (in case they are routed)
> # - remove preloaded route headers
> remove_hf("Route");
> if (is_method("INVITE|SUBSCRIBE")) {
> record_route();
> }
>
> # account only INVITEs
> if (is_method("INVITE")) {
> setflag(FLT_ACC); # do accounting
> }
>
> # handle presence related requests
> route(PRESENCE);
>
> # handle registrations
> route(REGISTRAR);
>
> if ($rU==$null) {
> # request with no Username in RURI
> sl_send_reply("484","Address Incomplete");
> exit;
> }
>
> # dispatch destinations
> route(DISPATCH);
> }
>
> route[FROM_FS]
> {
>         record_route();
>         route(RELAY);
>         exit;
> }
>
> route[RELAY] {
> if (!t_relay()) {
> sl_reply_error();
> }
> exit;
> }
>
> # Per SIP request initial checks
> route[REQINIT] {
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483","Too Many Hops");
> exit;
> }
>
> if(!sanity_check("1511", "7")) {
> xlog("Malformed SIP message from $si:$sp\n");
> exit;
> }
> }
>
> # Handle requests within SIP dialogs
> route[WITHINDLG] {
> if (has_totag()) {
> # sequential request withing a dialog should
> # take the path determined by record-routing
> if (loose_route()) {
> if (is_method("BYE")) {
> setflag(FLT_ACC); # do accounting ...
> setflag(FLT_ACCFAILED); # ... even if the transaction fails
> }
> route(RELAY);
> } else {
> if (is_method("SUBSCRIBE") && uri == myself) {
> # in-dialog subscribe requests
> route(PRESENCE);
> exit;
> }
> if ( is_method("ACK") ) {
> if ( t_check_trans() ) {
> # non loose-route, but stateful ACK;
> # must be ACK after a 487 or e.g. 404 from upstream server
> t_relay();
> exit;
> } else {
> # ACK without matching transaction ... ignore and discard.
> exit;
> }
> }
> sl_send_reply("404","Not here");
> }
> exit;
> }
> }
>
> # Handle SIP registrations
> route[REGISTRAR] {
> if(!is_method("REGISTER"))
> return;
> add_path_received();
>         route(DISPATCH);
> }
>
> # Presence server route
> route[PRESENCE] {
> if(!is_method("PUBLISH|SUBSCRIBE"))
> return;
>
> sl_send_reply("404", "Not here");
> exit;
> }
>
> # Dispatch requests
> route[DISPATCH] {
> # round robin dispatching on gateways group '1'
> switch ($fd){
> case "oro.sips.nl":
> send_reply(483, "Ok, Skipper!");
> if (!ds_select_dst("1", "4")) {
> log("ERROR: no active destinations found!\n");
> send_reply(503, "Service Unavailable");
> exit;
> }
> ds_select_dst("1", "4");
> log("---- flag value is $dd -- branch $fd \n");
> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
> $xavp(_dsdst_=>attrs))\n");
> break;
> case "oro2.sips.nl":
> send_reply(483, "Ok, Skipper!");
> if (!ds_select_dst("2", "4")) {
> log("ERROR: no active destinations found!\n");
> send_reply(503, "Service Unavailable");
> exit;
> }
> ds_select_dst("2", "4");
> log("---- flag value is $dd -- branch $fd \n");
> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
> $xavp(_dsdst_=>attrs))\n");
> break;
> default:
>    log("unknow destination?");
>    send_reply(503, "No service defined");
>    exit;
> }
>
> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
> $xavp(_dsdst_=>attrs))\n");
> t_on_failure("RTF_DISPATCH");
> route(RELAY);
> exit;
> }
>
> # Try next destionations in failure route
> failure_route[RTF_DISPATCH] {
> if (t_is_canceled()) {
> exit;
> }
> # next DST - only for 500 or local timeout
> if (t_check_status("500")
> or (t_branch_timeout() and !t_branch_replied())) {
> if(ds_next_dst()) {
> xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs:
> $xavp(_dsdst_=>attrs))\n");
> t_on_failure("RTF_DISPATCH");
> route(RELAY);
> exit;
> }
> }
> }
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/88b74a17/attachment.htm>

From cezar at mokalife.ro  Mon Dec  7 16:22:57 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Mon, 7 Dec 2020 17:22:57 +0200
Subject: [SR-Users] Kamilio dispatcher not registering with asterisk
In-Reply-To: <CALZWR5wBwKjBE2RBqFw8es0McBTttpDvoNYTif6nM0E7B8Lt3A@mail.gmail.com>
References: <CANk_n4bJwTJ7JvnabTo+N_o9gngJ1R94rbzzSUMz4Eo2sndcrw@mail.gmail.com>
 <CALZWR5wBwKjBE2RBqFw8es0McBTttpDvoNYTif6nM0E7B8Lt3A@mail.gmail.com>
Message-ID: <CANk_n4Z4fHzVRV_YTiLqu0hESU4=nbyCW-fBZFQ9j1U1E9QLEw@mail.gmail.com>

HI sergio,

I just set allow_guest = yes. I don't know what to set on the asterisk, if
you can guide a little bit ...

On Mon, Dec 7, 2020 at 5:17 PM Sergio Charrua <sergio.charrua at voip.pt>
wrote:

> Hi !
>
> what is the "type" of your SIP Peer, on Asterisk? Friend, Peer or User?
> and what about the "insecure" setting?
>
> *S?rgio Charrua*
>
>
> *www.voip.pt <http://www.voip.pt/>*
> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>
> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
>
> On Mon, Dec 7, 2020 at 3:09 PM Mihai <m at mokalife.ro> wrote:
>
>> Hi all,
>>
>> i have a problem with kamailio 5.3.x and asterisk 13, i basically forward
>> everything, but i cant manage to make it register.
>>
>> The register arrives on asterisk see the capture bellow:
>> Any help is much appreciated!
>> ----------------
>> REGISTER sip:oro.sips.nl;transport=UDP SIP/2.0
>> Via: SIP/2.0/UDP
>> 104.201.100.15;branch=z9hG4bK4d5e.997621d931a2ad9f6423e2ac7782a319.1
>> Via: SIP/2.0/UDP 34.12.55.102:34626
>> ;received=34.12.55.102;branch=z9hG4bK-524287-1---0a0bffd64bbd9941;rport=34626
>> Max-Forwards: 69
>> Contact: <sip:test-user1 at 34.12.55.102:34626
>> ;transport=UDP;rinstance=85c33e976be3dad1>
>> To: <sip:test-user1 at oro.sips.nl;transport=UDP>
>> From: <sip:test-user1 at oro.sips.nl;transport=UDP>;tag=6d8fd914
>> Call-ID: h6lkViFgxurpVRkw4Ly-GQ..
>> CSeq: 1 REGISTER
>> Expires: 60
>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
>> SUBSCRIBE
>> User-Agent: Z 5.4.9 rv2.10.11.7
>> Allow-Events: presence, kpml, talk
>> Content-Length: 0
>> Path: <sip:104.201.100.15;lr;received=sip:34.12.55.102:34626>
>>
>> -------------------the config -------
>> # - flags
>> #   FLT_ - per transaction (message) flags
>> # FLB_ - per branch flags
>> #!define FLT_ACC 1
>> #!define FLT_ACCMISSED 2
>> #!define FLT_ACCFAILED 3
>>
>> #!define FLT_FS 10
>>
>> ####### Global Parameters #########
>>
>> debug=4
>> log_stderror=yes
>>
>> memdbg=5
>> memlog=5
>>
>> log_facility=LOG_LOCAL0
>>
>> fork=yes
>> children=4
>>
>> /* comment the next line to enable TCP */
>> disable_tcp=yes
>>
>> /* uncomment the next line to disable the auto discovery of local aliases
>>    based on revers DNS on IPs (default on) */
>> auto_aliases=no
>>
>> /* add local domain aliases */
>> # alias="mysipserver.com"
>>
>> port=5060
>>
>> /* uncomment and configure the following line if you want Kamailio to
>>    bind on a specific interface/port/proto (default bind on all
>> available) */
>> # listen=udp:127.0.0.1:5060
>>
>> sip_warning=no
>>
>> ####### Modules Section ########
>>
>> # set module path
>> #mpath="/usr/local/lib/kamailio/modules/"
>>
>> #loadmodule "db_mysql.so"
>> loadmodule "jsonrpcs.so"
>> loadmodule "kex.so"
>> loadmodule "corex.so"
>> loadmodule "tm.so"
>> loadmodule "tmx.so"
>> loadmodule "sl.so"
>> loadmodule "rr.so"
>> loadmodule "pv.so"
>> loadmodule "maxfwd.so"
>> loadmodule "textops.so"
>> loadmodule "siputils.so"
>> loadmodule "xlog.so"
>> loadmodule "sanity.so"
>> loadmodule "ctl.so"
>> loadmodule "acc.so"
>> loadmodule "dispatcher.so"
>> loadmodule "path.so"
>>
>> # ----------------- setting module-specific parameters ---------------
>>
>>
>> # ----- jsonrpcs params -----
>> modparam("jsonrpcs", "pretty_format", 1)
>>
>>
>> # ----- rr params -----
>> # add value to ;lr param to cope with most of the UAs
>> modparam("rr", "enable_full_lr", 1)
>> # do not append from tag to the RR (no need for this script)
>> modparam("rr", "append_fromtag", 0)
>>
>>
>> # ----- acc params -----
>> modparam("acc", "log_flag", FLT_ACC)
>> modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
>> modparam("acc", "log_extra",
>> "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si")
>>
>> # ----- tm params -----
>> modparam("tm", "fr_timer", 2000)
>> modparam("tm", "fr_inv_timer", 40000)
>>
>> # ----- dispatcher params -----
>> #modparam("dispatcher", "db_url", DBURL)
>> #modparam("dispatcher", "table_name", "dispatcher")
>> modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
>> modparam("dispatcher", "flags", 2)
>> modparam("dispatcher", "xavp_dst", "_dsdst_")
>> modparam("dispatcher", "xavp_ctx", "_dsctx_")
>> modparam("dispatcher", "ds_ping_from", "sip:proxy at mykamailio")
>> modparam("dispatcher", "ds_ping_interval", 30)
>> modparam("dispatcher", "ds_probing_threshold", 10)
>> modparam("dispatcher", "ds_inactive_threshold", 5)
>> modparam("dispatcher", "ds_ping_reply_codes",
>> "class=2;code=403;code=488;class=3")
>> modparam("dispatcher", "ds_probing_mode", 1)
>>
>> modparam("path", "use_received", 1)
>>
>> ####### Routing Logic ########
>>
>>
>> # main request routing logic
>>
>> request_route {
>>
>> # per request initial checks
>> route(REQINIT);
>>
>>         if(ds_is_from_list()) {
>>        setflag(FLT_FS);
>>         }
>>
>> # CANCEL processing
>> if (is_method("CANCEL")) {
>> if (t_check_trans()) {
>> route(RELAY);
>> }
>> exit;
>> }
>>
>> # handle retransmissions
>> if (!is_method("ACK")) {
>> if(t_precheck_trans()) {
>> t_check_trans();
>> exit;
>> }
>> t_check_trans();
>> }
>>
>> # handle requests within SIP dialogs
>> route(WITHINDLG);
>>
>>         if (isflagset(FLT_FS)) {
>>                 route(FROM_FS);
>>                 exit;
>>         }
>>
>> ### only initial requests (no To tag)
>>
>> # record routing for dialog forming requests (in case they are routed)
>> # - remove preloaded route headers
>> remove_hf("Route");
>> if (is_method("INVITE|SUBSCRIBE")) {
>> record_route();
>> }
>>
>> # account only INVITEs
>> if (is_method("INVITE")) {
>> setflag(FLT_ACC); # do accounting
>> }
>>
>> # handle presence related requests
>> route(PRESENCE);
>>
>> # handle registrations
>> route(REGISTRAR);
>>
>> if ($rU==$null) {
>> # request with no Username in RURI
>> sl_send_reply("484","Address Incomplete");
>> exit;
>> }
>>
>> # dispatch destinations
>> route(DISPATCH);
>> }
>>
>> route[FROM_FS]
>> {
>>         record_route();
>>         route(RELAY);
>>         exit;
>> }
>>
>> route[RELAY] {
>> if (!t_relay()) {
>> sl_reply_error();
>> }
>> exit;
>> }
>>
>> # Per SIP request initial checks
>> route[REQINIT] {
>> if (!mf_process_maxfwd_header("10")) {
>> sl_send_reply("483","Too Many Hops");
>> exit;
>> }
>>
>> if(!sanity_check("1511", "7")) {
>> xlog("Malformed SIP message from $si:$sp\n");
>> exit;
>> }
>> }
>>
>> # Handle requests within SIP dialogs
>> route[WITHINDLG] {
>> if (has_totag()) {
>> # sequential request withing a dialog should
>> # take the path determined by record-routing
>> if (loose_route()) {
>> if (is_method("BYE")) {
>> setflag(FLT_ACC); # do accounting ...
>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>> }
>> route(RELAY);
>> } else {
>> if (is_method("SUBSCRIBE") && uri == myself) {
>> # in-dialog subscribe requests
>> route(PRESENCE);
>> exit;
>> }
>> if ( is_method("ACK") ) {
>> if ( t_check_trans() ) {
>> # non loose-route, but stateful ACK;
>> # must be ACK after a 487 or e.g. 404 from upstream server
>> t_relay();
>> exit;
>> } else {
>> # ACK without matching transaction ... ignore and discard.
>> exit;
>> }
>> }
>> sl_send_reply("404","Not here");
>> }
>> exit;
>> }
>> }
>>
>> # Handle SIP registrations
>> route[REGISTRAR] {
>> if(!is_method("REGISTER"))
>> return;
>> add_path_received();
>>         route(DISPATCH);
>> }
>>
>> # Presence server route
>> route[PRESENCE] {
>> if(!is_method("PUBLISH|SUBSCRIBE"))
>> return;
>>
>> sl_send_reply("404", "Not here");
>> exit;
>> }
>>
>> # Dispatch requests
>> route[DISPATCH] {
>> # round robin dispatching on gateways group '1'
>> switch ($fd){
>> case "oro.sips.nl":
>> send_reply(483, "Ok, Skipper!");
>> if (!ds_select_dst("1", "4")) {
>> log("ERROR: no active destinations found!\n");
>> send_reply(503, "Service Unavailable");
>> exit;
>> }
>> ds_select_dst("1", "4");
>> log("---- flag value is $dd -- branch $fd \n");
>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>> $xavp(_dsdst_=>attrs))\n");
>> break;
>> case "oro2.sips.nl":
>> send_reply(483, "Ok, Skipper!");
>> if (!ds_select_dst("2", "4")) {
>> log("ERROR: no active destinations found!\n");
>> send_reply(503, "Service Unavailable");
>> exit;
>> }
>> ds_select_dst("2", "4");
>> log("---- flag value is $dd -- branch $fd \n");
>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>> $xavp(_dsdst_=>attrs))\n");
>> break;
>> default:
>>    log("unknow destination?");
>>    send_reply(503, "No service defined");
>>    exit;
>> }
>>
>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>> $xavp(_dsdst_=>attrs))\n");
>> t_on_failure("RTF_DISPATCH");
>> route(RELAY);
>> exit;
>> }
>>
>> # Try next destionations in failure route
>> failure_route[RTF_DISPATCH] {
>> if (t_is_canceled()) {
>> exit;
>> }
>> # next DST - only for 500 or local timeout
>> if (t_check_status("500")
>> or (t_branch_timeout() and !t_branch_replied())) {
>> if(ds_next_dst()) {
>> xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs:
>> $xavp(_dsdst_=>attrs))\n");
>> t_on_failure("RTF_DISPATCH");
>> route(RELAY);
>> exit;
>> }
>> }
>> }
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/895f6ed6/attachment.htm>

From cezar at mokalife.ro  Mon Dec  7 17:09:42 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Mon, 7 Dec 2020 18:09:42 +0200
Subject: [SR-Users] Kamilio dispatcher not registering with asterisk
In-Reply-To: <CANk_n4Z4fHzVRV_YTiLqu0hESU4=nbyCW-fBZFQ9j1U1E9QLEw@mail.gmail.com>
References: <CANk_n4bJwTJ7JvnabTo+N_o9gngJ1R94rbzzSUMz4Eo2sndcrw@mail.gmail.com>
 <CALZWR5wBwKjBE2RBqFw8es0McBTttpDvoNYTif6nM0E7B8Lt3A@mail.gmail.com>
 <CANk_n4Z4fHzVRV_YTiLqu0hESU4=nbyCW-fBZFQ9j1U1E9QLEw@mail.gmail.com>
Message-ID: <CANk_n4aNJZb7bWp+hSf8XSi3On2T+5sPm41jFz+5GiExrp2gQw@mail.gmail.com>

I've added this to asterisk - sip.conf, with no luck


[proxy-trunk]
fromdomain=oro.sips.nl
host=104.201.100.15
type=friend
insecure=invite,port





On Mon, Dec 7, 2020 at 5:22 PM Mihai Cezar <cezar at mokalife.ro> wrote:

> HI sergio,
>
> I just set allow_guest = yes. I don't know what to set on the asterisk, if
> you can guide a little bit ...
>
> On Mon, Dec 7, 2020 at 5:17 PM Sergio Charrua <sergio.charrua at voip.pt>
> wrote:
>
>> Hi !
>>
>> what is the "type" of your SIP Peer, on Asterisk? Friend, Peer or User?
>> and what about the "insecure" setting?
>>
>> *S?rgio Charrua*
>>
>>
>> *www.voip.pt <http://www.voip.pt/>*
>> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>>
>> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>>
>> This message and any files or documents attached are strictly
>> confidential or otherwise legally protected.
>>
>> It is intended only for the individual or entity named. If you are not
>> the named addressee or have received this email in error, please inform the
>> sender immediately, delete it from your system and do not copy or disclose
>> it or its contents or use it for any purpose. Please also note that
>> transmission cannot be guaranteed to be secure or error-free.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 7, 2020 at 3:09 PM Mihai <m at mokalife.ro> wrote:
>>
>>> Hi all,
>>>
>>> i have a problem with kamailio 5.3.x and asterisk 13, i basically
>>> forward everything, but i cant manage to make it register.
>>>
>>> The register arrives on asterisk see the capture bellow:
>>> Any help is much appreciated!
>>> ----------------
>>> REGISTER sip:oro.sips.nl;transport=UDP SIP/2.0
>>> Via: SIP/2.0/UDP
>>> 104.201.100.15;branch=z9hG4bK4d5e.997621d931a2ad9f6423e2ac7782a319.1
>>> Via: SIP/2.0/UDP 34.12.55.102:34626
>>> ;received=34.12.55.102;branch=z9hG4bK-524287-1---0a0bffd64bbd9941;rport=34626
>>> Max-Forwards: 69
>>> Contact: <sip:test-user1 at 34.12.55.102:34626
>>> ;transport=UDP;rinstance=85c33e976be3dad1>
>>> To: <sip:test-user1 at oro.sips.nl;transport=UDP>
>>> From: <sip:test-user1 at oro.sips.nl;transport=UDP>;tag=6d8fd914
>>> Call-ID: h6lkViFgxurpVRkw4Ly-GQ..
>>> CSeq: 1 REGISTER
>>> Expires: 60
>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
>>> SUBSCRIBE
>>> User-Agent: Z 5.4.9 rv2.10.11.7
>>> Allow-Events: presence, kpml, talk
>>> Content-Length: 0
>>> Path: <sip:104.201.100.15;lr;received=sip:34.12.55.102:34626>
>>>
>>> -------------------the config -------
>>> # - flags
>>> #   FLT_ - per transaction (message) flags
>>> # FLB_ - per branch flags
>>> #!define FLT_ACC 1
>>> #!define FLT_ACCMISSED 2
>>> #!define FLT_ACCFAILED 3
>>>
>>> #!define FLT_FS 10
>>>
>>> ####### Global Parameters #########
>>>
>>> debug=4
>>> log_stderror=yes
>>>
>>> memdbg=5
>>> memlog=5
>>>
>>> log_facility=LOG_LOCAL0
>>>
>>> fork=yes
>>> children=4
>>>
>>> /* comment the next line to enable TCP */
>>> disable_tcp=yes
>>>
>>> /* uncomment the next line to disable the auto discovery of local aliases
>>>    based on revers DNS on IPs (default on) */
>>> auto_aliases=no
>>>
>>> /* add local domain aliases */
>>> # alias="mysipserver.com"
>>>
>>> port=5060
>>>
>>> /* uncomment and configure the following line if you want Kamailio to
>>>    bind on a specific interface/port/proto (default bind on all
>>> available) */
>>> # listen=udp:127.0.0.1:5060
>>>
>>> sip_warning=no
>>>
>>> ####### Modules Section ########
>>>
>>> # set module path
>>> #mpath="/usr/local/lib/kamailio/modules/"
>>>
>>> #loadmodule "db_mysql.so"
>>> loadmodule "jsonrpcs.so"
>>> loadmodule "kex.so"
>>> loadmodule "corex.so"
>>> loadmodule "tm.so"
>>> loadmodule "tmx.so"
>>> loadmodule "sl.so"
>>> loadmodule "rr.so"
>>> loadmodule "pv.so"
>>> loadmodule "maxfwd.so"
>>> loadmodule "textops.so"
>>> loadmodule "siputils.so"
>>> loadmodule "xlog.so"
>>> loadmodule "sanity.so"
>>> loadmodule "ctl.so"
>>> loadmodule "acc.so"
>>> loadmodule "dispatcher.so"
>>> loadmodule "path.so"
>>>
>>> # ----------------- setting module-specific parameters ---------------
>>>
>>>
>>> # ----- jsonrpcs params -----
>>> modparam("jsonrpcs", "pretty_format", 1)
>>>
>>>
>>> # ----- rr params -----
>>> # add value to ;lr param to cope with most of the UAs
>>> modparam("rr", "enable_full_lr", 1)
>>> # do not append from tag to the RR (no need for this script)
>>> modparam("rr", "append_fromtag", 0)
>>>
>>>
>>> # ----- acc params -----
>>> modparam("acc", "log_flag", FLT_ACC)
>>> modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
>>> modparam("acc", "log_extra",
>>> "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si")
>>>
>>> # ----- tm params -----
>>> modparam("tm", "fr_timer", 2000)
>>> modparam("tm", "fr_inv_timer", 40000)
>>>
>>> # ----- dispatcher params -----
>>> #modparam("dispatcher", "db_url", DBURL)
>>> #modparam("dispatcher", "table_name", "dispatcher")
>>> modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
>>> modparam("dispatcher", "flags", 2)
>>> modparam("dispatcher", "xavp_dst", "_dsdst_")
>>> modparam("dispatcher", "xavp_ctx", "_dsctx_")
>>> modparam("dispatcher", "ds_ping_from", "sip:proxy at mykamailio")
>>> modparam("dispatcher", "ds_ping_interval", 30)
>>> modparam("dispatcher", "ds_probing_threshold", 10)
>>> modparam("dispatcher", "ds_inactive_threshold", 5)
>>> modparam("dispatcher", "ds_ping_reply_codes",
>>> "class=2;code=403;code=488;class=3")
>>> modparam("dispatcher", "ds_probing_mode", 1)
>>>
>>> modparam("path", "use_received", 1)
>>>
>>> ####### Routing Logic ########
>>>
>>>
>>> # main request routing logic
>>>
>>> request_route {
>>>
>>> # per request initial checks
>>> route(REQINIT);
>>>
>>>         if(ds_is_from_list()) {
>>>        setflag(FLT_FS);
>>>         }
>>>
>>> # CANCEL processing
>>> if (is_method("CANCEL")) {
>>> if (t_check_trans()) {
>>> route(RELAY);
>>> }
>>> exit;
>>> }
>>>
>>> # handle retransmissions
>>> if (!is_method("ACK")) {
>>> if(t_precheck_trans()) {
>>> t_check_trans();
>>> exit;
>>> }
>>> t_check_trans();
>>> }
>>>
>>> # handle requests within SIP dialogs
>>> route(WITHINDLG);
>>>
>>>         if (isflagset(FLT_FS)) {
>>>                 route(FROM_FS);
>>>                 exit;
>>>         }
>>>
>>> ### only initial requests (no To tag)
>>>
>>> # record routing for dialog forming requests (in case they are routed)
>>> # - remove preloaded route headers
>>> remove_hf("Route");
>>> if (is_method("INVITE|SUBSCRIBE")) {
>>> record_route();
>>> }
>>>
>>> # account only INVITEs
>>> if (is_method("INVITE")) {
>>> setflag(FLT_ACC); # do accounting
>>> }
>>>
>>> # handle presence related requests
>>> route(PRESENCE);
>>>
>>> # handle registrations
>>> route(REGISTRAR);
>>>
>>> if ($rU==$null) {
>>> # request with no Username in RURI
>>> sl_send_reply("484","Address Incomplete");
>>> exit;
>>> }
>>>
>>> # dispatch destinations
>>> route(DISPATCH);
>>> }
>>>
>>> route[FROM_FS]
>>> {
>>>         record_route();
>>>         route(RELAY);
>>>         exit;
>>> }
>>>
>>> route[RELAY] {
>>> if (!t_relay()) {
>>> sl_reply_error();
>>> }
>>> exit;
>>> }
>>>
>>> # Per SIP request initial checks
>>> route[REQINIT] {
>>> if (!mf_process_maxfwd_header("10")) {
>>> sl_send_reply("483","Too Many Hops");
>>> exit;
>>> }
>>>
>>> if(!sanity_check("1511", "7")) {
>>> xlog("Malformed SIP message from $si:$sp\n");
>>> exit;
>>> }
>>> }
>>>
>>> # Handle requests within SIP dialogs
>>> route[WITHINDLG] {
>>> if (has_totag()) {
>>> # sequential request withing a dialog should
>>> # take the path determined by record-routing
>>> if (loose_route()) {
>>> if (is_method("BYE")) {
>>> setflag(FLT_ACC); # do accounting ...
>>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>>> }
>>> route(RELAY);
>>> } else {
>>> if (is_method("SUBSCRIBE") && uri == myself) {
>>> # in-dialog subscribe requests
>>> route(PRESENCE);
>>> exit;
>>> }
>>> if ( is_method("ACK") ) {
>>> if ( t_check_trans() ) {
>>> # non loose-route, but stateful ACK;
>>> # must be ACK after a 487 or e.g. 404 from upstream server
>>> t_relay();
>>> exit;
>>> } else {
>>> # ACK without matching transaction ... ignore and discard.
>>> exit;
>>> }
>>> }
>>> sl_send_reply("404","Not here");
>>> }
>>> exit;
>>> }
>>> }
>>>
>>> # Handle SIP registrations
>>> route[REGISTRAR] {
>>> if(!is_method("REGISTER"))
>>> return;
>>> add_path_received();
>>>         route(DISPATCH);
>>> }
>>>
>>> # Presence server route
>>> route[PRESENCE] {
>>> if(!is_method("PUBLISH|SUBSCRIBE"))
>>> return;
>>>
>>> sl_send_reply("404", "Not here");
>>> exit;
>>> }
>>>
>>> # Dispatch requests
>>> route[DISPATCH] {
>>> # round robin dispatching on gateways group '1'
>>> switch ($fd){
>>> case "oro.sips.nl":
>>> send_reply(483, "Ok, Skipper!");
>>> if (!ds_select_dst("1", "4")) {
>>> log("ERROR: no active destinations found!\n");
>>> send_reply(503, "Service Unavailable");
>>> exit;
>>> }
>>> ds_select_dst("1", "4");
>>> log("---- flag value is $dd -- branch $fd \n");
>>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>>> $xavp(_dsdst_=>attrs))\n");
>>> break;
>>> case "oro2.sips.nl":
>>> send_reply(483, "Ok, Skipper!");
>>> if (!ds_select_dst("2", "4")) {
>>> log("ERROR: no active destinations found!\n");
>>> send_reply(503, "Service Unavailable");
>>> exit;
>>> }
>>> ds_select_dst("2", "4");
>>> log("---- flag value is $dd -- branch $fd \n");
>>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>>> $xavp(_dsdst_=>attrs))\n");
>>> break;
>>> default:
>>>    log("unknow destination?");
>>>    send_reply(503, "No service defined");
>>>    exit;
>>> }
>>>
>>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>>> $xavp(_dsdst_=>attrs))\n");
>>> t_on_failure("RTF_DISPATCH");
>>> route(RELAY);
>>> exit;
>>> }
>>>
>>> # Try next destionations in failure route
>>> failure_route[RTF_DISPATCH] {
>>> if (t_is_canceled()) {
>>> exit;
>>> }
>>> # next DST - only for 500 or local timeout
>>> if (t_check_status("500")
>>> or (t_branch_timeout() and !t_branch_replied())) {
>>> if(ds_next_dst()) {
>>> xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs:
>>> $xavp(_dsdst_=>attrs))\n");
>>> t_on_failure("RTF_DISPATCH");
>>> route(RELAY);
>>> exit;
>>> }
>>> }
>>> }
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/3c24b217/attachment.htm>

From sergio.charrua at voip.pt  Mon Dec  7 18:40:44 2020
From: sergio.charrua at voip.pt (Sergio Charrua)
Date: Mon, 7 Dec 2020 17:40:44 +0000
Subject: [SR-Users] Kamilio dispatcher not registering with asterisk
In-Reply-To: <CANk_n4aNJZb7bWp+hSf8XSi3On2T+5sPm41jFz+5GiExrp2gQw@mail.gmail.com>
References: <CANk_n4bJwTJ7JvnabTo+N_o9gngJ1R94rbzzSUMz4Eo2sndcrw@mail.gmail.com>
 <CALZWR5wBwKjBE2RBqFw8es0McBTttpDvoNYTif6nM0E7B8Lt3A@mail.gmail.com>
 <CANk_n4Z4fHzVRV_YTiLqu0hESU4=nbyCW-fBZFQ9j1U1E9QLEw@mail.gmail.com>
 <CANk_n4aNJZb7bWp+hSf8XSi3On2T+5sPm41jFz+5GiExrp2gQw@mail.gmail.com>
Message-ID: <CALZWR5yRHjyDekFgW+3ciP3+n1PxgL9uz08J_-N8fDSuH9ftXQ@mail.gmail.com>

allow_guest=yes is a security risk. Basically you're telling Asterisk to
allow everyone to register and call everybody to all your routes. If your
Asterisk box is open directly to the outside world, it will be perfect for
scammers to make international calls and your bill will go sky-high!

from your last mail, you're trying to accept registers from a proxy trunk.
Is that your Kamailio server? i will assume it is.
Then try this :

[proxy-trunk]
host=104.201.100.15
type=friend
nat=force_rport,comedia
insecure=port,invite
port=5060
qualify=yes
disallow=all
allow=all
context=[your context where calls coming from proxy-trunk go and get
processed]
canreinvite=no
directmedia=no

Set NAT and DIRECTMEDIA as required. Usually CANREINVITE is not supported
by proxy servers, so it is turned off in this example

Also, Kamailio does not register into Asterisk. At best, Asterisk will
recognise Kamailio and allow calls and SIP messages (like REGISTER from a
peer).
In that case, try to set your SIP peers configuration as:
host=dynamic
type=friend
insecure=invite,port

and set the NAT and DIRECTMEDIA as needed.

Hope this helps.

*S?rgio Charrua*


*www.voip.pt <http://www.voip.pt/>*
Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77

Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Mon, Dec 7, 2020 at 4:14 PM Mihai Cezar <cezar at mokalife.ro> wrote:

> I've added this to asterisk - sip.conf, with no luck
>
>
> [proxy-trunk]
> fromdomain=oro.sips.nl
> host=104.201.100.15
> type=friend
> insecure=invite,port
>
>
>
>
>
> On Mon, Dec 7, 2020 at 5:22 PM Mihai Cezar <cezar at mokalife.ro> wrote:
>
>> HI sergio,
>>
>> I just set allow_guest = yes. I don't know what to set on the asterisk,
>> if you can guide a little bit ...
>>
>> On Mon, Dec 7, 2020 at 5:17 PM Sergio Charrua <sergio.charrua at voip.pt>
>> wrote:
>>
>>> Hi !
>>>
>>> what is the "type" of your SIP Peer, on Asterisk? Friend, Peer or User?
>>> and what about the "insecure" setting?
>>>
>>> *S?rgio Charrua*
>>>
>>>
>>> *www.voip.pt <http://www.voip.pt/>*
>>> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>>>
>>> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>>>
>>> This message and any files or documents attached are strictly
>>> confidential or otherwise legally protected.
>>>
>>> It is intended only for the individual or entity named. If you are not
>>> the named addressee or have received this email in error, please inform the
>>> sender immediately, delete it from your system and do not copy or disclose
>>> it or its contents or use it for any purpose. Please also note that
>>> transmission cannot be guaranteed to be secure or error-free.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Dec 7, 2020 at 3:09 PM Mihai <m at mokalife.ro> wrote:
>>>
>>>> Hi all,
>>>>
>>>> i have a problem with kamailio 5.3.x and asterisk 13, i basically
>>>> forward everything, but i cant manage to make it register.
>>>>
>>>> The register arrives on asterisk see the capture bellow:
>>>> Any help is much appreciated!
>>>> ----------------
>>>> REGISTER sip:oro.sips.nl;transport=UDP SIP/2.0
>>>> Via: SIP/2.0/UDP
>>>> 104.201.100.15;branch=z9hG4bK4d5e.997621d931a2ad9f6423e2ac7782a319.1
>>>> Via: SIP/2.0/UDP 34.12.55.102:34626
>>>> ;received=34.12.55.102;branch=z9hG4bK-524287-1---0a0bffd64bbd9941;rport=34626
>>>> Max-Forwards: 69
>>>> Contact: <sip:test-user1 at 34.12.55.102:34626
>>>> ;transport=UDP;rinstance=85c33e976be3dad1>
>>>> To: <sip:test-user1 at oro.sips.nl;transport=UDP>
>>>> From: <sip:test-user1 at oro.sips.nl;transport=UDP>;tag=6d8fd914
>>>> Call-ID: h6lkViFgxurpVRkw4Ly-GQ..
>>>> CSeq: 1 REGISTER
>>>> Expires: 60
>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
>>>> SUBSCRIBE
>>>> User-Agent: Z 5.4.9 rv2.10.11.7
>>>> Allow-Events: presence, kpml, talk
>>>> Content-Length: 0
>>>> Path: <sip:104.201.100.15;lr;received=sip:34.12.55.102:34626>
>>>>
>>>> -------------------the config -------
>>>> # - flags
>>>> #   FLT_ - per transaction (message) flags
>>>> # FLB_ - per branch flags
>>>> #!define FLT_ACC 1
>>>> #!define FLT_ACCMISSED 2
>>>> #!define FLT_ACCFAILED 3
>>>>
>>>> #!define FLT_FS 10
>>>>
>>>> ####### Global Parameters #########
>>>>
>>>> debug=4
>>>> log_stderror=yes
>>>>
>>>> memdbg=5
>>>> memlog=5
>>>>
>>>> log_facility=LOG_LOCAL0
>>>>
>>>> fork=yes
>>>> children=4
>>>>
>>>> /* comment the next line to enable TCP */
>>>> disable_tcp=yes
>>>>
>>>> /* uncomment the next line to disable the auto discovery of local
>>>> aliases
>>>>    based on revers DNS on IPs (default on) */
>>>> auto_aliases=no
>>>>
>>>> /* add local domain aliases */
>>>> # alias="mysipserver.com"
>>>>
>>>> port=5060
>>>>
>>>> /* uncomment and configure the following line if you want Kamailio to
>>>>    bind on a specific interface/port/proto (default bind on all
>>>> available) */
>>>> # listen=udp:127.0.0.1:5060
>>>>
>>>> sip_warning=no
>>>>
>>>> ####### Modules Section ########
>>>>
>>>> # set module path
>>>> #mpath="/usr/local/lib/kamailio/modules/"
>>>>
>>>> #loadmodule "db_mysql.so"
>>>> loadmodule "jsonrpcs.so"
>>>> loadmodule "kex.so"
>>>> loadmodule "corex.so"
>>>> loadmodule "tm.so"
>>>> loadmodule "tmx.so"
>>>> loadmodule "sl.so"
>>>> loadmodule "rr.so"
>>>> loadmodule "pv.so"
>>>> loadmodule "maxfwd.so"
>>>> loadmodule "textops.so"
>>>> loadmodule "siputils.so"
>>>> loadmodule "xlog.so"
>>>> loadmodule "sanity.so"
>>>> loadmodule "ctl.so"
>>>> loadmodule "acc.so"
>>>> loadmodule "dispatcher.so"
>>>> loadmodule "path.so"
>>>>
>>>> # ----------------- setting module-specific parameters ---------------
>>>>
>>>>
>>>> # ----- jsonrpcs params -----
>>>> modparam("jsonrpcs", "pretty_format", 1)
>>>>
>>>>
>>>> # ----- rr params -----
>>>> # add value to ;lr param to cope with most of the UAs
>>>> modparam("rr", "enable_full_lr", 1)
>>>> # do not append from tag to the RR (no need for this script)
>>>> modparam("rr", "append_fromtag", 0)
>>>>
>>>>
>>>> # ----- acc params -----
>>>> modparam("acc", "log_flag", FLT_ACC)
>>>> modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
>>>> modparam("acc", "log_extra",
>>>> "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si")
>>>>
>>>> # ----- tm params -----
>>>> modparam("tm", "fr_timer", 2000)
>>>> modparam("tm", "fr_inv_timer", 40000)
>>>>
>>>> # ----- dispatcher params -----
>>>> #modparam("dispatcher", "db_url", DBURL)
>>>> #modparam("dispatcher", "table_name", "dispatcher")
>>>> modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
>>>> modparam("dispatcher", "flags", 2)
>>>> modparam("dispatcher", "xavp_dst", "_dsdst_")
>>>> modparam("dispatcher", "xavp_ctx", "_dsctx_")
>>>> modparam("dispatcher", "ds_ping_from", "sip:proxy at mykamailio")
>>>> modparam("dispatcher", "ds_ping_interval", 30)
>>>> modparam("dispatcher", "ds_probing_threshold", 10)
>>>> modparam("dispatcher", "ds_inactive_threshold", 5)
>>>> modparam("dispatcher", "ds_ping_reply_codes",
>>>> "class=2;code=403;code=488;class=3")
>>>> modparam("dispatcher", "ds_probing_mode", 1)
>>>>
>>>> modparam("path", "use_received", 1)
>>>>
>>>> ####### Routing Logic ########
>>>>
>>>>
>>>> # main request routing logic
>>>>
>>>> request_route {
>>>>
>>>> # per request initial checks
>>>> route(REQINIT);
>>>>
>>>>         if(ds_is_from_list()) {
>>>>        setflag(FLT_FS);
>>>>         }
>>>>
>>>> # CANCEL processing
>>>> if (is_method("CANCEL")) {
>>>> if (t_check_trans()) {
>>>> route(RELAY);
>>>> }
>>>> exit;
>>>> }
>>>>
>>>> # handle retransmissions
>>>> if (!is_method("ACK")) {
>>>> if(t_precheck_trans()) {
>>>> t_check_trans();
>>>> exit;
>>>> }
>>>> t_check_trans();
>>>> }
>>>>
>>>> # handle requests within SIP dialogs
>>>> route(WITHINDLG);
>>>>
>>>>         if (isflagset(FLT_FS)) {
>>>>                 route(FROM_FS);
>>>>                 exit;
>>>>         }
>>>>
>>>> ### only initial requests (no To tag)
>>>>
>>>> # record routing for dialog forming requests (in case they are routed)
>>>> # - remove preloaded route headers
>>>> remove_hf("Route");
>>>> if (is_method("INVITE|SUBSCRIBE")) {
>>>> record_route();
>>>> }
>>>>
>>>> # account only INVITEs
>>>> if (is_method("INVITE")) {
>>>> setflag(FLT_ACC); # do accounting
>>>> }
>>>>
>>>> # handle presence related requests
>>>> route(PRESENCE);
>>>>
>>>> # handle registrations
>>>> route(REGISTRAR);
>>>>
>>>> if ($rU==$null) {
>>>> # request with no Username in RURI
>>>> sl_send_reply("484","Address Incomplete");
>>>> exit;
>>>> }
>>>>
>>>> # dispatch destinations
>>>> route(DISPATCH);
>>>> }
>>>>
>>>> route[FROM_FS]
>>>> {
>>>>         record_route();
>>>>         route(RELAY);
>>>>         exit;
>>>> }
>>>>
>>>> route[RELAY] {
>>>> if (!t_relay()) {
>>>> sl_reply_error();
>>>> }
>>>> exit;
>>>> }
>>>>
>>>> # Per SIP request initial checks
>>>> route[REQINIT] {
>>>> if (!mf_process_maxfwd_header("10")) {
>>>> sl_send_reply("483","Too Many Hops");
>>>> exit;
>>>> }
>>>>
>>>> if(!sanity_check("1511", "7")) {
>>>> xlog("Malformed SIP message from $si:$sp\n");
>>>> exit;
>>>> }
>>>> }
>>>>
>>>> # Handle requests within SIP dialogs
>>>> route[WITHINDLG] {
>>>> if (has_totag()) {
>>>> # sequential request withing a dialog should
>>>> # take the path determined by record-routing
>>>> if (loose_route()) {
>>>> if (is_method("BYE")) {
>>>> setflag(FLT_ACC); # do accounting ...
>>>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>>>> }
>>>> route(RELAY);
>>>> } else {
>>>> if (is_method("SUBSCRIBE") && uri == myself) {
>>>> # in-dialog subscribe requests
>>>> route(PRESENCE);
>>>> exit;
>>>> }
>>>> if ( is_method("ACK") ) {
>>>> if ( t_check_trans() ) {
>>>> # non loose-route, but stateful ACK;
>>>> # must be ACK after a 487 or e.g. 404 from upstream server
>>>> t_relay();
>>>> exit;
>>>> } else {
>>>> # ACK without matching transaction ... ignore and discard.
>>>> exit;
>>>> }
>>>> }
>>>> sl_send_reply("404","Not here");
>>>> }
>>>> exit;
>>>> }
>>>> }
>>>>
>>>> # Handle SIP registrations
>>>> route[REGISTRAR] {
>>>> if(!is_method("REGISTER"))
>>>> return;
>>>> add_path_received();
>>>>         route(DISPATCH);
>>>> }
>>>>
>>>> # Presence server route
>>>> route[PRESENCE] {
>>>> if(!is_method("PUBLISH|SUBSCRIBE"))
>>>> return;
>>>>
>>>> sl_send_reply("404", "Not here");
>>>> exit;
>>>> }
>>>>
>>>> # Dispatch requests
>>>> route[DISPATCH] {
>>>> # round robin dispatching on gateways group '1'
>>>> switch ($fd){
>>>> case "oro.sips.nl":
>>>> send_reply(483, "Ok, Skipper!");
>>>> if (!ds_select_dst("1", "4")) {
>>>> log("ERROR: no active destinations found!\n");
>>>> send_reply(503, "Service Unavailable");
>>>> exit;
>>>> }
>>>> ds_select_dst("1", "4");
>>>> log("---- flag value is $dd -- branch $fd \n");
>>>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>>>> $xavp(_dsdst_=>attrs))\n");
>>>> break;
>>>> case "oro2.sips.nl":
>>>> send_reply(483, "Ok, Skipper!");
>>>> if (!ds_select_dst("2", "4")) {
>>>> log("ERROR: no active destinations found!\n");
>>>> send_reply(503, "Service Unavailable");
>>>> exit;
>>>> }
>>>> ds_select_dst("2", "4");
>>>> log("---- flag value is $dd -- branch $fd \n");
>>>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>>>> $xavp(_dsdst_=>attrs))\n");
>>>> break;
>>>> default:
>>>>    log("unknow destination?");
>>>>    send_reply(503, "No service defined");
>>>>    exit;
>>>> }
>>>>
>>>> xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
>>>> $xavp(_dsdst_=>attrs))\n");
>>>> t_on_failure("RTF_DISPATCH");
>>>> route(RELAY);
>>>> exit;
>>>> }
>>>>
>>>> # Try next destionations in failure route
>>>> failure_route[RTF_DISPATCH] {
>>>> if (t_is_canceled()) {
>>>> exit;
>>>> }
>>>> # next DST - only for 500 or local timeout
>>>> if (t_check_status("500")
>>>> or (t_branch_timeout() and !t_branch_replied())) {
>>>> if(ds_next_dst()) {
>>>> xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs:
>>>> $xavp(_dsdst_=>attrs))\n");
>>>> t_on_failure("RTF_DISPATCH");
>>>> route(RELAY);
>>>> exit;
>>>> }
>>>> }
>>>> }
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/4ce79744/attachment.htm>

From hamid2kviii at hotmail.com  Mon Dec  7 21:09:47 2020
From: hamid2kviii at hotmail.com (Hamid Hashmi)
Date: Mon, 7 Dec 2020 20:09:47 +0000
Subject: [SR-Users] kamailio-5.2.0 Crash - udp_send failed
In-Reply-To: <180037fb-1d5d-6522-c372-5b029fda8f86@gmail.com>
References: <PU1PR03MB2908EE0F77AD2172A76CB369E0360@PU1PR03MB2908.apcprd03.prod.outlook.com>
 <AM0PR05MB659564ECE4CC900C49BB7B26C5370@AM0PR05MB6595.eurprd05.prod.outlook.com>
 <PU1PR03MB2908CED08A344DAA6099A583E0CF0@PU1PR03MB2908.apcprd03.prod.outlook.com>,
 <180037fb-1d5d-6522-c372-5b029fda8f86@gmail.com>
Message-ID: <PU1PR03MB29088FD756709F883B2CE789E0CE0@PU1PR03MB2908.apcprd03.prod.outlook.com>

Service is crashing from time to time and it crashed 13 times today. Please find the bt full traces below

Sig 11:

(gdb) bt full
#0  0x00000000006a16fc in timer_list_expire (t=1339518316, h=0x7facee484fd0, slow_l=0x7facee488208, slow_mark=7936) at core/timer.c:846
        tl = 0x7facf048e1b8
        ret = 0
#1  0x00000000006a1c19 in timer_handler () at core/timer.c:922
        saved_ticks = 1339518316
        run_slow_timer = 0
        i = 768
        __FUNCTION__ = "timer_handler"
#2  0x00000000006a20ba in timer_main () at core/timer.c:961
No locals.
#3  0x000000000042ac0a in main_loop () at main.c:1753
        i = 32
        pid = 0
        si = 0x0
        si_desc = "udp receiver child=31 sock=10.161.224.211:5060", '\000' <repeats 11 times>, "\354\325K\346\060\375\350\003\000\000\000\314\000\000\000\365k\000\000\000\000\000\000P\272A\000\000\000\000\000P\343o%\374\177", '\000' <repeats 18 times>, "\320\335o%\374\177\000\000\215\006Z\000\000\000\000"
        nrprocs = 32
        woneinit = 1
        __FUNCTION__ = "main_loop"
#4  0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at main.c:2856
        cfg_stream = 0x2674010
        c = -1
        r = 0
        tmp = 0x7ffc256fff2c ""
        tmp_len = 32685
        port = -1767840736
        proto = 32685
        ahost = 0x0
        aport = 0
        options = 0x7e2058 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
        ret = -1
        seed = 1101782887
        rfd = 4
        debug_save = 0
        debug_flag = 0
        dont_fork_cnt = 0
        n_lst = 0x7fad96a1d5f7
        p = 0x7fad96a0e77c "free"
        st = {st_dev = 17, st_ino = 15237, st_nlink = 2, st_mode = 16877, st_uid = 105, st_gid = 112, __pad0 = 0, st_rdev = 0, st_size = 120, st_blksize = 4096, st_blocks = 0, st_atim = {
            tv_sec = 1607000056, tv_nsec = 100000000}, st_mtim = {tv_sec = 1607002632, tv_nsec = 716000000}, st_ctim = {tv_sec = 1607003887, tv_nsec = 44000000}, __glibc_reserved = {0, 0, 0}}
        tbuf = "\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\210'?\255\177\000\000\030\207\241\226\255\177\000\000\000\000\000\000\000\000\000\000\220\340o%\374\177\000\000`\261w%\374\177\000\000\240\341o%\374\177\000\000?w%\374\177\000\000\220\341o%\374\177\000\000\000\000\000\000\000\000\000\000<\177\241\226\255\177\000\000\000\000\000\000\000\000\000\000.N=\366\000\000\000\000\004\000\000\000\000\000\000\000\006\000\000\000\000\000\000\000\250u\302\226\255\177\000\000\266\210\241\226\255\177", '\000' <repeats 11 times>, "\341o%\374\177\000\000\060=\362\225\255\177\000\000\020\342o%\374\177\000\000\370\001\363\225\255\177\000\000\070\365\330\003\000\000\000\000\000\342o%\374\177\000\000\350*?"...
        option_index = 0
        long_options = {{name = 0x7e424f "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x7df854 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x7e4254 "alias", has_arg = 1,
            flag = 0x0, val = 1024}, {name = 0x7e425a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7e4260 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {
            name = 0x7e4269 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7e4273 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7e427d "loadmodule", has_arg = 1,
            flag = 0x0, val = 1029}, {name = 0x7e4288 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7e4291 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {
            name = 0x7e429c "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
        __FUNCTION__ = "main"
(gdb)

Sig 6:


(gdb) bt full
#0  0x00007fad95f56c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fad95f5a028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x000000000041e39d in sig_alarm_abort (signo=14) at main.c:687
        __FUNCTION__ = "sig_alarm_abort"
#3  <signal handler called>
No symbol table info available.
#4  0x00007fad960183c7 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x00007fad6f5c024b in futex_get (lock=0x7facee70baa0) at ../../core/mem/../futexlock.h:121
        v = 1
        i = 0
#6  0x00007fad6f5c2167 in get_peer_by_fqdn (fqdn=0x7faceeb377b0) at peermanager.c:240
        i = 0x7f4d8a
#7  0x00007fad6f5e6c31 in get_first_connected_route (cdp_session=0x7faceeb37768, r=0x7facee70a220, app_id=16777236, vendor_id=10415) at routing.c:110
        peers = {0x7facee9f4870, 0x18, 0x1, 0x0, 0x102ef763ea8, 0xc, 0x0, 0x11b00000000, 0x0, 0x7facef617fb0, 0x7facf0a3f2d0, 0x7facef2b5f90, 0x8, 0x7facee407000, 0x7ffc256fd0d0,
          0x7ffc256fd0dc, 0x3007df3d8, 0x7fad6f617680, 0x41b610 <syslog at plt>, 0x7f4d8a}
        peer_count = 0
        prev_metric = 0
        i = 0x1007f4d8a
        p = 0x7ffc256fcff0
        j = 628084656
        least_recent_time = 7234707
        time_spec = {tv_sec = 140382874676976, tv_nsec = 1569531277302}
        __FUNCTION__ = "get_first_connected_route"
#8  0x00007fad6f5ea8b2 in get_routing_peer (cdp_session=0x7faceeb37768, m=0x7facef617fb0) at routing.c:272
        destination_realm = {s = 0x7facef6d38f0 "isbvpcrf001.zte.com", len = 19}
        destination_host = {s = 0x0, len = 0}
        avp = 0x7facef2b5f90
        avp_vendor = 0x0
        avp2 = 0x0
        group = {head = 0x0, tail = 0x0}
        p = 0x0
        rr = 0x0
        app_id = 16777236
        vendor_id = 10415
        __FUNCTION__ = "get_routing_peer"
#9  0x00007fad6f5ac72d in AAASendMessage (message=0x7facef617fb0, callback_f=0x0, callback_param=0x0) at diameter_comm.c:137
        cdp_session = 0x7faceeb37768
        p = 0x7facef7fdce0
        __FUNCTION__ = "AAASendMessage"
#10 0x00007fad6ef05dbb in rx_send_str (rx_session_id=0x7facf0849d50) at rx_str.c:157
        __FUNCTION__ = "rx_send_str"
        auth = 0x7faceeb37768
        str = 0x7facef617fb0
        avp = 0x7facef2b5f90
        x = "\000\000\000\001"
#11 0x00007fad6eeb25c4 in callback_dialog (dlg=0x7facf0036d70, type=8192, params=0x7fad72b2a1c0 <params>) at ims_qos_mod.c:453
        msg = 0x0
        parsed_cseq = 0x7facee4406c8
        rx_session_id = 0x7facf0849d50
---Type <return> to continue, or q <return> to quit---
        auth = 0x0
        p_session_data = 0x0
        current_fd = 0x0
        new_fd = 0x0
        current_has_video = 0
        new_has_video = 0
        must_unlock_aaa = 1
        __FUNCTION__ = "callback_dialog"
#12 0x00007fad728973af in run_dlg_callbacks (type=8192, dlg=0x7facf0036d70, req=0x0, rpl=0x0, dir=0, dlg_data=0x0) at dlg_cb.c:274
        cb = 0x7facf0849e68
        __FUNCTION__ = "run_dlg_callbacks"
#13 0x00007fad728d5315 in destroy_dlg (dlg=0x7facf0036d70) at dlg_hash.c:219
        ret = 0
        var = 0x7faceea76348
        __FUNCTION__ = "destroy_dlg"
#14 0x00007fad728d5b1b in destroy_dlg_table () at dlg_hash.c:291
        dlg = 0x0
        l_dlg = 0x7facf0036d70
        i = 120
        __FUNCTION__ = "destroy_dlg_table"
#15 0x00007fad7290b71e in mod_destroy () at ims_dialog.c:627
No locals.
#16 0x0000000000616ae1 in destroy_modules () at core/sr_module.c:746
        t = 0x7fad75fcae18
        foo = 0x7fad75fca710
        __FUNCTION__ = "destroy_modules"
#17 0x000000000041ce17 in cleanup (show_status=1) at main.c:563
        memlog = 0
        __FUNCTION__ = "cleanup"
#18 0x000000000041e6ef in shutdown_children (sig=15, show_status=1) at main.c:706
        __FUNCTION__ = "shutdown_children"
#19 0x0000000000421755 in handle_sigs () at main.c:806
        chld = 0
        chld_status = 139
        any_chld_stopped = 1
        memlog = 0
        __FUNCTION__ = "handle_sigs"
#20 0x000000000042bc85 in main_loop () at main.c:1817
        i = 32
        pid = 27887
        si = 0x0
        si_desc = "udp receiver child=31 sock=10.161.224.211:5060", '\000' <repeats 11 times>, "\354\325K\346\060\375\350\003\000\000\000\314\000\000\000\365k\000\000\000\000\000\000P\272A\000\000\000\000\000P\343o%\374\177", '\000' <repeats 18 times>, "\320\335o%\374\177\000\000\215\006Z\000\000\000\000"
        nrprocs = 32
        woneinit = 1
        __FUNCTION__ = "main_loop"
#21 0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at main.c:2856
        cfg_stream = 0x2674010
        c = -1
        r = 0
        tmp = 0x7ffc256fff2c ""
        tmp_len = 32685
---Type <return> to continue, or q <return> to quit---
        port = -1767840736
        proto = 32685
        ahost = 0x0
        aport = 0
        options = 0x7e2058 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
        ret = -1
        seed = 1101782887
        rfd = 4
        debug_save = 0
        debug_flag = 0
        dont_fork_cnt = 0
        n_lst = 0x7fad96a1d5f7
        p = 0x7fad96a0e77c "free"
        st = {st_dev = 17, st_ino = 15237, st_nlink = 2, st_mode = 16877, st_uid = 105, st_gid = 112, __pad0 = 0, st_rdev = 0, st_size = 120, st_blksize = 4096, st_blocks = 0, st_atim = {
            tv_sec = 1607000056, tv_nsec = 100000000}, st_mtim = {tv_sec = 1607002632, tv_nsec = 716000000}, st_ctim = {tv_sec = 1607003887, tv_nsec = 44000000}, __glibc_reserved = {0, 0, 0}}
        tbuf = "\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\210'?\255\177\000\000\030\207\241\226\255\177\000\000\000\000\000\000\000\000\000\000\220\340o%\374\177\000\000`\261w%\374\177\000\000\240\341o%\374\177\000\000?w%\374\177\000\000\220\341o%\374\177\000\000\000\000\000\000\000\000\000\000<\177\241\226\255\177\000\000\000\000\000\000\000\000\000\000.N=\366\000\000\000\000\004\000\000\000\000\000\000\000\006\000\000\000\000\000\000\000\250u\302\226\255\177\000\000\266\210\241\226\255\177", '\000' <repeats 11 times>, "\341o%\374\177\000\000\060=\362\225\255\177\000\000\020\342o%\374\177\000\000\370\001\363\225\255\177\000\000\070\365\330\003\000\000\000\000\000\342o%\374\177\000\000\350*?"...
        option_index = 0
        long_options = {{name = 0x7e424f "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x7df854 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x7e4254 "alias", has_arg = 1,
            flag = 0x0, val = 1024}, {name = 0x7e425a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7e4260 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {
            name = 0x7e4269 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7e4273 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7e427d "loadmodule", has_arg = 1,
            flag = 0x0, val = 1029}, {name = 0x7e4288 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7e4291 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {
            name = 0x7e429c "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
        __FUNCTION__ = "main"
(gdb)

I observed that service crash on Signal 11 and when service starts again it immediately crashes on Sig 6. After that service remains up for some time. Moreover, there are many following errors of udp_send_failed and tcp_read error.


#0  0x00007f668aa94013 in recvfrom () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00000000006638d0 in udp_rcv_loop () at core/udp_server.c:460
        len = 638
        buf = "SUBSCRIBE tel:+923492324215 SIP/2.0\r\nFrom: <tel:+923492324215>;tag=2869510412\r\nTo: <tel:+923492324215>\r\nCSeq: 722026762 SUBSCRIBE\r\nCall-ID: 2869510410_3596082716 at 10.100.217.241\r\nVia: SIP/2.0/UDP 10.100"...
        tmp = 0xdf831260 <error: Cannot access memory at address 0xdf831260>
        from = 0x7f666ac86e78
        fromlen = 16

and


#0  0x00007f668aa94013 in recvfrom () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00000000006638d0 in udp_rcv_loop () at core/udp_server.c:460
        len = 952
        buf = "REGISTER sip:ims.mnc006.mcc410.3gppnetwork.org SIP/2.0\r\nVia: SIP/2.0/UDP 10.100.213.50;rport;branch=z9hG4bKL60mek0i6jXu6V\r\nFrom: <sip:410060265715793 at ims.mnc006.mcc410.3gppnetwork.org>;tag=jYbVBQiAfL1"...
        tmp = 0xdf831260 <error: Cannot access memory at address 0xdf831260>
        from = 0x7f666ac86e78
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {140072621270026, 140723275665552}, addr32 = {852845578, 32613, 2967179408, 32764}, addr16 = {25610, 13013, 32613,
                0, 37008, 45275, 32764, 0}, addr = "\nd\325\062e\177\000\000\220\220?\374\177\000"}}, dst_ip = {af = 2, len = 4, u = {addrl = {3839926538, 0},
              addr32 = {3839926538, 0, 0, 0}, addr16 = {41226, 58592, 0, 0, 0, 0, 0, 0}, addr = "\n\241\340\344", '\000' <repeats 11 times>}}, src_port = 5060,
          dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\023\304\nd\325\062\000\000\000\000\000\000\000"}, sin = {
              sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 852845578}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195,
              sin6_flowinfo = 852845578, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0,
                    0}}}, sin6_scope_id = 0}}, bind_address = 0x7f666aa23d78, proto = 1 '\001'}
        evp = {data = 0x0, rcv = 0x0, dst = 0x0}
        printbuf = "P\221?\374\177\000\000\005\364<\337e\177\000\000 \221?\374\177\000\000\265?\337e\177\000\000\340\223?\374\177\000\000L\221?\374\177\000\000\340\223?\004\000\000\000\360\005|\000\016\000\000\000n\365\023o\016\000\000\000\177$\000\000\000\000\000\000P\221?\374\177\000\000(6\373\337e\177\000\000`\211A\000\000\000\000\000`\227?\374\177", '\000' <repeats 18 times>, "\020\222?\374\177\000\000\035\261]", '\000' <repeats 21 times>, "\300\022\262\000\000\000\000\000I/e\025\000\000\000\000`\211A\000\000\000\000\000`\227?\374\177", '\000' <repeats 19 times>, "\222"...
        i = -537187496
        j = 32613
        l = 32613
        __FUNCTION__ = "udp_rcv_loop"
#2  0x0000000000424c4c in main_loop () at main.c:1628

This VM PCSCF node is created on OpenStack.


Regards

Hamid R. Hashmi


________________________________
From: Daniel-Constantin Mierla <miconda at gmail.com>
Sent: Monday, December 7, 2020 5:53 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>; Hamid Hashmi <hamid2kviii at hotmail.com>; Henning Westerholt <hw at skalatan.de>
Subject: Re: [SR-Users] kamailio-5.2.0 Crash - udp_send failed


Hello,


get also the output of "bt full" from gdb.


I see you use ims moudules, they are known to have some limitations for various settings. Is this something that you can reproduce, or is something that happens from time to time without any pattern?


Cheers,
Daniel


On 06.12.20 20:13, Hamid Hashmi wrote:
Hello

I have updated Kamailio from 5.2.0 to 5.4.2 but the service is still crashing with sig 11 and sig 6. Please find the attached 'bt full' traces.

Sig 11:

Core was generated by `/usr/local/sbin/kamailio -f /usr/local/etc/kamailio_pcscf/kamailio.cfg -P /var/'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000006a16fc in timer_list_expire (t=1339518316, h=0x7facee484fd0, slow_l=0x7facee488208, slow_mark=7936) at core/timer.c:846
846                     _timer_rm_list(tl); /* detach */
(gdb) bt
#0  0x00000000006a16fc in timer_list_expire (t=1339518316, h=0x7facee484fd0, slow_l=0x7facee488208, slow_mark=7936) at core/timer.c:846
#1  0x00000000006a1c19 in timer_handler () at core/timer.c:922
#2  0x00000000006a20ba in timer_main () at core/timer.c:961
#3  0x000000000042ac0a in main_loop () at main.c:1753
#4  0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at main.c:2856

Sig 6:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/sbin/kamailio -f /usr/local/etc/kamailio_pcscf/kamailio.cfg -P /var/'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fad95f56c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007fad95f56c37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fad95f5a028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x000000000041e39d in sig_alarm_abort (signo=14) at main.c:687
#3  <signal handler called>
#4  0x00007fad960183c7 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007fad6f5c024b in futex_get (lock=0x7facee70baa0) at ../../core/mem/../futexlock.h:121
#6  0x00007fad6f5c2167 in get_peer_by_fqdn (fqdn=0x7faceeb377b0) at peermanager.c:240
#7  0x00007fad6f5e6c31 in get_first_connected_route (cdp_session=0x7faceeb37768, r=0x7facee70a220, app_id=16777236, vendor_id=10415) at routing.c:110
#8  0x00007fad6f5ea8b2 in get_routing_peer (cdp_session=0x7faceeb37768, m=0x7facef617fb0) at routing.c:272
#9  0x00007fad6f5ac72d in AAASendMessage (message=0x7facef617fb0, callback_f=0x0, callback_param=0x0) at diameter_comm.c:137
#10 0x00007fad6ef05dbb in rx_send_str (rx_session_id=0x7facf0849d50) at rx_str.c:157
#11 0x00007fad6eeb25c4 in callback_dialog (dlg=0x7facf0036d70, type=8192, params=0x7fad72b2a1c0 <params>) at ims_qos_mod.c:453
#12 0x00007fad728973af in run_dlg_callbacks (type=8192, dlg=0x7facf0036d70, req=0x0, rpl=0x0, dir=0, dlg_data=0x0) at dlg_cb.c:274
#13 0x00007fad728d5315 in destroy_dlg (dlg=0x7facf0036d70) at dlg_hash.c:219
#14 0x00007fad728d5b1b in destroy_dlg_table () at dlg_hash.c:291
#15 0x00007fad7290b71e in mod_destroy () at ims_dialog.c:627
#16 0x0000000000616ae1 in destroy_modules () at core/sr_module.c:746
#17 0x000000000041ce17 in cleanup (show_status=1) at main.c:563
#18 0x000000000041e6ef in shutdown_children (sig=15, show_status=1) at main.c:706
#19 0x0000000000421755 in handle_sigs () at main.c:806
#20 0x000000000042bc85 in main_loop () at main.c:1817
#21 0x000000000043400c in main (argc=13, argv=0x7ffc256fe358) at main.c:2856

PS: I am using ubuntu 14.04.


Regards

Hamid R. Hashmi

________________________________
From: Henning Westerholt <hw at skalatan.de><mailto:hw at skalatan.de>
Sent: Saturday, September 26, 2020 12:04 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org><mailto:sr-users at lists.kamailio.org>
Cc: Hamid Hashmi <hamid2kviii at hotmail.com><mailto:hamid2kviii at hotmail.com>
Subject: Re: kamailio-5.2.0 Crash - udp_send failed

Hello,

you are using a old and non released dev version of kamailio. These are meant only for development purposes.

Please update to a proper version (like the latest one based on 5.3 or 5.4 branch.

Then try to reproduce the bug again and report on the list or by creating an issue.

Cheers,

Henning


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

________________________________
From: sr-users <sr-users-bounces at lists.kamailio.org><mailto:sr-users-bounces at lists.kamailio.org> on behalf of Hamid Hashmi <hamid2kviii at hotmail.com><mailto:hamid2kviii at hotmail.com>
Sent: Friday, September 25, 2020 9:28:07 PM
To: sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org> <sr-users at lists.kamailio.org><mailto:sr-users at lists.kamailio.org>
Subject: [SR-Users] kamailio-5.2.0 Crash - udp_send failed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201207/be443029/attachment.htm>

From dcunningham at voisonics.com  Tue Dec  8 05:01:00 2020
From: dcunningham at voisonics.com (David Cunningham)
Date: Tue, 8 Dec 2020 17:01:00 +1300
Subject: [SR-Users] NAT problem with recvonly calls
Message-ID: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>

Hello,

We have a problem with a SIP doorbell device which sends media one way
only, and NAT at the receiving device.

When the doorbell button is pressed it makes a call to a configured
destination. Since the doorbell only sends and doesn't receive it sends the
INVITE with sendonly in the SDP, and the destination then replies with a
200 OK with recvonly in the SDP. The problem is that the destination is
behind NAT, and its reply contains a private network IP in the SDP.

Normally Asterisk when nat=yes works around that by adjusting the
destination for RTP to be the address it actually receives audio from,
however because this device is recvonly Asterisk never receives audio from
it. This means Asterisk keeps trying to send the doorbell's RTP to the
private network IP which of course fails, and the destination never gets
the RTP from the doorbell.

We haven't found a solution in Asterisk to this, so are now looking to
Kamailio which acts as a load-balancing proxy in front of Asterisk for one.
For example, maybe we could use fix_nated_sdp, but only on 200 OK's with
recvonly.

Has anyone else encountered this, and are there any recommended solutions?

Thank you in advance!

-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/08fd39f1/attachment.htm>

From arsperger at gmail.com  Tue Dec  8 05:45:11 2020
From: arsperger at gmail.com (Arsen Semenov)
Date: Tue, 8 Dec 2020 09:45:11 +0500
Subject: [SR-Users] Kamailio as an LCR based on prices but also
 signaling quality indicators
In-Reply-To: <CABc7nxurxvDPnLa_kyrUt0jUPNNn2DNFLvxyA_46-fXsBkdhog@mail.gmail.com>
References: <CABc7nxurxvDPnLa_kyrUt0jUPNNn2DNFLvxyA_46-fXsBkdhog@mail.gmail.com>
Message-ID: <CAC3hFArgtOq0d7Rm7eyt3q8YoS0d74nYK7f4A3yco31K0_S71Q@mail.gmail.com>

Hi,

You can try CGRateS. It could be easily integrated with kamailio and it has
LCR and QoS based routing as I remember..

Regards,

On Mon, Dec 7, 2020 at 6:31 PM Abdoul Oss?ni <abdoul.osseni at gmail.com>
wrote:

> Hello,
>
> I am trying to configure kamailio as an LCR based on prices but also
> signaling quality indicators like ASR and ACDR.
>
> Can you please help me and tell me where to start?
>
> Regards
> Abdoul
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Arsen Semenov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/fbb3c50d/attachment.htm>

From abalashov at evaristesys.com  Tue Dec  8 06:38:50 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 8 Dec 2020 00:38:50 -0500
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
Message-ID: <567F0A35-103A-405D-AFDE-C1D1793F3864@evaristesys.com>

RTPEngine does the same kind of port latching that Asterisk would ? that is, wait to receive an RTP frame in order to learn the external port that the NAT gateway has mapped the device?s (symmetric) RTP endpoint to. If it never gets one, it won?t learn. That?s the industry-standard solution.

No magic workarounds, alas.

?
Sent from mobile, with due apologies for brevity and errors.

> On Dec 7, 2020, at 11:02 PM, David Cunningham <dcunningham at voisonics.com> wrote:
> 
> ?
> Hello,
> 
> We have a problem with a SIP doorbell device which sends media one way only, and NAT at the receiving device.
> 
> When the doorbell button is pressed it makes a call to a configured destination. Since the doorbell only sends and doesn't receive it sends the INVITE with sendonly in the SDP, and the destination then replies with a 200 OK with recvonly in the SDP. The problem is that the destination is behind NAT, and its reply contains a private network IP in the SDP.
> 
> Normally Asterisk when nat=yes works around that by adjusting the destination for RTP to be the address it actually receives audio from, however because this device is recvonly Asterisk never receives audio from it. This means Asterisk keeps trying to send the doorbell's RTP to the private network IP which of course fails, and the destination never gets the RTP from the doorbell.
> 
> We haven't found a solution in Asterisk to this, so are now looking to Kamailio which acts as a load-balancing proxy in front of Asterisk for one. For example, maybe we could use fix_nated_sdp, but only on 200 OK's with recvonly.
> 
> Has anyone else encountered this, and are there any recommended solutions?
> 
> Thank you in advance!
> 
> -- 
> David Cunningham, Voisonics Limited
> http://voisonics.com/
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/e39fc798/attachment.htm>

From agiftel at gmail.com  Mon Dec  7 16:38:37 2020
From: agiftel at gmail.com (Agiftel)
Date: Mon, 7 Dec 2020 08:38:37 -0700 (MST)
Subject: [SR-Users] sngrep TLS connection
Message-ID: <1607355517135-0.post@n5.nabble.com>

Hi all, does anyone was able to use sngrep (with -k option) to decrypt TLS
connections?
I'am doing what help says; used private key is the correct one; but no
traffic is seen on sngrep.
If i use not ecrypted call i can see everything, so sngrep is working good.

Any hint?

regards




--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From ovoshlook at gmail.com  Tue Dec  8 08:37:16 2020
From: ovoshlook at gmail.com (Yuriy Gorlichenko)
Date: Tue, 8 Dec 2020 08:37:16 +0100
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <1607355517135-0.post@n5.nabble.com>
References: <1607355517135-0.post@n5.nabble.com>
Message-ID: <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>

As I remember sngrep doesn't work with TLS 1.3, so may be it is your case.

On Tue, 8 Dec 2020, 08:01 Agiftel, <agiftel at gmail.com> wrote:

> Hi all, does anyone was able to use sngrep (with -k option) to decrypt TLS
> connections?
> I'am doing what help says; used private key is the correct one; but no
> traffic is seen on sngrep.
> If i use not ecrypted call i can see everything, so sngrep is working good.
>
> Any hint?
>
> regards
>
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/0ee64a0c/attachment.htm>

From ovoshlook at gmail.com  Tue Dec  8 08:37:16 2020
From: ovoshlook at gmail.com (Yuriy Gorlichenko)
Date: Tue, 8 Dec 2020 08:37:16 +0100
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <1607355517135-0.post@n5.nabble.com>
References: <1607355517135-0.post@n5.nabble.com>
Message-ID: <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>

As I remember sngrep doesn't work with TLS 1.3, so may be it is your case.

On Tue, 8 Dec 2020, 08:01 Agiftel, <agiftel at gmail.com> wrote:

> Hi all, does anyone was able to use sngrep (with -k option) to decrypt TLS
> connections?
> I'am doing what help says; used private key is the correct one; but no
> traffic is seen on sngrep.
> If i use not ecrypted call i can see everything, so sngrep is working good.
>
> Any hint?
>
> regards
>
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/0ee64a0c/attachment-0001.htm>

From miconda at gmail.com  Tue Dec  8 09:08:05 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 8 Dec 2020 09:08:05 +0100
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
Message-ID: <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>

Hello,

there were some limitations in sngrep for capturing tls traffic:

? * https://github.com/irontec/sngrep/issues/112

Not sure if there was any work afterwards to improve. The best place to
ask in on sngrep project.

Anyhow, I want to add that if you use Kamailio, then you can load
sipdump module and get the traffic stored in pcap files -- it requires
master branch:

? *
https://www.kamailio.org/docs/modules/devel/modules/sipdump.html#sipdump.p.mode

For stable branches, sipdump can store the traffic in text files.

Cheers,
Daniel

On 08.12.20 08:37, Yuriy Gorlichenko wrote:
> As I remember sngrep doesn't work with TLS 1.3, so may be it is your case.
>
> On Tue, 8 Dec 2020, 08:01 Agiftel, <agiftel at gmail.com
> <mailto:agiftel at gmail.com>> wrote:
>
>     Hi all, does anyone was able to use sngrep (with -k option) to
>     decrypt TLS
>     connections?
>     I'am doing what help says; used private key is the correct one; but no
>     traffic is seen on sngrep.
>     If i use not ecrypted call i can see everything, so sngrep is
>     working good.
>
>     Any hint?
>
>     regards
>
>
>
>
>     --
>     Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>     <http://sip-router.1086192.n5.nabble.com/Users-f3.html>
>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/88abc8f5/attachment.htm>

From miconda at gmail.com  Tue Dec  8 09:56:13 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 8 Dec 2020 09:56:13 +0100
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
Message-ID: <71c409ac-ad0b-f836-2683-800a12fdb978@gmail.com>

Hello,

if the endpoint is not behind a port forwarding nat/firewall (when one
can instruct the rtp relay to use signaling address), then probably you
can try to remove the sendonly from the INVITE SDP. That will enable rtp
from endpoint to doorbell, which may rise additional concerns (e.g.,
privacy) if its is explicitly not wanted to happen. But as Alex said in
another response, the only way to get it work is to make the endpoint
behind nat to send a RTP packet. Usually the doorbells I encountered so
far were accepting incoming traffic as well, to discuss/interact with
the person ringing on it.

Cheers,
Daniel

On 08.12.20 05:01, David Cunningham wrote:
> Hello,
>
> We have a problem with a SIP doorbell device which sends media one way
> only, and NAT at the receiving device.
>
> When the doorbell button is pressed it makes a call to a configured
> destination. Since the doorbell only sends and doesn't receive it
> sends the INVITE with sendonly in the SDP, and the destination then
> replies with a 200 OK with recvonly in the SDP. The problem is that
> the destination is behind NAT, and its reply contains a private
> network IP in the SDP.
>
> Normally Asterisk when nat=yes works around that by adjusting the
> destination for RTP to be the address it actually receives audio from,
> however because this device is recvonly Asterisk never receives audio
> from it. This means Asterisk keeps trying to send the doorbell's RTP
> to the private network IP which of course fails, and the destination
> never gets the RTP from the doorbell.
>
> We haven't found a solution in Asterisk to this, so are now looking to
> Kamailio which acts as a load-balancing proxy in front of Asterisk for
> one. For example, maybe we could use fix_nated_sdp, but only on 200
> OK's with recvonly.
>
> Has anyone else encountered this, and are there any recommended solutions?
>
> Thank you in advance!
>
> -- 
> David Cunningham, Voisonics Limited
> http://voisonics.com/ <http://voisonics.com/>
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/e9358ecf/attachment.htm>

From me.projects at yahoo.com  Tue Dec  8 11:37:27 2020
From: me.projects at yahoo.com (me.projects at yahoo.com)
Date: Tue, 8 Dec 2020 10:37:27 +0000 (UTC)
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
Message-ID: <584348691.5654827.1607423847408@mail.yahoo.com>

 There are two options
1- use SIMPDUMP module to dup all SIP packets in Log file?SIPDUMP Module


| 
| 
|  | 
SIPDUMP Module


 |

 |

 |

?

2- use SIPTRACE module and broadcast SIP traffic from kamailio to any local port and then capture through sngrep -p BROACST_PORT
SipTrace Module


| 
| 
|  | 
SipTrace Module


 |

 |

 |


loadmodule "siptrace.so"
# check IP and port of your capture nodemodparam("siptrace", "duplicate_uri", "sip:127.0.0.1:9060")modparam("siptrace", "hep_mode_on", 0)modparam("siptrace", "trace_to_database", 0)modparam("siptrace", "trace_flag", 22)modparam("siptrace", "trace_on", 1)# modparam("siptrace", "hep_version", 3)modparam("siptrace", "xheaders_write", 1)
during code use? setflag(22); sip_trace();
This will broadcast SIP packet to local 9060 port and u can capture that through sngrep.
I hope it will help.





    On Tuesday, December 8, 2020, 01:08:44 PM GMT+5, Daniel-Constantin Mierla <miconda at gmail.com> wrote:  
 
  
Hello,
 
there were some limitations in sngrep for capturing tls traffic:
 
? * https://github.com/irontec/sngrep/issues/112
 
Not sure if there was any work afterwards to improve. The best place to ask in on sngrep project.
 
 
Anyhow, I want to add that if you use Kamailio, then you can load sipdump module and get the traffic stored in pcap files -- it requires master branch:
 
? *https://www.kamailio.org/docs/modules/devel/modules/sipdump.html#sipdump.p.mode
 
For stable branches, sipdump can store the traffic in text files.
 
Cheers,
 Daniel
 
 On 08.12.20 08:37, Yuriy Gorlichenko wrote:
  
 
As I remember sngrep doesn't work with TLS 1.3, so may be it is your case. 
  On Tue, 8 Dec 2020, 08:01 Agiftel, <agiftel at gmail.com> wrote:
  
Hi all, does anyone was able to use sngrep (with -k option) to decrypt TLS
 connections?
 I'am doing what help says; used private key is the correct one; but no
 traffic is seen on sngrep.
 If i use not ecrypted call i can see everything, so sngrep is working good.
 
 Any hint?
 
 regards
 
 
 
 
 --
 Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
 
 _______________________________________________
 Kamailio (SER) - Users Mailing List
 sr-users at lists.kamailio.org
 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
 
  
  _______________________________________________Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla _______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/027b5322/attachment.htm>

From david.villasmil.work at gmail.com  Tue Dec  8 14:47:33 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Tue, 8 Dec 2020 13:47:33 +0000
Subject: [SR-Users] Kamailio as an LCR based on prices but also
 signaling quality indicators
In-Reply-To: <CAC3hFArgtOq0d7Rm7eyt3q8YoS0d74nYK7f4A3yco31K0_S71Q@mail.gmail.com>
References: <CABc7nxurxvDPnLa_kyrUt0jUPNNn2DNFLvxyA_46-fXsBkdhog@mail.gmail.com>
 <CAC3hFArgtOq0d7Rm7eyt3q8YoS0d74nYK7f4A3yco31K0_S71Q@mail.gmail.com>
Message-ID: <CAFGRPVpHFrEDv+dz8D9C-8pJDypmj3D5j4Mv5Fch1Vf5=JNDEg@mail.gmail.com>

There?s a fork with a new module for just this...

On Tue, 8 Dec 2020 at 04:46, Arsen Semenov <arsperger at gmail.com> wrote:

> Hi,
>
> You can try CGRateS. It could be easily integrated with kamailio and it
> has LCR and QoS based routing as I remember..
>
> Regards,
>
> On Mon, Dec 7, 2020 at 6:31 PM Abdoul Oss?ni <abdoul.osseni at gmail.com>
> wrote:
>
>> Hello,
>>
>> I am trying to configure kamailio as an LCR based on prices but also
>> signaling quality indicators like ASR and ACDR.
>>
>> Can you please help me and tell me where to start?
>>
>> Regards
>> Abdoul
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Arsen Semenov
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/beb70c16/attachment.htm>

From osas at voipembedded.com  Tue Dec  8 18:53:03 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 8 Dec 2020 12:53:03 -0500
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
Message-ID: <CAND0Lksy2-93N6r5nhvNaNhtiYG_rnSR2D5S8MX8VvxzxdiCrA@mail.gmail.com>

Hello David,

If the receiving NATed device has support for ICE, you can enable ICE
support on the asterisk server and then the media should flow through
(NAT pinholes are opened during ICE candidates negotiation).

Regards,
Ovidiu Sas

On Mon, Dec 7, 2020 at 11:02 PM David Cunningham
<dcunningham at voisonics.com> wrote:
>
> Hello,
>
> We have a problem with a SIP doorbell device which sends media one way only, and NAT at the receiving device.
>
> When the doorbell button is pressed it makes a call to a configured destination. Since the doorbell only sends and doesn't receive it sends the INVITE with sendonly in the SDP, and the destination then replies with a 200 OK with recvonly in the SDP. The problem is that the destination is behind NAT, and its reply contains a private network IP in the SDP.
>
> Normally Asterisk when nat=yes works around that by adjusting the destination for RTP to be the address it actually receives audio from, however because this device is recvonly Asterisk never receives audio from it. This means Asterisk keeps trying to send the doorbell's RTP to the private network IP which of course fails, and the destination never gets the RTP from the doorbell.
>
> We haven't found a solution in Asterisk to this, so are now looking to Kamailio which acts as a load-balancing proxy in front of Asterisk for one. For example, maybe we could use fix_nated_sdp, but only on 200 OK's with recvonly.
>
> Has anyone else encountered this, and are there any recommended solutions?
>
> Thank you in advance!
>
> --
> David Cunningham, Voisonics Limited
> http://voisonics.com/
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From rfuchs at sipwise.com  Tue Dec  8 18:55:56 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Tue, 8 Dec 2020 12:55:56 -0500
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
Message-ID: <f00601b5-37f7-e8a2-5260-0337eb2f814b@sipwise.com>

Use IPv6 ?

Cheers

On 07/12/2020 23.01, David Cunningham wrote:
> Hello,
>
> We have a problem with a SIP doorbell device which sends media one way 
> only, and NAT at the receiving device.
>
> When the doorbell button is pressed it makes a call to a configured 
> destination. Since the doorbell only sends and doesn't receive it 
> sends the INVITE with sendonly in the SDP, and the destination then 
> replies with a 200 OK with recvonly in the SDP. The problem is that 
> the destination is behind NAT, and its reply contains a private 
> network IP in the SDP.
>
> Normally Asterisk when nat=yes works around that by adjusting the 
> destination for RTP to be the address it actually receives audio from, 
> however because this device is recvonly Asterisk never receives audio 
> from it. This means Asterisk keeps trying to send the doorbell's RTP 
> to the private network IP which of course fails, and the destination 
> never gets the RTP from the doorbell.
>
> We haven't found a solution in Asterisk to this, so are now looking to 
> Kamailio which acts as a load-balancing proxy in front of Asterisk for 
> one. For example, maybe we could use fix_nated_sdp, but only on 200 
> OK's with recvonly.
>
> Has anyone else encountered this, and are there any recommended solutions?
>
> Thank you in advance!
>
> -- 
> David Cunningham, Voisonics Limited
> http://voisonics.com/ <http://voisonics.com/>
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201208/8fd2916d/attachment.htm>

From miconda at gmail.com  Wed Dec  9 08:34:05 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 9 Dec 2020 08:34:05 +0100
Subject: [SR-Users] Releasing Kamailio v5.4.3
Message-ID: <1e6c9539-7662-f37b-00e0-52d997e860f4@gmail.com>

Hello,

I am considering to release Kamailio v5.4.3 sometime next week, likely
on Monday, December 14, 2020. This is the usual heads up notification to
see if anyone is aware of issues not yet reported to bug tracker and if
yes, do it as soon as possible to give them a chance to be fixed.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From oej at edvina.net  Wed Dec  9 08:39:02 2020
From: oej at edvina.net (Olle E. Johansson)
Date: Wed, 9 Dec 2020 08:39:02 +0100
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <f00601b5-37f7-e8a2-5260-0337eb2f814b@sipwise.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <f00601b5-37f7-e8a2-5260-0337eb2f814b@sipwise.com>
Message-ID: <25EC3E20-4862-474E-8F46-E5BE21EF768E@edvina.net>



> On 8 Dec 2020, at 18:55, Richard Fuchs <rfuchs at sipwise.com> wrote:
> 
> Use IPv6 ?

While I like that proposal, assuming that IPv6 will not have a stateful firewall is propably not a good assumption.
So I suspect that an IPv6 firewall would not let the packets in if there is not outbound traffic first. I do like Ovidius
ICE-based solution and would like to add RTCP - if muxed it would open the port, but the likelyhood that it?s 
implemented is propably low.

IPv6 greetings!
/O :-)
> 
> Cheers
> 
> On 07/12/2020 23.01, David Cunningham wrote:
>> Hello,
>> 
>> We have a problem with a SIP doorbell device which sends media one way only, and NAT at the receiving device.
>> 
>> When the doorbell button is pressed it makes a call to a configured destination. Since the doorbell only sends and doesn't receive it sends the INVITE with sendonly in the SDP, and the destination then replies with a 200 OK with recvonly in the SDP. The problem is that the destination is behind NAT, and its reply contains a private network IP in the SDP.
>> 
>> Normally Asterisk when nat=yes works around that by adjusting the destination for RTP to be the address it actually receives audio from, however because this device is recvonly Asterisk never receives audio from it. This means Asterisk keeps trying to send the doorbell's RTP to the private network IP which of course fails, and the destination never gets the RTP from the doorbell.
>> 
>> We haven't found a solution in Asterisk to this, so are now looking to Kamailio which acts as a load-balancing proxy in front of Asterisk for one. For example, maybe we could use fix_nated_sdp, but only on 200 OK's with recvonly.
>> 
>> Has anyone else encountered this, and are there any recommended solutions?
>> 
>> Thank you in advance!
>> 
>> -- 
>> David Cunningham, Voisonics Limited
>> http://voisonics.com/ <http://voisonics.com/>
>> USA: +1 213 221 1092
>> New Zealand: +64 (0)28 2558 3782
>> 
>> 
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201209/36b0f046/attachment.htm>

From abalashov at evaristesys.com  Wed Dec  9 08:40:14 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 9 Dec 2020 02:40:14 -0500
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <25EC3E20-4862-474E-8F46-E5BE21EF768E@edvina.net>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <f00601b5-37f7-e8a2-5260-0337eb2f814b@sipwise.com>
 <25EC3E20-4862-474E-8F46-E5BE21EF768E@edvina.net>
Message-ID: <ede880e1-aa9a-275c-5bad-e6c2de1ac76d@evaristesys.com>

ICE support just doesn't seem to me to be something a SIP doorbell would 
have.

On 12/9/20 2:39 AM, Olle E. Johansson wrote:
> 
> 
>> On 8 Dec 2020, at 18:55, Richard Fuchs <rfuchs at sipwise.com 
>> <mailto:rfuchs at sipwise.com>> wrote:
>>
>> Use IPv6 ?
> 
> While I like that proposal, assuming that IPv6 will not have a stateful 
> firewall is propably not a good assumption.
> So I suspect that an IPv6 firewall would not let the packets in if there 
> is not outbound traffic first. I do like Ovidius
> ICE-based solution and would like to add RTCP - if muxed it would open 
> the port, but the likelyhood that it?s
> implemented is propably low.
> 
> IPv6 greetings!
> /O :-)
>>
>> Cheers
>>
>> On 07/12/2020 23.01, David Cunningham wrote:
>>> Hello,
>>>
>>> We have a problem with a SIP doorbell device which sends media one 
>>> way only, and NAT at the receiving device.
>>>
>>> When the doorbell button is pressed it makes a call to a configured 
>>> destination. Since the doorbell only sends and doesn't receive it 
>>> sends the INVITE with sendonly in the SDP, and the destination then 
>>> replies with a 200 OK with recvonly in the SDP. The problem is that 
>>> the destination is behind NAT, and its reply contains a private 
>>> network IP in the SDP.
>>>
>>> Normally Asterisk when nat=yes works around that by adjusting the 
>>> destination for RTP to be the address it actually receives audio 
>>> from, however because this device is recvonly Asterisk never receives 
>>> audio from it. This means Asterisk keeps trying to send the 
>>> doorbell's RTP to the private network IP which of course fails, and 
>>> the destination never gets the RTP from the doorbell.
>>>
>>> We haven't found a solution in Asterisk to this, so are now looking 
>>> to Kamailio which acts as a load-balancing proxy in front of Asterisk 
>>> for one. For example, maybe we could use fix_nated_sdp, but only on 
>>> 200 OK's with recvonly.
>>>
>>> Has anyone else encountered this, and are there any recommended 
>>> solutions?
>>>
>>> Thank you in advance!
>>>
>>> -- 
>>> David Cunningham, Voisonics Limited
>>> http://voisonics.com/ <http://voisonics.com/>
>>> USA: +1 213 221 1092
>>> New Zealand: +64 (0)28 2558 3782
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From dcunningham at voisonics.com  Wed Dec  9 08:47:36 2020
From: dcunningham at voisonics.com (David Cunningham)
Date: Wed, 9 Dec 2020 20:47:36 +1300
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <71c409ac-ad0b-f836-2683-800a12fdb978@gmail.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <71c409ac-ad0b-f836-2683-800a12fdb978@gmail.com>
Message-ID: <CAHGbP--aYYPy97hk9rewTBB0LpG0cmWYyi6JzHbayAtCRV-_cA@mail.gmail.com>

Hi Daniel,

Removing the sendonly from the INVITE SDP sounds like the most workable
solution in our case. We'd only want to do it for a new INVITE though, not
a re-INVITE in a situation where a call is put on hold. Would you be able
to give an example of such a configuration?

Thanks very much for your help!


On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Hello,
>
> if the endpoint is not behind a port forwarding nat/firewall (when one can
> instruct the rtp relay to use signaling address), then probably you can try
> to remove the sendonly from the INVITE SDP. That will enable rtp from
> endpoint to doorbell, which may rise additional concerns (e.g., privacy) if
> its is explicitly not wanted to happen. But as Alex said in another
> response, the only way to get it work is to make the endpoint behind nat to
> send a RTP packet. Usually the doorbells I encountered so far were
> accepting incoming traffic as well, to discuss/interact with the person
> ringing on it.
>
> Cheers,
> Daniel
> On 08.12.20 05:01, David Cunningham wrote:
>
> Hello,
>
> We have a problem with a SIP doorbell device which sends media one way
> only, and NAT at the receiving device.
>
> When the doorbell button is pressed it makes a call to a configured
> destination. Since the doorbell only sends and doesn't receive it sends the
> INVITE with sendonly in the SDP, and the destination then replies with a
> 200 OK with recvonly in the SDP. The problem is that the destination is
> behind NAT, and its reply contains a private network IP in the SDP.
>
> Normally Asterisk when nat=yes works around that by adjusting the
> destination for RTP to be the address it actually receives audio from,
> however because this device is recvonly Asterisk never receives audio from
> it. This means Asterisk keeps trying to send the doorbell's RTP to the
> private network IP which of course fails, and the destination never gets
> the RTP from the doorbell.
>
> We haven't found a solution in Asterisk to this, so are now looking to
> Kamailio which acts as a load-balancing proxy in front of Asterisk for one.
> For example, maybe we could use fix_nated_sdp, but only on 200 OK's with
> recvonly.
>
> Has anyone else encountered this, and are there any recommended solutions?
>
> Thank you in advance!
>
> --
> David Cunningham, Voisonics Limited
> http://voisonics.com/
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>

-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201209/54791a98/attachment.htm>

From abalashov at evaristesys.com  Wed Dec  9 08:49:52 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 9 Dec 2020 02:49:52 -0500
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <CAHGbP--aYYPy97hk9rewTBB0LpG0cmWYyi6JzHbayAtCRV-_cA@mail.gmail.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <71c409ac-ad0b-f836-2683-800a12fdb978@gmail.com>
 <CAHGbP--aYYPy97hk9rewTBB0LpG0cmWYyi6JzHbayAtCRV-_cA@mail.gmail.com>
Message-ID: <bfbc0e25-d80b-fa01-d784-c089c5ee4f01@evaristesys.com>

The salient quality of a reinvite is that has_totag() == true; it is 
handled in the loose_route() section of your config. You want to do the 
SDP manipulation in the part below that, where initial INVITEs are handled.

On 12/9/20 2:47 AM, David Cunningham wrote:
> Hi Daniel,
> 
> Removing the sendonly from the INVITE SDP sounds like the most workable 
> solution in our case. We'd only want to do it for a new INVITE though, 
> not a re-INVITE in a situation where a call is put on hold. Would you be 
> able to give an example of such a configuration?
> 
> Thanks very much for your help!
> 
> 
> On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla <miconda at gmail.com 
> <mailto:miconda at gmail.com>> wrote:
> 
>     Hello,
> 
>     if the endpoint is not behind a port forwarding nat/firewall (when
>     one can instruct the rtp relay to use signaling address), then
>     probably you can try to remove the sendonly from the INVITE SDP.
>     That will enable rtp from endpoint to doorbell, which may rise
>     additional concerns (e.g., privacy) if its is explicitly not wanted
>     to happen. But as Alex said in another response, the only way to get
>     it work is to make the endpoint behind nat to send a RTP packet.
>     Usually the doorbells I encountered so far were accepting incoming
>     traffic as well, to discuss/interact with the person ringing on it.
> 
>     Cheers,
>     Daniel
> 
>     On 08.12.20 05:01, David Cunningham wrote:
>>     Hello,
>>
>>     We have a problem with a SIP doorbell device which sends media one
>>     way only, and NAT at the receiving device.
>>
>>     When the doorbell button is pressed it makes a call to a
>>     configured destination. Since the doorbell only sends and doesn't
>>     receive it sends the INVITE with sendonly in the SDP, and the
>>     destination then replies with a 200 OK with recvonly in the SDP.
>>     The problem is that the destination is behind NAT, and its reply
>>     contains a private network IP in the SDP.
>>
>>     Normally Asterisk when nat=yes works around that by adjusting the
>>     destination for RTP to be the address it actually receives audio
>>     from, however because this device is recvonly Asterisk never
>>     receives audio from it. This means Asterisk keeps trying to send
>>     the doorbell's RTP to the private network IP which of course
>>     fails, and the destination never gets the RTP from the doorbell.
>>
>>     We haven't found a solution in Asterisk to this, so are now
>>     looking to Kamailio which acts as a load-balancing proxy in front
>>     of Asterisk for one. For example, maybe we could use
>>     fix_nated_sdp, but only on 200 OK's with recvonly.
>>
>>     Has anyone else encountered this, and are there any recommended
>>     solutions?
>>
>>     Thank you in advance!
>>
>>     -- 
>>     David Cunningham, Voisonics Limited
>>     http://voisonics.com/ <http://voisonics.com/>
>>     USA: +1 213 221 1092
>>     New Zealand: +64 (0)28 2558 3782
>>
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org  <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users  <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> 
>     -- 
>     Daniel-Constantin Mierla --www.asipto.com  <http://www.asipto.com>
>     www.twitter.com/miconda  <http://www.twitter.com/miconda>  --www.linkedin.com/in/miconda  <http://www.linkedin.com/in/miconda>
>     Funding:https://www.paypal.me/dcmierla  <https://www.paypal.me/dcmierla>
> 
> 
> 
> -- 
> David Cunningham, Voisonics Limited
> http://voisonics.com/ <http://voisonics.com/>
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From s.safarov at gmail.com  Wed Dec  9 11:51:36 2020
From: s.safarov at gmail.com (Sergey Safarov)
Date: Wed, 9 Dec 2020 13:51:36 +0300
Subject: [SR-Users] GitHub discussion
Message-ID: <CAHtxdDc+rxYuEhLT3KYCw3xuPUijydakD__JOHArKnWY10xjXQ@mail.gmail.com>

GitHub release new feature - discussion.

Example
https://github.com/vercel/vercel/discussions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201209/42896124/attachment.htm>

From miconda at gmail.com  Wed Dec  9 12:22:24 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 9 Dec 2020 12:22:24 +0100
Subject: [SR-Users] GitHub discussion
In-Reply-To: <CAHtxdDc+rxYuEhLT3KYCw3xuPUijydakD__JOHArKnWY10xjXQ@mail.gmail.com>
References: <CAHtxdDc+rxYuEhLT3KYCw3xuPUijydakD__JOHArKnWY10xjXQ@mail.gmail.com>
Message-ID: <41d773c7-ac9e-d578-a2d3-6f90038687ba@gmail.com>

Hello,

personally I prefer to keep the "official" community discussions in a
single place, because can be distracting and unproductive to follow many
places, risking that the main goal of building a knowledge base reduces
its efficiency.

I understand that one medium doesn't match all needs, a reason there is
irc/matrix room, to offer a place for more real time interactions. But I
would not like to use many platforms for the same type of communication.
I know that some people organized "unofficial" discussion channels (on
slack, telegram), that's fine, I am referring to what the project
advertises to be somehow "official" and what is under kamailio github
organization is implicitly in this category.

No matter I am more an email-oriented person than real time IM or
forums, but considering that it's a new feature of github, at this
moment I think makes no sense to go for it. There are probably other
concerns related to it, like ability to migrate the content when/if
wanting to switch to another platform, copyright of the content and the
fact that we enforce the entire community (not only the registered
developers) to make an account and "sign" the agreement with
github/microsoft.

Cheers,
Daniel

On 09.12.20 11:51, Sergey Safarov wrote:
> GitHub release new feature - discussion.
>
> Example
> https://github.com/vercel/vercel/discussions
> <https://github.com/vercel/vercel/discussions>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201209/d4dc0b00/attachment.htm>

From osas at voipembedded.com  Wed Dec  9 15:09:29 2020
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 9 Dec 2020 09:09:29 -0500
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <ede880e1-aa9a-275c-5bad-e6c2de1ac76d@evaristesys.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <f00601b5-37f7-e8a2-5260-0337eb2f814b@sipwise.com>
 <25EC3E20-4862-474E-8F46-E5BE21EF768E@edvina.net>
 <ede880e1-aa9a-275c-5bad-e6c2de1ac76d@evaristesys.com>
Message-ID: <CAND0LktX3BUGMyAk60_Kf5S2TJ8LA_sOit_=UFciFxYGHVkQkA@mail.gmail.com>

The doorbell is the caller. ICE support would be required on the
callee side (between NATed callee and asterisk).
There's no need for ICE support on the doorbell/caller side.

-ovidiu

On Wed, Dec 9, 2020 at 2:42 AM Alex Balashov <abalashov at evaristesys.com> wrote:
>
> ICE support just doesn't seem to me to be something a SIP doorbell would
> have.
>
> On 12/9/20 2:39 AM, Olle E. Johansson wrote:
> >
> >
> >> On 8 Dec 2020, at 18:55, Richard Fuchs <rfuchs at sipwise.com
> >> <mailto:rfuchs at sipwise.com>> wrote:
> >>
> >> Use IPv6
> >
> > While I like that proposal, assuming that IPv6 will not have a stateful
> > firewall is propably not a good assumption.
> > So I suspect that an IPv6 firewall would not let the packets in if there
> > is not outbound traffic first. I do like Ovidius
> > ICE-based solution and would like to add RTCP - if muxed it would open
> > the port, but the likelyhood that it?s
> > implemented is propably low.
> >
> > IPv6 greetings!
> > /O :-)
> >>
> >> Cheers
> >>
> >> On 07/12/2020 23.01, David Cunningham wrote:
> >>> Hello,
> >>>
> >>> We have a problem with a SIP doorbell device which sends media one
> >>> way only, and NAT at the receiving device.
> >>>
> >>> When the doorbell button is pressed it makes a call to a configured
> >>> destination. Since the doorbell only sends and doesn't receive it
> >>> sends the INVITE with sendonly in the SDP, and the destination then
> >>> replies with a 200 OK with recvonly in the SDP. The problem is that
> >>> the destination is behind NAT, and its reply contains a private
> >>> network IP in the SDP.
> >>>
> >>> Normally Asterisk when nat=yes works around that by adjusting the
> >>> destination for RTP to be the address it actually receives audio
> >>> from, however because this device is recvonly Asterisk never receives
> >>> audio from it. This means Asterisk keeps trying to send the
> >>> doorbell's RTP to the private network IP which of course fails, and
> >>> the destination never gets the RTP from the doorbell.
> >>>
> >>> We haven't found a solution in Asterisk to this, so are now looking
> >>> to Kamailio which acts as a load-balancing proxy in front of Asterisk
> >>> for one. For example, maybe we could use fix_nated_sdp, but only on
> >>> 200 OK's with recvonly.
> >>>
> >>> Has anyone else encountered this, and are there any recommended
> >>> solutions?
> >>>
> >>> Thank you in advance!
> >>>
> >>> --
> >>> David Cunningham, Voisonics Limited
> >>> http://voisonics.com/ <http://voisonics.com/>
> >>> USA: +1 213 221 1092
> >>> New Zealand: +64 (0)28 2558 3782
> >>>
> >>> _______________________________________________
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users at lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >> _______________________________________________
> >> Kamailio (SER) - Users Mailing List
> >> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From dcunningham at voisonics.com  Thu Dec 10 01:43:16 2020
From: dcunningham at voisonics.com (David Cunningham)
Date: Thu, 10 Dec 2020 13:43:16 +1300
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <bfbc0e25-d80b-fa01-d784-c089c5ee4f01@evaristesys.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <71c409ac-ad0b-f836-2683-800a12fdb978@gmail.com>
 <CAHGbP--aYYPy97hk9rewTBB0LpG0cmWYyi6JzHbayAtCRV-_cA@mail.gmail.com>
 <bfbc0e25-d80b-fa01-d784-c089c5ee4f01@evaristesys.com>
Message-ID: <CAHGbP--X+fJe2RHYX=bD3fgMFrCHr1YUxzHAR-Qda_=2N45nnQ@mail.gmail.com>

Hi Alex,

Thank you for that. Do you offhand know of an easy way to test if the
sendonly attribute is set? Presumably we can use
sdp_remove_line_by_prefix() to remove it.,


On Wed, 9 Dec 2020 at 20:52, Alex Balashov <abalashov at evaristesys.com>
wrote:

> The salient quality of a reinvite is that has_totag() == true; it is
> handled in the loose_route() section of your config. You want to do the
> SDP manipulation in the part below that, where initial INVITEs are handled.
>
> On 12/9/20 2:47 AM, David Cunningham wrote:
> > Hi Daniel,
> >
> > Removing the sendonly from the INVITE SDP sounds like the most workable
> > solution in our case. We'd only want to do it for a new INVITE though,
> > not a re-INVITE in a situation where a call is put on hold. Would you be
> > able to give an example of such a configuration?
> >
> > Thanks very much for your help!
> >
> >
> > On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla <miconda at gmail.com
> > <mailto:miconda at gmail.com>> wrote:
> >
> >     Hello,
> >
> >     if the endpoint is not behind a port forwarding nat/firewall (when
> >     one can instruct the rtp relay to use signaling address), then
> >     probably you can try to remove the sendonly from the INVITE SDP.
> >     That will enable rtp from endpoint to doorbell, which may rise
> >     additional concerns (e.g., privacy) if its is explicitly not wanted
> >     to happen. But as Alex said in another response, the only way to get
> >     it work is to make the endpoint behind nat to send a RTP packet.
> >     Usually the doorbells I encountered so far were accepting incoming
> >     traffic as well, to discuss/interact with the person ringing on it.
> >
> >     Cheers,
> >     Daniel
> >
> >     On 08.12.20 05:01, David Cunningham wrote:
> >>     Hello,
> >>
> >>     We have a problem with a SIP doorbell device which sends media one
> >>     way only, and NAT at the receiving device.
> >>
> >>     When the doorbell button is pressed it makes a call to a
> >>     configured destination. Since the doorbell only sends and doesn't
> >>     receive it sends the INVITE with sendonly in the SDP, and the
> >>     destination then replies with a 200 OK with recvonly in the SDP.
> >>     The problem is that the destination is behind NAT, and its reply
> >>     contains a private network IP in the SDP.
> >>
> >>     Normally Asterisk when nat=yes works around that by adjusting the
> >>     destination for RTP to be the address it actually receives audio
> >>     from, however because this device is recvonly Asterisk never
> >>     receives audio from it. This means Asterisk keeps trying to send
> >>     the doorbell's RTP to the private network IP which of course
> >>     fails, and the destination never gets the RTP from the doorbell.
> >>
> >>     We haven't found a solution in Asterisk to this, so are now
> >>     looking to Kamailio which acts as a load-balancing proxy in front
> >>     of Asterisk for one. For example, maybe we could use
> >>     fix_nated_sdp, but only on 200 OK's with recvonly.
> >>
> >>     Has anyone else encountered this, and are there any recommended
> >>     solutions?
> >>
> >>     Thank you in advance!
> >>
> >>     --
> >>     David Cunningham, Voisonics Limited
> >>     http://voisonics.com/ <http://voisonics.com/>
> >>     USA: +1 213 221 1092
> >>     New Zealand: +64 (0)28 2558 3782
> >>
> >>     _______________________________________________
> >>     Kamailio (SER) - Users Mailing List
> >>     sr-users at lists.kamailio.org  <mailto:sr-users at lists.kamailio.org>
> >>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users  <
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> >
> >     --
> >     Daniel-Constantin Mierla --www.asipto.com  <http://www.asipto.com>
> >     www.twitter.com/miconda  <http://www.twitter.com/miconda>  --
> www.linkedin.com/in/miconda  <http://www.linkedin.com/in/miconda>
> >     Funding:https://www.paypal.me/dcmierla  <
> https://www.paypal.me/dcmierla>
> >
> >
> >
> > --
> > David Cunningham, Voisonics Limited
> > http://voisonics.com/ <http://voisonics.com/>
> > USA: +1 213 221 1092
> > New Zealand: +64 (0)28 2558 3782
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/c6fa8a4f/attachment.htm>

From abalashov at evaristesys.com  Thu Dec 10 02:07:26 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Wed, 9 Dec 2020 20:07:26 -0500
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <CAHGbP--X+fJe2RHYX=bD3fgMFrCHr1YUxzHAR-Qda_=2N45nnQ@mail.gmail.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <71c409ac-ad0b-f836-2683-800a12fdb978@gmail.com>
 <CAHGbP--aYYPy97hk9rewTBB0LpG0cmWYyi6JzHbayAtCRV-_cA@mail.gmail.com>
 <bfbc0e25-d80b-fa01-d784-c089c5ee4f01@evaristesys.com>
 <CAHGbP--X+fJe2RHYX=bD3fgMFrCHr1YUxzHAR-Qda_=2N45nnQ@mail.gmail.com>
Message-ID: <8d3ae020-2c2c-0bf4-165b-689c1011e2b3@evaristesys.com>

if(has_body("application/sdp") && search("a=sendonly")) [1]

It's what comes to mind off the top of my head, anyway.

-- Alex

[1] https://www.kamailio.org/docs/modules/stable/modules/textops.html

On 12/9/20 7:43 PM, David Cunningham wrote:
> Hi Alex,
> 
> Thank you for that. Do you offhand know of an easy way to test if the 
> sendonly attribute is set? Presumably we can use 
> sdp_remove_line_by_prefix() to remove it.,
> 
> 
> On Wed, 9 Dec 2020 at 20:52, Alex Balashov <abalashov at evaristesys.com 
> <mailto:abalashov at evaristesys.com>> wrote:
> 
>     The salient quality of a reinvite is that has_totag() == true; it is
>     handled in the loose_route() section of your config. You want to do the
>     SDP manipulation in the part below that, where initial INVITEs are
>     handled.
> 
>     On 12/9/20 2:47 AM, David Cunningham wrote:
>      > Hi Daniel,
>      >
>      > Removing the sendonly from the INVITE SDP sounds like the most
>     workable
>      > solution in our case. We'd only want to do it for a new INVITE
>     though,
>      > not a re-INVITE in a situation where a call is put on hold. Would
>     you be
>      > able to give an example of such a configuration?
>      >
>      > Thanks very much for your help!
>      >
>      >
>      > On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla
>     <miconda at gmail.com <mailto:miconda at gmail.com>
>      > <mailto:miconda at gmail.com <mailto:miconda at gmail.com>>> wrote:
>      >
>      >? ? ?Hello,
>      >
>      >? ? ?if the endpoint is not behind a port forwarding nat/firewall
>     (when
>      >? ? ?one can instruct the rtp relay to use signaling address), then
>      >? ? ?probably you can try to remove the sendonly from the INVITE SDP.
>      >? ? ?That will enable rtp from endpoint to doorbell, which may rise
>      >? ? ?additional concerns (e.g., privacy) if its is explicitly not
>     wanted
>      >? ? ?to happen. But as Alex said in another response, the only way
>     to get
>      >? ? ?it work is to make the endpoint behind nat to send a RTP packet.
>      >? ? ?Usually the doorbells I encountered so far were accepting
>     incoming
>      >? ? ?traffic as well, to discuss/interact with the person ringing
>     on it.
>      >
>      >? ? ?Cheers,
>      >? ? ?Daniel
>      >
>      >? ? ?On 08.12.20 05:01, David Cunningham wrote:
>      >>? ? ?Hello,
>      >>
>      >>? ? ?We have a problem with a SIP doorbell device which sends
>     media one
>      >>? ? ?way only, and NAT at the receiving device.
>      >>
>      >>? ? ?When the doorbell button is pressed it makes a call to a
>      >>? ? ?configured destination. Since the doorbell only sends and
>     doesn't
>      >>? ? ?receive it sends the INVITE with sendonly in the SDP, and the
>      >>? ? ?destination then replies with a 200 OK with recvonly in the SDP.
>      >>? ? ?The problem is that the destination is behind NAT, and its reply
>      >>? ? ?contains a private network IP in the SDP.
>      >>
>      >>? ? ?Normally Asterisk when nat=yes works around that by
>     adjusting the
>      >>? ? ?destination for RTP to be the address it actually receives audio
>      >>? ? ?from, however because this device is recvonly Asterisk never
>      >>? ? ?receives audio from it. This means Asterisk keeps trying to send
>      >>? ? ?the doorbell's RTP to the private network IP which of course
>      >>? ? ?fails, and the destination never gets the RTP from the doorbell.
>      >>
>      >>? ? ?We haven't found a solution in Asterisk to this, so are now
>      >>? ? ?looking to Kamailio which acts as a load-balancing proxy in
>     front
>      >>? ? ?of Asterisk for one. For example, maybe we could use
>      >>? ? ?fix_nated_sdp, but only on 200 OK's with recvonly.
>      >>
>      >>? ? ?Has anyone else encountered this, and are there any recommended
>      >>? ? ?solutions?
>      >>
>      >>? ? ?Thank you in advance!
>      >>
>      >>? ? ?--
>      >>? ? ?David Cunningham, Voisonics Limited
>      >> http://voisonics.com/ <http://voisonics.com/>
>     <http://voisonics.com/ <http://voisonics.com/>>
>      >>? ? ?USA: +1 213 221 1092
>      >>? ? ?New Zealand: +64 (0)28 2558 3782
>      >>
>      >>? ? ?_______________________________________________
>      >>? ? ?Kamailio (SER) - Users Mailing List
>      >> sr-users at lists.kamailio.org
>     <mailto:sr-users at lists.kamailio.org> 
>     <mailto:sr-users at lists.kamailio.org
>     <mailto:sr-users at lists.kamailio.org>>
>      >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> 
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>
>      >
>      >? ? ?--
>      >? ? ?Daniel-Constantin Mierla --www.asipto.com
>     <http://www.asipto.com>? <http://www.asipto.com <http://www.asipto.com>>
>      > www.twitter.com/miconda <http://www.twitter.com/miconda> 
>     <http://www.twitter.com/miconda <http://www.twitter.com/miconda>> 
>     --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> 
>     <http://www.linkedin.com/in/miconda
>     <http://www.linkedin.com/in/miconda>>
>      >? ? ?Funding:https://www.paypal.me/dcmierla
>     <https://www.paypal.me/dcmierla>? <https://www.paypal.me/dcmierla
>     <https://www.paypal.me/dcmierla>>
>      >
>      >
>      >
>      > --
>      > David Cunningham, Voisonics Limited
>      > http://voisonics.com/ <http://voisonics.com/>
>     <http://voisonics.com/ <http://voisonics.com/>>
>      > USA: +1 213 221 1092
>      > New Zealand: +64 (0)28 2558 3782
>      >
>      > _______________________________________________
>      > Kamailio (SER) - Users Mailing List
>      > sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>      > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>      >
> 
>     -- 
>     Alex Balashov | Principal | Evariste Systems LLC
> 
>     Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>     Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>,
>     http://www.csrpswitch.com/ <http://www.csrpswitch.com/>
> 
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> 
> 
> 
> -- 
> David Cunningham, Voisonics Limited
> http://voisonics.com/ <http://voisonics.com/>
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From dcunningham at voisonics.com  Thu Dec 10 02:17:51 2020
From: dcunningham at voisonics.com (David Cunningham)
Date: Thu, 10 Dec 2020 14:17:51 +1300
Subject: [SR-Users] NAT problem with recvonly calls
In-Reply-To: <8d3ae020-2c2c-0bf4-165b-689c1011e2b3@evaristesys.com>
References: <CAHGbP-_z_7sbVD7rAAy40gXa-797zYsz9tMR5U+m7RVdseL7QQ@mail.gmail.com>
 <71c409ac-ad0b-f836-2683-800a12fdb978@gmail.com>
 <CAHGbP--aYYPy97hk9rewTBB0LpG0cmWYyi6JzHbayAtCRV-_cA@mail.gmail.com>
 <bfbc0e25-d80b-fa01-d784-c089c5ee4f01@evaristesys.com>
 <CAHGbP--X+fJe2RHYX=bD3fgMFrCHr1YUxzHAR-Qda_=2N45nnQ@mail.gmail.com>
 <8d3ae020-2c2c-0bf4-165b-689c1011e2b3@evaristesys.com>
Message-ID: <CAHGbP-_vN7qhgAcH0MLYu=_2-MeyyeFnDrPhwxYckQFCwwyOnA@mail.gmail.com>

Thanks Alex!


On Thu, 10 Dec 2020 at 14:09, Alex Balashov <abalashov at evaristesys.com>
wrote:

> if(has_body("application/sdp") && search("a=sendonly")) [1]
>
> It's what comes to mind off the top of my head, anyway.
>
> -- Alex
>
> [1] https://www.kamailio.org/docs/modules/stable/modules/textops.html
>
> On 12/9/20 7:43 PM, David Cunningham wrote:
> > Hi Alex,
> >
> > Thank you for that. Do you offhand know of an easy way to test if the
> > sendonly attribute is set? Presumably we can use
> > sdp_remove_line_by_prefix() to remove it.,
> >
> >
> > On Wed, 9 Dec 2020 at 20:52, Alex Balashov <abalashov at evaristesys.com
> > <mailto:abalashov at evaristesys.com>> wrote:
> >
> >     The salient quality of a reinvite is that has_totag() == true; it is
> >     handled in the loose_route() section of your config. You want to do
> the
> >     SDP manipulation in the part below that, where initial INVITEs are
> >     handled.
> >
> >     On 12/9/20 2:47 AM, David Cunningham wrote:
> >      > Hi Daniel,
> >      >
> >      > Removing the sendonly from the INVITE SDP sounds like the most
> >     workable
> >      > solution in our case. We'd only want to do it for a new INVITE
> >     though,
> >      > not a re-INVITE in a situation where a call is put on hold. Would
> >     you be
> >      > able to give an example of such a configuration?
> >      >
> >      > Thanks very much for your help!
> >      >
> >      >
> >      > On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla
> >     <miconda at gmail.com <mailto:miconda at gmail.com>
> >      > <mailto:miconda at gmail.com <mailto:miconda at gmail.com>>> wrote:
> >      >
> >      >     Hello,
> >      >
> >      >     if the endpoint is not behind a port forwarding nat/firewall
> >     (when
> >      >     one can instruct the rtp relay to use signaling address), then
> >      >     probably you can try to remove the sendonly from the INVITE
> SDP.
> >      >     That will enable rtp from endpoint to doorbell, which may rise
> >      >     additional concerns (e.g., privacy) if its is explicitly not
> >     wanted
> >      >     to happen. But as Alex said in another response, the only way
> >     to get
> >      >     it work is to make the endpoint behind nat to send a RTP
> packet.
> >      >     Usually the doorbells I encountered so far were accepting
> >     incoming
> >      >     traffic as well, to discuss/interact with the person ringing
> >     on it.
> >      >
> >      >     Cheers,
> >      >     Daniel
> >      >
> >      >     On 08.12.20 05:01, David Cunningham wrote:
> >      >>     Hello,
> >      >>
> >      >>     We have a problem with a SIP doorbell device which sends
> >     media one
> >      >>     way only, and NAT at the receiving device.
> >      >>
> >      >>     When the doorbell button is pressed it makes a call to a
> >      >>     configured destination. Since the doorbell only sends and
> >     doesn't
> >      >>     receive it sends the INVITE with sendonly in the SDP, and the
> >      >>     destination then replies with a 200 OK with recvonly in the
> SDP.
> >      >>     The problem is that the destination is behind NAT, and its
> reply
> >      >>     contains a private network IP in the SDP.
> >      >>
> >      >>     Normally Asterisk when nat=yes works around that by
> >     adjusting the
> >      >>     destination for RTP to be the address it actually receives
> audio
> >      >>     from, however because this device is recvonly Asterisk never
> >      >>     receives audio from it. This means Asterisk keeps trying to
> send
> >      >>     the doorbell's RTP to the private network IP which of course
> >      >>     fails, and the destination never gets the RTP from the
> doorbell.
> >      >>
> >      >>     We haven't found a solution in Asterisk to this, so are now
> >      >>     looking to Kamailio which acts as a load-balancing proxy in
> >     front
> >      >>     of Asterisk for one. For example, maybe we could use
> >      >>     fix_nated_sdp, but only on 200 OK's with recvonly.
> >      >>
> >      >>     Has anyone else encountered this, and are there any
> recommended
> >      >>     solutions?
> >      >>
> >      >>     Thank you in advance!
> >      >>
> >      >>     --
> >      >>     David Cunningham, Voisonics Limited
> >      >> http://voisonics.com/ <http://voisonics.com/>
> >     <http://voisonics.com/ <http://voisonics.com/>>
> >      >>     USA: +1 213 221 1092
> >      >>     New Zealand: +64 (0)28 2558 3782
> >      >>
> >      >>     _______________________________________________
> >      >>     Kamailio (SER) - Users Mailing List
> >      >> sr-users at lists.kamailio.org
> >     <mailto:sr-users at lists.kamailio.org>
> >     <mailto:sr-users at lists.kamailio.org
> >     <mailto:sr-users at lists.kamailio.org>>
> >      >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> >     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>
> >      >
> >      >     --
> >      >     Daniel-Constantin Mierla --www.asipto.com
> >     <http://www.asipto.com>  <http://www.asipto.com <
> http://www.asipto.com>>
> >      > www.twitter.com/miconda <http://www.twitter.com/miconda>
> >     <http://www.twitter.com/miconda <http://www.twitter.com/miconda>>
> >     --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> >     <http://www.linkedin.com/in/miconda
> >     <http://www.linkedin.com/in/miconda>>
> >      >     Funding:https://www.paypal.me/dcmierla
> >     <https://www.paypal.me/dcmierla>  <https://www.paypal.me/dcmierla
> >     <https://www.paypal.me/dcmierla>>
> >      >
> >      >
> >      >
> >      > --
> >      > David Cunningham, Voisonics Limited
> >      > http://voisonics.com/ <http://voisonics.com/>
> >     <http://voisonics.com/ <http://voisonics.com/>>
> >      > USA: +1 213 221 1092
> >      > New Zealand: +64 (0)28 2558 3782
> >      >
> >      > _______________________________________________
> >      > Kamailio (SER) - Users Mailing List
> >      > sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> >      > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> >      >
> >
> >     --
> >     Alex Balashov | Principal | Evariste Systems LLC
> >
> >     Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> >     Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>,
> >     http://www.csrpswitch.com/ <http://www.csrpswitch.com/>
> >
> >     _______________________________________________
> >     Kamailio (SER) - Users Mailing List
> >     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> >     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> >
> >
> >
> > --
> > David Cunningham, Voisonics Limited
> > http://voisonics.com/ <http://voisonics.com/>
> > USA: +1 213 221 1092
> > New Zealand: +64 (0)28 2558 3782
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/8215a685/attachment.htm>

From aatifshaikh3295 at gmail.com  Thu Dec 10 06:55:02 2020
From: aatifshaikh3295 at gmail.com (Aatif Shaikh)
Date: Thu, 10 Dec 2020 11:25:02 +0530
Subject: [SR-Users] SLA presence not working proper with (SCA module)
Message-ID: <CALjjLb8bYQnOAHroDwjyu8XJp64wX8qJLdgyA5Anxe+m+LnOzQ@mail.gmail.com>

Aatif Shaikh <aatif.shaikh at ecosmob.com>
Mon, Dec 7, 11:00 AM (3 days ago)
to sr-users
Hello All
   I configure my kamailio.cfg to handle SLA using (SCA module) and shared
presence is working but still facing some issue in case of hold invite and
BYE and the reason behind of that issue is following error

Nov 26 07:38:40 SBC-4-1 /usr/local/sbin/kamailio[104107]: ERROR: sca
[sca_call_info.c:1008]: sca_call_info_invite_request_handler(): Failed to
update sip:4569 at test.sip.abcd.com appearance-index 0 to active

actually, in Kamailio appearances, I can see the entry for this call but
the index is 1 instead of 0, and Kamailio going to update with a 0 index

[root at SBC-4-1 ntcarfte-kamailio]# kamcmd sca.all_appearances
sip:4569 at test.sip.abcd.com 1 active 1606376289 sip:4569 at 10.xx.xx.xx
:5070;transport=udp sip:2003 at test.sip.abcd.com
186161_mobile-rel120MTQ5OTcyZjFhMjMyNmI1ZGE1MWY4ODc2M2RkN2VmZmQ
45dc18d8 H6cS9vecZ248B

if I manually update appearances using RPC command with index 1 then the
phone started blinking as I change state to held

# kamcmd sca.update_appearance sip:4569 at sc4test.sip.teledge.com 1 held
# kamcmd sca.all_appearances
sip:4569 at test.sip.abcd.com 1 held 1606376516 sip:4569 at 10.xx.xx.xx
:5070;transport=udp sip:2003 at test.sip.abcd.com
186161_mobile-rel120NzE5MDgyZDc1NjJiYjcwMWFlYmI3NzM3NjE2OTRhZjU
08f005cb eK9ratm83g92e

kamailio.cfg


route[SCA] {
        if(is_method("SUBSCRIBE")) {

                if ($hdr(Event) == "call-info" || $hdr(Event) ==
"line-seize") {
                xlog("L_INFO","(MAIN) :HELLO ($avp(uuid)) : $avp(rsi)  $sp
$hdr(Event)");
                        xdbg("SCA: $hdr(Event) SUBSCRIBE $ru from $si:$sp");
                        sca_handle_subscribe();
                        exit;
                }
                return;
        }

        if (!is_method("BYE|CANCEL|INVITE|PRACK|REFER")) {
                return;
        }
                        sca_call_info_update();
}

route[RELAY_OUTBOUND_FS] {
        xlog("L_INFO","(RELAY_OUTBOUND_FS) : ($avp(uuid)) : INSIDE ROUTE ");

        if (!has_totag()){
                $avp(set_h) = 1;
        }

        t_on_reply("REPLY_OUTBOUND_FS");
        route(SCA);
        if (!t_relay()) {
                sl_reply_error();
        }
        exit;
}

route[RELAY_INBOUND_FS] {

        if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
                $avp(s:puburis_caller) = $fu;
                setflag(8);
                dlg_manage();
        }

        if(is_method("REGISTER")) {
            t_on_reply("REPLY_REGISTER");
        } else {
            t_on_reply("REPLY_INBOUND_FS");
        }
        route(SCA);
        if (!t_relay()) {
                sl_reply_error();
        }
        exit;
}

onreply_route[REPLY_INBOUND_FS] {
xdbg("incoming reply\n");

if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
   return;
}

route(SCA);
}

onreply_route[REPLY_OUTBOUND_FS] {
xdbg("incoming reply\n");

if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
   return;
}

route(SCA);
}

can someone help me with this Did I missed something to handle SLA?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/a26e20bb/attachment.htm>

From jh at tutpro.com  Thu Dec 10 08:00:08 2020
From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 10 Dec 2020 09:00:08 +0200
Subject: [SR-Users] kamailio.cfg fomatter
Message-ID: <24529.51064.922965.868083@tutpro.com>

After noticing that emacs mode is missing, below is my first cut of
kamailio-mode.el.

-- Juha

-----------------------------------------------------------------------

;; kamailio mode for emacs (function list is not complete)

;; activate by starting your kamailio.cfg with this kind of line:

;; #-*-mode: kamailio; tab-width: 4; c-basic-offset: 4;

(setq kamailio-font-lock-keywords
      (let* (
            ;; define several category of keywords
            (x-keywords '("branch_route" "break" "case" "default" "else" "event_route" "exit" "failure_route" "for" "if" "loadmodule" "onreply_route" "onsend_route" "reply_route" "request_route" "return" "route" "switch" "while"))
            (x-types '())
            (x-constants '())
            (x-events '())
            (x-functions '("acc_db_request" "add_path_received" "add_rr_param" "allow_routing" "allow_trusted" "append_hf" "append_to_reply" "avp_check" "avp_delete" "change_reply_status" "check_route_param" "defined" "dp_translate" "ERROR" "fix_nated_sdp" "force_send_socket" "forward" "get_redirects" "handle_ruri_alias" "inactivate_gw" "INFO" "in_list" "isflagset" "is_avp_set" "isbflagset" "is_direction" "is_domain_local" "is_e164" "is_gflag" "is_gruu" "is_method" "is_numeric" "is_present_hf" "jsonrpc_dispatch" "load_gws" "lookup_domain" "lookup" "loose_route" "modparam" "mt_match" "NOTICE" "proxy_challenge" "record_route" "redirecting" "remove_hf" "resetflag" "rtpengine_answer" "rtpengine_delete" "rtpengine_offer" "save" "sdp_content" "sdp_transport" "send_reply_mode" "send_reply" "setbflag" "setflag" "setxflag" "set_reply_close" "set_reply_no_connect" "set_rtpengine_set" "set_uri_host" "set_uri_user" "set_forward_no_connect" "sql_query" "sql_result_free" "starts_with" "subst_uri" "tel2sip" "t_check_status" "t_is_canceled" "t_load_contacts" "t_next_contacts" "t_on_branch" "t_on_failure" "t_on_reply" "t_relay_cancel" "t_relay" "t_set_fr" "unregister" "WARN" "ws_handle_handshake" "www_challenge" "xhttp_reply"))
            (x-keywords-regexp (regexp-opt x-keywords 'words))
            (x-types-regexp (regexp-opt x-types 'words))
            (x-constants-regexp (regexp-opt x-constants 'words))
            (x-events-regexp (regexp-opt x-events 'words))
            (x-functions-regexp (regexp-opt x-functions 'words)))
        `(
          (,x-types-regexp . font-lock-type-face)
          (,x-constants-regexp . font-lock-constant-face)
          (,x-events-regexp . font-lock-builtin-face)
          (,x-functions-regexp . font-lock-function-name-face)
          (,x-keywords-regexp . font-lock-keyword-face)
          )))

(defvar kamailio-mode-syntax-table nil "Syntax table for `kamailio-mode'.")

(setq kamailio-mode-syntax-table
      (let ( (synTable (make-syntax-table)))
        ;; python style comment: ?# ??
        (modify-syntax-entry ?# "<" synTable)
        (modify-syntax-entry ?\n ">" synTable)
        synTable))

(define-derived-mode kamailio-mode c-mode "kamailio mode"
  "Major mode for editing Kamailio configuration files"
  (setq font-lock-defaults '((kamailio-font-lock-keywords)))
  (set-syntax-table kamailio-mode-syntax-table))

(provide 'kamailio-mode)

From m at mokalife.ro  Wed Dec  9 14:10:35 2020
From: m at mokalife.ro (Mihai)
Date: Wed, 9 Dec 2020 15:10:35 +0200
Subject: [SR-Users] Kamilio+asterisk = deregister after 2-3 minute
Message-ID: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>

Hi,

I am forwarding all the traffic to my asterisk server ( including registers)
everything seems to work when i first register but if stay idle 2-3 minute
it gets unregistered and then i can't register back unless i restart
kamailio
see attached print screen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201209/3b396efc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2020-12-09 at 15.07.16.png
Type: image/png
Size: 141843 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201209/3b396efc/attachment.png>

From miconda at gmail.com  Thu Dec 10 09:07:44 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 10 Dec 2020 09:07:44 +0100
Subject: [SR-Users] kamailio.cfg fomatter
In-Reply-To: <24529.51064.922965.868083@tutpro.com>
References: <24529.51064.922965.868083@tutpro.com>
Message-ID: <6775839b-8010-fa74-74cd-ae622a1a33d2@gmail.com>

Hello,

this is syntax highlighting for kamailio.cfg, right?

Just to clarify better to what was asked for earlier on the mailing list
as code formatter, which was expected to do indentation of the file
content (a-la clang-format for c files).

We can create a repo on kamailio github oraganization, like
emacs-kamailio-syntax, similar to what is now for vim:

? * https://github.com/kamailio/vim-kamailio-syntax

Cheers,
Daniel

On 10.12.20 08:00, Juha Heinanen wrote:
> After noticing that emacs mode is missing, below is my first cut of
> kamailio-mode.el.
>
> -- Juha
>
> -----------------------------------------------------------------------
>
> ;; kamailio mode for emacs (function list is not complete)
>
> ;; activate by starting your kamailio.cfg with this kind of line:
>
> ;; #-*-mode: kamailio; tab-width: 4; c-basic-offset: 4;
>
> (setq kamailio-font-lock-keywords
>       (let* (
>             ;; define several category of keywords
>             (x-keywords '("branch_route" "break" "case" "default" "else" "event_route" "exit" "failure_route" "for" "if" "loadmodule" "onreply_route" "onsend_route" "reply_route" "request_route" "return" "route" "switch" "while"))
>             (x-types '())
>             (x-constants '())
>             (x-events '())
>             (x-functions '("acc_db_request" "add_path_received" "add_rr_param" "allow_routing" "allow_trusted" "append_hf" "append_to_reply" "avp_check" "avp_delete" "change_reply_status" "check_route_param" "defined" "dp_translate" "ERROR" "fix_nated_sdp" "force_send_socket" "forward" "get_redirects" "handle_ruri_alias" "inactivate_gw" "INFO" "in_list" "isflagset" "is_avp_set" "isbflagset" "is_direction" "is_domain_local" "is_e164" "is_gflag" "is_gruu" "is_method" "is_numeric" "is_present_hf" "jsonrpc_dispatch" "load_gws" "lookup_domain" "lookup" "loose_route" "modparam" "mt_match" "NOTICE" "proxy_challenge" "record_route" "redirecting" "remove_hf" "resetflag" "rtpengine_answer" "rtpengine_delete" "rtpengine_offer" "save" "sdp_content" "sdp_transport" "send_reply_mode" "send_reply" "setbflag" "setflag" "setxflag" "set_reply_close" "set_reply_no_connect" "set_rtpengine_set" "set_uri_host" "set_uri_user" "set_forward_no_connect" "sql_query" "sql_result_free" "starts_with" "subst_uri" "tel2sip" "t_check_status" "t_is_canceled" "t_load_contacts" "t_next_contacts" "t_on_branch" "t_on_failure" "t_on_reply" "t_relay_cancel" "t_relay" "t_set_fr" "unregister" "WARN" "ws_handle_handshake" "www_challenge" "xhttp_reply"))
>             (x-keywords-regexp (regexp-opt x-keywords 'words))
>             (x-types-regexp (regexp-opt x-types 'words))
>             (x-constants-regexp (regexp-opt x-constants 'words))
>             (x-events-regexp (regexp-opt x-events 'words))
>             (x-functions-regexp (regexp-opt x-functions 'words)))
>         `(
>           (,x-types-regexp . font-lock-type-face)
>           (,x-constants-regexp . font-lock-constant-face)
>           (,x-events-regexp . font-lock-builtin-face)
>           (,x-functions-regexp . font-lock-function-name-face)
>           (,x-keywords-regexp . font-lock-keyword-face)
>           )))
>
> (defvar kamailio-mode-syntax-table nil "Syntax table for `kamailio-mode'.")
>
> (setq kamailio-mode-syntax-table
>       (let ( (synTable (make-syntax-table)))
>         ;; python style comment: ?# ??
>         (modify-syntax-entry ?# "<" synTable)
>         (modify-syntax-entry ?\n ">" synTable)
>         synTable))
>
> (define-derived-mode kamailio-mode c-mode "kamailio mode"
>   "Major mode for editing Kamailio configuration files"
>   (setq font-lock-defaults '((kamailio-font-lock-keywords)))
>   (set-syntax-table kamailio-mode-syntax-table))
>
> (provide 'kamailio-mode)
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla




From jh at tutpro.com  Thu Dec 10 09:33:43 2020
From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 10 Dec 2020 10:33:43 +0200
Subject: [SR-Users] kamailio.cfg fomatter
In-Reply-To: <6775839b-8010-fa74-74cd-ae622a1a33d2@gmail.com>
References: <24529.51064.922965.868083@tutpro.com>
 <6775839b-8010-fa74-74cd-ae622a1a33d2@gmail.com>
Message-ID: <24529.56679.925914.552799@tutpro.com>

Daniel-Constantin Mierla writes:

> this is syntax highlighting for kamailio.cfg, right?

Yes, plus indentation, which it inherits from c-mode.

> We can create a repo on kamailio github oraganization, like
> emacs-kamailio-syntax, similar to what is now for vim:
> 
> ? * https://github.com/kamailio/vim-kamailio-syntax

OK, Juha


From adi.tabacioiu at c-s.ro  Thu Dec 10 09:58:29 2020
From: adi.tabacioiu at c-s.ro (Adrian Tabacioiu)
Date: Thu, 10 Dec 2020 10:58:29 +0200
Subject: [SR-Users] REGINFO events not sending
In-Reply-To: <00d401d6c88c$ae5597f0$0b00c7d0$@c-s.ro>
References: <000001d6c3e5$8a057970$9e106c50$@c-s.ro>
 <AM0PR05MB65956A9ABAD02A38ECB32B0AC5F80@AM0PR05MB6595.eurprd05.prod.outlook.com>
 <00d401d6c88c$ae5597f0$0b00c7d0$@c-s.ro>
Message-ID: <000401d6ced2$a168c3e0$e43a4ba0$@c-s.ro>

Hello,

 

For somebody else that would reach here with the same issues, one of the
problem was that Kamailio does not accept its own messages coming on the
loopback interface (strange, no ?).

 

The solution is described in the post bellow.

https://lists.kamailio.org/pipermail/sr-users/2015-September/089879.html

 

Cheers,

Adrian

 

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Adrian
Tabacioiu
Sent: Wednesday, December 2, 2020 11:23 AM
To: 'Henning Westerholt' <hw at skalatan.de>; 'Kamailio (SER) - Users Mailing
List' <sr-users at lists.kamailio.org>
Subject: Re: [SR-Users] REGINFO events not sending

 

Hello Henning,

 

I receive presence notifications are working, I activated presence using
"WITH_PRESENCE" define.

 

Is there anything else I should do for reginfo ?

On the internet I don't find other examples than smsops project which seams
very particular, and documentation is very thin.

 

Thanks,

Adrian

 

 

From: Henning Westerholt <hw at skalatan.de <mailto:hw at skalatan.de> > 
Sent: Friday, November 27, 2020 9:58 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org
<mailto:sr-users at lists.kamailio.org> >
Cc: Adrian Tabacioiu <adi.tabacioiu at c-s.ro <mailto:adi.tabacioiu at c-s.ro> >
Subject: RE: [SR-Users] REGINFO events not sending

 

Hello Adrian,

 

are you also doing the usual presence stuff in your config, e.g. handling
subscriptions of the users?

 

The module documentation not much extensive, I would suggest to search for
some examples how to use it. There might be also something in the kamailio
repository or can be found on the net.

 

Cheers,

 

Henning

 

-- 

Henning Westerholt -  <https://skalatan.de/blog/> https://skalatan.de/blog/

Kamailio services -  <https://gilawa.com/> https://gilawa.com 

 

From: sr-users <sr-users-bounces at lists.kamailio.org
<mailto:sr-users-bounces at lists.kamailio.org> > On Behalf Of Adrian Tabacioiu
Sent: Thursday, November 26, 2020 12:16 PM
To: 'Kamailio (SER) - Users Mailing List' <sr-users at lists.kamailio.org
<mailto:sr-users at lists.kamailio.org> >
Subject: [SR-Users] REGINFO events not sending

 

Hello,

 

Does anybody has used with success the reginfo modules ?

I added lines bellow in configuration, and tried different variations, 

Even if my  subscribe for "reginfo" events  is accepted (with 202 OK), I
receive no notification when respective user registers.

Nor do I get the xml body in the first notification.

 

Added in my config:

 

 

loadmodule "presence_reginfo.so"

loadmodule "pua_reginfo.so"

 

modparam("pua_reginfo", "default_domain", "192.168.60.65")

modparam("pua_reginfo", "server_address", "sip:reginfo at 192.168.60.65")

modparam("pua_reginfo", "publish_reginfo", 1)

 

Thank you in advance,

Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/7b284916/attachment.htm>

From miconda at gmail.com  Thu Dec 10 10:09:19 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 10 Dec 2020 10:09:19 +0100
Subject: [SR-Users] kamailio.cfg fomatter
In-Reply-To: <24529.56679.925914.552799@tutpro.com>
References: <24529.51064.922965.868083@tutpro.com>
 <6775839b-8010-fa74-74cd-ae622a1a33d2@gmail.com>
 <24529.56679.925914.552799@tutpro.com>
Message-ID: <2c04826e-cff5-7cba-8499-82ad5a7f1792@gmail.com>

I created the repo:

? * https://github.com/kamailio/emacs-kamailio-syntax

You can add the new file there and eventually a few notes in the
README.md how to install it.

Otherwise, any existing developer should be able to push commits to this
repo.

Cheers,
Daniel

On 10.12.20 09:33, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> this is syntax highlighting for kamailio.cfg, right?
> Yes, plus indentation, which it inherits from c-mode.
>
>> We can create a repo on kamailio github oraganization, like
>> emacs-kamailio-syntax, similar to what is now for vim:
>>
>> ? * https://github.com/kamailio/vim-kamailio-syntax
> OK, Juha

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From g.wolzak at kazlow.nl  Thu Dec 10 10:33:37 2020
From: g.wolzak at kazlow.nl (Gertjan Wolzak)
Date: Thu, 10 Dec 2020 10:33:37 +0100
Subject: [SR-Users] Dialog profile not defined
Message-ID: <aa6cd1f0-0e2e-f096-a842-6b51d4d76935@kazlow.nl>

Hello Kamailions,

Well, I think I found the cause of my issue where the Dialog profile was 
not defined.. Well it was.

I had not enabled antiflood, by not enabling antiflood, the htable 
module was also not loaded...

I guess the us of profiles_with_value parameter needs htable? Is that 
correct?

If so, that means the htable is a dependency for the dialog module...., 
then it would be sometihng that could be added to the documentation of 
the dialog module.

When this is not the case, then I have to dig deeper, as I do not get an 
error anymore about the profile not being known...

Thank you.

Gertjan



From volodyaivanets at gmail.com  Thu Dec 10 10:49:24 2020
From: volodyaivanets at gmail.com (=?UTF-8?B?0JLQvtC70L7QtNC40LzQuNGAINCG0LLQsNC90LXRhtGM?=)
Date: Thu, 10 Dec 2020 11:49:24 +0200
Subject: [SR-Users] Kamilio+asterisk = deregister after 2-3 minute
In-Reply-To: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>
References: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>
Message-ID: <CAOQgkjbu8eKfsM-KtNApOoEPv2z-ehncsr6f2w7Wq6LxO3NiTw@mail.gmail.com>

Hello,

Can you see some warnings or errors in the Kamailio log file? If no, try to
increase the verbosity level.

Also, how does the third REGISTER compares to the first or second one?

??, 10 ????. 2020 ? 09:08 Mihai <m at mokalife.ro> ????:

> Hi,
>
> I am forwarding all the traffic to my asterisk server ( including
> registers)
> everything seems to work when i first register but if stay idle 2-3 minute
> it gets unregistered and then i can't register back unless i restart
> kamailio
> see attached print screen
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/c1603db9/attachment.htm>

From jh at tutpro.com  Thu Dec 10 11:00:57 2020
From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 10 Dec 2020 12:00:57 +0200
Subject: [SR-Users] kamailio.cfg fomatter
In-Reply-To: <2c04826e-cff5-7cba-8499-82ad5a7f1792@gmail.com>
References: <24529.51064.922965.868083@tutpro.com>
 <6775839b-8010-fa74-74cd-ae622a1a33d2@gmail.com>
 <24529.56679.925914.552799@tutpro.com>
 <2c04826e-cff5-7cba-8499-82ad5a7f1792@gmail.com>
Message-ID: <24529.61913.583856.816588@tutpro.com>

Daniel-Constantin Mierla writes:

> You can add the new file there and eventually a few notes in the
> README.md how to install it.

Done, Juha


From volodyaivanets at gmail.com  Thu Dec 10 11:17:23 2020
From: volodyaivanets at gmail.com (=?UTF-8?B?0JLQvtC70L7QtNC40LzQuNGAINCG0LLQsNC90LXRhtGM?=)
Date: Thu, 10 Dec 2020 12:17:23 +0200
Subject: [SR-Users] Dispatcher algorithm 11 possible priority drifting
Message-ID: <CAOQgkjZGcYZLaHunJLx_hY098CmrgYo=m7K-Gk_o=b1tguGUPA@mail.gmail.com>

Hello all!

We are running Kamailio version 5.3.3 with 16 small Asterisk servers.
Kamailio uses a dispatcher module to distribute calls. Algorithm #11 is
selected. All destinations are configured with priority set to 50 and
attribute to rweight=50.

We noticed that one server constantly receives more calls than others. I
run a few tests. I was sending 1000 calls to the system. 4 per second. All
servers except one were getting around 60 calls while the last one - around
100.

I then noticed that the server which receives most calls is always last in
the "kamcmd dispatcher.list" command output. I then changed the order in
the dispatcher DB table and repeat the test. The other server that now was
last was getting the most calls.

Does anyone else use algorithm #11 and finds the same thing? Is there
something additional that I can provide to help with the investigation?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/ec0511e6/attachment.htm>

From hw at skalatan.de  Thu Dec 10 11:21:44 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Thu, 10 Dec 2020 10:21:44 +0000
Subject: [SR-Users] Dialog profile not defined
In-Reply-To: <aa6cd1f0-0e2e-f096-a842-6b51d4d76935@kazlow.nl>
References: <aa6cd1f0-0e2e-f096-a842-6b51d4d76935@kazlow.nl>
Message-ID: <AM0PR05MB6595B222D32F846B9638B017C5CB0@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hi Gertjan,

there is no usage of the htable API etc.. in the dialog module. So if there is a dependency in your setup, it can be only be implemented in your cfg.

Cheers,

Henning

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

-----Original Message-----
From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Gertjan Wolzak
Sent: Thursday, December 10, 2020 10:34 AM
To: sr-users at lists.kamailio.org
Subject: Re: [SR-Users] Dialog profile not defined

Hello Kamailions,

Well, I think I found the cause of my issue where the Dialog profile was not defined.. Well it was.

I had not enabled antiflood, by not enabling antiflood, the htable module was also not loaded...

I guess the us of profiles_with_value parameter needs htable? Is that correct?

If so, that means the htable is a dependency for the dialog module...., then it would be sometihng that could be added to the documentation of the dialog module.

When this is not the case, then I have to dig deeper, as I do not get an error anymore about the profile not being known...

Thank you.

Gertjan


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


From g.wolzak at kazlow.nl  Thu Dec 10 11:43:57 2020
From: g.wolzak at kazlow.nl (Gertjan Wolzak)
Date: Thu, 10 Dec 2020 11:43:57 +0100
Subject: [SR-Users] Dialog profile not defined
In-Reply-To: <AM0PR05MB6595B222D32F846B9638B017C5CB0@AM0PR05MB6595.eurprd05.prod.outlook.com>
References: <aa6cd1f0-0e2e-f096-a842-6b51d4d76935@kazlow.nl>
 <AM0PR05MB6595B222D32F846B9638B017C5CB0@AM0PR05MB6595.eurprd05.prod.outlook.com>
Message-ID: <4b288a2f-fb61-473d-51fb-fc4992aaae27@kazlow.nl>

Hello Henning,

Thank you, will keep digging...

Dialog does work now, so priority is a bit lower.

Gertjan

On 12/10/20 11:21 AM, Henning Westerholt wrote:
> Hi Gertjan,
>
> there is no usage of the htable API etc.. in the dialog module. So if there is a dependency in your setup, it can be only be implemented in your cfg.
>
> Cheers,
>
> Henning
>


From sergio.charrua at voip.pt  Thu Dec 10 12:00:47 2020
From: sergio.charrua at voip.pt (Sergio Charrua)
Date: Thu, 10 Dec 2020 11:00:47 +0000
Subject: [SR-Users] Dispatcher algorithm 11 possible priority drifting
In-Reply-To: <CAOQgkjZGcYZLaHunJLx_hY098CmrgYo=m7K-Gk_o=b1tguGUPA@mail.gmail.com>
References: <CAOQgkjZGcYZLaHunJLx_hY098CmrgYo=m7K-Gk_o=b1tguGUPA@mail.gmail.com>
Message-ID: <CALZWR5wZ6Pmye0yn6uteW8pDFJD18eO3nJ2esniU_zW71D2CvQ@mail.gmail.com>

I noticed the exact same behaviour with my implementation, even though the
priority and rweight are different.
until now, i'm ignoring the "issue". But if there is a fix, I would like to
know too.

*S?rgio Charrua*


*www.voip.pt <http://www.voip.pt/>*
Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77

Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Thu, Dec 10, 2020 at 10:20 AM ????????? ??????? <volodyaivanets at gmail.com>
wrote:

> Hello all!
>
> We are running Kamailio version 5.3.3 with 16 small Asterisk servers.
> Kamailio uses a dispatcher module to distribute calls. Algorithm #11 is
> selected. All destinations are configured with priority set to 50 and
> attribute to rweight=50.
>
> We noticed that one server constantly receives more calls than others. I
> run a few tests. I was sending 1000 calls to the system. 4 per second. All
> servers except one were getting around 60 calls while the last one - around
> 100.
>
> I then noticed that the server which receives most calls is always last in
> the "kamcmd dispatcher.list" command output. I then changed the order in
> the dispatcher DB table and repeat the test. The other server that now was
> last was getting the most calls.
>
> Does anyone else use algorithm #11 and finds the same thing? Is there
> something additional that I can provide to help with the investigation?
>
> Thanks!
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/b508f450/attachment.htm>

From miconda at gmail.com  Thu Dec 10 14:02:00 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 10 Dec 2020 14:02:00 +0100
Subject: [SR-Users] Dispatcher algorithm 11 possible priority drifting
In-Reply-To: <CALZWR5wZ6Pmye0yn6uteW8pDFJD18eO3nJ2esniU_zW71D2CvQ@mail.gmail.com>
References: <CAOQgkjZGcYZLaHunJLx_hY098CmrgYo=m7K-Gk_o=b1tguGUPA@mail.gmail.com>
 <CALZWR5wZ6Pmye0yn6uteW8pDFJD18eO3nJ2esniU_zW71D2CvQ@mail.gmail.com>
Message-ID: <1a4056c4-9156-1e1c-b27e-c4bad4f14fe7@gmail.com>

Hello,

that's how the algorithm is implemented and the last one has more calls
because it is used to fill the slots left empty because of truncation in
percentage computation.

The weight is a percentage as an integer value, practically an integer
from 1 to 100.

So, if you have 16 gateways to route to with dispatcher, each with
weight 50, then the sum of weights is 800. The percentage corresponding
to each gateway is computed with (50/800)*100 = 6.25, converted to
integer is 6.

Now, 6*16=96, so 4 slots were left empty, which are filled with the last
destination that results in 10 slots for it.

I haven't implemented the rweight algorithm, but for the weight
algorithm is expected to set the value to an integer from 1 to 100 and
have the sum of them to be 100, otherwise also the last gateway fills
the empty slots. Moreover, if the sum exceeds 100, then the gateways
that end up after the 100 slots will be ignored.

Note that there are other algorithms if you want even distribution, like
round robin or call load balancing.

Cheers,
Daniel

On 10.12.20 12:00, Sergio Charrua wrote:
> I noticed the exact same behaviour with my implementation, even though
> the priority and rweight?are different.?
> until now, i'm ignoring the "issue". But if there is a fix, I would
> like to know too.
>
> *S?rgio Charrua*
>
> *
> *
>
> *www.voip.pt <http://www.voip.pt/>*
> Tel.:?+351? <callto:+351+91+104+12+66>21 130 71 77
>
> Email :?*sergio.charrua at voip.pt <mailto:sergio.charrua at voip.pt>*
>
> This message and any files or documents attached are strictly
> confidential or otherwise legally protected.?
>
> It is intended only for the individual or entity named. If you are not
> the named addressee or have received this email in error, please
> inform the sender immediately, delete it from your system and do not
> copy or disclose it or its contents or use it for any purpose. Please
> also note that transmission cannot be guaranteed to be secure or
> error-free.
>
> ?
>
> ?
>
>
>
>
>
> On Thu, Dec 10, 2020 at 10:20 AM ????????? ???????
> <volodyaivanets at gmail.com <mailto:volodyaivanets at gmail.com>> wrote:
>
>     Hello all!
>
>     We are running Kamailio version 5.3.3 with 16 small Asterisk
>     servers. Kamailio uses a dispatcher module to distribute calls.
>     Algorithm #11 is selected. All destinations are configured with
>     priority set to 50 and attribute to?rweight=50.
>
>     We noticed that one server constantly receives more calls than
>     others. I run?a few tests. I was sending 1000 calls to the system.
>     4 per second. All servers except one were getting around 60 calls
>     while the last one - around 100.
>
>     I then noticed that the server which receives most calls is
>     always?last in the "kamcmd dispatcher.list" command output. I then
>     changed the order in the dispatcher DB table and repeat the test.
>     The other server that now was last was getting the most calls.
>
>     Does anyone else use algorithm #11 and finds the same thing? Is
>     there something additional that I can provide to help with the
>     investigation?
>
>     Thanks!
>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/703c02b4/attachment.htm>

From miconda at gmail.com  Thu Dec 10 14:21:06 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 10 Dec 2020 14:21:06 +0100
Subject: [SR-Users] kamailio.cfg fomatter
In-Reply-To: <24529.61913.583856.816588@tutpro.com>
References: <24529.51064.922965.868083@tutpro.com>
 <6775839b-8010-fa74-74cd-ae622a1a33d2@gmail.com>
 <24529.56679.925914.552799@tutpro.com>
 <2c04826e-cff5-7cba-8499-82ad5a7f1792@gmail.com>
 <24529.61913.583856.816588@tutpro.com>
Message-ID: <577baca4-be4c-bdf1-854f-81051cf805cd@gmail.com>

Thanks! Published a news article about it:

? *
https://www.kamailio.org/w/2020/12/emacs-syntax-highlighting-for-kamailio-cfg/

Cheers,
Daniel

On 10.12.20 11:00, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> You can add the new file there and eventually a few notes in the
>> README.md how to install it.
> Done, Juha

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From volodyaivanets at gmail.com  Thu Dec 10 17:02:41 2020
From: volodyaivanets at gmail.com (=?UTF-8?B?0JLQvtC70L7QtNC40LzQuNGAINCG0LLQsNC90LXRhtGM?=)
Date: Thu, 10 Dec 2020 18:02:41 +0200
Subject: [SR-Users] Dispatcher algorithm 11 possible priority drifting
In-Reply-To: <1a4056c4-9156-1e1c-b27e-c4bad4f14fe7@gmail.com>
References: <CAOQgkjZGcYZLaHunJLx_hY098CmrgYo=m7K-Gk_o=b1tguGUPA@mail.gmail.com>
 <CALZWR5wZ6Pmye0yn6uteW8pDFJD18eO3nJ2esniU_zW71D2CvQ@mail.gmail.com>
 <1a4056c4-9156-1e1c-b27e-c4bad4f14fe7@gmail.com>
Message-ID: <CAOQgkjZjUoxFf9gt0ZvcbRx0WB5_PunZwRPcc_dNk51QWHbCHw@mail.gmail.com>

Hello Daniel,

Thank you for the explanation!

??, 10 ????. 2020 ? 15:04 Daniel-Constantin Mierla <miconda at gmail.com> ????:

> Hello,
>
> that's how the algorithm is implemented and the last one has more calls
> because it is used to fill the slots left empty because of truncation in
> percentage computation.
>
> The weight is a percentage as an integer value, practically an integer
> from 1 to 100.
>
> So, if you have 16 gateways to route to with dispatcher, each with weight
> 50, then the sum of weights is 800. The percentage corresponding to each
> gateway is computed with (50/800)*100 = 6.25, converted to integer is 6.
>
> Now, 6*16=96, so 4 slots were left empty, which are filled with the last
> destination that results in 10 slots for it.
>
> I haven't implemented the rweight algorithm, but for the weight algorithm
> is expected to set the value to an integer from 1 to 100 and have the sum
> of them to be 100, otherwise also the last gateway fills the empty slots.
> Moreover, if the sum exceeds 100, then the gateways that end up after the
> 100 slots will be ignored.
>
> Note that there are other algorithms if you want even distribution, like
> round robin or call load balancing.
>
> Cheers,
> Daniel
> On 10.12.20 12:00, Sergio Charrua wrote:
>
> I noticed the exact same behaviour with my implementation, even though the
> priority and rweight are different.
> until now, i'm ignoring the "issue". But if there is a fix, I would like
> to know too.
>
> *S?rgio Charrua*
>
>
> *www.voip.pt <http://www.voip.pt/>*
> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>
> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
>
> On Thu, Dec 10, 2020 at 10:20 AM ????????? ??????? <
> volodyaivanets at gmail.com> wrote:
>
>> Hello all!
>>
>> We are running Kamailio version 5.3.3 with 16 small Asterisk servers.
>> Kamailio uses a dispatcher module to distribute calls. Algorithm #11 is
>> selected. All destinations are configured with priority set to 50 and
>> attribute to rweight=50.
>>
>> We noticed that one server constantly receives more calls than others. I
>> run a few tests. I was sending 1000 calls to the system. 4 per second. All
>> servers except one were getting around 60 calls while the last one - around
>> 100.
>>
>> I then noticed that the server which receives most calls is always last
>> in the "kamcmd dispatcher.list" command output. I then changed the order in
>> the dispatcher DB table and repeat the test. The other server that now was
>> last was getting the most calls.
>>
>> Does anyone else use algorithm #11 and finds the same thing? Is there
>> something additional that I can provide to help with the investigation?
>>
>> Thanks!
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/5ba437b8/attachment.htm>

From benoitc at enki-multimedia.eu  Thu Dec 10 13:52:47 2020
From: benoitc at enki-multimedia.eu (Benoit Chesneau)
Date: Thu, 10 Dec 2020 12:52:47 +0000
Subject: [SR-Users] porting keepalive module new functions on 5.4 on 5.3?
Message-ID: <KUKz-dQnZxe_QJlKj8V_wCY9wRk1JuN_fSN5TraJ3qRyw6lMPWbI2Sq4cQKzS5FyEMInzlSSCnkURqRsXafSl1cn3WlSFpuFb3idMZGfzoM=@enki-multimedia.eu>

2 new functions have been added to the keepalive module:

- [ka_add_destination(sip_uri, owner)](https://kamailio.org/docs/modules/5.4.x/modules/keepalive.html#keepalive.ka_add_destination)

- [ka_del_destination(sip_uri, owner)](https://kamailio.org/docs/modules/5.4.x/modules/keepalive.html#keepalive.ka_del_destination)

Is there any possibility to do the same on 5.3? It seems that on 5.3 adding a destination can only be done statically:
https://kamailio.org/docs/modules/5.3.x/modules/keepalive.html#idm53

or can it also be done dynamically when receiving an event using the kazoo module for example?

Beno?t Chesneau, Enki Multimedia
?
t. +33608655490

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/617481d9/attachment.htm>

From hw at skalatan.de  Fri Dec 11 08:47:26 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Fri, 11 Dec 2020 07:47:26 +0000
Subject: [SR-Users] porting keepalive module new functions on 5.4 on 5.3?
In-Reply-To: <KUKz-dQnZxe_QJlKj8V_wCY9wRk1JuN_fSN5TraJ3qRyw6lMPWbI2Sq4cQKzS5FyEMInzlSSCnkURqRsXafSl1cn3WlSFpuFb3idMZGfzoM=@enki-multimedia.eu>
References: <KUKz-dQnZxe_QJlKj8V_wCY9wRk1JuN_fSN5TraJ3qRyw6lMPWbI2Sq4cQKzS5FyEMInzlSSCnkURqRsXafSl1cn3WlSFpuFb3idMZGfzoM=@enki-multimedia.eu>
Message-ID: <AM6PR05MB65982B660932E1984057C115C5CA0@AM6PR05MB6598.eurprd05.prod.outlook.com>

Hello Benoit,

the current stable branches 5.3. and 5.4 only receiving bugfixes and similar changes after release, this our current release policy.

You could ask one of the companies providing commercial services to Kamailio e.g., from this list https://www.kamailio.org/w/business-directory/ for providing you with a custom backport of the module.
Of course you can also investigate it by yourself.

Cheers,

Henning

--
Henning Westerholt ? https://skalatan.de/blog/
Kamailio services ? https://gilawa.com<https://gilawa.com/>

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Benoit Chesneau
Sent: Thursday, December 10, 2020 1:53 PM
To: sr-users at lists.kamailio.org
Subject: [SR-Users] porting keepalive module new functions on 5.4 on 5.3?

2 new functions have been added to the keepalive module:
?         ka_add_destination(sip_uri, owner)<https://kamailio.org/docs/modules/5.4.x/modules/keepalive.html#keepalive.ka_add_destination>
?         ka_del_destination(sip_uri, owner)<https://kamailio.org/docs/modules/5.4.x/modules/keepalive.html#keepalive.ka_del_destination>
Is there any possibility to do the same on 5.3?  It seems that on 5.3 adding a destination can only be done statically:
https://kamailio.org/docs/modules/5.3.x/modules/keepalive.html#idm53

or can it also be done dynamically when receiving an event using the kazoo module for example?

Beno?t Chesneau, Enki Multimedia
?
t. +33608655490

Sent with ProtonMail<https://protonmail.com> Secure Email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/08ad9c89/attachment.htm>

From adi.tabacioiu at c-s.ro  Fri Dec 11 13:10:28 2020
From: adi.tabacioiu at c-s.ro (Adrian Tabacioiu)
Date: Fri, 11 Dec 2020 14:10:28 +0200
Subject: [SR-Users] empty body on first NOTIFY on REGINFO subscription - bug
 ?
Message-ID: <004001d6cfb6$9d5d1910$d8174b30$@c-s.ro>

Hello,

 

If the user never registered (or few hours passed from its unregister) the
subscription to REGINFO will return an empty body NOTIFY (no xml).

I don't see any flag in module to force a body for this case,  as in the
presence module is force_dummy_presence who can force a body on a first
NOTIFY.

 

The RFC3680 says :

      o  Notifications triggered from a SUBSCRIBE contain full state
         (the list of all contacts bound to the address-of-record).

 

It appears that in this case the response is not conform to RFC.

 

Regards,

Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/00d51202/attachment.htm>

From agiftel at gmail.com  Fri Dec 11 08:26:57 2020
From: agiftel at gmail.com (Agiftel)
Date: Fri, 11 Dec 2020 00:26:57 -0700 (MST)
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <584348691.5654827.1607423847408@mail.yahoo.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
 <584348691.5654827.1607423847408@mail.yahoo.com>
Message-ID: <1607671617517-0.post@n5.nabble.com>

Thank Daniel and me.projects at yahoo.com.
I used SIPDUMP and works perfectly!

regards




--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From i.ribakov at zaleos.net  Fri Dec 11 11:04:47 2020
From: i.ribakov at zaleos.net (Ivan Ribakov)
Date: Fri, 11 Dec 2020 11:04:47 +0100
Subject: [SR-Users] Wrong To tag in t_reply
Message-ID: <E2557ECA-B08D-4D67-BF57-B7CAE92A107E@zaleos.net>

Hi all,

I?m trying to implement following routing behaviour:

- ingress INVITE is sequentially forked to 1 or more endpoints
- under certain conditions sequential forking may be stopped and pre-defined error returned to the caller

Here?s is part of the config responsible for handling errors:

failure_route[ROUTE_ELEMENT_FINAL_FAILURE_HELPER] {
    route(ROUTE_ELEMENT_FINAL_FAILURE);
}

route[ROUTE_ELEMENT_FINAL_FAILURE] {
    # We need to check if the error happens before the first egress, because T-state is not defined yet so we can not use t_reply
    if ($var(before_first_egress) == 0) {
        t_reply("$var(sipCode)", "$var(sipMessage)");
    } else {
        sl_send_reply("$var(sipCode)", "$var(sipMessage)");
    }
}



Here is a simple scenario where delivering call to first endpoint times out after receiving 180 Ringing (using custom fr_inv_timer value) where:
- .33 is caller
- .208 is Kamailio
- .138 is callee



Notice that 504 is retransmitted by Kamailio. Here is a comparison of 180 and 504 returned by Kamailio:



As can be seen, 180 was proxied from the callee and has callee?s to-tag (tag=CALLEE1), however 504 that was generated by Kamailio using t_reply() has a different to-tag (presumably generated by Kamailio).

How can I tell Kamailio not to generate new to-tag but to use the last one that proxied back to the caller?

Thanks in advance for any help!

Regards,
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/f42dd522/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 51562 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/f42dd522/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.tiff
Type: image/tiff
Size: 102494 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/f42dd522/attachment.tiff>

From miconda at gmail.com  Fri Dec 11 14:06:14 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 11 Dec 2020 14:06:14 +0100
Subject: [SR-Users] Wrong To tag in t_reply
In-Reply-To: <E2557ECA-B08D-4D67-BF57-B7CAE92A107E@zaleos.net>
References: <E2557ECA-B08D-4D67-BF57-B7CAE92A107E@zaleos.net>
Message-ID: <ad0cdb3a-9300-a7f1-8c27-115dd2320201@gmail.com>

Hello,

actually you are wrong that you think it is a wrong to tag. The entity
that generates the final reply sets the to-tag (e.g.,to be able to match
ack). Even here where you talk about the serial forking, you are going
to face the case of different to-tag values for each branch sent out and
replied. But also think about parallel forking, that timed out with many
active branches, which to-tag to use?!?

So think that kamailio itself is the branch of the incoming request, and
can create many outgoing branches. If it generates a final reply, it
does it to the incoming branch. It is not forwarding (sending back) a
reply from an outgoing branch.

Obviously, being open source, one can code a specific behaviour for some
specific needs, but is not SIP specs compliant. If the upstream cannot
deal with different to-tags, it won't really work with serial/parallel
forking anyhow.

As a side remark, seeing the comments, if
route(ROUTE_ELEMENT_FINAL_FAILURE) is used only in failure_route, then
transaction is always defined there, because failure_route is executed
only in the transaction context. Anyhow, if you are using in many
places, not knowing if transaction was created, you can use send_reply()
to avoid any test in the config.

Cheers,
Daniel

On 11.12.20 11:04, Ivan Ribakov wrote:
> Hi all,
>
> I?m trying to implement following routing behaviour:
>
> - ingress INVITE is sequentially forked to 1 or more endpoints
> - under certain conditions sequential forking may be stopped and
> pre-defined error returned to the caller
>
> Here?s is part of the config responsible for handling errors:
>
> failure_route[ROUTE_ELEMENT_FINAL_FAILURE_HELPER] {
> route(ROUTE_ELEMENT_FINAL_FAILURE);
> }
> route[ROUTE_ELEMENT_FINAL_FAILURE] {
> # We need to check if the error happens before the first egress,
> because T-state is not defined yet so we can not use t_reply
> if ($var(before_first_egress) == 0) {
> t_reply("$var(sipCode)", "$var(sipMessage)");
> } else {
> sl_send_reply("$var(sipCode)", "$var(sipMessage)");
> }
> }
>
>
>
> Here is a simple scenario where delivering call to first endpoint
> times out after receiving 180 Ringing (using custom fr_inv_timer
> value) where:
> - .33 is caller
> - .208 is Kamailio
> - .138 is callee
>
>
>
> Notice that 504 is retransmitted by Kamailio. Here is a comparison of
> 180 and 504 returned by Kamailio:
>
>
>
> As can be seen, 180 was proxied from the callee and has callee?s
> to-tag (tag=CALLEE1), however 504 that was generated by Kamailio using
> t_reply() has a different to-tag (presumably generated by Kamailio).
>
> How can I tell Kamailio not to generate new to-tag but to use the last
> one that proxied back to the caller?
>
> Thanks in advance for any help!
>
> Regards,
> Ivan
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/cd605bfd/attachment.htm>

From cezar at mokalife.ro  Fri Dec 11 14:23:35 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Fri, 11 Dec 2020 15:23:35 +0200
Subject: [SR-Users] Kamilio+asterisk = deregister after 2-3 minute
In-Reply-To: <CAOQgkjbu8eKfsM-KtNApOoEPv2z-ehncsr6f2w7Wq6LxO3NiTw@mail.gmail.com>
References: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>
 <CAOQgkjbu8eKfsM-KtNApOoEPv2z-ehncsr6f2w7Wq6LxO3NiTw@mail.gmail.com>
Message-ID: <CANk_n4abwW4TrLggb7rKtqTH9VxcVa_2cwDgTvyZCQ6H_5s7OA@mail.gmail.com>

Hello, You right, i've found something, seems that the kamailio-probe it
puts the destination down. Any ideas why it's doing this ?


: ds_run_route(): ds_run_route event_route[dispatcher:dst-down
: ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
3afe874f6d71811b-24504 at 127.0.0.1} dispatcher
: ds_options_callback(): OPTIONS-Request was finished with code 404 (to
sip:10.1.2.2;transport=udp, group 1)
: ds_update_state(): update state for sip:10.1.2.2;transport=udp in group 1
to 10
: ds_update_state(): destination did not replied 10 times, threshold 10
: ds_update_state(): deactivate destination, threshold 10 reached
: ds_run_route(): ds_run_route event_route[dispatcher:dst-down
: ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
3afe874f6d71811c-24504 at 127.0.0.1} dispatcher [dispatch.c:2805
: ds_manage_routes(): set 1

On Thu, Dec 10, 2020 at 11:53 AM ????????? ??????? <volodyaivanets at gmail.com>
wrote:

> Hello,
>
> Can you see some warnings or errors in the Kamailio log file? If no, try
> to increase the verbosity level.
>
> Also, how does the third REGISTER compares to the first or second one?
>
> ??, 10 ????. 2020 ? 09:08 Mihai <m at mokalife.ro> ????:
>
>> Hi,
>>
>> I am forwarding all the traffic to my asterisk server ( including
>> registers)
>> everything seems to work when i first register but if stay idle 2-3
>> minute it gets unregistered and then i can't register back unless i restart
>> kamailio
>> see attached print screen
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/ff47603e/attachment.htm>

From barry at flanagan.ie  Fri Dec 11 14:34:01 2020
From: barry at flanagan.ie (Barry Flanagan)
Date: Fri, 11 Dec 2020 13:34:01 +0000
Subject: [SR-Users] Kamilio+asterisk = deregister after 2-3 minute
In-Reply-To: <CANk_n4abwW4TrLggb7rKtqTH9VxcVa_2cwDgTvyZCQ6H_5s7OA@mail.gmail.com>
References: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>
 <CAOQgkjbu8eKfsM-KtNApOoEPv2z-ehncsr6f2w7Wq6LxO3NiTw@mail.gmail.com>
 <CANk_n4abwW4TrLggb7rKtqTH9VxcVa_2cwDgTvyZCQ6H_5s7OA@mail.gmail.com>
Message-ID: <e549576c-3cbe-ca5f-c86c-9fa4007c2e5c@flanagan.ie>

On 11/12/2020 13:23, Mihai Cezar wrote:
> Hello, You right, i've found something, seems that the kamailio-probe 
> it puts the destination down. Any ideas why it's doing this ?
>

"OPTIONS-Request was finished with code 404"

The OPTIONS returns a 404. You need to put something into your default 
context in Asterisk so it returns 200. If your default context is 
"default" then this would work in extensions.conf:

/[default]/

/exten => s,1,Hangup()/

Then do a "dialplan reload" in asterisk.

Hope this helps

-Barry Flanagan

>
> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS 
> 3afe874f6d71811b-24504 at 127.0.0.1 
> <mailto:3afe874f6d71811b-24504 at 127.0.0.1>} dispatcher
> : ds_options_callback(): OPTIONS-Request was finished with code 404 
> (to sip:10.1.2.2;transport=udp, group 1)
> : ds_update_state(): update state for sip:10.1.2.2;transport=udp in 
> group 1 to 10
> : ds_update_state(): destination did not replied 10 times, threshold 10
> : ds_update_state(): deactivate destination, threshold 10 reached
> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS 
> 3afe874f6d71811c-24504 at 127.0.0.1 
> <mailto:3afe874f6d71811c-24504 at 127.0.0.1>} dispatcher [dispatch.c:2805
> : ds_manage_routes(): set 1
>
> On Thu, Dec 10, 2020 at 11:53 AM ????????? ??????? 
> <volodyaivanets at gmail.com <mailto:volodyaivanets at gmail.com>> wrote:
>
>     Hello,
>
>     Can you see some warnings or errors in the Kamailio log file? If
>     no, try to increase the verbosity?level.
>
>     Also, how does the third REGISTER compares to the first or second one?
>
>     ??, 10 ????. 2020 ? 09:08 Mihai <m at mokalife.ro
>     <mailto:m at mokalife.ro>> ????:
>
>         Hi,
>
>         I am forwarding all the traffic to my asterisk server (
>         including registers)
>         everything seems to work when i first register but if stay
>         idle 2-3 minute it gets unregistered and then i can't register
>         back unless i restart kamailio
>         see attached print screen
>         _______________________________________________
>         Kamailio (SER) - Users Mailing List
>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>         <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
-Barry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/187210e1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB1C81B216B50A825.asc
Type: application/pgp-keys
Size: 3066 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/187210e1/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/187210e1/attachment.sig>

From amit.pal at coraltele.com  Fri Dec 11 17:18:59 2020
From: amit.pal at coraltele.com (Amit Pal)
Date: Fri, 11 Dec 2020 21:48:59 +0530 (IST)
Subject: [SR-Users] Kamailio dtmf signaling
Message-ID: <696670593.222.1607703539680.JavaMail.zimbra@coraltele.com>

Dear Team, 
I am using kamailio + rtpengine, how can I processed dtmf from cfg scripts. even thought I can able to see dtmf over syslog. 
but can not able to capture in kamailio.cfg. 
how can I prepared ivr using kamalio? 
Please find the attached syslog. 


Regards 
Amit Pal 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/e5109625/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtmf-type-rfc2833-log
Type: application/octet-stream
Size: 6249 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/e5109625/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtmf-type-INFO-log
Type: application/octet-stream
Size: 5650 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/e5109625/attachment-0001.obj>

From joel at textplus.com  Fri Dec 11 20:57:31 2020
From: joel at textplus.com (Joel Serrano)
Date: Fri, 11 Dec 2020 11:57:31 -0800
Subject: [SR-Users] Kamilio+asterisk = deregister after 2-3 minute
In-Reply-To: <e549576c-3cbe-ca5f-c86c-9fa4007c2e5c@flanagan.ie>
References: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>
 <CAOQgkjbu8eKfsM-KtNApOoEPv2z-ehncsr6f2w7Wq6LxO3NiTw@mail.gmail.com>
 <CANk_n4abwW4TrLggb7rKtqTH9VxcVa_2cwDgTvyZCQ6H_5s7OA@mail.gmail.com>
 <e549576c-3cbe-ca5f-c86c-9fa4007c2e5c@flanagan.ie>
Message-ID: <CAMtXxQ=OJcXFvDpQdW_o0bczRZ+6m9LKs7J=Eq0iUUquM0atWA@mail.gmail.com>

You can also set 404 as a valid response to the OPTIONS in Kam.

On Fri, Dec 11, 2020 at 05:36 Barry Flanagan <barry at flanagan.ie> wrote:

> On 11/12/2020 13:23, Mihai Cezar wrote:
>
> Hello, You right, i've found something, seems that the kamailio-probe it
> puts the destination down. Any ideas why it's doing this ?
>
>
> "OPTIONS-Request was finished with code 404"
>
> The OPTIONS returns a 404. You need to put something into your default
> context in Asterisk so it returns 200. If your default context is "default"
> then this would work in extensions.conf:
>
> *[default]*
>
> *exten => s,1,Hangup()*
>
> Then do a "dialplan reload" in asterisk.
>
> Hope this helps
>
> -Barry Flanagan
>
>
> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
> 3afe874f6d71811b-24504 at 127.0.0.1} dispatcher
> : ds_options_callback(): OPTIONS-Request was finished with code 404 (to
> sip:10.1.2.2;transport=udp, group 1)
> : ds_update_state(): update state for sip:10.1.2.2;transport=udp in group
> 1 to 10
> : ds_update_state(): destination did not replied 10 times, threshold 10
> : ds_update_state(): deactivate destination, threshold 10 reached
> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
> 3afe874f6d71811c-24504 at 127.0.0.1} dispatcher [dispatch.c:2805
> : ds_manage_routes(): set 1
>
> On Thu, Dec 10, 2020 at 11:53 AM ????????? ??????? <
> volodyaivanets at gmail.com> wrote:
>
>> Hello,
>>
>> Can you see some warnings or errors in the Kamailio log file? If no, try
>> to increase the verbosity level.
>>
>> Also, how does the third REGISTER compares to the first or second one?
>>
>> ??, 10 ????. 2020 ? 09:08 Mihai <m at mokalife.ro> ????:
>>
>>> Hi,
>>>
>>> I am forwarding all the traffic to my asterisk server ( including
>>> registers)
>>> everything seems to work when i first register but if stay idle 2-3
>>> minute it gets unregistered and then i can't register back unless i restart
>>> kamailio
>>> see attached print screen
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> -Barry
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/8f6e034d/attachment.htm>

From sergio.charrua at voip.pt  Fri Dec 11 22:33:10 2020
From: sergio.charrua at voip.pt (Sergio Charrua)
Date: Fri, 11 Dec 2020 21:33:10 +0000
Subject: [SR-Users] Kamilio+asterisk = deregister after 2-3 minute
In-Reply-To: <CAMtXxQ=OJcXFvDpQdW_o0bczRZ+6m9LKs7J=Eq0iUUquM0atWA@mail.gmail.com>
References: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>
 <CAOQgkjbu8eKfsM-KtNApOoEPv2z-ehncsr6f2w7Wq6LxO3NiTw@mail.gmail.com>
 <CANk_n4abwW4TrLggb7rKtqTH9VxcVa_2cwDgTvyZCQ6H_5s7OA@mail.gmail.com>
 <e549576c-3cbe-ca5f-c86c-9fa4007c2e5c@flanagan.ie>
 <CAMtXxQ=OJcXFvDpQdW_o0bczRZ+6m9LKs7J=Eq0iUUquM0atWA@mail.gmail.com>
Message-ID: <CALZWR5yuQJ3kK6QhXubWTfMRK9BhNX7HdkwRGuMaWrQCch8ipg@mail.gmail.com>

I will assume that you use Kamailio as SIP Proxy between a SIP Provider
(TelCo) and your Asterisk boxes (using SIP.conf), and that Kamailio is
receiving OPTIONS messages from TelCo, and forwarding those OPTIONS to
Asterisk who will fail to answer.
This is a common implementation with TelCos.The solution is to set Kamailio
to Reply to TelCo, adding following route:

route {
        # OPTIONS requests without a username in the Request-URI but one
        # of our domains or IPs are addressed to the proxy itself and
        # can be answered statelessly.
        if (is_method("OPTIONS"))
        {
                sl_send_reply("200","OK");
                exit;
        }
[.....]

It will then reply SIP 200 to TelCo.
Usually, Asterisk does not answer to SIP OPTION messages coming from TelCos
(and thus acting like a SIP Agent) but it does send OPTIONS to SIP Agents
and peers, which in turn will reply (I think it is set by the Qualify which
pings the SIP peers).
So, in this case, Kamailio should be the one to reply to Telco's SIP OPTION
request with a 200 OK response (if it replies 404 NOT FOUND the TelCo will
then set your servers as OFFLINE and you won't receive calls or SIP
messages anymore, just like it is happening to you in the present).

I think that Asterisk with PJSIP allows replies to OPTION messages, but I
still haven't used PJSIP.....

Hope this helps.

*S?rgio Charrua*


*www.voip.pt <http://www.voip.pt/>*
Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77

Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Fri, Dec 11, 2020 at 8:00 PM Joel Serrano <joel at textplus.com> wrote:

> You can also set 404 as a valid response to the OPTIONS in Kam.
>
> On Fri, Dec 11, 2020 at 05:36 Barry Flanagan <barry at flanagan.ie> wrote:
>
>> On 11/12/2020 13:23, Mihai Cezar wrote:
>>
>> Hello, You right, i've found something, seems that the kamailio-probe it
>> puts the destination down. Any ideas why it's doing this ?
>>
>>
>> "OPTIONS-Request was finished with code 404"
>>
>> The OPTIONS returns a 404. You need to put something into your default
>> context in Asterisk so it returns 200. If your default context is "default"
>> then this would work in extensions.conf:
>>
>> *[default]*
>>
>> *exten => s,1,Hangup()*
>>
>> Then do a "dialplan reload" in asterisk.
>>
>> Hope this helps
>>
>> -Barry Flanagan
>>
>>
>> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
>> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
>> 3afe874f6d71811b-24504 at 127.0.0.1} dispatcher
>> : ds_options_callback(): OPTIONS-Request was finished with code 404 (to
>> sip:10.1.2.2;transport=udp, group 1)
>> : ds_update_state(): update state for sip:10.1.2.2;transport=udp in
>> group 1 to 10
>> : ds_update_state(): destination did not replied 10 times, threshold 10
>> : ds_update_state(): deactivate destination, threshold 10 reached
>> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
>> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
>> 3afe874f6d71811c-24504 at 127.0.0.1} dispatcher [dispatch.c:2805
>> : ds_manage_routes(): set 1
>>
>> On Thu, Dec 10, 2020 at 11:53 AM ????????? ??????? <
>> volodyaivanets at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Can you see some warnings or errors in the Kamailio log file? If no, try
>>> to increase the verbosity level.
>>>
>>> Also, how does the third REGISTER compares to the first or second one?
>>>
>>> ??, 10 ????. 2020 ? 09:08 Mihai <m at mokalife.ro> ????:
>>>
>>>> Hi,
>>>>
>>>> I am forwarding all the traffic to my asterisk server ( including
>>>> registers)
>>>> everything seems to work when i first register but if stay idle 2-3
>>>> minute it gets unregistered and then i can't register back unless i restart
>>>> kamailio
>>>> see attached print screen
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> -Barry
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/3038091b/attachment.htm>

From syedshahryar at gmail.com  Sat Dec 12 05:33:08 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Fri, 11 Dec 2020 23:33:08 -0500
Subject: [SR-Users] How to use port number using $env in listen
Message-ID: <CA+mcf=u8Sn8Yq=U8FLKAzoMs+kLmy1-GabpMOatFx2MUaw6ESA@mail.gmail.com>

I tried many combinations of the following but I keep getting syntax errors:

listen=tls:TLS_IP:$env(TLS_PORT) advertise PUBLIC_IP:$env(TLS_PORT)


TLS_IP and PUBLIC_IP are constants defined at the top using #!define.
And, TLS_PORT is supposed to be the env variable.


-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/a35321bd/attachment.htm>

From syedshahryar at gmail.com  Sat Dec 12 05:42:30 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Fri, 11 Dec 2020 23:42:30 -0500
Subject: [SR-Users] DMQ using Consul
Message-ID: <CA+mcf=tJf3pyuBJmUq6d+=K2d7=wUZpH9eA_sgyrdStY0FT26g@mail.gmail.com>

Can someone share their configuration file explaining how they used consul
to achieve high availability?

-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201211/4ff91beb/attachment.htm>

From abalashov at evaristesys.com  Sat Dec 12 06:00:47 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Sat, 12 Dec 2020 00:00:47 -0500
Subject: [SR-Users] DMQ using Consul
In-Reply-To: <CA+mcf=tJf3pyuBJmUq6d+=K2d7=wUZpH9eA_sgyrdStY0FT26g@mail.gmail.com>
References: <CA+mcf=tJf3pyuBJmUq6d+=K2d7=wUZpH9eA_sgyrdStY0FT26g@mail.gmail.com>
Message-ID: <e06df0d9-223b-db81-9f1f-6af7575c8c0d@evaristesys.com>

On 12/11/20 11:42 PM, Syed Shahryar wrote:

> Can someone share their configuration file explaining how they used 
> consul to achieve high availability?

I'm not sure that there is a direct connection to Kamailio configuration 
there.

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From agiftel at gmail.com  Sat Dec 12 11:22:39 2020
From: agiftel at gmail.com (Agiftel)
Date: Sat, 12 Dec 2020 03:22:39 -0700 (MST)
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <584348691.5654827.1607423847408@mail.yahoo.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
 <584348691.5654827.1607423847408@mail.yahoo.com>
Message-ID: <1607768559710-0.post@n5.nabble.com>

Hi again, I sang victory too soon :-(

It's working perfectly if SIP calls are UDP or TCP based. If are TLS, very
strange thing, i can see all trace inside file .data created by siptrace but
if I open that file using sngrep, TLS calls are never displayed.
Any idea?
If not, anyway, I would like to ask you what is the best way to troubleshoot
TLS calls?
What do you use guys?

Best regards



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From khorsmann at gmail.com  Sat Dec 12 19:57:33 2020
From: khorsmann at gmail.com (Karsten Horsmann)
Date: Sat, 12 Dec 2020 19:57:33 +0100
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <1607768559710-0.post@n5.nabble.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
 <584348691.5654827.1607423847408@mail.yahoo.com>
 <1607768559710-0.post@n5.nabble.com>
Message-ID: <CAFArqsaMhBOqF-PHvQykYyi9bWvPkt_rF8ST4pTZjz0p0ZD5dA@mail.gmail.com>

Hi,

you can also setup an Homer docker instance and use Kamailio as active hep
client (homer encapsulation protocoll).

https://github.com/sipcapture/homer/wiki
So Kamailio sends copies of the signaling traffic via hep to Homer and you
can investigate it.

Cheers
Karsten Horsmann

Agiftel <agiftel at gmail.com> schrieb am Sa., 12. Dez. 2020, 17:30:

> Hi again, I sang victory too soon :-(
>
> It's working perfectly if SIP calls are UDP or TCP based. If are TLS, very
> strange thing, i can see all trace inside file .data created by siptrace
> but
> if I open that file using sngrep, TLS calls are never displayed.
> Any idea?
> If not, anyway, I would like to ask you what is the best way to
> troubleshoot
> TLS calls?
> What do you use guys?
>
> Best regards
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201212/c93bafdd/attachment.htm>

From khorsmann at gmail.com  Sat Dec 12 19:57:33 2020
From: khorsmann at gmail.com (Karsten Horsmann)
Date: Sat, 12 Dec 2020 19:57:33 +0100
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <1607768559710-0.post@n5.nabble.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
 <584348691.5654827.1607423847408@mail.yahoo.com>
 <1607768559710-0.post@n5.nabble.com>
Message-ID: <CAFArqsaMhBOqF-PHvQykYyi9bWvPkt_rF8ST4pTZjz0p0ZD5dA@mail.gmail.com>

Hi,

you can also setup an Homer docker instance and use Kamailio as active hep
client (homer encapsulation protocoll).

https://github.com/sipcapture/homer/wiki
So Kamailio sends copies of the signaling traffic via hep to Homer and you
can investigate it.

Cheers
Karsten Horsmann

Agiftel <agiftel at gmail.com> schrieb am Sa., 12. Dez. 2020, 17:30:

> Hi again, I sang victory too soon :-(
>
> It's working perfectly if SIP calls are UDP or TCP based. If are TLS, very
> strange thing, i can see all trace inside file .data created by siptrace
> but
> if I open that file using sngrep, TLS calls are never displayed.
> Any idea?
> If not, anyway, I would like to ask you what is the best way to
> troubleshoot
> TLS calls?
> What do you use guys?
>
> Best regards
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201212/c93bafdd/attachment-0001.htm>

From syedshahryar at gmail.com  Sun Dec 13 15:19:33 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Sun, 13 Dec 2020 09:19:33 -0500
Subject: [SR-Users] how to use environment variables to set listen address
Message-ID: <CA+mcf=tNQD2eKqKZ3DioF-SKiPqNw=Wg-Fn0nugmdfboEP5AWQ@mail.gmail.com>

This is a generic question about using environment variables in a config
file.

If I want to use below where TLS_IP itself is a constant defined somewhere
else. TLS_IP might be set via an env variable as well.

#!define TLS_TO_LISTEN tls:TLS_IP:$env(TLS_PORT)

Will that work? I see syntax errors and other weird issues. What's the
right syntax?
-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201213/2f0fb368/attachment.htm>

From daniel.donoghue at freespee.com  Sun Dec 13 15:39:32 2020
From: daniel.donoghue at freespee.com (Daniel Donoghue)
Date: Sun, 13 Dec 2020 15:39:32 +0100
Subject: [SR-Users] how to use environment variables to set listen
 address
In-Reply-To: <CA+mcf=tNQD2eKqKZ3DioF-SKiPqNw=Wg-Fn0nugmdfboEP5AWQ@mail.gmail.com>
References: <CA+mcf=tNQD2eKqKZ3DioF-SKiPqNw=Wg-Fn0nugmdfboEP5AWQ@mail.gmail.com>
Message-ID: <EB53DAAB-AEBC-403C-82AD-5633D7134E44@freespee.com>

You can pass in TLS_PORT and TLS_IP as defines using kamailio startup option -A TLS_IP=xxx -A TLS_PORT=xxxx but to my knowledge you can?t otherwise dynamically bind to IPs/Ports once kamailio has started.

Blessings,
?
Daniel Donoghue





> On 13 Dec 2020, at 15:19, Syed Shahryar <syedshahryar at gmail.com> wrote:
> 
> This is a generic question about using environment variables in a config file.
> 
> If I want to use below where TLS_IP itself is a constant defined somewhere else. TLS_IP might be set via an env variable as well.
> 
> #!define TLS_TO_LISTEN tls:TLS_IP:$env(TLS_PORT)
> 
> Will that work? I see syntax errors and other weird issues. What's the right syntax?
> -- 
> --
> This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. If verification is required, please request a hard-copy version.
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201213/03428705/attachment.htm>

From miconda at gmail.com  Mon Dec 14 08:51:24 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 14 Dec 2020 08:51:24 +0100
Subject: [SR-Users] Releasing Kamailio v5.4.3
In-Reply-To: <1e6c9539-7662-f37b-00e0-52d997e860f4@gmail.com>
References: <1e6c9539-7662-f37b-00e0-52d997e860f4@gmail.com>
Message-ID: <973c8fb0-90f9-f27f-0ed9-6597c1382503@gmail.com>

Hello,

short notice to remind that Kamailio v5.4.3 is going to be released
today, therefore any commits to branch 5.4 should be pushed only after
informing on sr-dev mailing list or matrix/irc channel and getting the
ack, in order to not interfere with release building process.

Cheers,
Daniel

On 09.12.20 08:34, Daniel-Constantin Mierla wrote:
> Hello,
>
> I am considering to release Kamailio v5.4.3 sometime next week, likely
> on Monday, December 14, 2020. This is the usual heads up notification to
> see if anyone is aware of issues not yet reported to bug tracker and if
> yes, do it as soon as possible to give them a chance to be fixed.
>
> Cheers,
> Daniel
>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From ataher at vanrise.com  Mon Dec 14 17:27:42 2020
From: ataher at vanrise.com (Ali Taher)
Date: Mon, 14 Dec 2020 16:27:42 +0000
Subject: [SR-Users] voltdb support
Message-ID: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>

Hello,

I just need to know if kamailio can communicate with Voltdb for sqlops operations for example.

Regards,
Ali Taher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/6f724b22/attachment.htm>

From abalashov at evaristesys.com  Mon Dec 14 17:37:31 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 14 Dec 2020 11:37:31 -0500
Subject: [SR-Users] voltdb support
In-Reply-To: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
Message-ID: <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>

Is VoltDB?s wire protocol binary-compatible with Postgres, MySQL, Oracle, or anything reachable via UnixODBC?

From what I understand, no. So, you can?t use SQL-native modules to talk to it.

You can, of course, get Kamailio to talk to it ?manually? for select purposes.

?
Sent from mobile, with due apologies for brevity and errors.

> On Dec 14, 2020, at 11:28 AM, Ali Taher <ataher at vanrise.com> wrote:
> 
> ?
> Hello,
>  
> I just need to know if kamailio can communicate with Voltdb for sqlops operations for example.
>  
> Regards,
> Ali Taher
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/80668b1c/attachment.htm>

From miconda at gmail.com  Mon Dec 14 17:45:49 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 14 Dec 2020 17:45:49 +0100
Subject: [SR-Users] Kamailio v5.4.3 Released
Message-ID: <09c5838e-ae56-55ed-ec1b-61504d463f14@gmail.com>

Hello,

Kamailio SIP Server v5.4.3 stable release is out.

This is a maintenance release of the latest stable branch, 5.4, that
includes fixes since the release of v5.4.2. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.4.x. Deployments running previous v5.4.x
versions are strongly recommended to be upgraded to v5.4.3.

For more details about version 5.4.3 (including links and guidelines to
download the tarball or from GIT repository), visit:

? * https://www.kamailio.org/w/2020/12/kamailio-v5-4-3-released/

RPM, Debian/Ubuntu packages will be available soon as well.

Many thanks to all contributing and using Kamailio!

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda



From duarterocha91 at gmail.com  Mon Dec 14 17:51:11 2020
From: duarterocha91 at gmail.com (Duarte Rocha)
Date: Mon, 14 Dec 2020 16:51:11 +0000
Subject: [SR-Users] Losing MySQL connections
Message-ID: <CAAJJHZinPpPukGVbXyNX2cn6Xj_zOaXEkFyiJ_02cHqx08af6g@mail.gmail.com>

Greetings all,

I'm having some dropped MySQL connections in my Kamailio in times of low or
no activity in the proxy.

These are the errors i'm getting :

    db_mysql [km_dbase.c:123]: db_mysql_submit_query(): driver error on
query: Lost connection to MySQL server during query (2013)
    <core> [db_query.c:348]: db_do_update(): error while submitting query
    usrloc [ucontact.c:1147]: db_update_ucontact_ruid(): updating database
failed
    usrloc [ucontact.c:1663]: update_contact_db(): failed to update database
    registrar [save.c:784]: update_contacts(): failed to update contact
    sl [sl_funcs.c:414]: sl_reply_error(): stateless error reply used: I'm
terribly sorry, server error occurred (1/SL)

In order to try to fix this i've added timeout_interval and ping_interval
from the db_mysql module. Is this the best approach?

I've restarted my Kamailio but i don't see any ping going to my BD. Is
there any other config that I need to add so that the pings are sent?

Is it possible to do a ping to verify connection and reconnect mannualy on
the config file?

Best Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/4fb4c471/attachment.htm>

From ataher at vanrise.com  Mon Dec 14 20:57:11 2020
From: ataher at vanrise.com (Ali Taher)
Date: Mon, 14 Dec 2020 19:57:11 +0000
Subject: [SR-Users] voltdb support
In-Reply-To: <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
Message-ID: <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>

Hi Alex,

Thanks for your answer. How to proceed to let Kamailio talk manually to VoltDB ?

Regards,
Ali Taher

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Monday, December 14, 2020 6:38 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Subject: Re: [SR-Users] voltdb support

Is VoltDB?s wire protocol binary-compatible with Postgres, MySQL, Oracle, or anything reachable via UnixODBC?

From what I understand, no. So, you can?t use SQL-native modules to talk to it.

You can, of course, get Kamailio to talk to it ?manually? for select purposes.
?
Sent from mobile, with due apologies for brevity and errors.


On Dec 14, 2020, at 11:28 AM, Ali Taher <ataher at vanrise.com<mailto:ataher at vanrise.com>> wrote:
?
Hello,

I just need to know if kamailio can communicate with Voltdb for sqlops operations for example.

Regards,
Ali Taher
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/384ca8a4/attachment.htm>

From abalashov at evaristesys.com  Mon Dec 14 21:15:40 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 14 Dec 2020 15:15:40 -0500
Subject: [SR-Users] voltdb support
In-Reply-To: <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
 <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
Message-ID: <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>

You'd have to devise some sort of API or use something that Kamailio can 
talk to, unless you're inclined to write a custom module that uses a 
library[1].

Otherwise, the usual integration paths are available, e.g.

1) You could put a REST API server in front of VoltDB and use:

https://kamailio.org/docs/modules/5.4.x/modules/http_async_client.html

https://kamailio.org/docs/modules/5.4.x/modules/http_client.html

2) Or, you could write a server of some kind which mediates these 
requests using EVAPI:

https://kamailio.org/docs/modules/5.4.x/modules/evapi.html

3) Or, you could write a minimal SIP redirect service using a library 
such as PJSUA/PJSIP, or JAIN,

https://www.oracle.com/technical-resources/articles/enterprise-architecture/introduction-jain-sip-part1.html

which would allow Kamailio to consume 3xx redirects as a transport for 
information queries. That is a common pattern for external routing 
services, for example.

It's also worth keeping in mind that even if you invent such a shim, 
you're not going to be able to use VoltDB to provide database backing 
for Kamailio's database-backed modules (e.g. htable, usrloc, dispatcher, 
carrierroute, etc). If your aim is to make VoltDB work transparently 
with those modules, then this isn't a viable project.

What you can do is query an API for some limited purposes. For example, 
you could get authentication credentials from VoltDB and store them in 
pseudovariables so as to feed them into functions which can use them, 
such as:

https://kamailio.org/docs/modules/5.4.x/modules/auth.html#auth.f.pv_auth_check

But most Kamailio modules which extensively utilise a relational 
database don't expose capabilities like that. That would, after all, 
contradict the basic purpose for which a lot of them exist, which is to 
transparently manage database interactions for you while providing terse 
and easy-to-use syntactical sugar.

So, it depends on what exactly you want to do. If it's something very 
specific, like getting routes or authentication credentials, you could 
potentially use an unsupported database if you devise a means of 
communicating with it indirectly, using a generic channel that Kamailio 
does support.

But if you're asking if Kamailio supports VoltDB in a rather general 
sense, the answer is no.

-- Alex

[1] https://docs.voltdb.com/UsingVoltDB/ChapAppDesign.php

On 12/14/20 2:57 PM, Ali Taher wrote:
> Hi Alex,
> 
> Thanks for your answer. How to proceed to let Kamailio talk manually to 
> VoltDB ?
> 
> Regards,
> 
> Ali Taher


-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From abalashov at evaristesys.com  Mon Dec 14 21:22:32 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 14 Dec 2020 15:22:32 -0500
Subject: [SR-Users] voltdb support
In-Reply-To: <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
 <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>
Message-ID: <dfeb0017-84c3-1cd0-ed06-8aa6b049b848@evaristesys.com>

A colleague clued me into the fact that VoltDB has a native HTTP / JSON 
interface, so you might not need any middleware to talk to it using the 
Kamailio HTTP modules:

    https://docs.voltdb.com/UsingVoltDB/ProgLangJson.php

But again, it depends on what exactly you're trying to do. It won't work 
for built-in database backing for the various popular modules.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From ataher at vanrise.com  Mon Dec 14 21:28:32 2020
From: ataher at vanrise.com (Ali Taher)
Date: Mon, 14 Dec 2020 20:28:32 +0000
Subject: [SR-Users] voltdb support
In-Reply-To: <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
 <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>
Message-ID: <AM6PR09MB2887768D8F52AC64AE3287D4CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>

What I need is to fetch routing from VoltDB and send it back to switch using 3xx response. So I think the API solution is the best approach here. 
Thanks for all this useful info.

-----Original Message-----
From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Monday, December 14, 2020 10:16 PM
To: sr-users at lists.kamailio.org
Subject: Re: [SR-Users] voltdb support

You'd have to devise some sort of API or use something that Kamailio can talk to, unless you're inclined to write a custom module that uses a library[1].

Otherwise, the usual integration paths are available, e.g.

1) You could put a REST API server in front of VoltDB and use:

https://kamailio.org/docs/modules/5.4.x/modules/http_async_client.html

https://kamailio.org/docs/modules/5.4.x/modules/http_client.html

2) Or, you could write a server of some kind which mediates these requests using EVAPI:

https://kamailio.org/docs/modules/5.4.x/modules/evapi.html

3) Or, you could write a minimal SIP redirect service using a library such as PJSUA/PJSIP, or JAIN,

https://www.oracle.com/technical-resources/articles/enterprise-architecture/introduction-jain-sip-part1.html

which would allow Kamailio to consume 3xx redirects as a transport for information queries. That is a common pattern for external routing services, for example.

It's also worth keeping in mind that even if you invent such a shim, you're not going to be able to use VoltDB to provide database backing for Kamailio's database-backed modules (e.g. htable, usrloc, dispatcher, carrierroute, etc). If your aim is to make VoltDB work transparently with those modules, then this isn't a viable project.

What you can do is query an API for some limited purposes. For example, you could get authentication credentials from VoltDB and store them in pseudovariables so as to feed them into functions which can use them, such as:

https://kamailio.org/docs/modules/5.4.x/modules/auth.html#auth.f.pv_auth_check

But most Kamailio modules which extensively utilise a relational database don't expose capabilities like that. That would, after all, contradict the basic purpose for which a lot of them exist, which is to transparently manage database interactions for you while providing terse and easy-to-use syntactical sugar.

So, it depends on what exactly you want to do. If it's something very specific, like getting routes or authentication credentials, you could potentially use an unsupported database if you devise a means of communicating with it indirectly, using a generic channel that Kamailio does support.

But if you're asking if Kamailio supports VoltDB in a rather general sense, the answer is no.

-- Alex

[1] https://docs.voltdb.com/UsingVoltDB/ChapAppDesign.php

On 12/14/20 2:57 PM, Ali Taher wrote:
> Hi Alex,
> 
> Thanks for your answer. How to proceed to let Kamailio talk manually 
> to VoltDB ?
> 
> Regards,
> 
> Ali Taher


--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

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


From abalashov at evaristesys.com  Mon Dec 14 21:31:16 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 14 Dec 2020 15:31:16 -0500
Subject: [SR-Users] voltdb support
In-Reply-To: <AM6PR09MB2887768D8F52AC64AE3287D4CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
 <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>
 <AM6PR09MB2887768D8F52AC64AE3287D4CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
Message-ID: <6efd85f7-959c-9c59-b6f2-b44f43036c46@evaristesys.com>

On 12/14/20 3:28 PM, Ali Taher wrote:

> What I need is to fetch routing from VoltDB and send it back to
> switch using 3xx response. So I think the API solution is the best
> approach here. Thanks for all this useful info. >

If Kamailio is sending the 3xx response, then it sounds like using the 
HTTP modules to interact with VoltDB's JSON interface might be the best 
way to go.

You'll have to account for the latency inherent in such queries and make 
sure you have a sufficient number of worker processes to handle the 
load, whether you use the async or synchronous HTTP modules. For more 
information on that topic, you can read an old blog post of mine:

http://www.evaristesys.com/blog/tuning-kamailio-for-high-throughput-and-performance/

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From ataher at vanrise.com  Mon Dec 14 21:35:25 2020
From: ataher at vanrise.com (Ali Taher)
Date: Mon, 14 Dec 2020 20:35:25 +0000
Subject: [SR-Users] voltdb support
In-Reply-To: <6efd85f7-959c-9c59-b6f2-b44f43036c46@evaristesys.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
 <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>
 <AM6PR09MB2887768D8F52AC64AE3287D4CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <6efd85f7-959c-9c59-b6f2-b44f43036c46@evaristesys.com>
Message-ID: <AM6PR09MB288700B0CECE9357287A2085CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>

What do you recommend using : http sync or async client modules?

-----Original Message-----
From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Monday, December 14, 2020 10:31 PM
To: sr-users at lists.kamailio.org
Subject: Re: [SR-Users] voltdb support

On 12/14/20 3:28 PM, Ali Taher wrote:

> What I need is to fetch routing from VoltDB and send it back to switch 
> using 3xx response. So I think the API solution is the best approach 
> here. Thanks for all this useful info. >

If Kamailio is sending the 3xx response, then it sounds like using the HTTP modules to interact with VoltDB's JSON interface might be the best way to go.

You'll have to account for the latency inherent in such queries and make sure you have a sufficient number of worker processes to handle the load, whether you use the async or synchronous HTTP modules. For more information on that topic, you can read an old blog post of mine:

http://www.evaristesys.com/blog/tuning-kamailio-for-high-throughput-and-performance/

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

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


From abalashov at evaristesys.com  Mon Dec 14 21:38:26 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 14 Dec 2020 15:38:26 -0500
Subject: [SR-Users] voltdb support
In-Reply-To: <AM6PR09MB288700B0CECE9357287A2085CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
References: <AM6PR09MB28879912A11047882D53D5CFCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <0E1AC6A7-00D4-4DDA-9B2F-0F989252D322@evaristesys.com>
 <AM6PR09MB2887F7429274C682A5BF030CCAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <1863c3a8-9f4e-e319-ec65-1d973b2e5f41@evaristesys.com>
 <AM6PR09MB2887768D8F52AC64AE3287D4CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
 <6efd85f7-959c-9c59-b6f2-b44f43036c46@evaristesys.com>
 <AM6PR09MB288700B0CECE9357287A2085CAC70@AM6PR09MB2887.eurprd09.prod.outlook.com>
Message-ID: <414694cf-e93f-9a94-8510-c580b91cd173@evaristesys.com>

Given a simple workflow where only one HTTP query is involved, I would 
recommend the async module. It's very straightforward to make the query 
out of the main request route, and pack the response into a 3xx redirect 
and send it out the door in the async reply route.

I've had to mix both modules in situations where there's a pipeline of 
HTTP requests -- what a pain.

I'm not sure of your request volumes, but I would set these to a 
relatively high number, e.g. 3x-4x the number of SIP children= processes 
you have.

https://kamailio.org/docs/modules/5.4.x/modules/http_async_client.html#idm55

-- Alex

On 12/14/20 3:35 PM, Ali Taher wrote:
> What do you recommend using : http sync or async client modules?
> 
> -----Original Message-----
> From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Alex Balashov
> Sent: Monday, December 14, 2020 10:31 PM
> To: sr-users at lists.kamailio.org
> Subject: Re: [SR-Users] voltdb support
> 
> On 12/14/20 3:28 PM, Ali Taher wrote:
> 
>> What I need is to fetch routing from VoltDB and send it back to switch
>> using 3xx response. So I think the API solution is the best approach
>> here. Thanks for all this useful info. >
> 
> If Kamailio is sending the 3xx response, then it sounds like using the HTTP modules to interact with VoltDB's JSON interface might be the best way to go.
> 
> You'll have to account for the latency inherent in such queries and make sure you have a sufficient number of worker processes to handle the load, whether you use the async or synchronous HTTP modules. For more information on that topic, you can read an old blog post of mine:
> 
> http://www.evaristesys.com/blog/tuning-kamailio-for-high-throughput-and-performance/
> 
> -- Alex
> 
> --
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From i.ribakov at zaleos.net  Mon Dec 14 09:18:47 2020
From: i.ribakov at zaleos.net (Ivan Ribakov)
Date: Mon, 14 Dec 2020 09:18:47 +0100
Subject: [SR-Users] Wrong To tag in t_reply
In-Reply-To: <ad0cdb3a-9300-a7f1-8c27-115dd2320201@gmail.com>
References: <E2557ECA-B08D-4D67-BF57-B7CAE92A107E@zaleos.net>
 <ad0cdb3a-9300-a7f1-8c27-115dd2320201@gmail.com>
Message-ID: <F239A977-CEEA-4373-9B2A-3796979D0620@zaleos.net>

> you can use send_reply() to avoid any test in the config.
> 
Thanks for the tip Daniel, will give it a go!

> So think that kamailio itself is the branch of the incoming request, and can create many outgoing branches. If it generates a final reply, it does it to the incoming branch. It is not forwarding (sending back) a reply from an outgoing branch.
> 

Ok, when you put it that way it actually makes more sense - thanks for a great example! 

I still have one question left about my current scenario - why does Kamailio retransmit final non-2xx response after receiving an ACK if the response is valid and, as far as I can tell, so is the ACK?

Just to provide more context:
1) Ingress INVITE vs 504 response from Kamailio


2) 504 response from Kamailio vs Caller ACK


Regards,
Ivan

> On 11 Dec 2020, at 14:06, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> actually you are wrong that you think it is a wrong to tag. The entity that generates the final reply sets the to-tag (e.g.,to be able to match ack). Even here where you talk about the serial forking, you are going to face the case of different to-tag values for each branch sent out and replied. But also think about parallel forking, that timed out with many active branches, which to-tag to use?!?
> 
> So think that kamailio itself is the branch of the incoming request, and can create many outgoing branches. If it generates a final reply, it does it to the incoming branch. It is not forwarding (sending back) a reply from an outgoing branch.
> 
> Obviously, being open source, one can code a specific behaviour for some specific needs, but is not SIP specs compliant. If the upstream cannot deal with different to-tags, it won't really work with serial/parallel forking anyhow.
> 
> As a side remark, seeing the comments, if route(ROUTE_ELEMENT_FINAL_FAILURE) is used only in failure_route, then transaction is always defined there, because failure_route is executed only in the transaction context. Anyhow, if you are using in many places, not knowing if transaction was created, you can use send_reply() to avoid any test in the config.
> 
> Cheers,
> Daniel
> 
> On 11.12.20 11:04, Ivan Ribakov wrote:
>> Hi all,
>> 
>> I?m trying to implement following routing behaviour:
>> 
>> - ingress INVITE is sequentially forked to 1 or more endpoints
>> - under certain conditions sequential forking may be stopped and pre-defined error returned to the caller
>> 
>> Here?s is part of the config responsible for handling errors:
>> 
>> failure_route[ROUTE_ELEMENT_FINAL_FAILURE_HELPER] {
>>     route(ROUTE_ELEMENT_FINAL_FAILURE);
>> }
>> 
>> route[ROUTE_ELEMENT_FINAL_FAILURE] {
>>     # We need to check if the error happens before the first egress, because T-state is not defined yet so we can not use t_reply
>>     if ($var(before_first_egress) == 0) {
>>         t_reply("$var(sipCode)", "$var(sipMessage)");
>>     } else {
>>         sl_send_reply("$var(sipCode)", "$var(sipMessage)");
>>     }
>> }
>> 
>> 
>> 
>> Here is a simple scenario where delivering call to first endpoint times out after receiving 180 Ringing (using custom fr_inv_timer value) where:
>> - .33 is caller
>> - .208 is Kamailio
>> - .138 is callee
>> 
>> 
>> 
>> Notice that 504 is retransmitted by Kamailio. Here is a comparison of 180 and 504 returned by Kamailio:
>> 
>> 
>> 
>> As can be seen, 180 was proxied from the callee and has callee?s to-tag (tag=CALLEE1), however 504 that was generated by Kamailio using t_reply() has a different to-tag (presumably generated by Kamailio).
>> 
>> How can I tell Kamailio not to generate new to-tag but to use the last one that proxied back to the caller?
>> 
>> Thanks in advance for any help!
>> 
>> Regards,
>> Ivan
>> 
>> 
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/72af2fd6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-5.png
Type: image/png
Size: 121610 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/72af2fd6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-6.png
Type: image/png
Size: 98097 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201214/72af2fd6/attachment-0001.png>

From cezar at mokalife.ro  Tue Dec 15 15:26:15 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Tue, 15 Dec 2020 16:26:15 +0200
Subject: [SR-Users] Kamilio+asterisk = deregister after 2-3 minute
In-Reply-To: <CALZWR5yuQJ3kK6QhXubWTfMRK9BhNX7HdkwRGuMaWrQCch8ipg@mail.gmail.com>
References: <CANk_n4bX37eW6HizdCwqE1LCi33ATp_Cn8XVwnEgWZWkAvip7w@mail.gmail.com>
 <CAOQgkjbu8eKfsM-KtNApOoEPv2z-ehncsr6f2w7Wq6LxO3NiTw@mail.gmail.com>
 <CANk_n4abwW4TrLggb7rKtqTH9VxcVa_2cwDgTvyZCQ6H_5s7OA@mail.gmail.com>
 <e549576c-3cbe-ca5f-c86c-9fa4007c2e5c@flanagan.ie>
 <CAMtXxQ=OJcXFvDpQdW_o0bczRZ+6m9LKs7J=Eq0iUUquM0atWA@mail.gmail.com>
 <CALZWR5yuQJ3kK6QhXubWTfMRK9BhNX7HdkwRGuMaWrQCch8ipg@mail.gmail.com>
Message-ID: <CANk_n4Zj8SR-HxR7k-cFZpnsNn1HV547p0jaVveP+GJRnb+iBg@mail.gmail.com>

Thanks for the help.
It worked with the solution proposed by Bary and Sergio!

On Fri, Dec 11, 2020 at 11:33 PM Sergio Charrua <sergio.charrua at voip.pt>
wrote:

> I will assume that you use Kamailio as SIP Proxy between a SIP Provider
> (TelCo) and your Asterisk boxes (using SIP.conf), and that Kamailio is
> receiving OPTIONS messages from TelCo, and forwarding those OPTIONS to
> Asterisk who will fail to answer.
> This is a common implementation with TelCos.The solution is to set
> Kamailio to Reply to TelCo, adding following route:
>
> route {
>         # OPTIONS requests without a username in the Request-URI but one
>         # of our domains or IPs are addressed to the proxy itself and
>         # can be answered statelessly.
>         if (is_method("OPTIONS"))
>         {
>                 sl_send_reply("200","OK");
>                 exit;
>         }
> [.....]
>
> It will then reply SIP 200 to TelCo.
> Usually, Asterisk does not answer to SIP OPTION messages coming from
> TelCos (and thus acting like a SIP Agent) but it does send OPTIONS to SIP
> Agents and peers, which in turn will reply (I think it is set by the
> Qualify which pings the SIP peers).
> So, in this case, Kamailio should be the one to reply to Telco's SIP
> OPTION request with a 200 OK response (if it replies 404 NOT FOUND the
> TelCo will then set your servers as OFFLINE and you won't receive calls or
> SIP messages anymore, just like it is happening to you in the present).
>
> I think that Asterisk with PJSIP allows replies to OPTION messages, but I
> still haven't used PJSIP.....
>
> Hope this helps.
>
> *S?rgio Charrua*
>
>
> *www.voip.pt <http://www.voip.pt/>*
> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>
> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
>
> On Fri, Dec 11, 2020 at 8:00 PM Joel Serrano <joel at textplus.com> wrote:
>
>> You can also set 404 as a valid response to the OPTIONS in Kam.
>>
>> On Fri, Dec 11, 2020 at 05:36 Barry Flanagan <barry at flanagan.ie> wrote:
>>
>>> On 11/12/2020 13:23, Mihai Cezar wrote:
>>>
>>> Hello, You right, i've found something, seems that the kamailio-probe it
>>> puts the destination down. Any ideas why it's doing this ?
>>>
>>>
>>> "OPTIONS-Request was finished with code 404"
>>>
>>> The OPTIONS returns a 404. You need to put something into your default
>>> context in Asterisk so it returns 200. If your default context is "default"
>>> then this would work in extensions.conf:
>>>
>>> *[default]*
>>>
>>> *exten => s,1,Hangup()*
>>>
>>> Then do a "dialplan reload" in asterisk.
>>>
>>> Hope this helps
>>>
>>> -Barry Flanagan
>>>
>>>
>>> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
>>> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
>>> 3afe874f6d71811b-24504 at 127.0.0.1} dispatcher
>>> : ds_options_callback(): OPTIONS-Request was finished with code 404 (to
>>> sip:10.1.2.2;transport=udp, group 1)
>>> : ds_update_state(): update state for sip:10.1.2.2;transport=udp in
>>> group 1 to 10
>>> : ds_update_state(): destination did not replied 10 times, threshold 10
>>> : ds_update_state(): deactivate destination, threshold 10 reached
>>> : ds_run_route(): ds_run_route event_route[dispatcher:dst-down
>>> : ds_run_route(): route does not exist 8(24491) DEBUG: {2 10 OPTIONS
>>> 3afe874f6d71811c-24504 at 127.0.0.1} dispatcher [dispatch.c:2805
>>> : ds_manage_routes(): set 1
>>>
>>> On Thu, Dec 10, 2020 at 11:53 AM ????????? ??????? <
>>> volodyaivanets at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Can you see some warnings or errors in the Kamailio log file? If no,
>>>> try to increase the verbosity level.
>>>>
>>>> Also, how does the third REGISTER compares to the first or second one?
>>>>
>>>> ??, 10 ????. 2020 ? 09:08 Mihai <m at mokalife.ro> ????:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am forwarding all the traffic to my asterisk server ( including
>>>>> registers)
>>>>> everything seems to work when i first register but if stay idle 2-3
>>>>> minute it gets unregistered and then i can't register back unless i restart
>>>>> kamailio
>>>>> see attached print screen
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> --
>>> -Barry
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/258c5028/attachment.htm>

From cezar at mokalife.ro  Tue Dec 15 15:31:55 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Tue, 15 Dec 2020 16:31:55 +0200
Subject: [SR-Users] X-Forwarded-for IP to asterisk
Message-ID: <CANk_n4bDU=LQtDccfu+Mvp06jAY=R+F5DQWqXTr7nb4bmfW2RA@mail.gmail.com>

Hello,

Is it something like the XFF for Kamailio so I can see in asterisk (sip
show peers) the ip of the registered softphone and not Kamailio's IP ?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/5214ea83/attachment.htm>

From pojogas at gmail.com  Tue Dec 15 15:46:27 2020
From: pojogas at gmail.com (Sergiu Pojoga)
Date: Tue, 15 Dec 2020 09:46:27 -0500
Subject: [SR-Users] X-Forwarded-for IP to asterisk
In-Reply-To: <CANk_n4bDU=LQtDccfu+Mvp06jAY=R+F5DQWqXTr7nb4bmfW2RA@mail.gmail.com>
References: <CANk_n4bDU=LQtDccfu+Mvp06jAY=R+F5DQWqXTr7nb4bmfW2RA@mail.gmail.com>
Message-ID: <CAJZsGCm1BYdqVBHoM1nUk8nM_CoHMk+Tkt5nQz3dVh9ivkxijg@mail.gmail.com>

Although not strictly a Kamailio-related question... and also depending on
how you "forward" registrations to Asterisk, but usually setting
*nat=no* should
show the peer's public IP.

Regards,
--Sergiu

On Tue, Dec 15, 2020 at 9:33 AM Mihai Cezar <cezar at mokalife.ro> wrote:

> Hello,
>
> Is it something like the XFF for Kamailio so I can see in asterisk (sip
> show peers) the ip of the registered softphone and not Kamailio's IP ?
>
> Thanks!
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/873d4b0a/attachment.htm>

From david.villasmil.work at gmail.com  Tue Dec 15 16:06:29 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Tue, 15 Dec 2020 15:06:29 +0000
Subject: [SR-Users] X-Forwarded-for IP to asterisk
In-Reply-To: <CAJZsGCm1BYdqVBHoM1nUk8nM_CoHMk+Tkt5nQz3dVh9ivkxijg@mail.gmail.com>
References: <CANk_n4bDU=LQtDccfu+Mvp06jAY=R+F5DQWqXTr7nb4bmfW2RA@mail.gmail.com>
 <CAJZsGCm1BYdqVBHoM1nUk8nM_CoHMk+Tkt5nQz3dVh9ivkxijg@mail.gmail.com>
Message-ID: <CAFGRPVomt8E0UfkAAK8HCqvCfix2M+-YrC0MGR8z9Wg0_pD7fg@mail.gmail.com>

You could also simply add that header :)

On Tue, 15 Dec 2020 at 14:48, Sergiu Pojoga <pojogas at gmail.com> wrote:

> Although not strictly a Kamailio-related question... and also depending on
> how you "forward" registrations to Asterisk, but usually setting *nat=no* should
> show the peer's public IP.
>
> Regards,
> --Sergiu
>
> On Tue, Dec 15, 2020 at 9:33 AM Mihai Cezar <cezar at mokalife.ro> wrote:
>
>> Hello,
>>
>> Is it something like the XFF for Kamailio so I can see in asterisk (sip
>> show peers) the ip of the registered softphone and not Kamailio's IP ?
>>
>> Thanks!
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/efc7dfb4/attachment.htm>

From cezar at mokalife.ro  Tue Dec 15 16:14:58 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Tue, 15 Dec 2020 17:14:58 +0200
Subject: [SR-Users] X-Forwarded-for IP to asterisk
In-Reply-To: <CAJZsGCm1BYdqVBHoM1nUk8nM_CoHMk+Tkt5nQz3dVh9ivkxijg@mail.gmail.com>
References: <CANk_n4bDU=LQtDccfu+Mvp06jAY=R+F5DQWqXTr7nb4bmfW2RA@mail.gmail.com>
 <CAJZsGCm1BYdqVBHoM1nUk8nM_CoHMk+Tkt5nQz3dVh9ivkxijg@mail.gmail.com>
Message-ID: <CANk_n4ZhVX5iEU07cfWaYE4g=R1PbyfoWRKfarpvw11uBmty-g@mail.gmail.com>

I've tried but didn't worked the first time, now that you told me, as saw
that i had in the general block defined as "nat=force_rport,comedia"; after
commented out, it worked!

Thanks,

On Tue, Dec 15, 2020 at 4:48 PM Sergiu Pojoga <pojogas at gmail.com> wrote:

> Although not strictly a Kamailio-related question... and also depending on
> how you "forward" registrations to Asterisk, but usually setting *nat=no* should
> show the peer's public IP.
>
> Regards,
> --Sergiu
>
> On Tue, Dec 15, 2020 at 9:33 AM Mihai Cezar <cezar at mokalife.ro> wrote:
>
>> Hello,
>>
>> Is it something like the XFF for Kamailio so I can see in asterisk (sip
>> show peers) the ip of the registered softphone and not Kamailio's IP ?
>>
>> Thanks!
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/c3f3ef1a/attachment.htm>

From cezar at mokalife.ro  Tue Dec 15 16:15:45 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Tue, 15 Dec 2020 17:15:45 +0200
Subject: [SR-Users] X-Forwarded-for IP to asterisk
In-Reply-To: <CAFGRPVomt8E0UfkAAK8HCqvCfix2M+-YrC0MGR8z9Wg0_pD7fg@mail.gmail.com>
References: <CANk_n4bDU=LQtDccfu+Mvp06jAY=R+F5DQWqXTr7nb4bmfW2RA@mail.gmail.com>
 <CAJZsGCm1BYdqVBHoM1nUk8nM_CoHMk+Tkt5nQz3dVh9ivkxijg@mail.gmail.com>
 <CAFGRPVomt8E0UfkAAK8HCqvCfix2M+-YrC0MGR8z9Wg0_pD7fg@mail.gmail.com>
Message-ID: <CANk_n4aA43VTZnzpXQ-F=wKjCF+MsE65JaBZDVMGxSA2XaiGKQ@mail.gmail.com>

Hi David!

How can I added  ?:D

On Tue, Dec 15, 2020 at 5:08 PM David Villasmil <
david.villasmil.work at gmail.com> wrote:

> You could also simply add that header :)
>
> On Tue, 15 Dec 2020 at 14:48, Sergiu Pojoga <pojogas at gmail.com> wrote:
>
>> Although not strictly a Kamailio-related question... and also depending
>> on how you "forward" registrations to Asterisk, but usually setting
>> *nat=no* should show the peer's public IP.
>>
>> Regards,
>> --Sergiu
>>
>> On Tue, Dec 15, 2020 at 9:33 AM Mihai Cezar <cezar at mokalife.ro> wrote:
>>
>>> Hello,
>>>
>>> Is it something like the XFF for Kamailio so I can see in asterisk (sip
>>> show peers) the ip of the registered softphone and not Kamailio's IP ?
>>>
>>> Thanks!
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.work at gmail.com
> phone: +34669448337
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/cdb66b48/attachment.htm>

From agiftel at gmail.com  Tue Dec 15 17:17:59 2020
From: agiftel at gmail.com (Agiftel)
Date: Tue, 15 Dec 2020 09:17:59 -0700 (MST)
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <CAFArqsaMhBOqF-PHvQykYyi9bWvPkt_rF8ST4pTZjz0p0ZD5dA@mail.gmail.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
 <584348691.5654827.1607423847408@mail.yahoo.com>
 <1607768559710-0.post@n5.nabble.com>
 <CAFArqsaMhBOqF-PHvQykYyi9bWvPkt_rF8ST4pTZjz0p0ZD5dA@mail.gmail.com>
Message-ID: <1608049079791-0.post@n5.nabble.com>

Thank you for advice!
Now I can see also TLS calls (using HOMER 7 on docker)

Regards




--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From sleeloy99 at gmail.com  Tue Dec 15 16:44:22 2020
From: sleeloy99 at gmail.com (Sheldon L)
Date: Tue, 15 Dec 2020 10:44:22 -0500
Subject: [SR-Users] Problems debugging memory issues
Message-ID: <CAKOSiMc6JWNLDY0LhNbWLtmBzG2hHrxVeZAkshGRjL3ZUkNm=A@mail.gmail.com>

Hi,

I'm trying to investigate a possible memory leak issue in Kamailio and I'm
following the instructions indicated in
https://www.kamailio.org/wiki/tutorials/troubleshooting/memory

I'm using Kamailo 4.4 with the following kamailio internals:

Print out of kamailio internals
  Version: kamailio 4.4.2 (x86_64/linux) 892ad6
  Default config:
/apollo/env/TachyonPlatformKamailio/etc/kamailio/kamailio.cfg
  Default paths to modules:
/apollo/env/TachyonPlatformKamailio/lib64/kamailio/modules
  Compile flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, DBG_QM_MALLOC,
USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER,
USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
  MAX_RECV_BUFFER_SIZE=262144
  MAX_LISTEN=16
  MAX_URI_SIZE=1024
  BUF_SIZE=65535
  DEFAULT PKG_SIZE=8MB
  DEFAULT SHM_SIZE=64MB
  ADAPTIVE_WAIT_LOOPS=1024
  TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select
  Source code revision ID: 892ad6
  Compiled with: x86_64-unknown-linux-gnu-gcc 4.9.4
  Compiled on: 23:36:48 Dec  8 2020
Thank you for flying kamailio!

I have attached to one of the kamailio tcp receiver processes via GDB and I
am trying to dump memory blocks from the memory manager.  However,
mem_block is not in the current_context.

The following is the output from my gdb session:

Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-amazon-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/opt/codedeploy-agent/deployment-root/95bb1634-e653-4cec-b327-99b18b9227a8/d-7AJ1XZP58/deployment-archive/sbin/kamailio...done.
Attaching to program: /apollo/env/TachyonPlatformKamailio/sbin/kamailio,
process 8946
ptrace: Operation not permitted.
(gdb) set $i=0
(gdb) set $a = mem_block->first_frag
No symbol "mem_block" in current context.
(gdb) info list
Undefined info command: "list".  Try "help info".
(gdb) info threads
No threads.


Is there something I need to do before accessing the mem_block symbol?

Also do you have any other suggestions for debugging memory leaks that may
not be documented?

Note: i can't upgrade to the latest version of Kamailio as we have custom
modules and would require considerable effort to upgrade.

Thanks,

Sheldon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/ee88a9c7/attachment.htm>

From miconda at gmail.com  Tue Dec 15 18:31:02 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 15 Dec 2020 18:31:02 +0100
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <1607768559710-0.post@n5.nabble.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
 <584348691.5654827.1607423847408@mail.yahoo.com>
 <1607768559710-0.post@n5.nabble.com>
Message-ID: <cea8ef2e-6360-74ea-466f-cf058e6ae509@gmail.com>

Hello,

the file .data has the content in plain text, is not the pcap format
expected by sngrep. In master branch (to become the future major
release), the sipdump module can be configured to write also .pcap file,
then you can see its content with sngrep like:

tail -c +1 -f /tmp/kamailio-sipdump-xyz.pcap | sngrep -I -

Probably I should make a news/blog post about what sipdump can do, to be
easier to use it.

An extra tip, which I haven't tried, but if you compile from sources,
the sipdump module from master branch may just work in 5.4 version by
overwriting its files.

Cheers,
Daniel

On 12.12.20 11:22, Agiftel wrote:
> Hi again, I sang victory too soon :-(
>
> It's working perfectly if SIP calls are UDP or TCP based. If are TLS, very
> strange thing, i can see all trace inside file .data created by siptrace but
> if I open that file using sngrep, TLS calls are never displayed.
> Any idea?
> If not, anyway, I would like to ask you what is the best way to troubleshoot
> TLS calls?
> What do you use guys?
>
> Best regards
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From miconda at gmail.com  Tue Dec 15 18:31:02 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 15 Dec 2020 18:31:02 +0100
Subject: [SR-Users] sngrep TLS connection
In-Reply-To: <1607768559710-0.post@n5.nabble.com>
References: <1607355517135-0.post@n5.nabble.com>
 <CABSP_Vcy+cB5v9pgGQrp1h+W64k38m+EVo52_P_DWjz86T__Rg@mail.gmail.com>
 <ce9a6911-9267-9b9f-4a13-c2d86137ad02@gmail.com>
 <584348691.5654827.1607423847408@mail.yahoo.com>
 <1607768559710-0.post@n5.nabble.com>
Message-ID: <cea8ef2e-6360-74ea-466f-cf058e6ae509@gmail.com>

Hello,

the file .data has the content in plain text, is not the pcap format
expected by sngrep. In master branch (to become the future major
release), the sipdump module can be configured to write also .pcap file,
then you can see its content with sngrep like:

tail -c +1 -f /tmp/kamailio-sipdump-xyz.pcap | sngrep -I -

Probably I should make a news/blog post about what sipdump can do, to be
easier to use it.

An extra tip, which I haven't tried, but if you compile from sources,
the sipdump module from master branch may just work in 5.4 version by
overwriting its files.

Cheers,
Daniel

On 12.12.20 11:22, Agiftel wrote:
> Hi again, I sang victory too soon :-(
>
> It's working perfectly if SIP calls are UDP or TCP based. If are TLS, very
> strange thing, i can see all trace inside file .data created by siptrace but
> if I open that file using sngrep, TLS calls are never displayed.
> Any idea?
> If not, anyway, I would like to ask you what is the best way to troubleshoot
> TLS calls?
> What do you use guys?
>
> Best regards
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From miconda at gmail.com  Tue Dec 15 18:35:37 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 15 Dec 2020 18:35:37 +0100
Subject: [SR-Users] Problems debugging memory issues
In-Reply-To: <CAKOSiMc6JWNLDY0LhNbWLtmBzG2hHrxVeZAkshGRjL3ZUkNm=A@mail.gmail.com>
References: <CAKOSiMc6JWNLDY0LhNbWLtmBzG2hHrxVeZAkshGRjL3ZUkNm=A@mail.gmail.com>
Message-ID: <dd6d40bd-cc8c-ba90-1b8e-e227a83adefb@gmail.com>

Hello,

4.4 is real old and you should seriously consider upgrading.

Then, to the question itself, you have to look for _qm_pkg_block for
private memory root structure, probably the guide needs some updates,
likely it was written before the option to select the memory manager.

Cheers,
Daniel

On 15.12.20 16:44, Sheldon L wrote:
> Hi,
>
> I'm trying to investigate a possible memory leak issue in Kamailio and
> I'm following the instructions indicated
> in?https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
> <https://www.kamailio.org/wiki/tutorials/troubleshooting/memory>
>
> I'm using Kamailo?4.4 with the following kamailio internals:
>
> Print out of kamailio internals
> ? Version: kamailio 4.4.2 (x86_64/linux) 892ad6
> ? Default config:
> /apollo/env/TachyonPlatformKamailio/etc/kamailio/kamailio.cfg
> ? Default paths to modules:
> /apollo/env/TachyonPlatformKamailio/lib64/kamailio/modules
> ? Compile flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS,
> USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
> SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY,
> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ? MAX_RECV_BUFFER_SIZE=262144
> ? MAX_LISTEN=16
> ? MAX_URI_SIZE=1024
> ? BUF_SIZE=65535
> ? DEFAULT PKG_SIZE=8MB
> ? DEFAULT SHM_SIZE=64MB
> ? ADAPTIVE_WAIT_LOOPS=1024
> ? TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select
> ? Source code revision ID: 892ad6
> ? Compiled with: x86_64-unknown-linux-gnu-gcc 4.9.4
> ? Compiled on: 23:36:48 Dec ?8 2020
> Thank you for flying kamailio!
>
> I have attached to one of the kamailio tcp receiver processes via GDB
> and I am trying to dump memory blocks from the memory manager.?
> However, mem_block is not in the current_context.
>
> The following is the output from my gdb session:
>
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html <http://gnu.org/licenses/gpl.html>>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.? Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-amazon-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/
> <http://www.gnu.org/software/gdb/bugs/>>...
> Reading symbols from
> /opt/codedeploy-agent/deployment-root/95bb1634-e653-4cec-b327-99b18b9227a8/d-7AJ1XZP58/deployment-archive/sbin/kamailio...done.
> Attaching to program:
> /apollo/env/TachyonPlatformKamailio/sbin/kamailio, process 8946
> ptrace: Operation not permitted.
> (gdb) set $i=0
> (gdb) set $a = mem_block->first_frag
> No symbol "mem_block" in current context.
> (gdb) info list
> Undefined info command: "list".? Try "help info".
> (gdb) info threads
> No threads.
>
>
> Is there something I need to do before accessing the mem_block symbol???
>
> Also do you have any other suggestions for debugging memory leaks that
> may not be documented?
>
> Note: i can't upgrade to the latest version of Kamailio as we have
> custom modules and would require considerable effort to upgrade.
>
> Thanks,
>
> Sheldon.
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/2bba325c/attachment.htm>

From miconda at gmail.com  Tue Dec 15 18:38:20 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 15 Dec 2020 18:38:20 +0100
Subject: [SR-Users] Losing MySQL connections
In-Reply-To: <CAAJJHZinPpPukGVbXyNX2cn6Xj_zOaXEkFyiJ_02cHqx08af6g@mail.gmail.com>
References: <CAAJJHZinPpPukGVbXyNX2cn6Xj_zOaXEkFyiJ_02cHqx08af6g@mail.gmail.com>
Message-ID: <c2fff447-bdfd-5286-34e2-f73f5231606b@gmail.com>

Hello,

the ping option is set to the libmysqlclient, kamailio itself doesn't do
anything in this regard. Iirc, in some old versions of the library, this
option didn't work.

On the other hand, kamailio should try to reconnect if disconnected, but
in this case it seems that the connection was broken during the query.

Cheers,
Daniel

On 14.12.20 17:51, Duarte Rocha wrote:
> Greetings all,?
>
> I'm having some dropped MySQL connections in my Kamailio in times of
> low or no activity in the proxy.?
>
> These are the errors i'm getting :?
>
> ? ? db_mysql [km_dbase.c:123]: db_mysql_submit_query(): driver error
> on query: Lost connection to MySQL server during query (2013)
> ? ? <core> [db_query.c:348]: db_do_update(): error while submitting query
> ? ? usrloc [ucontact.c:1147]: db_update_ucontact_ruid(): updating
> database failed
> ? ? usrloc [ucontact.c:1663]: update_contact_db(): failed to update
> database
> ? ? registrar [save.c:784]: update_contacts(): failed to update contact
> ? ? sl [sl_funcs.c:414]: sl_reply_error(): stateless error reply used:
> I'm terribly sorry, server error occurred (1/SL)
>
> In order to try to fix this i've added timeout_interval and
> ping_interval from the db_mysql module. Is this the best approach?
>
> I've restarted my Kamailio but i don't see any ping going to my BD. Is
> there any other config that I need to add so that the pings are sent?
>
> Is it possible to do a ping to verify connection and reconnect
> mannualy on the config file?
>
> Best Regards,
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/7350bc32/attachment.htm>

From miconda at gmail.com  Tue Dec 15 18:41:19 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 15 Dec 2020 18:41:19 +0100
Subject: [SR-Users] How to use port number using $env in listen
In-Reply-To: <CA+mcf=u8Sn8Yq=U8FLKAzoMs+kLmy1-GabpMOatFx2MUaw6ESA@mail.gmail.com>
References: <CA+mcf=u8Sn8Yq=U8FLKAzoMs+kLmy1-GabpMOatFx2MUaw6ESA@mail.gmail.com>
Message-ID: <75dbba1f-cba1-a440-1a14-168cc15d8ca5@gmail.com>

Hello,

as written on the tracker, look at using #!subst or #!substdef (see core
cookbook), they should be able to get the substitution value from
environment using $env(NAME).

The master branch introduced #!defenv as a (simpler) alternative.

Cheers,
Daniel

On 12.12.20 05:33, Syed Shahryar wrote:
> I tried many combinations of the following but I keep getting syntax
> errors:
>
> listen=tls:TLS_IP:$env(TLS_PORT) advertise PUBLIC_IP:$env(TLS_PORT)
>
>
> TLS_IP and?PUBLIC_IP are constants defined at the top using #!define.
> And,?TLS_PORT is supposed to be the env variable.
>
>
> -- 
> --
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee, you
> should not disseminate, distribute or copy this email. Please notify
> the sender immediately by email if you have received this email by
> mistake and delete this email from your system. Email transmission
> cannot be guaranteed to be secure or error-free, as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
> or contain viruses. The sender, therefore, does not accept liability
> for any errors or omissions in the contents of this message which
> arise as a result of email transmission. If verification is required,
> please request a hard-copy version.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/0472c4ad/attachment.htm>

From hw at skalatan.de  Tue Dec 15 19:56:45 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Tue, 15 Dec 2020 18:56:45 +0000
Subject: [SR-Users] X-Forwarded-for IP to asterisk
In-Reply-To: <CANk_n4aA43VTZnzpXQ-F=wKjCF+MsE65JaBZDVMGxSA2XaiGKQ@mail.gmail.com>
References: <CANk_n4bDU=LQtDccfu+Mvp06jAY=R+F5DQWqXTr7nb4bmfW2RA@mail.gmail.com>
 <CAJZsGCm1BYdqVBHoM1nUk8nM_CoHMk+Tkt5nQz3dVh9ivkxijg@mail.gmail.com>
 <CAFGRPVomt8E0UfkAAK8HCqvCfix2M+-YrC0MGR8z9Wg0_pD7fg@mail.gmail.com>
 <CANk_n4aA43VTZnzpXQ-F=wKjCF+MsE65JaBZDVMGxSA2XaiGKQ@mail.gmail.com>
Message-ID: <AM0PR05MB659511E3E9A8C81F6DE27D08C5C60@AM0PR05MB6595.eurprd05.prod.outlook.com>

Like this, for example:
https://kamailio.org/docs/modules/devel/modules/textops.html#textops.f.append_hf

Cheers,

Henning

--
Henning Westerholt ? https://skalatan.de/blog/
Kamailio services ? https://gilawa.com<https://gilawa.com/>

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Mihai Cezar
Sent: Tuesday, December 15, 2020 4:16 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Subject: Re: [SR-Users] X-Forwarded-for IP to asterisk

Hi David!

How can I added  ?:D

On Tue, Dec 15, 2020 at 5:08 PM David Villasmil <david.villasmil.work at gmail.com<mailto:david.villasmil.work at gmail.com>> wrote:
You could also simply add that header :)

On Tue, 15 Dec 2020 at 14:48, Sergiu Pojoga <pojogas at gmail.com<mailto:pojogas at gmail.com>> wrote:
Although not strictly a Kamailio-related question... and also depending on how you "forward" registrations to Asterisk, but usually setting nat=no should show the peer's public IP.

Regards,
--Sergiu

On Tue, Dec 15, 2020 at 9:33 AM Mihai Cezar <cezar at mokalife.ro<mailto:cezar at mokalife.ro>> wrote:
Hello,

Is it something like the XFF for Kamailio so I can see in asterisk (sip show peers) the ip of the registered softphone and not Kamailio's IP ?

Thanks!
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Regards,

David Villasmil
email: david.villasmil.work at gmail.com<mailto:david.villasmil.work at gmail.com>
phone: +34669448337
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/993c0d61/attachment.htm>

From syedshahryar at gmail.com  Tue Dec 15 20:27:22 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Tue, 15 Dec 2020 14:27:22 -0500
Subject: [SR-Users] ERROR: <core> [core/parser/parse_uri.c:1326]:
 _parse_ruri(): bad uri </sip?jwt=..
Message-ID: <CA+mcf=uMnoNjo9KnH6TotnNkVNeLMW5AzpH8BDYQvvu60qUQ=Q@mail.gmail.com>

I am sending JWT tokens via SIP URL through JSSIP for authentication before
websocket connection is made.

However, I am getting errors like:

ERROR: <core> [core/parser/parse_uri.c:1326]: _parse_ruri(): bad uri <
*/sip?jwt=..*

I have the following setting in kamailio config:
modparam("xhttp", "url_match", "^/sip") // only match this path

Is this a bug or some configuration issue? How do I resolve it?

-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/a1c06462/attachment.htm>

From miconda at gmail.com  Tue Dec 15 20:38:09 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 15 Dec 2020 20:38:09 +0100
Subject: [SR-Users] ERROR: <core> [core/parser/parse_uri.c:1326]:
 _parse_ruri(): bad uri </sip?jwt=..
In-Reply-To: <CA+mcf=uMnoNjo9KnH6TotnNkVNeLMW5AzpH8BDYQvvu60qUQ=Q@mail.gmail.com>
References: <CA+mcf=uMnoNjo9KnH6TotnNkVNeLMW5AzpH8BDYQvvu60qUQ=Q@mail.gmail.com>
Message-ID: <cf5294f6-cc38-69b1-b1a2-cf79ea82d16c@gmail.com>

Hello,

can you provide the entire http request with such a URL?

Also, run with debug=3 in kamailio.cfg and attach all the log messages
printed by kamailio when processing such request.

Cheers,
Daniel

On 15.12.20 20:27, Syed Shahryar wrote:
>
> I am sending JWT tokens via SIP URL through JSSIP for authentication
> before websocket connection is made.
> ?
> However, I am getting errors like:
>
> ERROR: <core> [core/parser/parse_uri.c:1326]: _parse_ruri(): bad uri
> <*/sip?jwt=..*
>
> I have the following setting in kamailio config:
> modparam("xhttp", "url_match", "^/sip") // only match this path
>
> Is this a bug or some configuration issue? How do I resolve it?
>
> -- 
> --
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee, you
> should not disseminate, distribute or copy this email. Please notify
> the sender immediately by email if you have received this email by
> mistake and delete this email from your system. Email transmission
> cannot be guaranteed to be secure or error-free, as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
> or contain viruses. The sender, therefore, does not accept liability
> for any errors or omissions in the contents of this message which
> arise as a result of email transmission. If verification is required,
> please request a hard-copy version.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201215/2c6ecb31/attachment.htm>

From david.villaume at sewan.fr  Wed Dec 16 09:17:01 2020
From: david.villaume at sewan.fr (David VILLAUME)
Date: Wed, 16 Dec 2020 08:17:01 +0000
Subject: [SR-Users] ndb_redis with keydb master/master
Message-ID: <PR2P264MB0607A4177E6E1AC9810AD8EAFDC50@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>

Hello,

I consider using keydb-server in an active/action setup without sentinel.
Do you know if there is a way to declare both hosts in ndb_redis with the same server name (target use : topos) ?

Regards,
David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/46345266/attachment.htm>

From rabs at dimension-virtual.com  Wed Dec 16 10:37:41 2020
From: rabs at dimension-virtual.com (=?utf-8?B?UmHDumw=?= Alexis Betancor Santana)
Date: Wed, 16 Dec 2020 10:37:41 +0100 (CET)
Subject: [SR-Users] Kamailio dtmf signaling
In-Reply-To: <696670593.222.1607703539680.JavaMail.zimbra@coraltele.com>
References: <696670593.222.1607703539680.JavaMail.zimbra@coraltele.com>
Message-ID: <1687804019.370462.1608111461206.JavaMail.zimbra@dimension-virtual.com>

You could NOT build an IVR on Kamailio. 

Kamailio it's not a SIP-UAS, neither a B2BUA, Kamailio it's a SIP-Router with steroids, but will not handle an IVR. 

You should review the docs and try to undestand what Kamailio it's made for. 


From: "Amit Pal" <amit.pal at coraltele.com> 
To: "Kamailio" <sr-users at lists.kamailio.org> 
Sent: Friday, December 11, 2020 4:18:59 PM 
Subject: [SR-Users] Kamailio dtmf signaling 

Dear Team, 
I am using kamailio + rtpengine, how can I processed dtmf from cfg scripts. even thought I can able to see dtmf over syslog. 
but can not able to capture in kamailio.cfg. 
how can I prepared ivr using kamalio? 
Please find the attached syslog. 


Regards 
Amit Pal 

_______________________________________________ 
Kamailio (SER) - Users Mailing List 
sr-users at lists.kamailio.org 
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/b28ebdb2/attachment.htm>

From s.safarov at gmail.com  Wed Dec 16 14:38:36 2020
From: s.safarov at gmail.com (Sergey Safarov)
Date: Wed, 16 Dec 2020 16:38:36 +0300
Subject: [SR-Users] Kamailio dtmf signaling
In-Reply-To: <696670593.222.1607703539680.JavaMail.zimbra@coraltele.com>
References: <696670593.222.1607703539680.JavaMail.zimbra@coraltele.com>
Message-ID: <CAHtxdDefFzo1OLSP9m2bFOYuFbNY3NWt+jy_j31Dz26G300n2A@mail.gmail.com>

You can use FreeSwitch in this case

On Fri, Dec 11, 2020 at 7:19 PM Amit Pal <amit.pal at coraltele.com> wrote:

> Dear Team,
>      I am using kamailio + rtpengine, how can I processed dtmf from cfg
> scripts. even thought I can able to see dtmf over syslog.
> but can not able to capture in kamailio.cfg.
> how can I prepared ivr using kamalio?
> Please find the attached  syslog.
>
>
> Regards
> Amit Pal
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/e1b82cf1/attachment.htm>

From syedshahryar at gmail.com  Wed Dec 16 14:59:26 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Wed, 16 Dec 2020 08:59:26 -0500
Subject: [SR-Users] ERROR: dmq [notification_peer.c:337]:
 add_server_and_notify(): error adding notification node
Message-ID: <CA+mcf=te4qUQ_1q++LsAsUHck=m30LQMbjN+mXcU71BhqfVTDw@mail.gmail.com>

Here is my setting:

modparam("dmq", "server_address", "sip:0.0.0.0:5090" )
modparam("dmq", "notification_address", "sip:0.0.0.0:5090")
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 2)
modparam("dmq", "worker_usleep", 0)
modparam("dmq", "ping_interval", 90)

I have tried localhost and I believe other options but to no avail.

I also get the following message:

ERROR: dmq [dmq_funcs.c:516]: ping_servers(): cannot retrieve initial
nodelist from sip:0.0.0.0:5090

How do I set up DMQ for adding and removing any Kamailio instance to/from
the cluster and any Kamailio instance could serve any request coming from
any client? ie. all Kamailio instances keep the current state in DMQ.

I also have dmq_usrloc enabled.


-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/5dcd1bf2/attachment.htm>

From hw at skalatan.de  Wed Dec 16 17:11:26 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Wed, 16 Dec 2020 16:11:26 +0000
Subject: [SR-Users] ERROR: dmq [notification_peer.c:337]:
 add_server_and_notify(): error adding notification node
In-Reply-To: <CA+mcf=te4qUQ_1q++LsAsUHck=m30LQMbjN+mXcU71BhqfVTDw@mail.gmail.com>
References: <CA+mcf=te4qUQ_1q++LsAsUHck=m30LQMbjN+mXcU71BhqfVTDw@mail.gmail.com>
Message-ID: <AM0PR05MB6595B538854B15892EECB973C5C50@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hello,

you need to configure the ?real? IP address of the own and peer server, not the ?0? address.

Cheers,

Henning

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Syed Shahryar
Sent: Wednesday, December 16, 2020 2:59 PM
To: sr-users at lists.kamailio.org
Subject: [SR-Users] ERROR: dmq [notification_peer.c:337]: add_server_and_notify(): error adding notification node

Here is my setting:

modparam("dmq", "server_address", "sip:0.0.0.0:5090<http://0.0.0.0:5090>" )
modparam("dmq", "notification_address", "sip:0.0.0.0:5090<http://0.0.0.0:5090>")
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 2)
modparam("dmq", "worker_usleep", 0)
modparam("dmq", "ping_interval", 90)

I have tried localhost and I believe other options but to no avail.

I also get the following message:

ERROR: dmq [dmq_funcs.c:516]: ping_servers(): cannot retrieve initial nodelist from sip:0.0.0.0:5090<http://0.0.0.0:5090>

How do I set up DMQ for adding and removing any Kamailio instance to/from the cluster and any Kamailio instance could serve any request coming from any client? ie. all Kamailio instances keep the current state in DMQ.

I also have dmq_usrloc enabled.


--
--
This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. If verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/92b36b69/attachment.htm>

From miconda at gmail.com  Wed Dec 16 17:42:34 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Wed, 16 Dec 2020 17:42:34 +0100
Subject: [SR-Users] INFO: RTC Devroom Fosdem 2021 - Online Event
Message-ID: <3e355078-0279-711d-ac97-62dc938fa800@gmail.com>

Hello,

(cross-posting to kamailio public groups, a few may get this message
duplicated).

Fosdem 2021 is going to be online, meaning that it opens the possibility
for everyone to do a presentation on the RTC Devroom, no longer being
required to travel to Brussels. Therefore I am sending here the link to
CFP in case someone would be interested to present about Kamailio or
something else RTC-related:

? * https://github.com/FreeRTC/fosdem/blob/master/2021/cfp.md

New speakers are always welcome! Only have in mind that the event is
targeting developers and source code development, therefore your
proposals have to be made from this perspective.

Note also that submission deadline is 20th of December, very short time
frame from now.


Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda



From hbilling at gmail.com  Wed Dec 16 17:57:36 2020
From: hbilling at gmail.com (harneet singh)
Date: Wed, 16 Dec 2020 22:27:36 +0530
Subject: [SR-Users] DLGLOAD stuck in Dispatcher Module(HA Mode)
Message-ID: <CAHTs8D_EtwxFi5Hw6J1jNfX-zZDjg0iQ7_1ygV+J_T6mJyswPw@mail.gmail.com>

Hi All,

I am using Kamailio in HA mode with Keepalived providing the VIP(Virtual
IP) functionality, and have run into a rather peculiar issue.

*Setup:*

Caller ------------ KamailioVIP(*Primary *and *Secondary* Kamailio)-------
Callee

    HA provided by Keepalived
    DMQ is used between the Primary and Secondary Kamailio for dialog sync

*Issue Seen:*

*Suppose the Primary Kamailio has been brought down* and the Secondary one
is actually active and tied to the VIP.

When a call is fired from the Caller, it traverses through the Secondary
Kamailio and lands onto the callee. The dialogs are updated properly. At
this point, the Primary Kamailio is brought up, and dialog state is synced
due to the DMQ module.
The Keepalived will now attach the VIP to the Primary Instance. If the
caller hangs up the phone at this point, the BYE sip message traverses
through the Primary Kamailio instance to the callee and the call is
cleared, but there are two issues here.

  1.  The Primary Kamailio throws an error in *ds_load_remove() *saying
that it cannot find the load for the specific call id. This is apparently
due to the fact that the dispatcher data is not synced between the two
modules but dialog data is. So dialog wise, things are fine. Can this be
fixed somehow?

  2. The above is still as grave a problem as the dialogs are cleared. BUT,
if we check the '*kamcmd dispatcher.list*' on the *SECONDARY* kamailio even
well after the call is cleared, the *DLGLOAD* shows 1. Since we are using
the *Call Load based distribution* for the dispatching, this is effectively
one call stuck on the dispatcher, which leads to resource leak.

Is this a known issue, and if so, do we have a way to circumvent this?

Regards,
Harneet Singh
-- 
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/734bd44c/attachment.htm>

From social at bohboh.info  Wed Dec 16 18:16:21 2020
From: social at bohboh.info (Social Boh)
Date: Wed, 16 Dec 2020 12:16:21 -0500
Subject: [SR-Users] DLGLOAD stuck in Dispatcher Module(HA Mode)
In-Reply-To: <CAHTs8D_EtwxFi5Hw6J1jNfX-zZDjg0iQ7_1ygV+J_T6mJyswPw@mail.gmail.com>
References: <CAHTs8D_EtwxFi5Hw6J1jNfX-zZDjg0iQ7_1ygV+J_T6mJyswPw@mail.gmail.com>
Message-ID: <21076e1e-eb30-055a-922c-562fff9718f2@bohboh.info>

Maybe a option is leave the secondary like primary when primary go up newly.

Example: Primary go down, Secondary is the new Primary. Primary came 
back up but Secondary still is the VIP and still process the calls.

Only if Secondary go down, primary is the new VIP.

The keepalived parameter for this behaviour is:

*nopreempt*

---
I'm SoCIaL, MayBe

El 16/12/2020 a las 11:57 a.?m., harneet singh escribi?:
> Hi All,
>
> I am using Kamailio in HA mode with Keepalived providing the 
> VIP(Virtual IP) functionality, and have run into a rather peculiar issue.
>
> _Setup:_
>
> Caller ------------ KamailioVIP(*Primary *and *Secondary* 
> Kamailio)------- Callee
>
> ? ? HA provided by Keepalived
> ? ? DMQ is used between the Primary and Secondary Kamailio for dialog sync
>
> */_Issue Seen:_/*
> */_
> _/*
> */_Suppose the Primary Kamailio has been brought?down_/* and the 
> Secondary one is actually active and tied to the VIP.
>
> When a call is fired from the Caller, it traverses through the 
> Secondary Kamailio and lands onto the callee. The dialogs are updated 
> properly. At this point, the Primary Kamailio is brought up,?and 
> dialog state?is synced due to the DMQ module.
> The Keepalived will now attach the VIP to the Primary Instance. If the 
> caller hangs up the phone at this point, the BYE sip message traverses 
> through the Primary Kamailio instance to the callee and the call is 
> cleared, but there are two issues here.
>
> ? 1.? The Primary Kamailio throws an error?in *ds_load_remove() 
> *saying that it cannot find the load for the specific call id. This is 
> apparently due to the fact that the dispatcher data is not synced 
> between the two modules but dialog data is. So dialog wise, things are 
> fine. Can this be fixed somehow?
>
> ? 2. The above is still as grave a problem as the dialogs are cleared. 
> BUT, if we check the '*kamcmd dispatcher.list*' on the *SECONDARY* 
> kamailio even well after the call is cleared, the *DLGLOAD* shows 1. 
> Since we are using the *Call Load based distribution* for the 
> dispatching, this is effectively one call stuck on the dispatcher, 
> which leads to resource leak.
>
> Is this a known issue, and if so, do we have a way to circumvent this?
>
> Regards,
> Harneet Singh
> -- 
> "Once you eliminate the impossible, whatever remains, no matter how 
> improbable, must be the truth" - Sir Arthur Conan Doyle
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/1800538e/attachment.htm>

From terry at fullduplex.co.uk  Thu Dec 17 11:23:27 2020
From: terry at fullduplex.co.uk (Terry Tailor)
Date: Thu, 17 Dec 2020 15:23:27 +0500
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
Message-ID: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>

Hi, Here is setup details
Kamailio Proxy a <-----> Kamailio Proxy b  <-----> Asterisk
Kamailio proxy b auth based on IP Kamailio Proxy a
1. Kamailio proxy sends an Invite request to Kamailio proxy b with CSeq:
102 INVITE
2. Kamailio proxy b check again IP auth and sends invite request to
asterisk with CSeq: 102 INVITE
4 asterisk response with 401 Unauthorized with  CSeq: 102
5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
8. Kamailio proxy b relay 180 ringing with  CSeq: 102 INVITE
9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b relay it to proxy
a with CSeq: 102 INVITE
10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b relay ACK to
asterisk with CSeq: 102 ACK

Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE and proxy a is
sending ACK with Cseq: 102 ACK

Same happing in case of 487 Request Terminated

Here is my config

modparam("dialog", "default_timeout", 10800) # 3h
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "db_mode", 0)
modparam("dialog", "send_bye", 1)
modparam("dialog", "track_cseq_updates", 1)
modparam("uac","auth_username_avp","$avp(auser)")
modparam("uac","auth_password_avp","$avp(apass)")
modparam("uac","auth_realm_avp","$avp(arealm)")

modparam("tm", "failure_reply_mode", 3)
# default retransmission timeout: 3 sec
modparam("tm", "fr_timer", 2000)
modparam("tm", "retr_timer1", 250)
modparam("tm", "retr_timer2", 500)
# default invite retransmission timeout after 1xx: 60 sec
modparam("tm", "fr_inv_timer", 60000)
modparam("tm", "reparse_on_dns_failover", 0)



if (is_method("INVITE") && !has_totag()) {
        dlg_setflag(FLD_RTPPROXY);
        dlg_manage();
    }
    route(RELAY);




route[RELAY] {

    # At this point all checks are passed
    t_on_branch("MANAGE_BRANCH");
    t_on_reply("MANAGE_REPLY");
    t_on_failure("MANAGE_FAILURE");
    if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
     #$fd = "sip.comms.kuflink.com";
      t_on_failure("RELAY_AUTH");
    }

    if (!t_relay()) {
        send_reply("500", "Cannot relay to $du/$ru");
    }
    exit;
}

failure_route[RELAY_AUTH] {
    t_on_branch("MANAGE_BRANCH");
    t_on_reply("MANAGE_REPLY");
    if (t_is_canceled()) {
        exit;
    }
    if(t_check_status("401|407")) {
        #$fd = "sip.comms.kuflink.com";
        $avp(auser) = "DID_UA_USERNAME";
        $avp(apass) = "DID_UA_PASSWORD";
        if (uac_auth()) {
            t_relay();
        }
        exit;
    }
}


route[WITHINDLG] {
    if (!has_totag()) {
        return;
    }

    if (is_method("BYE")) {
        rtpengine_delete();
    }

    # sequential request withing a dialog should
    # take the path determined by record-routing
    if (loose_route()) {
        route(DLGURI);
        if (is_method("ACK")) {
            # ACK is forwarded statelessly
            route(NATMANAGE);
        } else if (is_method("NOTIFY")) {
            # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
            record_route();
        }
        route(RELAY);
        exit;
    }

    if (is_method("SUBSCRIBE") && uri == myself) {
        # in-dialog subscribe requests
        route(PRESENCE);
        exit;
    }
    if (is_method("ACK") ) {
        if (t_check_trans()) {
            # no loose-route, but stateful ACK;
            # must be an ACK after a 487
            # or e.g. 404 from upstream server
            route(RELAY);
            exit;
        } else {
            # ACK without matching transaction ... ignore and discard
            exit;
        }
    }
    send_reply("404","Not here");
    exit;
}


kamailio -v
version: kamailio 5.3.7 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0


uname -a
Linux example.com 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC
2020 x86_64 GNU/Linux



SIP logs
2020/12/17 10:08:18.483907 proxy-a.com:5060 -> 10.0.14.118:5060
INVITE sip:123456 at proxy-a.com SIP/2.0
Record-Route: <sip:proxy-a.com;lr>
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>
Contact: <sip:7654321 at did.com:5060>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
User-Agent: ProxyA
CSeq: 102 INVITE
User-Agent: proxy
Date: Thu, 17 Dec 2020 10:08:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "7654321" <sip:7654321 at did.com
>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 885



2020/12/17 10:08:18.485063 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 INVITE
Server: kamailio (5.3.7 (x86_64/linux))
Content-Length: 0


2020/12/17 10:08:18.485576 10.0.14.118:5060 -> 10.0.14.118:6000
INVITE sip:123456 at proxy-a.com SIP/2.0
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>
Contact: <sip:7654321 at did.com:5060>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
User-Agent: ProxyA
CSeq: 102 INVITE
User-Agent: proxy
Date: Thu, 17 Dec 2020 10:08:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "7654321" <sip:7654321 at did.com
>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 885



2020/12/17 10:08:18.622867 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as4107645c
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com",
nonce="11139d33"
Content-Length: 0



2020/12/17 10:08:18.624034 10.0.14.118:5060 -> 10.0.14.118:6000
ACK sip:123456 at proxy-a.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as4107645c
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 ACK
Content-Length: 0



2020/12/17 10:08:18.625557 10.0.14.118:5060 -> 10.0.14.118:6000
INVITE sip:123456 at proxy-a.com SIP/2.0
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>
Contact: <sip:7654321 at did.com:5060>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
User-Agent: ProxyA
CSeq: 103 INVITE
User-Agent: proxy
Date: Thu, 17 Dec 2020 10:08:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "7654321" <sip:7654321 at did.com
>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 885
Authorization: Digest username="xxxxx", realm="xxxx", nonce="11139d33",
uri="sip:123456 at proxy-a.com", response="qwewqeqwe", algorithm=MD5



2020/12/17 10:08:18.779483 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Length: 0




2020/12/17 10:08:20.937756 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Length: 0



2020/12/17 10:08:20.938593 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Length: 0



2020/12/17 10:08:22.075814 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Type: application/sdp
Require: timer
Content-Length: 296


2020/12/17 10:08:22.077049 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Type: application/sdp
Require: timer
Content-Length: 316



2020/12/17 10:08:22.103365 proxy-a.com:5060 -> 10.0.14.118:5060
ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
SIP/2.0
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK2a5fae72;rport=5060
Route: <sip:proxy-b.com;lr;did=d18.7a9>
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0



2020/12/17 10:08:22.103877 10.0.14.118:5060 -> 10.0.14.118:6000
ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK2a5fae72;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0
P-K-CSeq-Refresh: 103


2020/12/17 10:08:22.575533 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Type: application/sdp
Require: timer
Content-Length: 296



2020/12/17 10:08:22.576777 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Type: application/sdp
Require: timer
Content-Length: 316



2020/12/17 10:08:22.581649 proxy-a.com:5060 -> 10.0.14.118:5060
ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
SIP/2.0
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK219933f6;rport=5060
Route: <sip:proxy-b.com;lr;did=d18.7a9>
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0



2020/12/17 10:08:22.582313 10.0.14.118:5060 -> 10.0.14.118:6000
ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK219933f6;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0
P-K-CSeq-Refresh: 103


2020/12/17 10:08:23.575828 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-b.com:5060
;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Type: application/sdp
Require: timer
Content-Length: 296


2020/12/17 10:08:23.577863 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com;lr>
From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Type: application/sdp
Require: timer
Content-Length: 316
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/cb1ec37e/attachment.htm>

From cezar at mokalife.ro  Thu Dec 17 12:08:30 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Thu, 17 Dec 2020 13:08:30 +0200
Subject: [SR-Users] Kamailio RTP proxy require?
Message-ID: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>

Hi,

Can't figure it out when to use RTPproxy, i am forwarding everything to
asterisk in seem to work without RTPproxy.

The scenario is like this:
Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)

Now it seems to work without any rtpproxy but is it ok?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/671f3936/attachment.htm>

From hw at skalatan.de  Thu Dec 17 12:09:42 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Thu, 17 Dec 2020 11:09:42 +0000
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
In-Reply-To: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
References: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
Message-ID: <AM0PR05MB65957B85563FA91B93CC931EC5C40@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hello,

this might be the reason: https://www.mail-archive.com/sr-users at lists.kamailio.org/msg14071.html

I will release 5.3.8 in the next days which should contain the fix.

Cheers,

Henning

--
Henning Westerholt ? https://skalatan.de/blog/
Kamailio services ? https://gilawa.com<https://gilawa.com/>

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Terry Tailor
Sent: Thursday, December 17, 2020 11:23 AM
To: sr-users at lists.kamailio.org
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK

Hi, Here is setup details
Kamailio Proxy a <-----> Kamailio Proxy b  <-----> Asterisk
Kamailio proxy b auth based on IP Kamailio Proxy a
1. Kamailio proxy sends an Invite request to Kamailio proxy b with CSeq: 102 INVITE
2. Kamailio proxy b check again IP auth and sends invite request to asterisk with CSeq: 102 INVITE
4 asterisk response with 401 Unauthorized with  CSeq: 102
5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
8. Kamailio proxy b relay 180 ringing with  CSeq: 102 INVITE
9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b relay it to proxy a with CSeq: 102 INVITE
10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b relay ACK to asterisk with CSeq: 102 ACK

Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE and proxy a is sending ACK with Cseq: 102 ACK

Same happing in case of 487 Request Terminated

Here is my config

modparam("dialog", "default_timeout", 10800) # 3h
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "db_mode", 0)
modparam("dialog", "send_bye", 1)
modparam("dialog", "track_cseq_updates", 1)
modparam("uac","auth_username_avp","$avp(auser)")
modparam("uac","auth_password_avp","$avp(apass)")
modparam("uac","auth_realm_avp","$avp(arealm)")

modparam("tm", "failure_reply_mode", 3)
# default retransmission timeout: 3 sec
modparam("tm", "fr_timer", 2000)
modparam("tm", "retr_timer1", 250)
modparam("tm", "retr_timer2", 500)
# default invite retransmission timeout after 1xx: 60 sec
modparam("tm", "fr_inv_timer", 60000)
modparam("tm", "reparse_on_dns_failover", 0)



if (is_method("INVITE") && !has_totag()) {
        dlg_setflag(FLD_RTPPROXY);
        dlg_manage();
    }
    route(RELAY);




route[RELAY] {

    # At this point all checks are passed
    t_on_branch("MANAGE_BRANCH");
    t_on_reply("MANAGE_REPLY");
    t_on_failure("MANAGE_FAILURE");
    if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
     #$fd = "sip.comms.kuflink.com<http://sip.comms.kuflink.com>";
      t_on_failure("RELAY_AUTH");
    }

    if (!t_relay()) {
        send_reply("500", "Cannot relay to $du/$ru");
    }
    exit;
}

failure_route[RELAY_AUTH] {
    t_on_branch("MANAGE_BRANCH");
    t_on_reply("MANAGE_REPLY");
    if (t_is_canceled()) {
        exit;
    }
    if(t_check_status("401|407")) {
        #$fd = "sip.comms.kuflink.com<http://sip.comms.kuflink.com>";
        $avp(auser) = "DID_UA_USERNAME";
        $avp(apass) = "DID_UA_PASSWORD";
        if (uac_auth()) {
            t_relay();
        }
        exit;
    }
}


route[WITHINDLG] {
    if (!has_totag()) {
        return;
    }

    if (is_method("BYE")) {
        rtpengine_delete();
    }

    # sequential request withing a dialog should
    # take the path determined by record-routing
    if (loose_route()) {
        route(DLGURI);
        if (is_method("ACK")) {
            # ACK is forwarded statelessly
            route(NATMANAGE);
        } else if (is_method("NOTIFY")) {
            # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
            record_route();
        }
        route(RELAY);
        exit;
    }

    if (is_method("SUBSCRIBE") && uri == myself) {
        # in-dialog subscribe requests
        route(PRESENCE);
        exit;
    }
    if (is_method("ACK") ) {
        if (t_check_trans()) {
            # no loose-route, but stateful ACK;
            # must be an ACK after a 487
            # or e.g. 404 from upstream server
            route(RELAY);
            exit;
        } else {
            # ACK without matching transaction ... ignore and discard
            exit;
        }
    }
    send_reply("404","Not here");
    exit;
}


kamailio -v
version: kamailio 5.3.7 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0


uname -a
Linux example.com<http://example.com> 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 GNU/Linux



SIP logs
2020/12/17 10:08:18.483907 proxy-a.com:5060<http://proxy-a.com:5060> -> 10.0.14.118:5060<http://10.0.14.118:5060>
INVITE sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com> SIP/2.0
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
Via: SIP/2.0/UDP proxy-a.com:5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>
Contact: <sip:7654321 at did.com:5060<http://sip:7654321 at did.com:5060>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
User-Agent: ProxyA
CSeq: 102 INVITE
User-Agent: proxy
Date: Thu, 17 Dec 2020 10:08:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 885



2020/12/17 10:08:18.485063 10.0.14.118:5060<http://10.0.14.118:5060> -> proxy-a.com:5060<http://proxy-a.com:5060>
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP proxy-a.com:5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 INVITE
Server: kamailio (5.3.7 (x86_64/linux))
Content-Length: 0


2020/12/17 10:08:18.485576 10.0.14.118:5060<http://10.0.14.118:5060> -> 10.0.14.118:6000<http://10.0.14.118:6000>
INVITE sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com> SIP/2.0
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>
Contact: <sip:7654321 at did.com:5060<http://sip:7654321 at did.com:5060>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
User-Agent: ProxyA
CSeq: 102 INVITE
User-Agent: proxy
Date: Thu, 17 Dec 2020 10:08:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 885



2020/12/17 10:08:18.622867 10.0.14.118:6000<http://10.0.14.118:6000> -> 10.0.14.118:5060<http://10.0.14.118:5060>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as4107645c
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com<http://sip1.comms.kuflink.com>", nonce="11139d33"
Content-Length: 0



2020/12/17 10:08:18.624034 10.0.14.118:5060<http://10.0.14.118:5060> -> 10.0.14.118:6000<http://10.0.14.118:6000>
ACK sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com> SIP/2.0
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as4107645c
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 ACK
Content-Length: 0



2020/12/17 10:08:18.625557 10.0.14.118:5060<http://10.0.14.118:5060> -> 10.0.14.118:6000<http://10.0.14.118:6000>
INVITE sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com> SIP/2.0
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>
Contact: <sip:7654321 at did.com:5060<http://sip:7654321 at did.com:5060>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
User-Agent: ProxyA
CSeq: 103 INVITE
User-Agent: proxy
Date: Thu, 17 Dec 2020 10:08:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 885
Authorization: Digest username="xxxxx", realm="xxxx", nonce="11139d33", uri="sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>", response="qwewqeqwe", algorithm=MD5



2020/12/17 10:08:18.779483 10.0.14.118:6000<http://10.0.14.118:6000> -> 10.0.14.118:5060<http://10.0.14.118:5060>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000<http://sip:123456 at 10.0.14.118:6000>>
Content-Length: 0




2020/12/17 10:08:20.937756 10.0.14.118:6000<http://10.0.14.118:6000> -> 10.0.14.118:5060<http://10.0.14.118:5060>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000<http://sip:123456 at 10.0.14.118:6000>>
Content-Length: 0



2020/12/17 10:08:20.938593 10.0.14.118:5060<http://10.0.14.118:5060> -> proxy-a.com:5060<http://proxy-a.com:5060>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Length: 0



2020/12/17 10:08:22.075814 10.0.14.118:6000<http://10.0.14.118:6000> -> 10.0.14.118:5060<http://10.0.14.118:5060>
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000<http://sip:123456 at 10.0.14.118:6000>>
Content-Type: application/sdp
Require: timer
Content-Length: 296


2020/12/17 10:08:22.077049 10.0.14.118:5060<http://10.0.14.118:5060> -> proxy-a.com:5060<http://proxy-a.com:5060>
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Type: application/sdp
Require: timer
Content-Length: 316



2020/12/17 10:08:22.103365 proxy-a.com:5060<http://proxy-a.com:5060> -> 10.0.14.118:5060<http://10.0.14.118:5060>
ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1 SIP/2.0
Via: SIP/2.0/UDP proxy-a.com:5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK2a5fae72;rport=5060
Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060<http://sip:7654321 at did.com:5060>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0



2020/12/17 10:08:22.103877 10.0.14.118:5060<http://10.0.14.118:5060> -> 10.0.14.118:6000<http://10.0.14.118:6000>
ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK2a5fae72;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060<http://sip:7654321 at did.com:5060>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0
P-K-CSeq-Refresh: 103


2020/12/17 10:08:22.575533 10.0.14.118:6000<http://10.0.14.118:6000> -> 10.0.14.118:5060<http://10.0.14.118:5060>
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000<http://sip:123456 at 10.0.14.118:6000>>
Content-Type: application/sdp
Require: timer
Content-Length: 296



2020/12/17 10:08:22.576777 10.0.14.118:5060<http://10.0.14.118:5060> -> proxy-a.com:5060<http://proxy-a.com:5060>
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Type: application/sdp
Require: timer
Content-Length: 316



2020/12/17 10:08:22.581649 proxy-a.com:5060<http://proxy-a.com:5060> -> 10.0.14.118:5060<http://10.0.14.118:5060>
ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1 SIP/2.0
Via: SIP/2.0/UDP proxy-a.com:5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK219933f6;rport=5060
Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060<http://sip:7654321 at did.com:5060>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0



2020/12/17 10:08:22.582313 10.0.14.118:5060<http://10.0.14.118:5060> -> 10.0.14.118:6000<http://10.0.14.118:6000>
ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK219933f6;rport=5060
Max-Forwards: 70
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Contact: <sip:7654321 at did.com:5060<http://sip:7654321 at did.com:5060>>
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 ACK
User-Agent: proxy
Content-Length: 0
P-K-CSeq-Refresh: 103


2020/12/17 10:08:23.575828 10.0.14.118:6000<http://10.0.14.118:6000> -> 10.0.14.118:5060<http://10.0.14.118:5060>
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 103 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000<http://sip:123456 at 10.0.14.118:6000>>
Content-Type: application/sdp
Require: timer
Content-Length: 296


2020/12/17 10:08:23.577863 10.0.14.118:5060<http://10.0.14.118:5060> -> proxy-a.com:5060<http://proxy-a.com:5060>
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
Via: SIP/2.0/UDP did.com:5060;received=did.com<http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
Record-Route: <sip:proxy-b.com<http://proxy-b.com>;lr;did=d18.7a9>
Record-Route: <sip:proxy-a.com<http://proxy-a.com>;lr>
From: "7654321" <sip:7654321 at did.com<mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
To: <sip:123456 at proxy-a.com<mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
Call-ID: 67675c7e636d6e773860255316e54779 at did.com<mailto:67675c7e636d6e773860255316e54779 at did.com>
CSeq: 102 INVITE
Server: proxy
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Type: application/sdp
Require: timer
Content-Length: 316


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/8c55c457/attachment.htm>

From hw at skalatan.de  Thu Dec 17 12:14:29 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Thu, 17 Dec 2020 11:14:29 +0000
Subject: [SR-Users] Releasing Kamailio 5.3.8
Message-ID: <AM0PR05MB6595FCBE737050F69F5F79DCC5C40@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hello,

I am planning to release next week (likely on Monday 21st December) the next minor version out of branch 5.3, version 5.3.8.

Backports of fixed issues from git master will be integrated as usual. If you are aware of new issues which were not yet reported, let us know (by creating an issue on the tracker).

Cheers,

Henning

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/5e9b4777/attachment.htm>

From david.villasmil.work at gmail.com  Thu Dec 17 12:14:33 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 17 Dec 2020 11:14:33 +0000
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
Message-ID: <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>

It?s totally fine. Rtpengine is mainly used to also proxy rtp ie: public to
private, etc. But if your asterisk is public, rtps will reach it, and
you?re fine with it, go ahead

On Thu, 17 Dec 2020 at 11:10, Mihai Cezar <cezar at mokalife.ro> wrote:

> Hi,
>
> Can't figure it out when to use RTPproxy, i am forwarding everything to
> asterisk in seem to work without RTPproxy.
>
> The scenario is like this:
> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>
> Now it seems to work without any rtpproxy but is it ok?
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/36cc2ef0/attachment.htm>

From david.villasmil.work at gmail.com  Thu Dec 17 12:16:35 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 17 Dec 2020 11:16:35 +0000
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
Message-ID: <CAFGRPVqmTDPjeM1bFn8h45SgsLVA+1wo2gQ=u1zaYJBfgKM-AA@mail.gmail.com>

I should point out proxying rtps and having asterisk in a private network
is better security-wise, since only kamailio can reach it and you control
kamailio.

On Thu, 17 Dec 2020 at 11:14, David Villasmil <
david.villasmil.work at gmail.com> wrote:

> It?s totally fine. Rtpengine is mainly used to also proxy rtp ie: public
> to private, etc. But if your asterisk is public, rtps will reach it, and
> you?re fine with it, go ahead
>
> On Thu, 17 Dec 2020 at 11:10, Mihai Cezar <cezar at mokalife.ro> wrote:
>
>> Hi,
>>
>> Can't figure it out when to use RTPproxy, i am forwarding everything to
>> asterisk in seem to work without RTPproxy.
>>
>> The scenario is like this:
>> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>>
>> Now it seems to work without any rtpproxy but is it ok?
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.work at gmail.com
> phone: +34669448337
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/66ad024d/attachment.htm>

From georgediam at gmail.com  Thu Dec 17 12:20:00 2020
From: georgediam at gmail.com (George Diamantopoulos)
Date: Thu, 17 Dec 2020 13:20:00 +0200
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
In-Reply-To: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
References: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
Message-ID: <CAPcKEYMWXvhVnM3YhQS-d-FjCSmRJZ+z4Yc-yyfFSNEPJLFsQA@mail.gmail.com>

Not sure if this is related, but I've also run into issues with
track_cseq_updates:
https://www.mail-archive.com/sr-users at lists.kamailio.org/msg12362.html

More specifically, kamailio won't process the 100 Trying to an Cseq-bumped
INVITE it generated
itself with uac_auth() when track_cseq_updates is on.

This implementation appears to be a little too fragile for the time
being....

BR,
George

On Thu, 17 Dec 2020 at 12:29, Terry Tailor <terry at fullduplex.co.uk> wrote:

> Hi, Here is setup details
> Kamailio Proxy a <-----> Kamailio Proxy b  <-----> Asterisk
> Kamailio proxy b auth based on IP Kamailio Proxy a
> 1. Kamailio proxy sends an Invite request to Kamailio proxy b with CSeq:
> 102 INVITE
> 2. Kamailio proxy b check again IP auth and sends invite request to
> asterisk with CSeq: 102 INVITE
> 4 asterisk response with 401 Unauthorized with  CSeq: 102
> 5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
> 6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
> 7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
> 8. Kamailio proxy b relay 180 ringing with  CSeq: 102 INVITE
> 9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b relay it to
> proxy a with CSeq: 102 INVITE
> 10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b relay ACK to
> asterisk with CSeq: 102 ACK
>
> Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE and proxy a is
> sending ACK with Cseq: 102 ACK
>
> Same happing in case of 487 Request Terminated
>
> Here is my config
>
> modparam("dialog", "default_timeout", 10800) # 3h
> modparam("dialog", "dlg_match_mode", 1)
> modparam("dialog", "db_mode", 0)
> modparam("dialog", "send_bye", 1)
> modparam("dialog", "track_cseq_updates", 1)
> modparam("uac","auth_username_avp","$avp(auser)")
> modparam("uac","auth_password_avp","$avp(apass)")
> modparam("uac","auth_realm_avp","$avp(arealm)")
>
> modparam("tm", "failure_reply_mode", 3)
> # default retransmission timeout: 3 sec
> modparam("tm", "fr_timer", 2000)
> modparam("tm", "retr_timer1", 250)
> modparam("tm", "retr_timer2", 500)
> # default invite retransmission timeout after 1xx: 60 sec
> modparam("tm", "fr_inv_timer", 60000)
> modparam("tm", "reparse_on_dns_failover", 0)
>
>
>
> if (is_method("INVITE") && !has_totag()) {
>         dlg_setflag(FLD_RTPPROXY);
>         dlg_manage();
>     }
>     route(RELAY);
>
>
>
>
> route[RELAY] {
>
>     # At this point all checks are passed
>     t_on_branch("MANAGE_BRANCH");
>     t_on_reply("MANAGE_REPLY");
>     t_on_failure("MANAGE_FAILURE");
>     if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
>      #$fd = "sip.comms.kuflink.com";
>       t_on_failure("RELAY_AUTH");
>     }
>
>     if (!t_relay()) {
>         send_reply("500", "Cannot relay to $du/$ru");
>     }
>     exit;
> }
>
> failure_route[RELAY_AUTH] {
>     t_on_branch("MANAGE_BRANCH");
>     t_on_reply("MANAGE_REPLY");
>     if (t_is_canceled()) {
>         exit;
>     }
>     if(t_check_status("401|407")) {
>         #$fd = "sip.comms.kuflink.com";
>         $avp(auser) = "DID_UA_USERNAME";
>         $avp(apass) = "DID_UA_PASSWORD";
>         if (uac_auth()) {
>             t_relay();
>         }
>         exit;
>     }
> }
>
>
> route[WITHINDLG] {
>     if (!has_totag()) {
>         return;
>     }
>
>     if (is_method("BYE")) {
>         rtpengine_delete();
>     }
>
>     # sequential request withing a dialog should
>     # take the path determined by record-routing
>     if (loose_route()) {
>         route(DLGURI);
>         if (is_method("ACK")) {
>             # ACK is forwarded statelessly
>             route(NATMANAGE);
>         } else if (is_method("NOTIFY")) {
>             # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
>             record_route();
>         }
>         route(RELAY);
>         exit;
>     }
>
>     if (is_method("SUBSCRIBE") && uri == myself) {
>         # in-dialog subscribe requests
>         route(PRESENCE);
>         exit;
>     }
>     if (is_method("ACK") ) {
>         if (t_check_trans()) {
>             # no loose-route, but stateful ACK;
>             # must be an ACK after a 487
>             # or e.g. 404 from upstream server
>             route(RELAY);
>             exit;
>         } else {
>             # ACK without matching transaction ... ignore and discard
>             exit;
>         }
>     }
>     send_reply("404","Not here");
>     exit;
> }
>
>
> kamailio -v
> version: kamailio 5.3.7 (x86_64/linux)
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled with gcc 6.3.0
>
>
> uname -a
> Linux example.com 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43
> UTC 2020 x86_64 GNU/Linux
>
>
>
> SIP logs
> 2020/12/17 10:08:18.483907 proxy-a.com:5060 -> 10.0.14.118:5060
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> User-Agent: ProxyA
> CSeq: 102 INVITE
> User-Agent: proxy
> Date: Thu, 17 Dec 2020 10:08:18 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "7654321" <sip:7654321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 885
>
>
>
> 2020/12/17 10:08:18.485063 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 100 trying -- your call is important to us
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: kamailio (5.3.7 (x86_64/linux))
> Content-Length: 0
>
>
> 2020/12/17 10:08:18.485576 10.0.14.118:5060 -> 10.0.14.118:6000
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> User-Agent: ProxyA
> CSeq: 102 INVITE
> User-Agent: proxy
> Date: Thu, 17 Dec 2020 10:08:18 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "7654321" <sip:7654321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 885
>
>
>
> 2020/12/17 10:08:18.622867 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as4107645c
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com",
> nonce="11139d33"
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:18.624034 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as4107645c
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:18.625557 10.0.14.118:5060 -> 10.0.14.118:6000
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> User-Agent: ProxyA
> CSeq: 103 INVITE
> User-Agent: proxy
> Date: Thu, 17 Dec 2020 10:08:18 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "7654321" <sip:7654321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 885
> Authorization: Digest username="xxxxx", realm="xxxx", nonce="11139d33",
> uri="sip:123456 at proxy-a.com", response="qwewqeqwe", algorithm=MD5
>
>
>
> 2020/12/17 10:08:18.779483 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Length: 0
>
>
>
>
> 2020/12/17 10:08:20.937756 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:20.938593 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:22.075814 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 296
>
>
> 2020/12/17 10:08:22.077049 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 316
>
>
>
> 2020/12/17 10:08:22.103365 proxy-a.com:5060 -> 10.0.14.118:5060
> ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
> SIP/2.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK2a5fae72;rport=5060
> Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:22.103877 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK2a5fae72;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
> P-K-CSeq-Refresh: 103
>
>
> 2020/12/17 10:08:22.575533 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 296
>
>
>
> 2020/12/17 10:08:22.576777 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 316
>
>
>
> 2020/12/17 10:08:22.581649 proxy-a.com:5060 -> 10.0.14.118:5060
> ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
> SIP/2.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK219933f6;rport=5060
> Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:22.582313 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK219933f6;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
> P-K-CSeq-Refresh: 103
>
>
> 2020/12/17 10:08:23.575828 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 296
>
>
> 2020/12/17 10:08:23.577863 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 316
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/d32351d7/attachment.htm>

From terry at fullduplex.co.uk  Thu Dec 17 12:27:57 2020
From: terry at fullduplex.co.uk (Terry Tailor)
Date: Thu, 17 Dec 2020 16:27:57 +0500
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
In-Reply-To: <AM0PR05MB65957B85563FA91B93CC931EC5C40@AM0PR05MB6595.eurprd05.prod.outlook.com>
References: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
 <AM0PR05MB65957B85563FA91B93CC931EC5C40@AM0PR05MB6595.eurprd05.prod.outlook.com>
Message-ID: <CAK7XD1uknAaVNSvWhtfoh_28zBrYg1A20iZj=bOcc+sX32D=RA@mail.gmail.com>

Hi Hennin,
Thank you

I confirm that by updating to Kamailio 5.4 it resolve the issue.
Cheers,
Terry

On Thu, Dec 17, 2020 at 4:09 PM Henning Westerholt <hw at skalatan.de> wrote:

> Hello,
>
>
>
> this might be the reason:
> https://www.mail-archive.com/sr-users at lists.kamailio.org/msg14071.html
>
>
>
> I will release 5.3.8 in the next days which should contain the fix.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt ? https://skalatan.de/blog/
>
> Kamailio services ? https://gilawa.com
>
>
>
> *From:* sr-users <sr-users-bounces at lists.kamailio.org> *On Behalf Of *Terry
> Tailor
> *Sent:* Thursday, December 17, 2020 11:23 AM
> *To:* sr-users at lists.kamailio.org
> *Subject:* [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
>
>
>
> Hi, Here is setup details
>
> Kamailio Proxy a <-----> Kamailio Proxy b  <-----> Asterisk
>
> Kamailio proxy b auth based on IP Kamailio Proxy a
>
> 1. Kamailio proxy sends an Invite request to Kamailio proxy b with CSeq:
> 102 INVITE
>
> 2. Kamailio proxy b check again IP auth and sends invite request to
> asterisk with CSeq: 102 INVITE
>
> 4 asterisk response with 401 Unauthorized with  CSeq: 102
>
> 5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
>
> 6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
>
> 7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
>
> 8. Kamailio proxy b relay 180 ringing with  CSeq: 102 INVITE
>
> 9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b relay it to
> proxy a with CSeq: 102 INVITE
>
> 10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b relay ACK to
> asterisk with CSeq: 102 ACK
>
>
>
> Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE and proxy a is
> sending ACK with Cseq: 102 ACK
>
>
>
> Same happing in case of 487 Request Terminated
>
>
>
> Here is my config
>
>
>
> modparam("dialog", "default_timeout", 10800) # 3h
> modparam("dialog", "dlg_match_mode", 1)
> modparam("dialog", "db_mode", 0)
> modparam("dialog", "send_bye", 1)
> modparam("dialog", "track_cseq_updates", 1)
> modparam("uac","auth_username_avp","$avp(auser)")
> modparam("uac","auth_password_avp","$avp(apass)")
> modparam("uac","auth_realm_avp","$avp(arealm)")
>
>
>
> modparam("tm", "failure_reply_mode", 3)
> # default retransmission timeout: 3 sec
> modparam("tm", "fr_timer", 2000)
> modparam("tm", "retr_timer1", 250)
> modparam("tm", "retr_timer2", 500)
> # default invite retransmission timeout after 1xx: 60 sec
> modparam("tm", "fr_inv_timer", 60000)
> modparam("tm", "reparse_on_dns_failover", 0)
>
>
>
>
>
>
>
> if (is_method("INVITE") && !has_totag()) {
>         dlg_setflag(FLD_RTPPROXY);
>         dlg_manage();
>     }
>     route(RELAY);
>
>
>
>
>
>
>
>
>
> route[RELAY] {
>
>     # At this point all checks are passed
>     t_on_branch("MANAGE_BRANCH");
>     t_on_reply("MANAGE_REPLY");
>     t_on_failure("MANAGE_FAILURE");
>     if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
>      #$fd = "sip.comms.kuflink.com";
>       t_on_failure("RELAY_AUTH");
>     }
>
>     if (!t_relay()) {
>         send_reply("500", "Cannot relay to $du/$ru");
>     }
>     exit;
> }
>
> failure_route[RELAY_AUTH] {
>     t_on_branch("MANAGE_BRANCH");
>     t_on_reply("MANAGE_REPLY");
>     if (t_is_canceled()) {
>         exit;
>     }
>     if(t_check_status("401|407")) {
>         #$fd = "sip.comms.kuflink.com";
>         $avp(auser) = "DID_UA_USERNAME";
>         $avp(apass) = "DID_UA_PASSWORD";
>         if (uac_auth()) {
>             t_relay();
>         }
>         exit;
>     }
> }
>
>
>
>
>
> route[WITHINDLG] {
>     if (!has_totag()) {
>         return;
>     }
>
>     if (is_method("BYE")) {
>         rtpengine_delete();
>     }
>
>     # sequential request withing a dialog should
>     # take the path determined by record-routing
>     if (loose_route()) {
>         route(DLGURI);
>         if (is_method("ACK")) {
>             # ACK is forwarded statelessly
>             route(NATMANAGE);
>         } else if (is_method("NOTIFY")) {
>             # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
>             record_route();
>         }
>         route(RELAY);
>         exit;
>     }
>
>     if (is_method("SUBSCRIBE") && uri == myself) {
>         # in-dialog subscribe requests
>         route(PRESENCE);
>         exit;
>     }
>     if (is_method("ACK") ) {
>         if (t_check_trans()) {
>             # no loose-route, but stateful ACK;
>             # must be an ACK after a 487
>             # or e.g. 404 from upstream server
>             route(RELAY);
>             exit;
>         } else {
>             # ACK without matching transaction ... ignore and discard
>             exit;
>         }
>     }
>     send_reply("404","Not here");
>     exit;
> }
>
>
>
>
>
> kamailio -v
>
> version: kamailio 5.3.7 (x86_64/linux)
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled with gcc 6.3.0
>
>
>
>
>
> uname -a
>
> Linux example.com 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43
> UTC 2020 x86_64 GNU/Linux
>
>
>
>
>
>
>
> SIP logs
>
> 2020/12/17 10:08:18.483907 proxy-a.com:5060 -> 10.0.14.118:5060
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> User-Agent: ProxyA
> CSeq: 102 INVITE
> User-Agent: proxy
> Date: Thu, 17 Dec 2020 10:08:18 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "7654321" <sip:7654321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 885
>
>
>
> 2020/12/17 10:08:18.485063 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 100 trying -- your call is important to us
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: kamailio (5.3.7 (x86_64/linux))
> Content-Length: 0
>
>
> 2020/12/17 10:08:18.485576 10.0.14.118:5060 -> 10.0.14.118:6000
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> User-Agent: ProxyA
> CSeq: 102 INVITE
> User-Agent: proxy
> Date: Thu, 17 Dec 2020 10:08:18 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "7654321" <sip:7654321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 885
>
>
>
> 2020/12/17 10:08:18.622867 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as4107645c
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com",
> nonce="11139d33"
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:18.624034 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as4107645c
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:18.625557 10.0.14.118:5060 -> 10.0.14.118:6000
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> User-Agent: ProxyA
> CSeq: 103 INVITE
> User-Agent: proxy
> Date: Thu, 17 Dec 2020 10:08:18 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "7654321" <sip:7654321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 885
> Authorization: Digest username="xxxxx", realm="xxxx", nonce="11139d33",
> uri="sip:123456 at proxy-a.com", response="qwewqeqwe", algorithm=MD5
>
>
>
> 2020/12/17 10:08:18.779483 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Length: 0
>
>
>
>
> 2020/12/17 10:08:20.937756 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:20.938593 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:22.075814 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 296
>
>
> 2020/12/17 10:08:22.077049 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 316
>
>
>
> 2020/12/17 10:08:22.103365 proxy-a.com:5060 -> 10.0.14.118:5060
> ACK
> sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
> SIP/2.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK2a5fae72;rport=5060
> Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:22.103877 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK2a5fae72;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
> P-K-CSeq-Refresh: 103
>
>
> 2020/12/17 10:08:22.575533 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 296
>
>
>
> 2020/12/17 10:08:22.576777 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 316
>
>
>
> 2020/12/17 10:08:22.581649 proxy-a.com:5060 -> 10.0.14.118:5060
> ACK
> sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
> SIP/2.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK219933f6;rport=5060
> Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
>
>
>
> 2020/12/17 10:08:22.582313 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK219933f6;rport=5060
> Max-Forwards: 70
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Contact: <sip:7654321 at did.com:5060>
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 ACK
> User-Agent: proxy
> Content-Length: 0
> P-K-CSeq-Refresh: 103
>
>
> 2020/12/17 10:08:23.575828 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-b.com:5060
> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 103 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 296
>
>
> 2020/12/17 10:08:23.577863 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK45f94ed9;rport=5060
> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
> Record-Route: <sip:proxy-a.com;lr>
> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
> CSeq: 102 INVITE
> Server: proxy
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 316
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/90335d0a/attachment.htm>

From s.safarov at gmail.com  Thu Dec 17 12:32:37 2020
From: s.safarov at gmail.com (Sergey Safarov)
Date: Thu, 17 Dec 2020 14:32:37 +0300
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
Message-ID: <CAHtxdDfdzyqRFAE=cG6CWgBeHWWAKDqnw7WFQhi=yy40t4X8+A@mail.gmail.com>

Try to make a call to the device behind double NAT (home WiFi router +
carrier NAT).

On Thu, Dec 17, 2020 at 2:09 PM Mihai Cezar <cezar at mokalife.ro> wrote:

> Hi,
>
> Can't figure it out when to use RTPproxy, i am forwarding everything to
> asterisk in seem to work without RTPproxy.
>
> The scenario is like this:
> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>
> Now it seems to work without any rtpproxy but is it ok?
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/d128d9ae/attachment.htm>

From s.safarov at gmail.com  Thu Dec 17 12:36:04 2020
From: s.safarov at gmail.com (Sergey Safarov)
Date: Thu, 17 Dec 2020 14:36:04 +0300
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
Message-ID: <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>

yes, if your asterisk has statically assigned (NAT-ed) public IP, then you
do not need RTPproxy.
RTP proxy required when both sides of the call do not have
statically assigned (NAT-ed) public IP.

On Thu, Dec 17, 2020 at 2:33 PM David Villasmil <
david.villasmil.work at gmail.com> wrote:

> It?s totally fine. Rtpengine is mainly used to also proxy rtp ie: public
> to private, etc. But if your asterisk is public, rtps will reach it, and
> you?re fine with it, go ahead
>
> On Thu, 17 Dec 2020 at 11:10, Mihai Cezar <cezar at mokalife.ro> wrote:
>
>> Hi,
>>
>> Can't figure it out when to use RTPproxy, i am forwarding everything to
>> asterisk in seem to work without RTPproxy.
>>
>> The scenario is like this:
>> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>>
>> Now it seems to work without any rtpproxy but is it ok?
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.work at gmail.com
> phone: +34669448337
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/0fee33e7/attachment.htm>

From terry at fullduplex.co.uk  Thu Dec 17 13:05:19 2020
From: terry at fullduplex.co.uk (Terry Tailor)
Date: Thu, 17 Dec 2020 17:05:19 +0500
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
In-Reply-To: <CAPcKEYMWXvhVnM3YhQS-d-FjCSmRJZ+z4Yc-yyfFSNEPJLFsQA@mail.gmail.com>
References: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
 <CAPcKEYMWXvhVnM3YhQS-d-FjCSmRJZ+z4Yc-yyfFSNEPJLFsQA@mail.gmail.com>
Message-ID: <CAK7XD1tUKkcs1DJf0BEg1DHpA0p5V+Z07yjzOwn6-CwpjQ_RVg@mail.gmail.com>

 Hi, I have updated Kamailio to 5.4 still there is an issue with Cseq of
cancel in case of cancel it is not increasing cSeq
here are details
1. proxy a sends invite with CSeq: 102 INVITE and proxy b route it to
asterisk with CSeq: 102 INVITE
2. asterisk sends 401 Unauthorized with CSeq: 102 INVITE and proxy b sends
ACK with CSeq: 102 ACK
3. proxy b sends invite with CSeq: 103 INVITE and asterisk sends 100 Trying
and 180 Ringing with CSeq: 103 INVITE
4. proxy b relay to proxy a 180 Ringing with CSeq: 102 INVITE
5. proxy a send CANCEL with CSeq: 102 CANCEL and proxy b sends CANCEL with
CSeq: 102 CANCEL to asterisk
6. Now asterisk is sending 481 Call leg/transaction does not exist

uname -a: Linux example.com 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6
10:54:43 UTC 2020 x86_64 GNU/Linux
kamailio -v: version: kamailio 5.4.3 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0


sip logs:


2020/12/17 11:42:32.289934 proxy-a.com:5060 -> 10.0.14.118:5060
INVITE sip:123456 at proxy-a.com SIP/2.0
Record-Route: <sip:proxy-a.com;lr>
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Contact: <sip:54321 at did.com:5060>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
User-Agent: VB-Proxy
CSeq: 102 INVITE
User-Agent: did
Date: Thu, 17 Dec 2020 11:42:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "54321" <sip:54321 at did.com
>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 889

2020/12/17 11:42:32.290569 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 INVITE
Server: kamailio (5.4.3 (x86_64/linux))
Content-Length: 0



2020/12/17 11:42:32.291036 10.0.14.118:5060 -> 10.0.14.118:6000
INVITE sip:123456 at proxy-a.com SIP/2.0
Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
Record-Route: <sip:proxy-a.com;lr>
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Contact: <sip:54321 at did.com:5060>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
User-Agent: VB-Proxy
CSeq: 102 INVITE
User-Agent: did
Date: Thu, 17 Dec 2020 11:42:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "54321" <sip:54321 at did.com
>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 889



2020/12/17 11:42:32.308279 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as152bd976
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 INVITE
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com",
nonce="3673a540"
Content-Length: 0


2020/12/17 11:42:32.308770 10.0.14.118:5060 -> 10.0.14.118:6000
ACK sip:123456 at proxy-a.com SIP/2.0
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as152bd976
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 ACK
Content-Length: 0


2020/12/17 11:42:32.309610 10.0.14.118:5060 -> 10.0.14.118:6000
INVITE sip:123456 at proxy-a.com SIP/2.0
Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
Record-Route: <sip:proxy-a.com;lr>
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Contact: <sip:54321 at did.com:5060>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
User-Agent: VB-Proxy
CSeq: 103 INVITE
User-Agent: did
Date: Thu, 17 Dec 2020 11:42:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "54321" <sip:54321 at did.com
>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 889
Authorization: Digest username="did095499", realm="sip1.comms.kuflink.com",
nonce="3673a540", uri="sip:123456 at proxy-a.com",
response="24d8949f18f4f2650913ce3feaa78380", algorithm=MD5




2020/12/17 11:42:32.333610 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
Record-Route: <sip:proxy-a.com;lr>
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 103 INVITE
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Length: 0



2020/12/17 11:42:34.276380 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
Record-Route: <sip:proxy-a.com;lr>
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as12b14194
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 103 INVITE
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Length: 0


2020/12/17 11:42:34.277337 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
Record-Route: <sip:proxy-a.com;lr>
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as12b14194
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 INVITE
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
Content-Length: 0



2020/12/17 11:42:38.113181 proxy-a.com:5060 -> 10.0.14.118:5060
CANCEL sip:123456 at proxy-a.com SIP/2.0
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 CANCEL
Content-Length: 0


2020/12/17 11:42:38.113918 10.0.14.118:5060 -> 10.0.14.118:6000
CANCEL sip:123456 at proxy-a.com SIP/2.0
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 CANCEL
Content-Length: 0
P-K-CSeq-Auth: 103



2020/12/17 11:42:38.114114 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 200 canceling
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=a74459175e9494c7e23ffeb306461015-0f770312
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 CANCEL
Server: kamailio (5.4.3 (x86_64/linux))
Content-Length: 0



2020/12/17 11:42:38.116456 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as24deed39
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 CANCEL
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0



2020/12/17 11:42:54.554350 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
Record-Route: <sip:proxy-a.com;lr>
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as12b14194
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 103 INVITE
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:123456 at 10.0.14.118:6000>
Content-Type: application/sdp
Require: timer
Content-Length: 292



2020/12/17 11:42:54.554978 10.0.14.118:5060 -> 10.0.14.118:6000
CANCEL sip:123456 at proxy-a.com SIP/2.0
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 CANCEL
Content-Length: 0
P-K-CSeq-Auth: 103



2020/12/17 11:42:54.557082 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as5eee0295
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 CANCEL
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0



2020/12/17 11:42:59.617825 10.0.14.118:6000 -> 10.0.14.118:5060
SIP/2.0 603 Declined
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as12b14194
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 103 INVITE
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Content-Length: 0



2020/12/17 11:42:59.618423 10.0.14.118:5060 -> 10.0.14.118:6000
ACK sip:123456 at proxy-a.com SIP/2.0
Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as12b14194
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 103 ACK
Content-Length: 0



2020/12/17 11:42:59.618944 10.0.14.118:5060 -> proxy-a.com:5060
SIP/2.0 603 Declined
Via: SIP/2.0/UDP proxy-a.com:5060
;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Via: SIP/2.0/UDP did.com:5060;received=did.com
;branch=z9hG4bK3756a567;rport=5060
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as12b14194
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 INVITE
Server: did
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Content-Length: 0



2020/12/17 11:42:59.620074 proxy-a.com:5060 -> 10.0.14.118:5060
ACK sip:123456 at proxy-a.com SIP/2.0
Via: SIP/2.0/UDP proxy-a.com:5060
;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
Max-Forwards: 70
From: "54321" <sip:54321 at did.com>;tag=as02b3f892
To: <sip:123456 at proxy-a.com>;tag=as12b14194
Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
CSeq: 102 ACK
Content-Length: 0

On Thu, Dec 17, 2020 at 4:52 PM George Diamantopoulos <georgediam at gmail.com>
wrote:

> Not sure if this is related, but I've also run into issues with
> track_cseq_updates:
> https://www.mail-archive.com/sr-users at lists.kamailio.org/msg12362.html
>
> More specifically, kamailio won't process the 100 Trying to an Cseq-bumped
> INVITE it generated
> itself with uac_auth() when track_cseq_updates is on.
>
> This implementation appears to be a little too fragile for the time
> being....
>
> BR,
> George
>
> On Thu, 17 Dec 2020 at 12:29, Terry Tailor <terry at fullduplex.co.uk> wrote:
>
>> Hi, Here is setup details
>> Kamailio Proxy a <-----> Kamailio Proxy b  <-----> Asterisk
>> Kamailio proxy b auth based on IP Kamailio Proxy a
>> 1. Kamailio proxy sends an Invite request to Kamailio proxy b with CSeq:
>> 102 INVITE
>> 2. Kamailio proxy b check again IP auth and sends invite request to
>> asterisk with CSeq: 102 INVITE
>> 4 asterisk response with 401 Unauthorized with  CSeq: 102
>> 5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
>> 6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
>> 7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
>> 8. Kamailio proxy b relay 180 ringing with  CSeq: 102 INVITE
>> 9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b relay it to
>> proxy a with CSeq: 102 INVITE
>> 10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b relay ACK to
>> asterisk with CSeq: 102 ACK
>>
>> Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE and proxy a
>> is sending ACK with Cseq: 102 ACK
>>
>> Same happing in case of 487 Request Terminated
>>
>> Here is my config
>>
>> modparam("dialog", "default_timeout", 10800) # 3h
>> modparam("dialog", "dlg_match_mode", 1)
>> modparam("dialog", "db_mode", 0)
>> modparam("dialog", "send_bye", 1)
>> modparam("dialog", "track_cseq_updates", 1)
>> modparam("uac","auth_username_avp","$avp(auser)")
>> modparam("uac","auth_password_avp","$avp(apass)")
>> modparam("uac","auth_realm_avp","$avp(arealm)")
>>
>> modparam("tm", "failure_reply_mode", 3)
>> # default retransmission timeout: 3 sec
>> modparam("tm", "fr_timer", 2000)
>> modparam("tm", "retr_timer1", 250)
>> modparam("tm", "retr_timer2", 500)
>> # default invite retransmission timeout after 1xx: 60 sec
>> modparam("tm", "fr_inv_timer", 60000)
>> modparam("tm", "reparse_on_dns_failover", 0)
>>
>>
>>
>> if (is_method("INVITE") && !has_totag()) {
>>         dlg_setflag(FLD_RTPPROXY);
>>         dlg_manage();
>>     }
>>     route(RELAY);
>>
>>
>>
>>
>> route[RELAY] {
>>
>>     # At this point all checks are passed
>>     t_on_branch("MANAGE_BRANCH");
>>     t_on_reply("MANAGE_REPLY");
>>     t_on_failure("MANAGE_FAILURE");
>>     if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
>>      #$fd = "sip.comms.kuflink.com";
>>       t_on_failure("RELAY_AUTH");
>>     }
>>
>>     if (!t_relay()) {
>>         send_reply("500", "Cannot relay to $du/$ru");
>>     }
>>     exit;
>> }
>>
>> failure_route[RELAY_AUTH] {
>>     t_on_branch("MANAGE_BRANCH");
>>     t_on_reply("MANAGE_REPLY");
>>     if (t_is_canceled()) {
>>         exit;
>>     }
>>     if(t_check_status("401|407")) {
>>         #$fd = "sip.comms.kuflink.com";
>>         $avp(auser) = "DID_UA_USERNAME";
>>         $avp(apass) = "DID_UA_PASSWORD";
>>         if (uac_auth()) {
>>             t_relay();
>>         }
>>         exit;
>>     }
>> }
>>
>>
>> route[WITHINDLG] {
>>     if (!has_totag()) {
>>         return;
>>     }
>>
>>     if (is_method("BYE")) {
>>         rtpengine_delete();
>>     }
>>
>>     # sequential request withing a dialog should
>>     # take the path determined by record-routing
>>     if (loose_route()) {
>>         route(DLGURI);
>>         if (is_method("ACK")) {
>>             # ACK is forwarded statelessly
>>             route(NATMANAGE);
>>         } else if (is_method("NOTIFY")) {
>>             # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
>>             record_route();
>>         }
>>         route(RELAY);
>>         exit;
>>     }
>>
>>     if (is_method("SUBSCRIBE") && uri == myself) {
>>         # in-dialog subscribe requests
>>         route(PRESENCE);
>>         exit;
>>     }
>>     if (is_method("ACK") ) {
>>         if (t_check_trans()) {
>>             # no loose-route, but stateful ACK;
>>             # must be an ACK after a 487
>>             # or e.g. 404 from upstream server
>>             route(RELAY);
>>             exit;
>>         } else {
>>             # ACK without matching transaction ... ignore and discard
>>             exit;
>>         }
>>     }
>>     send_reply("404","Not here");
>>     exit;
>> }
>>
>>
>> kamailio -v
>> version: kamailio 5.3.7 (x86_64/linux)
>> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
>> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
>> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
>> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
>> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
>> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> id: unknown
>> compiled with gcc 6.3.0
>>
>>
>> uname -a
>> Linux example.com 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43
>> UTC 2020 x86_64 GNU/Linux
>>
>>
>>
>> SIP logs
>> 2020/12/17 10:08:18.483907 proxy-a.com:5060 -> 10.0.14.118:5060
>> INVITE sip:123456 at proxy-a.com SIP/2.0
>> Record-Route: <sip:proxy-a.com;lr>
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>
>> Contact: <sip:7654321 at did.com:5060>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> User-Agent: ProxyA
>> CSeq: 102 INVITE
>> User-Agent: proxy
>> Date: Thu, 17 Dec 2020 10:08:18 GMT
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Remote-Party-ID: "7654321" <sip:7654321 at did.com
>> >;party=calling;privacy=off;screen=no
>> Content-Type: application/sdp
>> Content-Length: 885
>>
>>
>>
>> 2020/12/17 10:08:18.485063 10.0.14.118:5060 -> proxy-a.com:5060
>> SIP/2.0 100 trying -- your call is important to us
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 INVITE
>> Server: kamailio (5.3.7 (x86_64/linux))
>> Content-Length: 0
>>
>>
>> 2020/12/17 10:08:18.485576 10.0.14.118:5060 -> 10.0.14.118:6000
>> INVITE sip:123456 at proxy-a.com SIP/2.0
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>
>> Contact: <sip:7654321 at did.com:5060>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> User-Agent: ProxyA
>> CSeq: 102 INVITE
>> User-Agent: proxy
>> Date: Thu, 17 Dec 2020 10:08:18 GMT
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Remote-Party-ID: "7654321" <sip:7654321 at did.com
>> >;party=calling;privacy=off;screen=no
>> Content-Type: application/sdp
>> Content-Length: 885
>>
>>
>>
>> 2020/12/17 10:08:18.622867 10.0.14.118:6000 -> 10.0.14.118:5060
>> SIP/2.0 401 Unauthorized
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as4107645c
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com",
>> nonce="11139d33"
>> Content-Length: 0
>>
>>
>>
>> 2020/12/17 10:08:18.624034 10.0.14.118:5060 -> 10.0.14.118:6000
>> ACK sip:123456 at proxy-a.com SIP/2.0
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as4107645c
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 ACK
>> Content-Length: 0
>>
>>
>>
>> 2020/12/17 10:08:18.625557 10.0.14.118:5060 -> 10.0.14.118:6000
>> INVITE sip:123456 at proxy-a.com SIP/2.0
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>
>> Contact: <sip:7654321 at did.com:5060>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> User-Agent: ProxyA
>> CSeq: 103 INVITE
>> User-Agent: proxy
>> Date: Thu, 17 Dec 2020 10:08:18 GMT
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Remote-Party-ID: "7654321" <sip:7654321 at did.com
>> >;party=calling;privacy=off;screen=no
>> Content-Type: application/sdp
>> Content-Length: 885
>> Authorization: Digest username="xxxxx", realm="xxxx", nonce="11139d33",
>> uri="sip:123456 at proxy-a.com", response="qwewqeqwe", algorithm=MD5
>>
>>
>>
>> 2020/12/17 10:08:18.779483 10.0.14.118:6000 -> 10.0.14.118:5060
>> SIP/2.0 100 Trying
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 103 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000>
>> Content-Length: 0
>>
>>
>>
>>
>> 2020/12/17 10:08:20.937756 10.0.14.118:6000 -> 10.0.14.118:5060
>> SIP/2.0 180 Ringing
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 103 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000>
>> Content-Length: 0
>>
>>
>>
>> 2020/12/17 10:08:20.938593 10.0.14.118:5060 -> proxy-a.com:5060
>> SIP/2.0 180 Ringing
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>> Content-Length: 0
>>
>>
>>
>> 2020/12/17 10:08:22.075814 10.0.14.118:6000 -> 10.0.14.118:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 103 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000>
>> Content-Type: application/sdp
>> Require: timer
>> Content-Length: 296
>>
>>
>> 2020/12/17 10:08:22.077049 10.0.14.118:5060 -> proxy-a.com:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>> Content-Type: application/sdp
>> Require: timer
>> Content-Length: 316
>>
>>
>>
>> 2020/12/17 10:08:22.103365 proxy-a.com:5060 -> 10.0.14.118:5060
>> ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>> SIP/2.0
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK2a5fae72;rport=5060
>> Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Contact: <sip:7654321 at did.com:5060>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 ACK
>> User-Agent: proxy
>> Content-Length: 0
>>
>>
>>
>> 2020/12/17 10:08:22.103877 10.0.14.118:5060 -> 10.0.14.118:6000
>> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK2a5fae72;rport=5060
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Contact: <sip:7654321 at did.com:5060>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 ACK
>> User-Agent: proxy
>> Content-Length: 0
>> P-K-CSeq-Refresh: 103
>>
>>
>> 2020/12/17 10:08:22.575533 10.0.14.118:6000 -> 10.0.14.118:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 103 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000>
>> Content-Type: application/sdp
>> Require: timer
>> Content-Length: 296
>>
>>
>>
>> 2020/12/17 10:08:22.576777 10.0.14.118:5060 -> proxy-a.com:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>> Content-Type: application/sdp
>> Require: timer
>> Content-Length: 316
>>
>>
>>
>> 2020/12/17 10:08:22.581649 proxy-a.com:5060 -> 10.0.14.118:5060
>> ACK sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>> SIP/2.0
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK219933f6;rport=5060
>> Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Contact: <sip:7654321 at did.com:5060>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 ACK
>> User-Agent: proxy
>> Content-Length: 0
>>
>>
>>
>> 2020/12/17 10:08:22.582313 10.0.14.118:5060 -> 10.0.14.118:6000
>> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK219933f6;rport=5060
>> Max-Forwards: 70
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Contact: <sip:7654321 at did.com:5060>
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 ACK
>> User-Agent: proxy
>> Content-Length: 0
>> P-K-CSeq-Refresh: 103
>>
>>
>> 2020/12/17 10:08:23.575828 10.0.14.118:6000 -> 10.0.14.118:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP proxy-b.com:5060
>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 103 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000>
>> Content-Type: application/sdp
>> Require: timer
>> Content-Length: 296
>>
>>
>> 2020/12/17 10:08:23.577863 10.0.14.118:5060 -> proxy-a.com:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP proxy-a.com:5060
>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>> ;branch=z9hG4bK45f94ed9;rport=5060
>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>> Record-Route: <sip:proxy-a.com;lr>
>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>> CSeq: 102 INVITE
>> Server: proxy
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
>> PUBLISH, MESSAGE
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uas
>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>> Content-Type: application/sdp
>> Require: timer
>> Content-Length: 316
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/18e44e24/attachment.htm>

From sergio.charrua at voip.pt  Thu Dec 17 13:28:02 2020
From: sergio.charrua at voip.pt (Sergio Charrua)
Date: Thu, 17 Dec 2020 12:28:02 +0000
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
 <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>
Message-ID: <CALZWR5xBiGuYv8=VcGXkiKvZ3Yy-_GOcv=udsDkMYeR14N301Q@mail.gmail.com>

Another example of when to use RTPProxy / RTPEngine is:

SIP user -> router -> INTERNET -> router / firewall -> Kamailio (private
IP) -> Asterisk (private IP)

Apart from the routers, all other equipments are private IPs, hence being
NATed and requiring RTP Proxy / RTP Engine to forward RTP streams to the
correct ports.
As David Vilasmil points out, security wise, this is the best approach....
but it is a PITA configuring and making all the services work correctly.

*S?rgio Charrua*


*www.voip.pt <http://www.voip.pt/>*
Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77

Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Thu, Dec 17, 2020 at 12:15 PM Sergey Safarov <s.safarov at gmail.com> wrote:

> yes, if your asterisk has statically assigned (NAT-ed) public IP, then you
> do not need RTPproxy.
> RTP proxy required when both sides of the call do not have
> statically assigned (NAT-ed) public IP.
>
> On Thu, Dec 17, 2020 at 2:33 PM David Villasmil <
> david.villasmil.work at gmail.com> wrote:
>
>> It?s totally fine. Rtpengine is mainly used to also proxy rtp ie: public
>> to private, etc. But if your asterisk is public, rtps will reach it, and
>> you?re fine with it, go ahead
>>
>> On Thu, 17 Dec 2020 at 11:10, Mihai Cezar <cezar at mokalife.ro> wrote:
>>
>>> Hi,
>>>
>>> Can't figure it out when to use RTPproxy, i am forwarding everything to
>>> asterisk in seem to work without RTPproxy.
>>>
>>> The scenario is like this:
>>> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>>>
>>> Now it seems to work without any rtpproxy but is it ok?
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> --
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.work at gmail.com
>> phone: +34669448337
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/5e921fbb/attachment.htm>

From cezar at mokalife.ro  Thu Dec 17 14:16:50 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Thu, 17 Dec 2020 15:16:50 +0200
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CALZWR5xBiGuYv8=VcGXkiKvZ3Yy-_GOcv=udsDkMYeR14N301Q@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
 <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>
 <CALZWR5xBiGuYv8=VcGXkiKvZ3Yy-_GOcv=udsDkMYeR14N301Q@mail.gmail.com>
Message-ID: <CANk_n4b-EPY-ahWQe-HfmTTmpyhhxjmZvGmAA2oR+2qT0vdh2w@mail.gmail.com>

I do have kamailio an public IP and another nic with private IP that
connects to the Asterisk LAN.

@Sergey I tried that scenario with double NAT, and, it work it.

If i choose to go rtpproxy which modules should i load (nat_helper,
nat_traversal, rtpproxy) ?



On Thu, Dec 17, 2020 at 2:38 PM Sergio Charrua <sergio.charrua at voip.pt>
wrote:

> Another example of when to use RTPProxy / RTPEngine is:
>
> SIP user -> router -> INTERNET -> router / firewall -> Kamailio (private
> IP) -> Asterisk (private IP)
>
> Apart from the routers, all other equipments are private IPs, hence being
> NATed and requiring RTP Proxy / RTP Engine to forward RTP streams to the
> correct ports.
> As David Vilasmil points out, security wise, this is the best approach....
> but it is a PITA configuring and making all the services work correctly.
>
> *S?rgio Charrua*
>
>
> *www.voip.pt <http://www.voip.pt/>*
> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>
> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
>
> On Thu, Dec 17, 2020 at 12:15 PM Sergey Safarov <s.safarov at gmail.com>
> wrote:
>
>> yes, if your asterisk has statically assigned (NAT-ed) public IP, then
>> you do not need RTPproxy.
>> RTP proxy required when both sides of the call do not have
>> statically assigned (NAT-ed) public IP.
>>
>> On Thu, Dec 17, 2020 at 2:33 PM David Villasmil <
>> david.villasmil.work at gmail.com> wrote:
>>
>>> It?s totally fine. Rtpengine is mainly used to also proxy rtp ie: public
>>> to private, etc. But if your asterisk is public, rtps will reach it, and
>>> you?re fine with it, go ahead
>>>
>>> On Thu, 17 Dec 2020 at 11:10, Mihai Cezar <cezar at mokalife.ro> wrote:
>>>
>>>> Hi,
>>>>
>>>> Can't figure it out when to use RTPproxy, i am forwarding everything to
>>>> asterisk in seem to work without RTPproxy.
>>>>
>>>> The scenario is like this:
>>>> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>>>>
>>>> Now it seems to work without any rtpproxy but is it ok?
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> --
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.work at gmail.com
>>> phone: +34669448337
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/3afc7494/attachment.htm>

From david.villasmil.work at gmail.com  Thu Dec 17 14:58:47 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 17 Dec 2020 13:58:47 +0000
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CANk_n4b-EPY-ahWQe-HfmTTmpyhhxjmZvGmAA2oR+2qT0vdh2w@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
 <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>
 <CALZWR5xBiGuYv8=VcGXkiKvZ3Yy-_GOcv=udsDkMYeR14N301Q@mail.gmail.com>
 <CANk_n4b-EPY-ahWQe-HfmTTmpyhhxjmZvGmAA2oR+2qT0vdh2w@mail.gmail.com>
Message-ID: <CAFGRPVrVyD_rS6nt=JZ+v31V4Ejk1LkNbqkDmbyzvurZpGbdkQ@mail.gmail.com>

This might help you as a starting point.

https://github.com/davidcsi/kamailio-private-public

Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337


On Thu, Dec 17, 2020 at 1:20 PM Mihai Cezar <cezar at mokalife.ro> wrote:

> I do have kamailio an public IP and another nic with private IP that
> connects to the Asterisk LAN.
>
> @Sergey I tried that scenario with double NAT, and, it work it.
>
> If i choose to go rtpproxy which modules should i load (nat_helper,
> nat_traversal, rtpproxy) ?
>
>
>
> On Thu, Dec 17, 2020 at 2:38 PM Sergio Charrua <sergio.charrua at voip.pt>
> wrote:
>
>> Another example of when to use RTPProxy / RTPEngine is:
>>
>> SIP user -> router -> INTERNET -> router / firewall -> Kamailio (private
>> IP) -> Asterisk (private IP)
>>
>> Apart from the routers, all other equipments are private IPs, hence being
>> NATed and requiring RTP Proxy / RTP Engine to forward RTP streams to the
>> correct ports.
>> As David Vilasmil points out, security wise, this is the best
>> approach.... but it is a PITA configuring and making all the services work
>> correctly.
>>
>> *S?rgio Charrua*
>>
>>
>> *www.voip.pt <http://www.voip.pt/>*
>> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>>
>> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>>
>> This message and any files or documents attached are strictly
>> confidential or otherwise legally protected.
>>
>> It is intended only for the individual or entity named. If you are not
>> the named addressee or have received this email in error, please inform the
>> sender immediately, delete it from your system and do not copy or disclose
>> it or its contents or use it for any purpose. Please also note that
>> transmission cannot be guaranteed to be secure or error-free.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Dec 17, 2020 at 12:15 PM Sergey Safarov <s.safarov at gmail.com>
>> wrote:
>>
>>> yes, if your asterisk has statically assigned (NAT-ed) public IP, then
>>> you do not need RTPproxy.
>>> RTP proxy required when both sides of the call do not have
>>> statically assigned (NAT-ed) public IP.
>>>
>>> On Thu, Dec 17, 2020 at 2:33 PM David Villasmil <
>>> david.villasmil.work at gmail.com> wrote:
>>>
>>>> It?s totally fine. Rtpengine is mainly used to also proxy rtp ie:
>>>> public to private, etc. But if your asterisk is public, rtps will reach it,
>>>> and you?re fine with it, go ahead
>>>>
>>>> On Thu, 17 Dec 2020 at 11:10, Mihai Cezar <cezar at mokalife.ro> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Can't figure it out when to use RTPproxy, i am forwarding everything
>>>>> to asterisk in seem to work without RTPproxy.
>>>>>
>>>>> The scenario is like this:
>>>>> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>>>>>
>>>>> Now it seems to work without any rtpproxy but is it ok?
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>> --
>>>> Regards,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.work at gmail.com
>>>> phone: +34669448337
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/65389941/attachment.htm>

From miconda at gmail.com  Thu Dec 17 14:59:47 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 17 Dec 2020 14:59:47 +0100
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
In-Reply-To: <CAK7XD1tUKkcs1DJf0BEg1DHpA0p5V+Z07yjzOwn6-CwpjQ_RVg@mail.gmail.com>
References: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
 <CAPcKEYMWXvhVnM3YhQS-d-FjCSmRJZ+z4Yc-yyfFSNEPJLFsQA@mail.gmail.com>
 <CAK7XD1tUKkcs1DJf0BEg1DHpA0p5V+Z07yjzOwn6-CwpjQ_RVg@mail.gmail.com>
Message-ID: <ce569742-c28c-a3b6-e4bd-0ae2bcb50815@gmail.com>

Hello,

can you try with latest git branch 5.4? I just pushed a commit to handle
this case.

You have to compile from sources, like:

? * https://kamailio.org/docs/tutorials/5.4.x/kamailio-install-guide-git/

Debian packages from branch 5.4 are also built over night:

? * http://deb.kamailio.org/#dev54

Cheers,
Daniel

On 17.12.20 13:05, Terry Tailor wrote:
> Hi, I have updated Kamailio to 5.4 still there is an issue with Cseq
> of cancel in case of cancel it is not increasing cSeq
> here are details
> 1. proxy a sends invite with CSeq: 102 INVITE and proxy b route it to
> asterisk with CSeq: 102 INVITE
> 2. asterisk sends 401 Unauthorized with CSeq: 102 INVITE and proxy b
> sends ACK with CSeq: 102 ACK
> 3. proxy b sends invite with CSeq: 103 INVITE and asterisk sends 100
> Trying and 180 Ringing with CSeq: 103 INVITE
> 4. proxy b relay to proxy a 180 Ringing with CSeq: 102 INVITE
> 5. proxy a send CANCEL with CSeq: 102 CANCEL and proxy b sends CANCEL
> with CSeq: 102 CANCEL to asterisk
> 6. Now asterisk is sending 481 Call leg/transaction does not exist
>
> uname -a: Linux example.com <http://example.com> 4.15.0-124-generic
> #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 GNU/Linux
> kamailio -v: version: kamailio 5.4.3 (x86_64/linux)
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
> USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
> 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled with gcc 6.3.0
>
>
> sip logs:
>
>
> 2020/12/17 11:42:32.289934 proxy-a.com:5060 <http://proxy-a.com:5060>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> INVITE sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
> Via: SIP/2.0/UDP
> proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Contact: <sip:54321 at did.com:5060 <http://sip:54321 at did.com:5060>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> User-Agent: VB-Proxy
> CSeq: 102 INVITE
> User-Agent: did
> Date: Thu, 17 Dec 2020 11:42:32 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 889
>
> 2020/12/17 11:42:32.290569 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> proxy-a.com:5060 <http://proxy-a.com:5060>
> SIP/2.0 100 trying -- your call is important to us
> Via: SIP/2.0/UDP
> proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 INVITE
> Server: kamailio (5.4.3 (x86_64/linux))
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:32.291036 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> 10.0.14.118:6000 <http://10.0.14.118:6000>
> INVITE sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Record-Route: <sip:sip.comms.kuflink.com
> <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Contact: <sip:54321 at did.com:5060 <http://sip:54321 at did.com:5060>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> User-Agent: VB-Proxy
> CSeq: 102 INVITE
> User-Agent: did
> Date: Thu, 17 Dec 2020 11:42:32 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 889
>
>
>
> 2020/12/17 11:42:32.308279 10.0.14.118:6000 <http://10.0.14.118:6000>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as152bd976
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com
> <http://sip1.comms.kuflink.com>", nonce="3673a540"
> Content-Length: 0
>
>
> 2020/12/17 11:42:32.308770 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> 10.0.14.118:6000 <http://10.0.14.118:6000>
> ACK sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as152bd976
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 ACK
> Content-Length: 0
>
>
> 2020/12/17 11:42:32.309610 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> 10.0.14.118:6000 <http://10.0.14.118:6000>
> INVITE sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Record-Route: <sip:sip.comms.kuflink.com
> <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Contact: <sip:54321 at did.com:5060 <http://sip:54321 at did.com:5060>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> User-Agent: VB-Proxy
> CSeq: 103 INVITE
> User-Agent: did
> Date: Thu, 17 Dec 2020 11:42:32 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 889
> Authorization: Digest username="did095499",
> realm="sip1.comms.kuflink.com <http://sip1.comms.kuflink.com>",
> nonce="3673a540", uri="sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>",
> response="24d8949f18f4f2650913ce3feaa78380", algorithm=MD5
>
>
>
>
> 2020/12/17 11:42:32.333610 10.0.14.118:6000 <http://10.0.14.118:6000>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com
> <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000
> <http://sip:123456 at 10.0.14.118:6000>>
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:34.276380 10.0.14.118:6000 <http://10.0.14.118:6000>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com
> <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000
> <http://sip:123456 at 10.0.14.118:6000>>
> Content-Length: 0
>
>
> 2020/12/17 11:42:34.277337 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> proxy-a.com:5060 <http://proxy-a.com:5060>
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com
> <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:38.113181 proxy-a.com:5060 <http://proxy-a.com:5060>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> CANCEL sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Via: SIP/2.0/UDP
> proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 CANCEL
> Content-Length: 0
>
>
> 2020/12/17 11:42:38.113918 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> 10.0.14.118:6000 <http://10.0.14.118:6000>
> CANCEL sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 CANCEL
> Content-Length: 0
> P-K-CSeq-Auth: 103
>
>
>
> 2020/12/17 11:42:38.114114 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> proxy-a.com:5060 <http://proxy-a.com:5060>
> SIP/2.0 200 canceling
> Via: SIP/2.0/UDP
> proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=a74459175e9494c7e23ffeb306461015-0f770312
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 CANCEL
> Server: kamailio (5.4.3 (x86_64/linux))
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:38.116456 10.0.14.118:6000 <http://10.0.14.118:6000>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> SIP/2.0 481 Call leg/transaction does not exist
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as24deed39
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 CANCEL
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:54.554350 10.0.14.118:6000 <http://10.0.14.118:6000>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> SIP/2.0 183 Session Progress
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com
> <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000
> <http://sip:123456 at 10.0.14.118:6000>>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 292
>
>
>
> 2020/12/17 11:42:54.554978 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> 10.0.14.118:6000 <http://10.0.14.118:6000>
> CANCEL sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 CANCEL
> Content-Length: 0
> P-K-CSeq-Auth: 103
>
>
>
> 2020/12/17 11:42:54.557082 10.0.14.118:6000 <http://10.0.14.118:6000>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> SIP/2.0 481 Call leg/transaction does not exist
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as5eee0295
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 CANCEL
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.617825 10.0.14.118:6000 <http://10.0.14.118:6000>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> SIP/2.0 603 Declined
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.618423 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> 10.0.14.118:6000 <http://10.0.14.118:6000>
> ACK sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Via: SIP/2.0/UDP
> sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 103 ACK
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.618944 10.0.14.118:5060 <http://10.0.14.118:5060>
> -> proxy-a.com:5060 <http://proxy-a.com:5060>
> SIP/2.0 603 Declined
> Via: SIP/2.0/UDP
> proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> <http://did.com>;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.620074 proxy-a.com:5060 <http://proxy-a.com:5060>
> -> 10.0.14.118:5060 <http://10.0.14.118:5060>
> ACK sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
> Via: SIP/2.0/UDP
> proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com
> <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com
> <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
> CSeq: 102 ACK
> Content-Length: 0
>
> On Thu, Dec 17, 2020 at 4:52 PM George Diamantopoulos
> <georgediam at gmail.com <mailto:georgediam at gmail.com>> wrote:
>
>     Not sure if this is related, but I've also run into issues with
>     track_cseq_updates:
>     https://www.mail-archive.com/sr-users at lists.kamailio.org/msg12362.html
>     <https://www.mail-archive.com/sr-users at lists.kamailio.org/msg12362.html>
>
>     More specifically, kamailio won't process the 100 Trying to an
>     Cseq-bumped INVITE it generated
>     itself with uac_auth() when track_cseq_updates is on.
>
>     This implementation appears to be a little too fragile for the
>     time being....
>
>     BR,
>     George
>
>     On Thu, 17 Dec 2020 at 12:29, Terry Tailor <terry at fullduplex.co.uk
>     <mailto:terry at fullduplex.co.uk>> wrote:
>
>         Hi, Here is setup details
>         Kamailio Proxy a <-----> Kamailio Proxy b? <-----> Asterisk
>         Kamailio proxy b auth based on IP Kamailio Proxy a
>         1. Kamailio proxy sends an Invite request to Kamailio proxy b
>         with CSeq: 102 INVITE
>         2. Kamailio proxy b check again IP auth and sends invite
>         request to asterisk with CSeq: 102 INVITE
>         4 asterisk response with 401 Unauthorized with? CSeq: 102
>         5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
>         6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
>         7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
>         8. Kamailio proxy b relay 180 ringing with? CSeq: 102 INVITE
>         9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b
>         relay it to proxy a with CSeq: 102 INVITE
>         10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b
>         relay ACK to asterisk with CSeq: 102 ACK
>
>         Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE
>         and proxy a is sending ACK with Cseq: 102 ACK
>
>         Same happing in case of 487 Request Terminated
>
>         Here is my config
>
>         modparam("dialog", "default_timeout", 10800) # 3h
>         modparam("dialog", "dlg_match_mode", 1)
>         modparam("dialog", "db_mode", 0)
>         modparam("dialog", "send_bye", 1)
>         modparam("dialog", "track_cseq_updates", 1)
>         modparam("uac","auth_username_avp","$avp(auser)")
>         modparam("uac","auth_password_avp","$avp(apass)")
>         modparam("uac","auth_realm_avp","$avp(arealm)")
>
>         modparam("tm", "failure_reply_mode", 3)
>         # default retransmission timeout: 3 sec
>         modparam("tm", "fr_timer", 2000)
>         modparam("tm", "retr_timer1", 250)
>         modparam("tm", "retr_timer2", 500)
>         # default invite retransmission timeout after 1xx: 60 sec
>         modparam("tm", "fr_inv_timer", 60000)
>         modparam("tm", "reparse_on_dns_failover", 0)
>
>
>
>         if (is_method("INVITE") && !has_totag()) {
>         ? ? ? ? dlg_setflag(FLD_RTPPROXY);
>         ? ? ? ? dlg_manage();
>         ? ? }
>         ? ? route(RELAY);
>
>
>
>
>         route[RELAY] {
>
>         ? ? # At this point all checks are passed
>         ? ? t_on_branch("MANAGE_BRANCH");
>         ? ? t_on_reply("MANAGE_REPLY");
>         ? ? t_on_failure("MANAGE_FAILURE");
>         ? ? if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
>         ? ? ?#$fd = "sip.comms.kuflink.com
>         <http://sip.comms.kuflink.com>";
>         ? ? ? t_on_failure("RELAY_AUTH");
>         ? ? }
>
>         ? ? if (!t_relay()) {
>         ? ? ? ? send_reply("500", "Cannot relay to $du/$ru");
>         ? ? }
>         ? ? exit;
>         }
>
>         failure_route[RELAY_AUTH] {
>         ? ? t_on_branch("MANAGE_BRANCH");
>         ? ? t_on_reply("MANAGE_REPLY");
>         ? ? if (t_is_canceled()) {
>         ? ? ? ? exit;
>         ? ? }
>         ? ? if(t_check_status("401|407")) {
>         ? ? ? ? #$fd = "sip.comms.kuflink.com
>         <http://sip.comms.kuflink.com>";
>         ? ? ? ? $avp(auser) = "DID_UA_USERNAME";
>         ? ? ? ? $avp(apass) = "DID_UA_PASSWORD";
>         ? ? ? ? if (uac_auth()) {
>         ? ? ? ? ? ? t_relay();
>         ? ? ? ? }
>         ? ? ? ? exit;
>         ? ? }
>         }
>
>
>         route[WITHINDLG] {
>         ? ? if (!has_totag()) {
>         ? ? ? ? return;
>         ? ? }
>
>         ? ? if (is_method("BYE")) {
>         ? ? ? ? rtpengine_delete();
>         ? ? }
>
>         ? ? # sequential request withing a dialog should
>         ? ? # take the path determined by record-routing
>         ? ? if (loose_route()) {
>         ? ? ? ? route(DLGURI);
>         ? ? ? ? if (is_method("ACK")) {
>         ? ? ? ? ? ? # ACK is forwarded statelessly
>         ? ? ? ? ? ? route(NATMANAGE);
>         ? ? ? ? } else if (is_method("NOTIFY")) {
>         ? ? ? ? ? ? # Add Record-Route for in-dialog NOTIFY as per RFC
>         6665.
>         ? ? ? ? ? ? record_route();
>         ? ? ? ? }
>         ? ? ? ? route(RELAY);
>         ? ? ? ? exit;
>         ? ? }
>
>         ? ? if (is_method("SUBSCRIBE") && uri == myself) {
>         ? ? ? ? # in-dialog subscribe requests
>         ? ? ? ? route(PRESENCE);
>         ? ? ? ? exit;
>         ? ? }
>         ? ? if (is_method("ACK") ) {
>         ? ? ? ? if (t_check_trans()) {
>         ? ? ? ? ? ? # no loose-route, but stateful ACK;
>         ? ? ? ? ? ? # must be an ACK after a 487
>         ? ? ? ? ? ? # or e.g. 404 from upstream server
>         ? ? ? ? ? ? route(RELAY);
>         ? ? ? ? ? ? exit;
>         ? ? ? ? } else {
>         ? ? ? ? ? ? # ACK without matching transaction ... ignore and
>         discard
>         ? ? ? ? ? ? exit;
>         ? ? ? ? }
>         ? ? }
>         ? ? send_reply("404","Not here");
>         ? ? exit;
>         }
>
>
>         kamailio -v
>         version: kamailio 5.3.7 (x86_64/linux)
>         flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>         DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC,
>         Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
>         FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER,
>         USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES,
>         TLS_PTHREAD_MUTEX_SHARED
>         ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144,
>         MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>         poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>         id: unknown
>         compiled with gcc 6.3.0
>
>
>         uname -a
>         Linux example.com <http://example.com> 4.15.0-124-generic
>         #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 GNU/Linux
>
>
>
>         SIP logs
>         2020/12/17 10:08:18.483907 proxy-a.com:5060
>         <http://proxy-a.com:5060> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         INVITE sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>         Contact: <sip:7654321 at did.com:5060
>         <http://sip:7654321 at did.com:5060>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         User-Agent: ProxyA
>         CSeq: 102 INVITE
>         User-Agent: proxy
>         Date: Thu, 17 Dec 2020 10:08:18 GMT
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Remote-Party-ID: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
>         Content-Type: application/sdp
>         Content-Length: 885
>
>
>
>         2020/12/17 10:08:18.485063 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> proxy-a.com:5060
>         <http://proxy-a.com:5060>
>         SIP/2.0 100 trying -- your call is important to us
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 INVITE
>         Server: kamailio (5.3.7 (x86_64/linux))
>         Content-Length: 0
>
>
>         2020/12/17 10:08:18.485576 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> 10.0.14.118:6000
>         <http://10.0.14.118:6000>
>         INVITE sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>         Contact: <sip:7654321 at did.com:5060
>         <http://sip:7654321 at did.com:5060>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         User-Agent: ProxyA
>         CSeq: 102 INVITE
>         User-Agent: proxy
>         Date: Thu, 17 Dec 2020 10:08:18 GMT
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Remote-Party-ID: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
>         Content-Type: application/sdp
>         Content-Length: 885
>
>
>
>         2020/12/17 10:08:18.622867 10.0.14.118:6000
>         <http://10.0.14.118:6000> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         SIP/2.0 401 Unauthorized
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as4107645c
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         WWW-Authenticate: Digest algorithm=MD5,
>         realm="sip1.comms.kuflink.com
>         <http://sip1.comms.kuflink.com>", nonce="11139d33"
>         Content-Length: 0
>
>
>
>         2020/12/17 10:08:18.624034 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> 10.0.14.118:6000
>         <http://10.0.14.118:6000>
>         ACK sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>
>         SIP/2.0
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as4107645c
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 ACK
>         Content-Length: 0
>
>
>
>         2020/12/17 10:08:18.625557 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> 10.0.14.118:6000
>         <http://10.0.14.118:6000>
>         INVITE sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>         Contact: <sip:7654321 at did.com:5060
>         <http://sip:7654321 at did.com:5060>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         User-Agent: ProxyA
>         CSeq: 103 INVITE
>         User-Agent: proxy
>         Date: Thu, 17 Dec 2020 10:08:18 GMT
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Remote-Party-ID: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
>         Content-Type: application/sdp
>         Content-Length: 885
>         Authorization: Digest username="xxxxx", realm="xxxx",
>         nonce="11139d33", uri="sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>", response="qwewqeqwe",
>         algorithm=MD5
>
>
>
>         2020/12/17 10:08:18.779483 10.0.14.118:6000
>         <http://10.0.14.118:6000> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         SIP/2.0 100 Trying
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 103 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000
>         <http://sip:123456 at 10.0.14.118:6000>>
>         Content-Length: 0
>
>
>
>
>         2020/12/17 10:08:20.937756 10.0.14.118:6000
>         <http://10.0.14.118:6000> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         SIP/2.0 180 Ringing
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 103 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000
>         <http://sip:123456 at 10.0.14.118:6000>>
>         Content-Length: 0
>
>
>
>         2020/12/17 10:08:20.938593 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> proxy-a.com:5060
>         <http://proxy-a.com:5060>
>         SIP/2.0 180 Ringing
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>         Content-Length: 0
>
>
>
>         2020/12/17 10:08:22.075814 10.0.14.118:6000
>         <http://10.0.14.118:6000> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         SIP/2.0 200 OK
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 103 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000
>         <http://sip:123456 at 10.0.14.118:6000>>
>         Content-Type: application/sdp
>         Require: timer
>         Content-Length: 296
>
>
>         2020/12/17 10:08:22.077049 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> proxy-a.com:5060
>         <http://proxy-a.com:5060>
>         SIP/2.0 200 OK
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>         Content-Type: application/sdp
>         Require: timer
>         Content-Length: 316
>
>
>
>         2020/12/17 10:08:22.103365 proxy-a.com:5060
>         <http://proxy-a.com:5060> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         ACK
>         sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>         SIP/2.0
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK2a5fae72;rport=5060
>         Route: <sip:proxy-b.com <http://proxy-b.com>;lr;did=d18.7a9>
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Contact: <sip:7654321 at did.com:5060
>         <http://sip:7654321 at did.com:5060>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 ACK
>         User-Agent: proxy
>         Content-Length: 0
>
>
>
>         2020/12/17 10:08:22.103877 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> 10.0.14.118:6000
>         <http://10.0.14.118:6000>
>         ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1
>         SIP/2.0
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK2a5fae72;rport=5060
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Contact: <sip:7654321 at did.com:5060
>         <http://sip:7654321 at did.com:5060>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 ACK
>         User-Agent: proxy
>         Content-Length: 0
>         P-K-CSeq-Refresh: 103
>
>
>         2020/12/17 10:08:22.575533 10.0.14.118:6000
>         <http://10.0.14.118:6000> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         SIP/2.0 200 OK
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 103 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000
>         <http://sip:123456 at 10.0.14.118:6000>>
>         Content-Type: application/sdp
>         Require: timer
>         Content-Length: 296
>
>
>
>         2020/12/17 10:08:22.576777 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> proxy-a.com:5060
>         <http://proxy-a.com:5060>
>         SIP/2.0 200 OK
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>         Content-Type: application/sdp
>         Require: timer
>         Content-Length: 316
>
>
>
>         2020/12/17 10:08:22.581649 proxy-a.com:5060
>         <http://proxy-a.com:5060> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         ACK
>         sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>         SIP/2.0
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK219933f6;rport=5060
>         Route: <sip:proxy-b.com <http://proxy-b.com>;lr;did=d18.7a9>
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Contact: <sip:7654321 at did.com:5060
>         <http://sip:7654321 at did.com:5060>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 ACK
>         User-Agent: proxy
>         Content-Length: 0
>
>
>
>         2020/12/17 10:08:22.582313 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> 10.0.14.118:6000
>         <http://10.0.14.118:6000>
>         ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1
>         SIP/2.0
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK219933f6;rport=5060
>         Max-Forwards: 70
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Contact: <sip:7654321 at did.com:5060
>         <http://sip:7654321 at did.com:5060>>
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 ACK
>         User-Agent: proxy
>         Content-Length: 0
>         P-K-CSeq-Refresh: 103
>
>
>         2020/12/17 10:08:23.575828 10.0.14.118:6000
>         <http://10.0.14.118:6000> -> 10.0.14.118:5060
>         <http://10.0.14.118:5060>
>         SIP/2.0 200 OK
>         Via: SIP/2.0/UDP
>         proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 103 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000
>         <http://sip:123456 at 10.0.14.118:6000>>
>         Content-Type: application/sdp
>         Require: timer
>         Content-Length: 296
>
>
>         2020/12/17 10:08:23.577863 10.0.14.118:5060
>         <http://10.0.14.118:5060> -> proxy-a.com:5060
>         <http://proxy-a.com:5060>
>         SIP/2.0 200 OK
>         Via: SIP/2.0/UDP
>         proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>         Via: SIP/2.0/UDP did.com:5060;received=did.com
>         <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>         Record-Route: <sip:proxy-b.com
>         <http://proxy-b.com>;lr;did=d18.7a9>
>         Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>         From: "7654321" <sip:7654321 at did.com
>         <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>         To: <sip:123456 at proxy-a.com
>         <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>         Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>         <mailto:67675c7e636d6e773860255316e54779 at did.com>
>         CSeq: 102 INVITE
>         Server: proxy
>         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>         NOTIFY, INFO, PUBLISH, MESSAGE
>         Supported: replaces, timer
>         Session-Expires: 1800;refresher=uas
>         Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>         Content-Type: application/sdp
>         Require: timer
>         Content-Length: 316
>
>
>
>         _______________________________________________
>         Kamailio (SER) - Users Mailing List
>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>         <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/f1f3a2bd/attachment.htm>

From sergio.charrua at voip.pt  Thu Dec 17 15:00:44 2020
From: sergio.charrua at voip.pt (Sergio Charrua)
Date: Thu, 17 Dec 2020 14:00:44 +0000
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CANk_n4b-EPY-ahWQe-HfmTTmpyhhxjmZvGmAA2oR+2qT0vdh2w@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
 <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>
 <CALZWR5xBiGuYv8=VcGXkiKvZ3Yy-_GOcv=udsDkMYeR14N301Q@mail.gmail.com>
 <CANk_n4b-EPY-ahWQe-HfmTTmpyhhxjmZvGmAA2oR+2qT0vdh2w@mail.gmail.com>
Message-ID: <CALZWR5y=S6S3KDkyGHpeDsMaR1NemjpPZ5u6W5NMNRBHOuVUVQ@mail.gmail.com>

Personally I use NATHelper and RTPEngine modules

RTPEngine, afaik, is the latest and upgraded version of RTPProxy (please,
anyone correct me if that is not the case)

*S?rgio Charrua*


*www.voip.pt <http://www.voip.pt/>*
Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77

Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Thu, Dec 17, 2020 at 1:21 PM Mihai Cezar <cezar at mokalife.ro> wrote:

> I do have kamailio an public IP and another nic with private IP that
> connects to the Asterisk LAN.
>
> @Sergey I tried that scenario with double NAT, and, it work it.
>
> If i choose to go rtpproxy which modules should i load (nat_helper,
> nat_traversal, rtpproxy) ?
>
>
>
> On Thu, Dec 17, 2020 at 2:38 PM Sergio Charrua <sergio.charrua at voip.pt>
> wrote:
>
>> Another example of when to use RTPProxy / RTPEngine is:
>>
>> SIP user -> router -> INTERNET -> router / firewall -> Kamailio (private
>> IP) -> Asterisk (private IP)
>>
>> Apart from the routers, all other equipments are private IPs, hence being
>> NATed and requiring RTP Proxy / RTP Engine to forward RTP streams to the
>> correct ports.
>> As David Vilasmil points out, security wise, this is the best
>> approach.... but it is a PITA configuring and making all the services work
>> correctly.
>>
>> *S?rgio Charrua*
>>
>>
>> *www.voip.pt <http://www.voip.pt/>*
>> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>>
>> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>>
>> This message and any files or documents attached are strictly
>> confidential or otherwise legally protected.
>>
>> It is intended only for the individual or entity named. If you are not
>> the named addressee or have received this email in error, please inform the
>> sender immediately, delete it from your system and do not copy or disclose
>> it or its contents or use it for any purpose. Please also note that
>> transmission cannot be guaranteed to be secure or error-free.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Dec 17, 2020 at 12:15 PM Sergey Safarov <s.safarov at gmail.com>
>> wrote:
>>
>>> yes, if your asterisk has statically assigned (NAT-ed) public IP, then
>>> you do not need RTPproxy.
>>> RTP proxy required when both sides of the call do not have
>>> statically assigned (NAT-ed) public IP.
>>>
>>> On Thu, Dec 17, 2020 at 2:33 PM David Villasmil <
>>> david.villasmil.work at gmail.com> wrote:
>>>
>>>> It?s totally fine. Rtpengine is mainly used to also proxy rtp ie:
>>>> public to private, etc. But if your asterisk is public, rtps will reach it,
>>>> and you?re fine with it, go ahead
>>>>
>>>> On Thu, 17 Dec 2020 at 11:10, Mihai Cezar <cezar at mokalife.ro> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Can't figure it out when to use RTPproxy, i am forwarding everything
>>>>> to asterisk in seem to work without RTPproxy.
>>>>>
>>>>> The scenario is like this:
>>>>> Softphone -> INTERNET -> Kamailio - > Asterisk (private ip)
>>>>>
>>>>> Now it seems to work without any rtpproxy but is it ok?
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>> --
>>>> Regards,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.work at gmail.com
>>>> phone: +34669448337
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/3f3b019f/attachment.htm>

From rfuchs at sipwise.com  Thu Dec 17 15:30:24 2020
From: rfuchs at sipwise.com (Richard Fuchs)
Date: Thu, 17 Dec 2020 09:30:24 -0500
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <CALZWR5y=S6S3KDkyGHpeDsMaR1NemjpPZ5u6W5NMNRBHOuVUVQ@mail.gmail.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
 <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>
 <CALZWR5xBiGuYv8=VcGXkiKvZ3Yy-_GOcv=udsDkMYeR14N301Q@mail.gmail.com>
 <CANk_n4b-EPY-ahWQe-HfmTTmpyhhxjmZvGmAA2oR+2qT0vdh2w@mail.gmail.com>
 <CALZWR5y=S6S3KDkyGHpeDsMaR1NemjpPZ5u6W5NMNRBHOuVUVQ@mail.gmail.com>
Message-ID: <12faf4b5-2aad-e1b9-c34d-6ba7ff089231@sipwise.com>

On 17/12/2020 09.00, Sergio Charrua wrote:
> Personally I use NATHelper and RTPEngine modules
>
> RTPEngine, afaik, is the latest and upgraded version of RTPProxy 
> (please, anyone correct me if that is not the case)
>
They serve a similar purpose, but they're unrelated products and 
rtpengine is not based on rtpproxy at all.

Cheers



From sergio.charrua at voip.pt  Thu Dec 17 15:41:31 2020
From: sergio.charrua at voip.pt (Sergio Charrua)
Date: Thu, 17 Dec 2020 14:41:31 +0000
Subject: [SR-Users] Kamailio RTP proxy require?
In-Reply-To: <12faf4b5-2aad-e1b9-c34d-6ba7ff089231@sipwise.com>
References: <CANk_n4bXPoV6oLhvOz__+KaBt_dr8NfnDqNdxbkvRWmdap=ykg@mail.gmail.com>
 <CAFGRPVq2CgxHeqQg=pAw4R7xV_5J8_yaza9264aOMQE1_NP0RQ@mail.gmail.com>
 <CAHtxdDe_FZZv8mGPSj1e59TM2YdxO01M9RkeMxRV+5G8QdQM-A@mail.gmail.com>
 <CALZWR5xBiGuYv8=VcGXkiKvZ3Yy-_GOcv=udsDkMYeR14N301Q@mail.gmail.com>
 <CANk_n4b-EPY-ahWQe-HfmTTmpyhhxjmZvGmAA2oR+2qT0vdh2w@mail.gmail.com>
 <CALZWR5y=S6S3KDkyGHpeDsMaR1NemjpPZ5u6W5NMNRBHOuVUVQ@mail.gmail.com>
 <12faf4b5-2aad-e1b9-c34d-6ba7ff089231@sipwise.com>
Message-ID: <CALZWR5wZRAH34rpxUB7+QhSi4feavfDLAd-J8Q-O1pKtOVw=hg@mail.gmail.com>

Thanks for the details, Richard

*S?rgio Charrua*


*www.voip.pt <http://www.voip.pt/>*
Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77

Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Thu, Dec 17, 2020 at 2:32 PM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 17/12/2020 09.00, Sergio Charrua wrote:
> > Personally I use NATHelper and RTPEngine modules
> >
> > RTPEngine, afaik, is the latest and upgraded version of RTPProxy
> > (please, anyone correct me if that is not the case)
> >
> They serve a similar purpose, but they're unrelated products and
> rtpengine is not based on rtpproxy at all.
>
> Cheers
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201217/21eb789b/attachment.htm>

From moises.ynfante at pushmotion.com  Fri Dec 18 03:38:32 2020
From: moises.ynfante at pushmotion.com (moisesynfante)
Date: Thu, 17 Dec 2020 19:38:32 -0700 (MST)
Subject: [SR-Users] MID-Registrar Example
Message-ID: <1608259112948-0.post@n5.nabble.com>

Hello,

I'm a newbie when it comes to Kamailio and I would like to know if there's a
working example of a Mid-Registrar implementation. I read on other posts
that the UAC module can be used to achieve this but, honestly, I don't
understand how. If any of you could provide some path I could follow I would
be very thankful.



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From abalashov at evaristesys.com  Fri Dec 18 03:40:51 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Thu, 17 Dec 2020 21:40:51 -0500
Subject: [SR-Users] MID-Registrar Example
In-Reply-To: <1608259112948-0.post@n5.nabble.com>
References: <1608259112948-0.post@n5.nabble.com>
Message-ID: <db567cdd-4c66-f2bd-d528-b5d5a1aaf49a@evaristesys.com>

It would probably help if you could state exactly what it is that you 
are trying to achieve. The term "mid-registrar" encompasses a fairly 
large category of conceivable configurations, though all of them have in 
common, I suppose, the quality of not passing through registrations 
upstream in a 1:1 fashion.

On 12/17/20 9:38 PM, moisesynfante wrote:
> Hello,
> 
> I'm a newbie when it comes to Kamailio and I would like to know if there's a
> working example of a Mid-Registrar implementation. I read on other posts
> that the UAC module can be used to achieve this but, honestly, I don't
> understand how. If any of you could provide some path I could follow I would
> be very thankful.
> 
> 
> 
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From terry at fullduplex.co.uk  Fri Dec 18 09:19:00 2020
From: terry at fullduplex.co.uk (Terry Tailor)
Date: Fri, 18 Dec 2020 13:19:00 +0500
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
In-Reply-To: <ce569742-c28c-a3b6-e4bd-0ae2bcb50815@gmail.com>
References: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
 <CAPcKEYMWXvhVnM3YhQS-d-FjCSmRJZ+z4Yc-yyfFSNEPJLFsQA@mail.gmail.com>
 <CAK7XD1tUKkcs1DJf0BEg1DHpA0p5V+Z07yjzOwn6-CwpjQ_RVg@mail.gmail.com>
 <ce569742-c28c-a3b6-e4bd-0ae2bcb50815@gmail.com>
Message-ID: <CAK7XD1vVxhF+=EfN-=mbagop4tF5DzEUkpExr3T7OS0S+0Z-GQ@mail.gmail.com>

 Hi Daniel,
I have tested CANCEL and ACK cases with nighty Release it is working fine.
Thank you

Regards
Terry

On Thu, Dec 17, 2020 at 6:59 PM Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Hello,
>
> can you try with latest git branch 5.4? I just pushed a commit to handle
> this case.
>
> You have to compile from sources, like:
>
>   * https://kamailio.org/docs/tutorials/5.4.x/kamailio-install-guide-git/
>
> Debian packages from branch 5.4 are also built over night:
>
>   * http://deb.kamailio.org/#dev54
>
> Cheers,
> Daniel
> On 17.12.20 13:05, Terry Tailor wrote:
>
> Hi, I have updated Kamailio to 5.4 still there is an issue with Cseq of
> cancel in case of cancel it is not increasing cSeq
> here are details
> 1. proxy a sends invite with CSeq: 102 INVITE and proxy b route it to
> asterisk with CSeq: 102 INVITE
> 2. asterisk sends 401 Unauthorized with CSeq: 102 INVITE and proxy b sends
> ACK with CSeq: 102 ACK
> 3. proxy b sends invite with CSeq: 103 INVITE and asterisk sends 100
> Trying and 180 Ringing with CSeq: 103 INVITE
> 4. proxy b relay to proxy a 180 Ringing with CSeq: 102 INVITE
> 5. proxy a send CANCEL with CSeq: 102 CANCEL and proxy b sends CANCEL with
> CSeq: 102 CANCEL to asterisk
> 6. Now asterisk is sending 481 Call leg/transaction does not exist
>
> uname -a: Linux example.com 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6
> 10:54:43 UTC 2020 x86_64 GNU/Linux
> kamailio -v: version: kamailio 5.4.3 (x86_64/linux)
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
> BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled with gcc 6.3.0
>
>
> sip logs:
>
>
> 2020/12/17 11:42:32.289934 proxy-a.com:5060 -> 10.0.14.118:5060
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:54321 at did.com:5060>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> User-Agent: VB-Proxy
> CSeq: 102 INVITE
> User-Agent: did
> Date: Thu, 17 Dec 2020 11:42:32 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "54321" <sip:54321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 889
>
> 2020/12/17 11:42:32.290569 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 100 trying -- your call is important to us
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 INVITE
> Server: kamailio (5.4.3 (x86_64/linux))
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:32.291036 10.0.14.118:5060 -> 10.0.14.118:6000
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:54321 at did.com:5060>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> User-Agent: VB-Proxy
> CSeq: 102 INVITE
> User-Agent: did
> Date: Thu, 17 Dec 2020 11:42:32 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "54321" <sip:54321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 889
>
>
>
> 2020/12/17 11:42:32.308279 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as152bd976
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com",
> nonce="3673a540"
> Content-Length: 0
>
>
> 2020/12/17 11:42:32.308770 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as152bd976
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 ACK
> Content-Length: 0
>
>
> 2020/12/17 11:42:32.309610 10.0.14.118:5060 -> 10.0.14.118:6000
> INVITE sip:123456 at proxy-a.com SIP/2.0
> Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com;lr>
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Contact: <sip:54321 at did.com:5060>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> User-Agent: VB-Proxy
> CSeq: 103 INVITE
> User-Agent: did
> Date: Thu, 17 Dec 2020 11:42:32 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Remote-Party-ID: "54321" <sip:54321 at did.com
> >;party=calling;privacy=off;screen=no
> Content-Type: application/sdp
> Content-Length: 889
> Authorization: Digest username="did095499", realm="sip1.comms.kuflink.com",
> nonce="3673a540", uri="sip:123456 at proxy-a.com",
> response="24d8949f18f4f2650913ce3feaa78380", algorithm=MD5
>
>
>
>
> 2020/12/17 11:42:32.333610 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com;lr>
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:34.276380 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com;lr>
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Length: 0
>
>
> 2020/12/17 11:42:34.277337 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com;lr>
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:38.113181 proxy-a.com:5060 -> 10.0.14.118:5060
> CANCEL sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 CANCEL
> Content-Length: 0
>
>
> 2020/12/17 11:42:38.113918 10.0.14.118:5060 -> 10.0.14.118:6000
> CANCEL sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 CANCEL
> Content-Length: 0
> P-K-CSeq-Auth: 103
>
>
>
> 2020/12/17 11:42:38.114114 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 200 canceling
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=a74459175e9494c7e23ffeb306461015-0f770312
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 CANCEL
> Server: kamailio (5.4.3 (x86_64/linux))
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:38.116456 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 481 Call leg/transaction does not exist
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as24deed39
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 CANCEL
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:54.554350 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 183 Session Progress
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> Record-Route: <sip:sip.comms.kuflink.com;lr;did=baf.7bf1>
> Record-Route: <sip:proxy-a.com;lr>
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:123456 at 10.0.14.118:6000>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 292
>
>
>
> 2020/12/17 11:42:54.554978 10.0.14.118:5060 -> 10.0.14.118:6000
> CANCEL sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 CANCEL
> Content-Length: 0
> P-K-CSeq-Auth: 103
>
>
>
> 2020/12/17 11:42:54.557082 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 481 Call leg/transaction does not exist
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as5eee0295
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 CANCEL
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.617825 10.0.14.118:6000 -> 10.0.14.118:5060
> SIP/2.0 603 Declined
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 103 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.618423 10.0.14.118:5060 -> 10.0.14.118:6000
> ACK sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP sip.comms.kuflink.com:5060
> ;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 103 ACK
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.618944 10.0.14.118:5060 -> proxy-a.com:5060
> SIP/2.0 603 Declined
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Via: SIP/2.0/UDP did.com:5060;received=did.com
> ;branch=z9hG4bK3756a567;rport=5060
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 INVITE
> Server: did
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Content-Length: 0
>
>
>
> 2020/12/17 11:42:59.620074 proxy-a.com:5060 -> 10.0.14.118:5060
> ACK sip:123456 at proxy-a.com SIP/2.0
> Via: SIP/2.0/UDP proxy-a.com:5060
> ;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
> Max-Forwards: 70
> From: "54321" <sip:54321 at did.com>;tag=as02b3f892
> To: <sip:123456 at proxy-a.com>;tag=as12b14194
> Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
> CSeq: 102 ACK
> Content-Length: 0
>
> On Thu, Dec 17, 2020 at 4:52 PM George Diamantopoulos <
> georgediam at gmail.com> wrote:
>
>> Not sure if this is related, but I've also run into issues with
>> track_cseq_updates:
>> https://www.mail-archive.com/sr-users at lists.kamailio.org/msg12362.html
>>
>> More specifically, kamailio won't process the 100 Trying to an
>> Cseq-bumped INVITE it generated
>> itself with uac_auth() when track_cseq_updates is on.
>>
>> This implementation appears to be a little too fragile for the time
>> being....
>>
>> BR,
>> George
>>
>> On Thu, 17 Dec 2020 at 12:29, Terry Tailor <terry at fullduplex.co.uk>
>> wrote:
>>
>>> Hi, Here is setup details
>>> Kamailio Proxy a <-----> Kamailio Proxy b  <-----> Asterisk
>>> Kamailio proxy b auth based on IP Kamailio Proxy a
>>> 1. Kamailio proxy sends an Invite request to Kamailio proxy b with CSeq:
>>> 102 INVITE
>>> 2. Kamailio proxy b check again IP auth and sends invite request to
>>> asterisk with CSeq: 102 INVITE
>>> 4 asterisk response with 401 Unauthorized with  CSeq: 102
>>> 5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
>>> 6. Kamailio proxy b sends INVITE request with CSeq: 103 INVITE
>>> 7. Asterisk sends 100 trying and 180 ringing with CSeq: 103 INVITE
>>> 8. Kamailio proxy b relay 180 ringing with  CSeq: 102 INVITE
>>> 9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b relay it to
>>> proxy a with CSeq: 102 INVITE
>>> 10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy b relay ACK to
>>> asterisk with CSeq: 102 ACK
>>>
>>> Now asterisk is retransmitting 200 ok with CSeq: 103 INVITE and proxy a
>>> is sending ACK with Cseq: 102 ACK
>>>
>>> Same happing in case of 487 Request Terminated
>>>
>>> Here is my config
>>>
>>> modparam("dialog", "default_timeout", 10800) # 3h
>>> modparam("dialog", "dlg_match_mode", 1)
>>> modparam("dialog", "db_mode", 0)
>>> modparam("dialog", "send_bye", 1)
>>> modparam("dialog", "track_cseq_updates", 1)
>>> modparam("uac","auth_username_avp","$avp(auser)")
>>> modparam("uac","auth_password_avp","$avp(apass)")
>>> modparam("uac","auth_realm_avp","$avp(arealm)")
>>>
>>> modparam("tm", "failure_reply_mode", 3)
>>> # default retransmission timeout: 3 sec
>>> modparam("tm", "fr_timer", 2000)
>>> modparam("tm", "retr_timer1", 250)
>>> modparam("tm", "retr_timer2", 500)
>>> # default invite retransmission timeout after 1xx: 60 sec
>>> modparam("tm", "fr_inv_timer", 60000)
>>> modparam("tm", "reparse_on_dns_failover", 0)
>>>
>>>
>>>
>>> if (is_method("INVITE") && !has_totag()) {
>>>         dlg_setflag(FLD_RTPPROXY);
>>>         dlg_manage();
>>>     }
>>>     route(RELAY);
>>>
>>>
>>>
>>>
>>> route[RELAY] {
>>>
>>>     # At this point all checks are passed
>>>     t_on_branch("MANAGE_BRANCH");
>>>     t_on_reply("MANAGE_REPLY");
>>>     t_on_failure("MANAGE_FAILURE");
>>>     if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
>>>      #$fd = "sip.comms.kuflink.com";
>>>       t_on_failure("RELAY_AUTH");
>>>     }
>>>
>>>     if (!t_relay()) {
>>>         send_reply("500", "Cannot relay to $du/$ru");
>>>     }
>>>     exit;
>>> }
>>>
>>> failure_route[RELAY_AUTH] {
>>>     t_on_branch("MANAGE_BRANCH");
>>>     t_on_reply("MANAGE_REPLY");
>>>     if (t_is_canceled()) {
>>>         exit;
>>>     }
>>>     if(t_check_status("401|407")) {
>>>         #$fd = "sip.comms.kuflink.com";
>>>         $avp(auser) = "DID_UA_USERNAME";
>>>         $avp(apass) = "DID_UA_PASSWORD";
>>>         if (uac_auth()) {
>>>             t_relay();
>>>         }
>>>         exit;
>>>     }
>>> }
>>>
>>>
>>> route[WITHINDLG] {
>>>     if (!has_totag()) {
>>>         return;
>>>     }
>>>
>>>     if (is_method("BYE")) {
>>>         rtpengine_delete();
>>>     }
>>>
>>>     # sequential request withing a dialog should
>>>     # take the path determined by record-routing
>>>     if (loose_route()) {
>>>         route(DLGURI);
>>>         if (is_method("ACK")) {
>>>             # ACK is forwarded statelessly
>>>             route(NATMANAGE);
>>>         } else if (is_method("NOTIFY")) {
>>>             # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
>>>             record_route();
>>>         }
>>>         route(RELAY);
>>>         exit;
>>>     }
>>>
>>>     if (is_method("SUBSCRIBE") && uri == myself) {
>>>         # in-dialog subscribe requests
>>>         route(PRESENCE);
>>>         exit;
>>>     }
>>>     if (is_method("ACK") ) {
>>>         if (t_check_trans()) {
>>>             # no loose-route, but stateful ACK;
>>>             # must be an ACK after a 487
>>>             # or e.g. 404 from upstream server
>>>             route(RELAY);
>>>             exit;
>>>         } else {
>>>             # ACK without matching transaction ... ignore and discard
>>>             exit;
>>>         }
>>>     }
>>>     send_reply("404","Not here");
>>>     exit;
>>> }
>>>
>>>
>>> kamailio -v
>>> version: kamailio 5.3.7 (x86_64/linux)
>>> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
>>> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
>>> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
>>> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
>>> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
>>> 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>> id: unknown
>>> compiled with gcc 6.3.0
>>>
>>>
>>> uname -a
>>> Linux example.com 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43
>>> UTC 2020 x86_64 GNU/Linux
>>>
>>>
>>>
>>> SIP logs
>>> 2020/12/17 10:08:18.483907 proxy-a.com:5060 -> 10.0.14.118:5060
>>> INVITE sip:123456 at proxy-a.com SIP/2.0
>>> Record-Route: <sip:proxy-a.com;lr>
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>
>>> Contact: <sip:7654321 at did.com:5060>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> User-Agent: ProxyA
>>> CSeq: 102 INVITE
>>> User-Agent: proxy
>>> Date: Thu, 17 Dec 2020 10:08:18 GMT
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Remote-Party-ID: "7654321" <sip:7654321 at did.com
>>> >;party=calling;privacy=off;screen=no
>>> Content-Type: application/sdp
>>> Content-Length: 885
>>>
>>>
>>>
>>> 2020/12/17 10:08:18.485063 10.0.14.118:5060 -> proxy-a.com:5060
>>> SIP/2.0 100 trying -- your call is important to us
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 INVITE
>>> Server: kamailio (5.3.7 (x86_64/linux))
>>> Content-Length: 0
>>>
>>>
>>> 2020/12/17 10:08:18.485576 10.0.14.118:5060 -> 10.0.14.118:6000
>>> INVITE sip:123456 at proxy-a.com SIP/2.0
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>
>>> Contact: <sip:7654321 at did.com:5060>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> User-Agent: ProxyA
>>> CSeq: 102 INVITE
>>> User-Agent: proxy
>>> Date: Thu, 17 Dec 2020 10:08:18 GMT
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Remote-Party-ID: "7654321" <sip:7654321 at did.com
>>> >;party=calling;privacy=off;screen=no
>>> Content-Type: application/sdp
>>> Content-Length: 885
>>>
>>>
>>>
>>> 2020/12/17 10:08:18.622867 10.0.14.118:6000 -> 10.0.14.118:5060
>>> SIP/2.0 401 Unauthorized
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as4107645c
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> WWW-Authenticate: Digest algorithm=MD5, realm="sip1.comms.kuflink.com",
>>> nonce="11139d33"
>>> Content-Length: 0
>>>
>>>
>>>
>>> 2020/12/17 10:08:18.624034 10.0.14.118:5060 -> 10.0.14.118:6000
>>> ACK sip:123456 at proxy-a.com SIP/2.0
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as4107645c
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 ACK
>>> Content-Length: 0
>>>
>>>
>>>
>>> 2020/12/17 10:08:18.625557 10.0.14.118:5060 -> 10.0.14.118:6000
>>> INVITE sip:123456 at proxy-a.com SIP/2.0
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>
>>> Contact: <sip:7654321 at did.com:5060>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> User-Agent: ProxyA
>>> CSeq: 103 INVITE
>>> User-Agent: proxy
>>> Date: Thu, 17 Dec 2020 10:08:18 GMT
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Remote-Party-ID: "7654321" <sip:7654321 at did.com
>>> >;party=calling;privacy=off;screen=no
>>> Content-Type: application/sdp
>>> Content-Length: 885
>>> Authorization: Digest username="xxxxx", realm="xxxx", nonce="11139d33",
>>> uri="sip:123456 at proxy-a.com", response="qwewqeqwe", algorithm=MD5
>>>
>>>
>>>
>>> 2020/12/17 10:08:18.779483 10.0.14.118:6000 -> 10.0.14.118:5060
>>> SIP/2.0 100 Trying
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 103 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000>
>>> Content-Length: 0
>>>
>>>
>>>
>>>
>>> 2020/12/17 10:08:20.937756 10.0.14.118:6000 -> 10.0.14.118:5060
>>> SIP/2.0 180 Ringing
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 103 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000>
>>> Content-Length: 0
>>>
>>>
>>>
>>> 2020/12/17 10:08:20.938593 10.0.14.118:5060 -> proxy-a.com:5060
>>> SIP/2.0 180 Ringing
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>> Content-Length: 0
>>>
>>>
>>>
>>> 2020/12/17 10:08:22.075814 10.0.14.118:6000 -> 10.0.14.118:5060
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 103 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000>
>>> Content-Type: application/sdp
>>> Require: timer
>>> Content-Length: 296
>>>
>>>
>>> 2020/12/17 10:08:22.077049 10.0.14.118:5060 -> proxy-a.com:5060
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>> Content-Type: application/sdp
>>> Require: timer
>>> Content-Length: 316
>>>
>>>
>>>
>>> 2020/12/17 10:08:22.103365 proxy-a.com:5060 -> 10.0.14.118:5060
>>> ACK
>>> sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>>> SIP/2.0
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK2a5fae72;rport=5060
>>> Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Contact: <sip:7654321 at did.com:5060>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 ACK
>>> User-Agent: proxy
>>> Content-Length: 0
>>>
>>>
>>>
>>> 2020/12/17 10:08:22.103877 10.0.14.118:5060 -> 10.0.14.118:6000
>>> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK2a5fae72;rport=5060
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Contact: <sip:7654321 at did.com:5060>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 ACK
>>> User-Agent: proxy
>>> Content-Length: 0
>>> P-K-CSeq-Refresh: 103
>>>
>>>
>>> 2020/12/17 10:08:22.575533 10.0.14.118:6000 -> 10.0.14.118:5060
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 103 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000>
>>> Content-Type: application/sdp
>>> Require: timer
>>> Content-Length: 296
>>>
>>>
>>>
>>> 2020/12/17 10:08:22.576777 10.0.14.118:5060 -> proxy-a.com:5060
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>> Content-Type: application/sdp
>>> Require: timer
>>> Content-Length: 316
>>>
>>>
>>>
>>> 2020/12/17 10:08:22.581649 proxy-a.com:5060 -> 10.0.14.118:5060
>>> ACK
>>> sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>>> SIP/2.0
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK219933f6;rport=5060
>>> Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Contact: <sip:7654321 at did.com:5060>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 ACK
>>> User-Agent: proxy
>>> Content-Length: 0
>>>
>>>
>>>
>>> 2020/12/17 10:08:22.582313 10.0.14.118:5060 -> 10.0.14.118:6000
>>> ACK sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1 SIP/2.0
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK219933f6;rport=5060
>>> Max-Forwards: 70
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Contact: <sip:7654321 at did.com:5060>
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 ACK
>>> User-Agent: proxy
>>> Content-Length: 0
>>> P-K-CSeq-Refresh: 103
>>>
>>>
>>> 2020/12/17 10:08:23.575828 10.0.14.118:6000 -> 10.0.14.118:5060
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP proxy-b.com:5060
>>> ;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 103 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000>
>>> Content-Type: application/sdp
>>> Require: timer
>>> Content-Length: 296
>>>
>>>
>>> 2020/12/17 10:08:23.577863 10.0.14.118:5060 -> proxy-a.com:5060
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP proxy-a.com:5060
>>> ;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>> Via: SIP/2.0/UDP did.com:5060;received=did.com
>>> ;branch=z9hG4bK45f94ed9;rport=5060
>>> Record-Route: <sip:proxy-b.com;lr;did=d18.7a9>
>>> Record-Route: <sip:proxy-a.com;lr>
>>> From: "7654321" <sip:7654321 at did.com>;tag=as55c522e1
>>> To: <sip:123456 at proxy-a.com>;tag=as147bfa3e
>>> Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>> CSeq: 102 INVITE
>>> Server: proxy
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE
>>> Supported: replaces, timer
>>> Session-Expires: 1800;refresher=uas
>>> Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>> Content-Type: application/sdp
>>> Require: timer
>>> Content-Length: 316
>>>
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201218/cd80592f/attachment.htm>

From miconda at gmail.com  Fri Dec 18 09:29:10 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Fri, 18 Dec 2020 09:29:10 +0100
Subject: [SR-Users] Kamailio not updating CSeq after uac_auth() for ACK
In-Reply-To: <CAK7XD1vVxhF+=EfN-=mbagop4tF5DzEUkpExr3T7OS0S+0Z-GQ@mail.gmail.com>
References: <CAK7XD1s6Mftgy1dX5sYJ2CGvkh=Cq1_QwV8v9GqumzgvuKbaGg@mail.gmail.com>
 <CAPcKEYMWXvhVnM3YhQS-d-FjCSmRJZ+z4Yc-yyfFSNEPJLFsQA@mail.gmail.com>
 <CAK7XD1tUKkcs1DJf0BEg1DHpA0p5V+Z07yjzOwn6-CwpjQ_RVg@mail.gmail.com>
 <ce569742-c28c-a3b6-e4bd-0ae2bcb50815@gmail.com>
 <CAK7XD1vVxhF+=EfN-=mbagop4tF5DzEUkpExr3T7OS0S+0Z-GQ@mail.gmail.com>
Message-ID: <41950c6c-0bf0-74f0-e1a9-ae93f55d46ce@gmail.com>

Hello,

ok, thanks for testing and feedback.

Cheers,
Daniel

On 18.12.20 09:19, Terry Tailor wrote:
> Hi Daniel,
> I have tested CANCEL and ACK cases with nighty Release it is working
> fine. Thank you
>
> Regards
> Terry
>
> On Thu, Dec 17, 2020 at 6:59 PM Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     can you try with latest git branch 5.4? I just pushed a commit to
>     handle this case.
>
>     You have to compile from sources, like:
>
>     ? *
>     https://kamailio.org/docs/tutorials/5.4.x/kamailio-install-guide-git/
>     <https://kamailio.org/docs/tutorials/5.4.x/kamailio-install-guide-git/>
>
>     Debian packages from branch 5.4 are also built over night:
>
>     ? * http://deb.kamailio.org/#dev54 <http://deb.kamailio.org/#dev54>
>
>     Cheers,
>     Daniel
>
>     On 17.12.20 13:05, Terry Tailor wrote:
>>     Hi, I have updated Kamailio to 5.4 still there is an issue with
>>     Cseq of cancel in case of cancel it is not increasing cSeq
>>     here are details
>>     1. proxy a sends invite with CSeq: 102 INVITE and proxy b route
>>     it to asterisk with CSeq: 102 INVITE
>>     2. asterisk sends 401 Unauthorized with CSeq: 102 INVITE and
>>     proxy b sends ACK with CSeq: 102 ACK
>>     3. proxy b sends invite with CSeq: 103 INVITE and asterisk sends
>>     100 Trying and 180 Ringing with CSeq: 103 INVITE
>>     4. proxy b relay to proxy a 180 Ringing with CSeq: 102 INVITE
>>     5. proxy a send CANCEL with CSeq: 102 CANCEL and proxy b sends
>>     CANCEL with CSeq: 102 CANCEL to asterisk
>>     6. Now asterisk is sending 481 Call leg/transaction does not exist
>>
>>     uname -a: Linux example.com <http://example.com>
>>     4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020
>>     x86_64 GNU/Linux
>>     kamailio -v: version: kamailio 5.4.3 (x86_64/linux)
>>     flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>>     DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC,
>>     Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
>>     FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER,
>>     USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES,
>>     TLS_PTHREAD_MUTEX_SHARED
>>     ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144,
>>     MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>>     poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>     id: unknown
>>     compiled with gcc 6.3.0
>>
>>
>>     sip logs:
>>
>>
>>     2020/12/17 11:42:32.289934 proxy-a.com:5060
>>     <http://proxy-a.com:5060> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     INVITE sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>
>>     SIP/2.0
>>     Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Contact: <sip:54321 at did.com:5060 <http://sip:54321 at did.com:5060>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     User-Agent: VB-Proxy
>>     CSeq: 102 INVITE
>>     User-Agent: did
>>     Date: Thu, 17 Dec 2020 11:42:32 GMT
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Remote-Party-ID: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;party=calling;privacy=off;screen=no
>>     Content-Type: application/sdp
>>     Content-Length: 889
>>
>>     2020/12/17 11:42:32.290569 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> proxy-a.com:5060
>>     <http://proxy-a.com:5060>
>>     SIP/2.0 100 trying -- your call is important to us
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 INVITE
>>     Server: kamailio (5.4.3 (x86_64/linux))
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:32.291036 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>     <http://10.0.14.118:6000>
>>     INVITE sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>
>>     SIP/2.0
>>     Record-Route: <sip:sip.comms.kuflink.com
>>     <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
>>     Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Contact: <sip:54321 at did.com:5060 <http://sip:54321 at did.com:5060>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     User-Agent: VB-Proxy
>>     CSeq: 102 INVITE
>>     User-Agent: did
>>     Date: Thu, 17 Dec 2020 11:42:32 GMT
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Remote-Party-ID: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;party=calling;privacy=off;screen=no
>>     Content-Type: application/sdp
>>     Content-Length: 889
>>
>>
>>
>>     2020/12/17 11:42:32.308279 10.0.14.118:6000
>>     <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     SIP/2.0 401 Unauthorized
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0;received=10.0.14.118;rport=5060
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as152bd976
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 INVITE
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     WWW-Authenticate: Digest algorithm=MD5,
>>     realm="sip1.comms.kuflink.com <http://sip1.comms.kuflink.com>",
>>     nonce="3673a540"
>>     Content-Length: 0
>>
>>
>>     2020/12/17 11:42:32.308770 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>     <http://10.0.14.118:6000>
>>     ACK sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.0
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as152bd976
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 ACK
>>     Content-Length: 0
>>
>>
>>     2020/12/17 11:42:32.309610 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>     <http://10.0.14.118:6000>
>>     INVITE sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>
>>     SIP/2.0
>>     Record-Route: <sip:sip.comms.kuflink.com
>>     <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
>>     Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Contact: <sip:54321 at did.com:5060 <http://sip:54321 at did.com:5060>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     User-Agent: VB-Proxy
>>     CSeq: 103 INVITE
>>     User-Agent: did
>>     Date: Thu, 17 Dec 2020 11:42:32 GMT
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Remote-Party-ID: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;party=calling;privacy=off;screen=no
>>     Content-Type: application/sdp
>>     Content-Length: 889
>>     Authorization: Digest username="did095499",
>>     realm="sip1.comms.kuflink.com <http://sip1.comms.kuflink.com>",
>>     nonce="3673a540", uri="sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>",
>>     response="24d8949f18f4f2650913ce3feaa78380", algorithm=MD5
>>
>>
>>
>>
>>     2020/12/17 11:42:32.333610 10.0.14.118:6000
>>     <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     SIP/2.0 100 Trying
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     Record-Route: <sip:sip.comms.kuflink.com
>>     <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
>>     Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 103 INVITE
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Session-Expires: 1800;refresher=uas
>>     Contact: <sip:123456 at 10.0.14.118:6000
>>     <http://sip:123456 at 10.0.14.118:6000>>
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:34.276380 10.0.14.118:6000
>>     <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     SIP/2.0 180 Ringing
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     Record-Route: <sip:sip.comms.kuflink.com
>>     <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
>>     Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 103 INVITE
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Session-Expires: 1800;refresher=uas
>>     Contact: <sip:123456 at 10.0.14.118:6000
>>     <http://sip:123456 at 10.0.14.118:6000>>
>>     Content-Length: 0
>>
>>
>>     2020/12/17 11:42:34.277337 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> proxy-a.com:5060
>>     <http://proxy-a.com:5060>
>>     SIP/2.0 180 Ringing
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     Record-Route: <sip:sip.comms.kuflink.com
>>     <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
>>     Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 INVITE
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Session-Expires: 1800;refresher=uas
>>     Contact: <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:38.113181 proxy-a.com:5060
>>     <http://proxy-a.com:5060> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     CANCEL sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>
>>     SIP/2.0
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 CANCEL
>>     Content-Length: 0
>>
>>
>>     2020/12/17 11:42:38.113918 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>     <http://10.0.14.118:6000>
>>     CANCEL sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>
>>     SIP/2.0
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 CANCEL
>>     Content-Length: 0
>>     P-K-CSeq-Auth: 103
>>
>>
>>
>>     2020/12/17 11:42:38.114114 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> proxy-a.com:5060
>>     <http://proxy-a.com:5060>
>>     SIP/2.0 200 canceling
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1;rport=5060
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=a74459175e9494c7e23ffeb306461015-0f770312
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 CANCEL
>>     Server: kamailio (5.4.3 (x86_64/linux))
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:38.116456 10.0.14.118:6000
>>     <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     SIP/2.0 481 Call leg/transaction does not exist
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as24deed39
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 CANCEL
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:54.554350 10.0.14.118:6000
>>     <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     SIP/2.0 183 Session Progress
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     Record-Route: <sip:sip.comms.kuflink.com
>>     <http://sip.comms.kuflink.com>;lr;did=baf.7bf1>
>>     Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 103 INVITE
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Session-Expires: 1800;refresher=uas
>>     Contact: <sip:123456 at 10.0.14.118:6000
>>     <http://sip:123456 at 10.0.14.118:6000>>
>>     Content-Type: application/sdp
>>     Require: timer
>>     Content-Length: 292
>>
>>
>>
>>     2020/12/17 11:42:54.554978 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>     <http://10.0.14.118:6000>
>>     CANCEL sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>
>>     SIP/2.0
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com>>
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 CANCEL
>>     Content-Length: 0
>>     P-K-CSeq-Auth: 103
>>
>>
>>
>>     2020/12/17 11:42:54.557082 10.0.14.118:6000
>>     <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     SIP/2.0 481 Call leg/transaction does not exist
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1;received=10.0.14.118;rport=5060
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as5eee0295
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 CANCEL
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:59.617825 10.0.14.118:6000
>>     <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     SIP/2.0 603 Declined
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102;received=10.0.14.118;rport=5060
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 103 INVITE
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Session-Expires: 1800;refresher=uas
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:59.618423 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>     <http://10.0.14.118:6000>
>>     ACK sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>>     Via: SIP/2.0/UDP
>>     sip.comms.kuflink.com:5060;branch=z9hG4bKb7e1.bbcb7aefd10825105e2fce86fd82efe6.1.cs102
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 103 ACK
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:59.618944 10.0.14.118:5060
>>     <http://10.0.14.118:5060> -> proxy-a.com:5060
>>     <http://proxy-a.com:5060>
>>     SIP/2.0 603 Declined
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;rport=5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Via: SIP/2.0/UDP did.com:5060;received=did.com
>>     <http://did.com>;branch=z9hG4bK3756a567;rport=5060
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 INVITE
>>     Server: did
>>     Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>>     NOTIFY, INFO, PUBLISH, MESSAGE
>>     Supported: replaces, timer
>>     Session-Expires: 1800;refresher=uas
>>     Content-Length: 0
>>
>>
>>
>>     2020/12/17 11:42:59.620074 proxy-a.com:5060
>>     <http://proxy-a.com:5060> -> 10.0.14.118:5060
>>     <http://10.0.14.118:5060>
>>     ACK sip:123456 at proxy-a.com <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>>     Via: SIP/2.0/UDP
>>     proxy-a.com:5060;branch=z9hG4bKb7e1.f58c5fbd664fa63cd69162afcb07f88a.1
>>     Max-Forwards: 70
>>     From: "54321" <sip:54321 at did.com
>>     <mailto:sip%3A54321 at did.com>>;tag=as02b3f892
>>     To: <sip:123456 at proxy-a.com
>>     <mailto:sip%3A123456 at proxy-a.com>>;tag=as12b14194
>>     Call-ID: 6a981008384dd72c23ee9e59690eb5eb at did.com
>>     <mailto:6a981008384dd72c23ee9e59690eb5eb at did.com>
>>     CSeq: 102 ACK
>>     Content-Length: 0
>>
>>     On Thu, Dec 17, 2020 at 4:52 PM George Diamantopoulos
>>     <georgediam at gmail.com <mailto:georgediam at gmail.com>> wrote:
>>
>>         Not sure if this is related, but I've also run into issues
>>         with track_cseq_updates:
>>         https://www.mail-archive.com/sr-users at lists.kamailio.org/msg12362.html
>>         <https://www.mail-archive.com/sr-users at lists.kamailio.org/msg12362.html>
>>
>>         More specifically, kamailio won't process the 100 Trying to
>>         an Cseq-bumped INVITE it generated
>>         itself with uac_auth() when track_cseq_updates is on.
>>
>>         This implementation appears to be a little too fragile for
>>         the time being....
>>
>>         BR,
>>         George
>>
>>         On Thu, 17 Dec 2020 at 12:29, Terry Tailor
>>         <terry at fullduplex.co.uk <mailto:terry at fullduplex.co.uk>> wrote:
>>
>>             Hi, Here is setup details
>>             Kamailio Proxy a <-----> Kamailio Proxy b? <-----> Asterisk
>>             Kamailio proxy b auth based on IP Kamailio Proxy a
>>             1. Kamailio proxy sends an Invite request to Kamailio
>>             proxy b with CSeq: 102 INVITE
>>             2. Kamailio proxy b check again IP auth and sends invite
>>             request to asterisk with CSeq: 102 INVITE
>>             4 asterisk response with 401 Unauthorized with? CSeq: 102
>>             5. Kamailio proxy b sends ACK request with CSeq: 102 ACK
>>             6. Kamailio proxy b sends INVITE request with CSeq: 103
>>             INVITE
>>             7. Asterisk sends 100 trying and 180 ringing with CSeq:
>>             103 INVITE
>>             8. Kamailio proxy b relay 180 ringing with? CSeq: 102 INVITE
>>             9. Asterisk send 200 Ok with CSeq: 103 INVITE and proxy b
>>             relay it to proxy a with CSeq: 102 INVITE
>>             10. Now Proxy a send an ACK with CSeq: 102 ACK and proxy
>>             b relay ACK to asterisk with CSeq: 102 ACK
>>
>>             Now asterisk is retransmitting 200 ok with CSeq: 103
>>             INVITE and proxy a is sending ACK with Cseq: 102 ACK
>>
>>             Same happing in case of 487 Request Terminated
>>
>>             Here is my config
>>
>>             modparam("dialog", "default_timeout", 10800) # 3h
>>             modparam("dialog", "dlg_match_mode", 1)
>>             modparam("dialog", "db_mode", 0)
>>             modparam("dialog", "send_bye", 1)
>>             modparam("dialog", "track_cseq_updates", 1)
>>             modparam("uac","auth_username_avp","$avp(auser)")
>>             modparam("uac","auth_password_avp","$avp(apass)")
>>             modparam("uac","auth_realm_avp","$avp(arealm)")
>>
>>             modparam("tm", "failure_reply_mode", 3)
>>             # default retransmission timeout: 3 sec
>>             modparam("tm", "fr_timer", 2000)
>>             modparam("tm", "retr_timer1", 250)
>>             modparam("tm", "retr_timer2", 500)
>>             # default invite retransmission timeout after 1xx: 60 sec
>>             modparam("tm", "fr_inv_timer", 60000)
>>             modparam("tm", "reparse_on_dns_failover", 0)
>>
>>
>>
>>             if (is_method("INVITE") && !has_totag()) {
>>             ? ? ? ? dlg_setflag(FLD_RTPPROXY);
>>             ? ? ? ? dlg_manage();
>>             ? ? }
>>             ? ? route(RELAY);
>>
>>
>>
>>
>>             route[RELAY] {
>>
>>             ? ? # At this point all checks are passed
>>             ? ? t_on_branch("MANAGE_BRANCH");
>>             ? ? t_on_reply("MANAGE_REPLY");
>>             ? ? t_on_failure("MANAGE_FAILURE");
>>             ? ? if(is_method("INVITE") && isflagset(FLT_FROMDID)) {
>>             ? ? ?#$fd = "sip.comms.kuflink.com
>>             <http://sip.comms.kuflink.com>";
>>             ? ? ? t_on_failure("RELAY_AUTH");
>>             ? ? }
>>
>>             ? ? if (!t_relay()) {
>>             ? ? ? ? send_reply("500", "Cannot relay to $du/$ru");
>>             ? ? }
>>             ? ? exit;
>>             }
>>
>>             failure_route[RELAY_AUTH] {
>>             ? ? t_on_branch("MANAGE_BRANCH");
>>             ? ? t_on_reply("MANAGE_REPLY");
>>             ? ? if (t_is_canceled()) {
>>             ? ? ? ? exit;
>>             ? ? }
>>             ? ? if(t_check_status("401|407")) {
>>             ? ? ? ? #$fd = "sip.comms.kuflink.com
>>             <http://sip.comms.kuflink.com>";
>>             ? ? ? ? $avp(auser) = "DID_UA_USERNAME";
>>             ? ? ? ? $avp(apass) = "DID_UA_PASSWORD";
>>             ? ? ? ? if (uac_auth()) {
>>             ? ? ? ? ? ? t_relay();
>>             ? ? ? ? }
>>             ? ? ? ? exit;
>>             ? ? }
>>             }
>>
>>
>>             route[WITHINDLG] {
>>             ? ? if (!has_totag()) {
>>             ? ? ? ? return;
>>             ? ? }
>>
>>             ? ? if (is_method("BYE")) {
>>             ? ? ? ? rtpengine_delete();
>>             ? ? }
>>
>>             ? ? # sequential request withing a dialog should
>>             ? ? # take the path determined by record-routing
>>             ? ? if (loose_route()) {
>>             ? ? ? ? route(DLGURI);
>>             ? ? ? ? if (is_method("ACK")) {
>>             ? ? ? ? ? ? # ACK is forwarded statelessly
>>             ? ? ? ? ? ? route(NATMANAGE);
>>             ? ? ? ? } else if (is_method("NOTIFY")) {
>>             ? ? ? ? ? ? # Add Record-Route for in-dialog NOTIFY as
>>             per RFC 6665.
>>             ? ? ? ? ? ? record_route();
>>             ? ? ? ? }
>>             ? ? ? ? route(RELAY);
>>             ? ? ? ? exit;
>>             ? ? }
>>
>>             ? ? if (is_method("SUBSCRIBE") && uri == myself) {
>>             ? ? ? ? # in-dialog subscribe requests
>>             ? ? ? ? route(PRESENCE);
>>             ? ? ? ? exit;
>>             ? ? }
>>             ? ? if (is_method("ACK") ) {
>>             ? ? ? ? if (t_check_trans()) {
>>             ? ? ? ? ? ? # no loose-route, but stateful ACK;
>>             ? ? ? ? ? ? # must be an ACK after a 487
>>             ? ? ? ? ? ? # or e.g. 404 from upstream server
>>             ? ? ? ? ? ? route(RELAY);
>>             ? ? ? ? ? ? exit;
>>             ? ? ? ? } else {
>>             ? ? ? ? ? ? # ACK without matching transaction ... ignore
>>             and discard
>>             ? ? ? ? ? ? exit;
>>             ? ? ? ? }
>>             ? ? }
>>             ? ? send_reply("404","Not here");
>>             ? ? exit;
>>             }
>>
>>
>>             kamailio -v
>>             version: kamailio 5.3.7 (x86_64/linux)
>>             flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS,
>>             USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK,
>>             SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC,
>>             DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
>>             USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
>>             USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
>>             ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144,
>>             MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>>             poll method support: poll, epoll_lt, epoll_et, sigio_rt,
>>             select.
>>             id: unknown
>>             compiled with gcc 6.3.0
>>
>>
>>             uname -a
>>             Linux example.com <http://example.com> 4.15.0-124-generic
>>             #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 GNU/Linux
>>
>>
>>
>>             SIP logs
>>             2020/12/17 10:08:18.483907 proxy-a.com:5060
>>             <http://proxy-a.com:5060> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             INVITE sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>
>>             Contact: <sip:7654321 at did.com:5060
>>             <http://sip:7654321 at did.com:5060>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             User-Agent: ProxyA
>>             CSeq: 102 INVITE
>>             User-Agent: proxy
>>             Date: Thu, 17 Dec 2020 10:08:18 GMT
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Remote-Party-ID: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
>>             Content-Type: application/sdp
>>             Content-Length: 885
>>
>>
>>
>>             2020/12/17 10:08:18.485063 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> proxy-a.com:5060
>>             <http://proxy-a.com:5060>
>>             SIP/2.0 100 trying -- your call is important to us
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1;rport=5060
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 INVITE
>>             Server: kamailio (5.3.7 (x86_64/linux))
>>             Content-Length: 0
>>
>>
>>             2020/12/17 10:08:18.485576 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>             <http://10.0.14.118:6000>
>>             INVITE sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>
>>             Contact: <sip:7654321 at did.com:5060
>>             <http://sip:7654321 at did.com:5060>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             User-Agent: ProxyA
>>             CSeq: 102 INVITE
>>             User-Agent: proxy
>>             Date: Thu, 17 Dec 2020 10:08:18 GMT
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Remote-Party-ID: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
>>             Content-Type: application/sdp
>>             Content-Length: 885
>>
>>
>>
>>             2020/12/17 10:08:18.622867 10.0.14.118:6000
>>             <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             SIP/2.0 401 Unauthorized
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0;received=10.0.14.118;rport=5060
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as4107645c
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             WWW-Authenticate: Digest algorithm=MD5,
>>             realm="sip1.comms.kuflink.com
>>             <http://sip1.comms.kuflink.com>", nonce="11139d33"
>>             Content-Length: 0
>>
>>
>>
>>             2020/12/17 10:08:18.624034 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>             <http://10.0.14.118:6000>
>>             ACK sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.0
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as4107645c
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 ACK
>>             Content-Length: 0
>>
>>
>>
>>             2020/12/17 10:08:18.625557 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>             <http://10.0.14.118:6000>
>>             INVITE sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com> SIP/2.0
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>
>>             Contact: <sip:7654321 at did.com:5060
>>             <http://sip:7654321 at did.com:5060>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             User-Agent: ProxyA
>>             CSeq: 103 INVITE
>>             User-Agent: proxy
>>             Date: Thu, 17 Dec 2020 10:08:18 GMT
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Remote-Party-ID: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;party=calling;privacy=off;screen=no
>>             Content-Type: application/sdp
>>             Content-Length: 885
>>             Authorization: Digest username="xxxxx", realm="xxxx",
>>             nonce="11139d33", uri="sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>", response="qwewqeqwe",
>>             algorithm=MD5
>>
>>
>>
>>             2020/12/17 10:08:18.779483 10.0.14.118:6000
>>             <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             SIP/2.0 100 Trying
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 103 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact: <sip:123456 at 10.0.14.118:6000
>>             <http://sip:123456 at 10.0.14.118:6000>>
>>             Content-Length: 0
>>
>>
>>
>>
>>             2020/12/17 10:08:20.937756 10.0.14.118:6000
>>             <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             SIP/2.0 180 Ringing
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 103 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact: <sip:123456 at 10.0.14.118:6000
>>             <http://sip:123456 at 10.0.14.118:6000>>
>>             Content-Length: 0
>>
>>
>>
>>             2020/12/17 10:08:20.938593 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> proxy-a.com:5060
>>             <http://proxy-a.com:5060>
>>             SIP/2.0 180 Ringing
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact:
>>             <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>             Content-Length: 0
>>
>>
>>
>>             2020/12/17 10:08:22.075814 10.0.14.118:6000
>>             <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             SIP/2.0 200 OK
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 103 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact: <sip:123456 at 10.0.14.118:6000
>>             <http://sip:123456 at 10.0.14.118:6000>>
>>             Content-Type: application/sdp
>>             Require: timer
>>             Content-Length: 296
>>
>>
>>             2020/12/17 10:08:22.077049 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> proxy-a.com:5060
>>             <http://proxy-a.com:5060>
>>             SIP/2.0 200 OK
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact:
>>             <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>             Content-Type: application/sdp
>>             Require: timer
>>             Content-Length: 316
>>
>>
>>
>>             2020/12/17 10:08:22.103365 proxy-a.com:5060
>>             <http://proxy-a.com:5060> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             ACK
>>             sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>>             SIP/2.0
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK2a5fae72;rport=5060
>>             Route: <sip:proxy-b.com <http://proxy-b.com>;lr;did=d18.7a9>
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Contact: <sip:7654321 at did.com:5060
>>             <http://sip:7654321 at did.com:5060>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 ACK
>>             User-Agent: proxy
>>             Content-Length: 0
>>
>>
>>
>>             2020/12/17 10:08:22.103877 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>             <http://10.0.14.118:6000>
>>             ACK
>>             sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1
>>             SIP/2.0
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.79f351d031912aae585207d2f26d5650.0
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.0fc1940efc770391762d7d67094c24f8.0
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK2a5fae72;rport=5060
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Contact: <sip:7654321 at did.com:5060
>>             <http://sip:7654321 at did.com:5060>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 ACK
>>             User-Agent: proxy
>>             Content-Length: 0
>>             P-K-CSeq-Refresh: 103
>>
>>
>>             2020/12/17 10:08:22.575533 10.0.14.118:6000
>>             <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             SIP/2.0 200 OK
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 103 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact: <sip:123456 at 10.0.14.118:6000
>>             <http://sip:123456 at 10.0.14.118:6000>>
>>             Content-Type: application/sdp
>>             Require: timer
>>             Content-Length: 296
>>
>>
>>
>>             2020/12/17 10:08:22.576777 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> proxy-a.com:5060
>>             <http://proxy-a.com:5060>
>>             SIP/2.0 200 OK
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact:
>>             <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>             Content-Type: application/sdp
>>             Require: timer
>>             Content-Length: 316
>>
>>
>>
>>             2020/12/17 10:08:22.581649 proxy-a.com:5060
>>             <http://proxy-a.com:5060> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             ACK
>>             sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1;alias=109.72.216.251~5060~1
>>             SIP/2.0
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK219933f6;rport=5060
>>             Route: <sip:proxy-b.com <http://proxy-b.com>;lr;did=d18.7a9>
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Contact: <sip:7654321 at did.com:5060
>>             <http://sip:7654321 at did.com:5060>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 ACK
>>             User-Agent: proxy
>>             Content-Length: 0
>>
>>
>>
>>             2020/12/17 10:08:22.582313 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> 10.0.14.118:6000
>>             <http://10.0.14.118:6000>
>>             ACK
>>             sip:123456 at 10.0.14.118:6000;alias=109.72.216.251~5060~1
>>             SIP/2.0
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.33626b5695ad4648ba393bc62bed6a8c.0
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.b9c7eeccd4cd7b44f05b173308dbaf0a.0
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK219933f6;rport=5060
>>             Max-Forwards: 70
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Contact: <sip:7654321 at did.com:5060
>>             <http://sip:7654321 at did.com:5060>>
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 ACK
>>             User-Agent: proxy
>>             Content-Length: 0
>>             P-K-CSeq-Refresh: 103
>>
>>
>>             2020/12/17 10:08:23.575828 10.0.14.118:6000
>>             <http://10.0.14.118:6000> -> 10.0.14.118:5060
>>             <http://10.0.14.118:5060>
>>             SIP/2.0 200 OK
>>             Via: SIP/2.0/UDP
>>             proxy-b.com:5060;branch=z9hG4bKbe6d.619fd995c3fc8764ce5cd9c7be7efeef.1.cs102;received=10.0.14.118;rport=5060
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 103 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact: <sip:123456 at 10.0.14.118:6000
>>             <http://sip:123456 at 10.0.14.118:6000>>
>>             Content-Type: application/sdp
>>             Require: timer
>>             Content-Length: 296
>>
>>
>>             2020/12/17 10:08:23.577863 10.0.14.118:5060
>>             <http://10.0.14.118:5060> -> proxy-a.com:5060
>>             <http://proxy-a.com:5060>
>>             SIP/2.0 200 OK
>>             Via: SIP/2.0/UDP
>>             proxy-a.com:5060;rport=5060;branch=z9hG4bKbe6d.10c4c5f001c66b8976214d4aef9f635c.1
>>             Via: SIP/2.0/UDP did.com:5060;received=did.com
>>             <http://did.com>;branch=z9hG4bK45f94ed9;rport=5060
>>             Record-Route: <sip:proxy-b.com
>>             <http://proxy-b.com>;lr;did=d18.7a9>
>>             Record-Route: <sip:proxy-a.com <http://proxy-a.com>;lr>
>>             From: "7654321" <sip:7654321 at did.com
>>             <mailto:sip%3A7654321 at did.com>>;tag=as55c522e1
>>             To: <sip:123456 at proxy-a.com
>>             <mailto:sip%3A123456 at proxy-a.com>>;tag=as147bfa3e
>>             Call-ID: 67675c7e636d6e773860255316e54779 at did.com
>>             <mailto:67675c7e636d6e773860255316e54779 at did.com>
>>             CSeq: 102 INVITE
>>             Server: proxy
>>             Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>             SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>             Supported: replaces, timer
>>             Session-Expires: 1800;refresher=uas
>>             Contact:
>>             <sip:123456 at 10.0.14.118:6000;alias=10.0.14.118~6000~1>
>>             Content-Type: application/sdp
>>             Require: timer
>>             Content-Length: 316
>>
>>
>>
>>             _______________________________________________
>>             Kamailio (SER) - Users Mailing List
>>             sr-users at lists.kamailio.org
>>             <mailto:sr-users at lists.kamailio.org>
>>             https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>             <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>         _______________________________________________
>>         Kamailio (SER) - Users Mailing List
>>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>         <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>     -- 
>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201218/1ca59b8e/attachment-0001.htm>

From nicolas.chaigneau at capgemini.com  Fri Dec 18 15:07:40 2020
From: nicolas.chaigneau at capgemini.com (Chaigneau, Nicolas)
Date: Fri, 18 Dec 2020 14:07:40 +0000
Subject: [SR-Users] Trying to use $sel(contact.uri.params)
Message-ID: <AM9PR02MB65473806529A7A5EE9446B13E6C30@AM9PR02MB6547.eurprd02.prod.outlook.com>

Hello,


I'd like to use a < select > as described here:
http://www.kamailio.org/wiki/cookbooks/5.4.x/selects#contactparams_s

I'm trying to extract a parameter from the Contact URI.
What I've tried to do:
                               xlog("L_INFO", "contact.uri: $sel(contact.uri)\n"); # OK
                               xlog("L_INFO", "contact.uri.params: $sel(contact.uri.params)\n"); # null ??

This does not seem to work... see output here :

3(10316) INFO: {1 INVITE r8wEHsAgxNIS5OJL} <script>: contact.uri: sip:+33145678901;tgrp=YC031;trunk-context=YC90 at 10.31.22.2:5099
3(10316) INFO: {1 INVITE r8wEHsAgxNIS5OJL} <script>: contact.uri.params: <null>


What am I doing wrong ?
Maybe this is the wrong approach for what I'm trying to do ?



Regards,
Nicolas.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201218/84c4ea87/attachment.htm>

From nicolas.chaigneau at capgemini.com  Fri Dec 18 15:52:48 2020
From: nicolas.chaigneau at capgemini.com (Chaigneau, Nicolas)
Date: Fri, 18 Dec 2020 14:52:48 +0000
Subject: [SR-Users] Trying to use $sel(contact.uri.params)
In-Reply-To: <AM9PR02MB65473806529A7A5EE9446B13E6C30@AM9PR02MB6547.eurprd02.prod.outlook.com>
References: <AM9PR02MB65473806529A7A5EE9446B13E6C30@AM9PR02MB6547.eurprd02.prod.outlook.com>
Message-ID: <AM9PR02MB6547DE52CF410E032193FDB2E6C30@AM9PR02MB6547.eurprd02.prod.outlook.com>

I've come up with something that works:

                               $var(contact_uri) = $sel(contact.uri);
                               $var(tgrp) = $(var(contact_uri){param.value,tgrp});


Not sure if ? $sel(contact.uri.params) ? is supposed to work as I think it should...


De : sr-users <sr-users-bounces at lists.kamailio.org> De la part de Chaigneau, Nicolas
Envoy? : vendredi 18 d?cembre 2020 15:08
? : Kamailio (SER) - Users Mailing List
Objet : [SR-Users] Trying to use $sel(contact.uri.params)

Hello,


I'd like to use a ? select ? as described here:
http://www.kamailio.org/wiki/cookbooks/5.4.x/selects#contactparams_s

I'm trying to extract a parameter from the Contact URI.
What I've tried to do:
                               xlog("L_INFO", "contact.uri: $sel(contact.uri)\n"); # OK
                               xlog("L_INFO", "contact.uri.params: $sel(contact.uri.params)\n"); # null ??

This does not seem to work... see output here :

3(10316) INFO: {1 INVITE r8wEHsAgxNIS5OJL} <script>: contact.uri: sip:+33145678901;tgrp=YC031;trunk-context=YC90 at 10.31.22.2:5099
3(10316) INFO: {1 INVITE r8wEHsAgxNIS5OJL} <script>: contact.uri.params: <null>


What am I doing wrong ?
Maybe this is the wrong approach for what I'm trying to do ?



Regards,
Nicolas.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201218/95500f53/attachment.htm>

From eschmidbauer at gmail.com  Sat Dec 19 03:05:59 2020
From: eschmidbauer at gmail.com (E. Schmidbauer)
Date: Fri, 18 Dec 2020 19:05:59 -0700
Subject: [SR-Users] MID-Registrar Example
In-Reply-To: <db567cdd-4c66-f2bd-d528-b5d5a1aaf49a@evaristesys.com>
References: <1608259112948-0.post@n5.nabble.com>
 <db567cdd-4c66-f2bd-d528-b5d5a1aaf49a@evaristesys.com>
Message-ID: <CAJwe+CBQqv8ai+kc8qLu80oSHO+rXZZFydJe6HiStp_LgLYJSw@mail.gmail.com>

Opensips has mid-registrar module. It's a method of forwarding registration
data to another registrar (usually with a much higher expiration). The idea
is to handle high volumes of registrations at opensips and only forward the
registration data to another registrar when the data changes.
Kamailio doesn't have a mid-registrar module, and IMO, for good reason. The
concept of a mid-registrar doesn't make a lot of sense to me as there are
much better ways to scale registration data without forwarding REGISTER
packets to other registrars.

On Thu, Dec 17, 2020, 7:41 PM Alex Balashov <abalashov at evaristesys.com>
wrote:

> It would probably help if you could state exactly what it is that you
> are trying to achieve. The term "mid-registrar" encompasses a fairly
> large category of conceivable configurations, though all of them have in
> common, I suppose, the quality of not passing through registrations
> upstream in a 1:1 fashion.
>
> On 12/17/20 9:38 PM, moisesynfante wrote:
> > Hello,
> >
> > I'm a newbie when it comes to Kamailio and I would like to know if
> there's a
> > working example of a Mid-Registrar implementation. I read on other posts
> > that the UAC module can be used to achieve this but, honestly, I don't
> > understand how. If any of you could provide some path I could follow I
> would
> > be very thankful.
> >
> >
> >
> > --
> > Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201218/4688698f/attachment.htm>

From abalashov at evaristesys.com  Sat Dec 19 05:13:43 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 18 Dec 2020 23:13:43 -0500
Subject: [SR-Users] MID-Registrar Example
In-Reply-To: <CAJwe+CBQqv8ai+kc8qLu80oSHO+rXZZFydJe6HiStp_LgLYJSw@mail.gmail.com>
References: <1608259112948-0.post@n5.nabble.com>
 <db567cdd-4c66-f2bd-d528-b5d5a1aaf49a@evaristesys.com>
 <CAJwe+CBQqv8ai+kc8qLu80oSHO+rXZZFydJe6HiStp_LgLYJSw@mail.gmail.com>
Message-ID: <b023a785-ea2b-b1ce-daba-9378d5e969f2@evaristesys.com>

On 12/18/20 9:05 PM, E. Schmidbauer wrote:

> Kamailio doesn't have a mid-registrar module, and IMO, for good
> reason. The concept of a mid-registrar doesn't make a lot of sense to
> me as there are much better ways to scale registration data without
> forwarding REGISTER packets to other registrars.

I would strongly agree with that. Nevertheless, the concept of a 
"condom" to protect vulnerable and poorly-performing commercial 
registrars from high registration volumes has a lot of currency and 
steady demand.

The Other Project is not very purist, and is good at packaging and 
marketing solutions which cater to specific concepts users seem to be 
infatuated with.

    ?If I had asked people what they wanted, they would
     have said faster horses.? -- Henry Ford

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/


From khorsmann at gmail.com  Sun Dec 20 22:14:15 2020
From: khorsmann at gmail.com (Karsten Horsmann)
Date: Sun, 20 Dec 2020 22:14:15 +0100
Subject: [SR-Users] ndb_redis with keydb master/master
In-Reply-To: <PR2P264MB0607A4177E6E1AC9810AD8EAFDC50@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
References: <PR2P264MB0607A4177E6E1AC9810AD8EAFDC50@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <CAFArqsYnQx4Xp-uZDg5f=pOHDQ4Gz37T7pfzYN3v4E5Lb0n+4w@mail.gmail.com>

Hi,

Maybe you got some inspiration from Yufei Tao presentation

https://youtu.be/p56F2fw483I

about an HA Setup with Kamailio. There is redis in a cross subscription
manner in use.


Kind regards
Karsten Horsmann

David VILLAUME <david.villaume at sewan.fr> schrieb am Mi., 16. Dez. 2020,
09:18:

> Hello,
>
>
>
> I consider using keydb-server in an active/action setup without sentinel.
>
> Do you know if there is a way to declare both hosts in ndb_redis with the
> same server name (target use : topos) ?
>
>
>
> Regards,
>
> David
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201220/bf13a649/attachment.htm>

From syedshahryar at gmail.com  Mon Dec 21 06:29:42 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Mon, 21 Dec 2020 00:29:42 -0500
Subject: [SR-Users] send MESSAGE to other sessions of same user
Message-ID: <CA+mcf=vfG+9x1Q4mSL8dk1rMvZyMn_y-yC2=2tQm0RjfkF=BTA@mail.gmail.com>

What's the best way of sending a message to all other sessions (and the
receiver) of the same sender?

For example: If user1 at example.com is logged in to Kamailio from multiple
devices and from one of the devices user1 sends a SIP message to
user2 at example.com. I want the message forwarded not only to
user2 at example.com but also to all other user1 at example.com sessions.

What's the easiest way to achieve this?

-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201221/d035a6fa/attachment.htm>

From hw at skalatan.de  Mon Dec 21 10:34:02 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Mon, 21 Dec 2020 09:34:02 +0000
Subject: [SR-Users] Releasing Kamailio 5.3.8
In-Reply-To: <AM0PR05MB6595FCBE737050F69F5F79DCC5C40@AM0PR05MB6595.eurprd05.prod.outlook.com>
References: <AM0PR05MB6595FCBE737050F69F5F79DCC5C40@AM0PR05MB6595.eurprd05.prod.outlook.com>
Message-ID: <AM0PR05MB6595EBACB57CE24B4E531CFBC5C00@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hello,

a quick reminder that 5.3.8 will be released later today. So, until the announcement is out, please do not push any new commits on branch 5.3 to not interfere with the release process.

If you need to push on the 5.3 branch, please ask on sr-dev or the Kamailio matrix channel before and wait for a confirmation.

Cheers,

Henning

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

From: Henning Westerholt
Sent: Thursday, December 17, 2020 12:14 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>; Kamailio (SER) - Development Mailing List <sr-dev at lists.kamailio.org>
Subject: Releasing Kamailio 5.3.8

Hello,

I am planning to release next week (likely on Monday 21st December) the next minor version out of branch 5.3, version 5.3.8.

Backports of fixed issues from git master will be integrated as usual. If you are aware of new issues which were not yet reported, let us know (by creating an issue on the tracker).

Cheers,

Henning

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201221/d567de21/attachment.htm>

From miconda at gmail.com  Mon Dec 21 10:52:14 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 21 Dec 2020 10:52:14 +0100
Subject: [SR-Users] Trying to use $sel(contact.uri.params)
In-Reply-To: <AM9PR02MB65473806529A7A5EE9446B13E6C30@AM9PR02MB6547.eurprd02.prod.outlook.com>
References: <AM9PR02MB65473806529A7A5EE9446B13E6C30@AM9PR02MB6547.eurprd02.prod.outlook.com>
Message-ID: <5b69ee37-51d6-b0ac-83d3-f782cbb2ad78@gmail.com>

Hello,

the doc listing suggest that the name of the parameter has to be
provided, like:

$sel(contact.uri.params[name])

On the other hand, the URI in the logs has username parameters, not URI
parameters.

Cheers,
Daniel

On 18.12.20 15:07, Chaigneau, Nicolas wrote:
>
> Hello,
>
> ?
>
> ?
>
> I?d like to use a ??select?? as described here:
>
> http://www.kamailio.org/wiki/cookbooks/5.4.x/selects#contactparams_s
>
> ?
>
> I?m trying to extract a parameter from the Contact URI.
>
> What I?ve tried to do:
>
> ?????????????????????????????? xlog("L_INFO", "contact.uri:
> $sel(contact.uri)\n"); # OK
>
> ?????????????????????????????? xlog("L_INFO", "contact.uri.params:
> $sel(contact.uri.params)\n"); # null???
>
> ?
>
> This does not seem to work? see output here?:
>
> ?
>
> 3(10316) INFO: {1 INVITE r8wEHsAgxNIS5OJL} <script>: contact.uri:
> sip:+33145678901;tgrp=YC031;trunk-context=YC90 at 10.31.22.2:5099
>
> 3(10316) INFO: {1 INVITE r8wEHsAgxNIS5OJL} <script>:
> contact.uri.params: <null>
>
> ?
>
> ?
>
> What am I doing wrong??
>
> Maybe this is the wrong approach for what I?m trying to do??
>
> ?
>
> ?
>
> ?
>
> Regards,
>
> Nicolas.
>
> This message contains information that may be privileged or
> confidential and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not
> the intended recipient, you are not authorized to read, print, retain,
> copy, disseminate, distribute, or use this message or any part
> thereof. If you receive this message in error, please notify the
> sender immediately and delete all copies of this message.
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201221/83d308fa/attachment.htm>

From david.villaume at sewan.fr  Mon Dec 21 14:01:10 2020
From: david.villaume at sewan.fr (David VILLAUME)
Date: Mon, 21 Dec 2020 13:01:10 +0000
Subject: [SR-Users] ndb_redis with keydb master/master
In-Reply-To: <CAFArqsYnQx4Xp-uZDg5f=pOHDQ4Gz37T7pfzYN3v4E5Lb0n+4w@mail.gmail.com>
References: <PR2P264MB0607A4177E6E1AC9810AD8EAFDC50@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
 <CAFArqsYnQx4Xp-uZDg5f=pOHDQ4Gz37T7pfzYN3v4E5Lb0n+4w@mail.gmail.com>
Message-ID: <PR2P264MB06073632956D1C3785D25043FDC00@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>

Hello,

Thanks for your response, cross subscription mechanism in video is native rtpengine, not on Kamailio side.

My goal is to have redundant topos in Kamailio without having to build a full redis cluster with sentinel, but I?m not sure if  there is a way to declare two hosts in ndb_redis with the same name (and any parameter to set them either as active/passive either active/active).

Regards,
David

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Karsten Horsmann
Sent: Sunday, December 20, 2020 10:14 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Subject: Re: [SR-Users] ndb_redis with keydb master/master

Hi,

Maybe you got some inspiration from Yufei Tao presentation

https://youtu.be/p56F2fw483I

about an HA Setup with Kamailio. There is redis in a cross subscription manner in use.


Kind regards
Karsten Horsmann

David VILLAUME <david.villaume at sewan.fr<mailto:david.villaume at sewan.fr>> schrieb am Mi., 16. Dez. 2020, 09:18:
Hello,

I consider using keydb-server in an active/action setup without sentinel.
Do you know if there is a way to declare both hosts in ndb_redis with the same server name (target use : topos) ?

Regards,
David

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201221/cbe5c3dd/attachment.htm>

From miconda at gmail.com  Mon Dec 21 15:11:54 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 21 Dec 2020 15:11:54 +0100
Subject: [SR-Users] MID-Registrar Example
In-Reply-To: <b023a785-ea2b-b1ce-daba-9378d5e969f2@evaristesys.com>
References: <1608259112948-0.post@n5.nabble.com>
 <db567cdd-4c66-f2bd-d528-b5d5a1aaf49a@evaristesys.com>
 <CAJwe+CBQqv8ai+kc8qLu80oSHO+rXZZFydJe6HiStp_LgLYJSw@mail.gmail.com>
 <b023a785-ea2b-b1ce-daba-9378d5e969f2@evaristesys.com>
Message-ID: <cd5fba24-99fd-0173-6c85-fa2db4d648fd@gmail.com>

Hello,

the mid registrar can be done with current kamailio. Practically there
are two scenarios:

1) the mid registrar is aware of the passwords for end users, in that
case, practically it is just uac module with uacreg database table from
kamailio to registrar server:

? * https://www.kamailio.org/docs/modules/devel/modules/uac.html#idm650

With options for fine tuning using the functions to enable/disable
uacreg records based on registration/unregistration from end points:

? *
https://www.kamailio.org/docs/modules/devel/modules/uac.html#uac.f.uac_reg_enable

On the end point side, the registrar+usrloc are used as usual

2) the mid registrar is agnostic of username and passwords, it relies on
the IP of the first (authenticated by registrar) REGISTER for subsequent
registrations of the endpoint -- in this case there was a recent
discussion on this mailing list where I described how it can be done:

? * https://lists.kamailio.org/pipermail/sr-users/2020-October/110779.html

? * https://lists.kamailio.org/pipermail/sr-users/2020-October/110782.html

Looking at the other messages in the thread can be also useful, just get
the subject from the above two links and spot the corresponding thread at:

? *
https://lists.kamailio.org/pipermail/sr-users/2020-October/thread.html#start

The registrar+usrloc can still be used, or not, a matter of what main
registrar can do.

So far I needed 1) and works like a charm, providing a lot of
flexibility when needing to offload traffic of a system in the same
operator. The 2) may look a bit like complex config oriented, but it is
not really much.

Considering the two variants available, I think Kamailio offers all
needed for what people refer as mid-registrar. If people find cases that
they think cannot be covered, just write here and I can try to assist
further.

Cheers,
Daniel

On 19.12.20 05:13, Alex Balashov wrote:
> On 12/18/20 9:05 PM, E. Schmidbauer wrote:
>
>> Kamailio doesn't have a mid-registrar module, and IMO, for good
>> reason. The concept of a mid-registrar doesn't make a lot of sense to
>> me as there are much better ways to scale registration data without
>> forwarding REGISTER packets to other registrars.
>
> I would strongly agree with that. Nevertheless, the concept of a
> "condom" to protect vulnerable and poorly-performing commercial
> registrars from high registration volumes has a lot of currency and
> steady demand.
>
> The Other Project is not very purist, and is good at packaging and
> marketing solutions which cater to specific concepts users seem to be
> infatuated with.
>
> ?? ?If I had asked people what they wanted, they would
> ??? have said faster horses.? -- Henry Ford
>
> -- Alex
>
> --?
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla



From hw at skalatan.de  Mon Dec 21 18:38:46 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Mon, 21 Dec 2020 17:38:46 +0000
Subject: [SR-Users] Kamailio v5.3.8 released
Message-ID: <AM0PR05MB6595C16D3AA53968E99435E3C5C00@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hello,



Kamailio SIP Server v5.3.8 stable has been released.



This is a maintenance release of the previous stable branch (5.3), that includes fixes since the release of v5.3.7. There are no change to database schema or configuration language structure that you have to do on previous installations of v5.3.x.



Deployments running previous v5.3.x versions are recommended to be upgraded to v5.3.8.



For more details about version 5.3.8 (including links and guidelines to download the tar file or from GIT repository), visit:



https://www.kamailio.org/w/2020/12/kamailio-v5-3-8-released/



RPM, Debian/Ubuntu packages will be available soon as well.



Many thanks to all contributing and using Kamailio!



Cheers,



Henning

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201221/c17480d5/attachment.htm>

From moises.ynfante at pushmotion.com  Mon Dec 21 21:25:43 2020
From: moises.ynfante at pushmotion.com (moisesynfante)
Date: Mon, 21 Dec 2020 13:25:43 -0700 (MST)
Subject: [SR-Users] MID-Registrar Example
In-Reply-To: <cd5fba24-99fd-0173-6c85-fa2db4d648fd@gmail.com>
References: <1608259112948-0.post@n5.nabble.com>
 <db567cdd-4c66-f2bd-d528-b5d5a1aaf49a@evaristesys.com>
 <CAJwe+CBQqv8ai+kc8qLu80oSHO+rXZZFydJe6HiStp_LgLYJSw@mail.gmail.com>
 <b023a785-ea2b-b1ce-daba-9378d5e969f2@evaristesys.com>
 <cd5fba24-99fd-0173-6c85-fa2db4d648fd@gmail.com>
Message-ID: <1608582343976-0.post@n5.nabble.com>

Thank you for your answer. 

I'm going for the second scenario. I will try the solutions provided in the
links and let you know if I made it work!



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From khorsmann at gmail.com  Tue Dec 22 00:33:35 2020
From: khorsmann at gmail.com (Karsten Horsmann)
Date: Tue, 22 Dec 2020 00:33:35 +0100
Subject: [SR-Users] ndb_redis with keydb master/master
In-Reply-To: <PR2P264MB06073632956D1C3785D25043FDC00@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
References: <PR2P264MB0607A4177E6E1AC9810AD8EAFDC50@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
 <CAFArqsYnQx4Xp-uZDg5f=pOHDQ4Gz37T7pfzYN3v4E5Lb0n+4w@mail.gmail.com>
 <PR2P264MB06073632956D1C3785D25043FDC00@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <CAFArqsYnUxmQOVWYfW7Bxe2AKS8cApf++YoHwZJ5w=6gPsR2_w@mail.gmail.com>

Hi David,

ah okay. I used the full way of an redis sentinel cluster with haproxy for
dead end detection.
And this redis setup is for my Kamailio Topos and my rtpengine.

But you can subscribe to one redis dB 1 and replicate it to the other side.
And vice versa. With Kamailio cfg pointing to the local or cross over redis
and the right db it should possible.

I did tried that it's more an idea from the rtpengine folks.

Also Topos will work with other backends IMHO like mysql.

Cheers
Karsten Horsmann

David VILLAUME <david.villaume at sewan.fr> schrieb am Mo., 21. Dez. 2020,
14:02:

> Hello,
>
>
>
> Thanks for your response, cross subscription mechanism in video is native
> rtpengine, not on Kamailio side.
>
>
>
> My goal is to have redundant topos in Kamailio without having to build a
> full redis cluster with sentinel, but I?m not sure if  there is a way to
> declare two hosts in ndb_redis with the same name (and any parameter to
> set them either as active/passive either active/active).
>
>
>
> Regards,
>
> David
>
>
>
> *From:* sr-users <sr-users-bounces at lists.kamailio.org> * On Behalf Of *Karsten
> Horsmann
> *Sent:* Sunday, December 20, 2020 10:14 PM
> *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
> *Subject:* Re: [SR-Users] ndb_redis with keydb master/master
>
>
>
> Hi,
>
>
>
> Maybe you got some inspiration from Yufei Tao presentation
>
>
>
> https://youtu.be/p56F2fw483I
>
>
>
> about an HA Setup with Kamailio. There is redis in a cross subscription
> manner in use.
>
>
>
>
>
> Kind regards
>
> Karsten Horsmann
>
>
>
> David VILLAUME <david.villaume at sewan.fr> schrieb am Mi., 16. Dez. 2020,
> 09:18:
>
> Hello,
>
>
>
> I consider using keydb-server in an active/action setup without sentinel.
>
> Do you know if there is a way to declare both hosts in ndb_redis with the
> same server name (target use : topos) ?
>
>
>
> Regards,
>
> David
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/57a381a1/attachment.htm>

From hbilling at gmail.com  Tue Dec 22 05:48:46 2020
From: hbilling at gmail.com (harneet singh)
Date: Tue, 22 Dec 2020 10:18:46 +0530
Subject: [SR-Users] DLGLOAD stuck in Dispatcher Module(HA Mode)
In-Reply-To: <CAHTs8D9p1mF+w8MUEvCNVzgcTs_NPtd+3J1HdoFTDy_4OTm8FA@mail.gmail.com>
References: <CAHTs8D_EtwxFi5Hw6J1jNfX-zZDjg0iQ7_1ygV+J_T6mJyswPw@mail.gmail.com>
 <5283ba0d-a428-0175-421b-cceb373f60c5@bohboh.info>
 <CAHTs8D9p1mF+w8MUEvCNVzgcTs_NPtd+3J1HdoFTDy_4OTm8FA@mail.gmail.com>
Message-ID: <CAHTs8D9oEXra=ttsURwS-utuhUKhvA4JcdnECs8r4+NiQf9=kA@mail.gmail.com>

Apologies for not having included the sr-users in the previous email.
Anyhow, the solution suggested by Social Boh indeed worked, as a side
effect of which we would not run into the issue described.

*NOTE:* There was a peculiar configuration in keepalived with keeping both
the nodes as BACKUP and setting the 'nopreempt' flag only in the actual
MASTER(one with higher 'priority') side to make the keepalived thing to
work properly.

However, I was wondering if someone could confirm if this issue has been
fixed inside the source code itself as I am using an older release v5.3.2

Regards,
Harneet Singh

On Thu, Dec 17, 2020 at 9:52 PM harneet singh <hbilling at gmail.com> wrote:

> Thanks Social Boh,
>
> I will investigate this possibility and if it does work in our case, that
> should circumvent the issue.
> In addition, is there a fix known to the SR-Users which could be available
> inside the Dispatcher module to cause syncing just like the syncing is
> there in the Dialog module via DMQ. I wanted to check this as I am using
> v5.3.2 and unaware if new releases could have fixed this issue?
>
> Regards,
> Harneet Singh
>
> On Wed, Dec 16, 2020 at 10:46 PM Social Boh <social at bohboh.info> wrote:
>
>> Maybe a option is leave the secondary like primary when primary go up
>> newly.
>>
>> Example: Primary go down, Secondary is the new Primary. Primary came back
>> up but Secondary still is the VIP and still process the calls.
>>
>> Only if Secondary go down, primary is the new VIP.
>>
>> The keepalived parameter for this behaviour is:
>>
>> *nopreempt*
>>
>> ---
>> I'm SoCIaL, MayBe
>>
>> El 16/12/2020 a las 11:57 a. m., harneet singh escribi?:
>>
>> Hi All,
>>
>> I am using Kamailio in HA mode with Keepalived providing the VIP(Virtual
>> IP) functionality, and have run into a rather peculiar issue.
>>
>> *Setup:*
>>
>> Caller ------------ KamailioVIP(*Primary *and *Secondary*
>> Kamailio)------- Callee
>>
>>     HA provided by Keepalived
>>     DMQ is used between the Primary and Secondary Kamailio for dialog sync
>>
>> *Issue Seen:*
>>
>> *Suppose the Primary Kamailio has been brought down* and the Secondary
>> one is actually active and tied to the VIP.
>>
>> When a call is fired from the Caller, it traverses through the Secondary
>> Kamailio and lands onto the callee. The dialogs are updated properly. At
>> this point, the Primary Kamailio is brought up, and dialog state is synced
>> due to the DMQ module.
>> The Keepalived will now attach the VIP to the Primary Instance. If the
>> caller hangs up the phone at this point, the BYE sip message traverses
>> through the Primary Kamailio instance to the callee and the call is
>> cleared, but there are two issues here.
>>
>>   1.  The Primary Kamailio throws an error in *ds_load_remove() *saying
>> that it cannot find the load for the specific call id. This is apparently
>> due to the fact that the dispatcher data is not synced between the two
>> modules but dialog data is. So dialog wise, things are fine. Can this be
>> fixed somehow?
>>
>>   2. The above is still as grave a problem as the dialogs are cleared.
>> BUT, if we check the '*kamcmd dispatcher.list*' on the *SECONDARY*
>> kamailio even well after the call is cleared, the *DLGLOAD* shows 1.
>> Since we are using the *Call Load based distribution* for the
>> dispatching, this is effectively one call stuck on the dispatcher, which
>> leads to resource leak.
>>
>> Is this a known issue, and if so, do we have a way to circumvent this?
>>
>> Regards,
>> Harneet Singh
>> --
>> "Once you eliminate the impossible, whatever remains, no matter how
>> improbable, must be the truth" - Sir Arthur Conan Doyle
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> --
> "Once you eliminate the impossible, whatever remains, no matter how
> improbable, must be the truth" - Sir Arthur Conan Doyle
>


-- 
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/d18874a7/attachment.htm>

From syedshahryar at gmail.com  Tue Dec 22 06:58:38 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Tue, 22 Dec 2020 00:58:38 -0500
Subject: [SR-Users] How to use port number using $env in listen
In-Reply-To: <CA+mcf=vLp1gBgikgpCWu8uVNb0O2hsgg_RiqXk9uRVAvMQnJVg@mail.gmail.com>
References: <CA+mcf=u8Sn8Yq=U8FLKAzoMs+kLmy1-GabpMOatFx2MUaw6ESA@mail.gmail.com>
 <75dbba1f-cba1-a440-1a14-168cc15d8ca5@gmail.com>
 <CA+mcf=vLp1gBgikgpCWu8uVNb0O2hsgg_RiqXk9uRVAvMQnJVg@mail.gmail.com>
Message-ID: <CA+mcf=v8fOufD6xxvJEmmY-DqX3TUUpwbs5JgNX6jrUqZcNuxw@mail.gmail.com>

Any updates on this?

On Tue, Dec 15, 2020 at 8:13 PM Syed Shahryar <syedshahryar at gmail.com>
wrote:

> I am new to Kamailio so may be doing something wrong. I looked at
> https://www.kamailio.org/wiki/cookbooks/5.4.x/core.
>
> I tried the following combinations but getting errors in all cases:
>
> #!subst "/EVAPI_PORT/$env(EVAPI_PORT)/"
> #!substdef "/EVAPI_PORT/$env(EVAPI_PORT)/"
> #!substdefs "/EVAPI_PORT/$env(EVAPI_PORT)/"
>
> *Errors:*
>  0(6) ERROR: <core> [core/pvapi.c:924]: pv_parse_spec2(): error searching
> pvar "env"
>  0(6) ERROR: <core> [core/pvapi.c:1127]: pv_parse_spec2(): wrong char
> [E/69] in [$env(EVAPI_PORT)/] at [5 (5)]
>  0(6) ERROR: <core> [core/re.c:170]: parse_repl(): bad specifier in
> replace part /$env(EVAPI_PORT)/
>  0(6) ERROR: <core> [core/ppcfg.c:69]: pp_subst_add(): bad subst
> expression: /EVAPI_PORT/$env(EVAPI_PORT)/
>
> At a later step, I would like to do:
> #!define EVAPI_LISTEN "0.0.0.0:EVAPI_PORT"
>
> And use EVAP_LISTEN in mod_param for the evapi module.
>
> And something similar to above for TLS settings.
>
>
> On Tue, Dec 15, 2020 at 12:41 PM Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> as written on the tracker, look at using #!subst or #!substdef (see core
>> cookbook), they should be able to get the substitution value from
>> environment using $env(NAME).
>>
>> The master branch introduced #!defenv as a (simpler) alternative.
>>
>> Cheers,
>> Daniel
>> On 12.12.20 05:33, Syed Shahryar wrote:
>>
>> I tried many combinations of the following but I keep getting syntax
>> errors:
>>
>> listen=tls:TLS_IP:$env(TLS_PORT) advertise PUBLIC_IP:$env(TLS_PORT)
>>
>>
>> TLS_IP and PUBLIC_IP are constants defined at the top using #!define.
>> And, TLS_PORT is supposed to be the env variable.
>>
>>
>> --
>> --
>> This message contains confidential information and is intended only for
>> the individual named. If you are not the named addressee, you should not
>> disseminate, distribute or copy this email. Please notify the sender
>> immediately by email if you have received this email by mistake and delete
>> this email from your system. Email transmission cannot be guaranteed to be
>> secure or error-free, as information could be intercepted, corrupted, lost,
>> destroyed, arrive late or incomplete, or contain viruses. The sender,
>> therefore, does not accept liability for any errors or omissions in the
>> contents of this message which arise as a result of email transmission. If
>> verification is required, please request a hard-copy version.
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Funding: https://www.paypal.me/dcmierla
>>
>>
>
> --
> --
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee, you should not
> disseminate, distribute or copy this email. Please notify the sender
> immediately by email if you have received this email by mistake and delete
> this email from your system. Email transmission cannot be guaranteed to be
> secure or error-free, as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender,
> therefore, does not accept liability for any errors or omissions in the
> contents of this message which arise as a result of email transmission. If
> verification is required, please request a hard-copy version.
>


-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/f00aa463/attachment.htm>

From david.villaume at sewan.fr  Tue Dec 22 08:47:34 2020
From: david.villaume at sewan.fr (David VILLAUME)
Date: Tue, 22 Dec 2020 07:47:34 +0000
Subject: [SR-Users] ndb_redis with keydb master/master
In-Reply-To: <CAFArqsYnUxmQOVWYfW7Bxe2AKS8cApf++YoHwZJ5w=6gPsR2_w@mail.gmail.com>
References: <PR2P264MB0607A4177E6E1AC9810AD8EAFDC50@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
 <CAFArqsYnQx4Xp-uZDg5f=pOHDQ4Gz37T7pfzYN3v4E5Lb0n+4w@mail.gmail.com>
 <PR2P264MB06073632956D1C3785D25043FDC00@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>
 <CAFArqsYnUxmQOVWYfW7Bxe2AKS8cApf++YoHwZJ5w=6gPsR2_w@mail.gmail.com>
Message-ID: <PR2P264MB060714599D21F3010B824F86FDDF0@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM>

Hello,

I?ll try make the failover at the keepalived level, I misunderstood seeing the sentinel stuff, that ndb_redis was hangdling failover/load_balancing.

Thanks for your answer that made things clearer.

Regards,
David

From: sr-users <sr-users-bounces at lists.kamailio.org> On Behalf Of Karsten Horsmann
Sent: Tuesday, December 22, 2020 12:34 AM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Subject: Re: [SR-Users] ndb_redis with keydb master/master

Hi David,

ah okay. I used the full way of an redis sentinel cluster with haproxy for dead end detection.
And this redis setup is for my Kamailio Topos and my rtpengine.

But you can subscribe to one redis dB 1 and replicate it to the other side. And vice versa. With Kamailio cfg pointing to the local or cross over redis and the right db it should possible.

I did tried that it's more an idea from the rtpengine folks.

Also Topos will work with other backends IMHO like mysql.

Cheers
Karsten Horsmann
David VILLAUME <david.villaume at sewan.fr<mailto:david.villaume at sewan.fr>> schrieb am Mo., 21. Dez. 2020, 14:02:
Hello,

Thanks for your response, cross subscription mechanism in video is native rtpengine, not on Kamailio side.

My goal is to have redundant topos in Kamailio without having to build a full redis cluster with sentinel, but I?m not sure if  there is a way to declare two hosts in ndb_redis with the same name (and any parameter to set them either as active/passive either active/active).

Regards,
David

From: sr-users <sr-users-bounces at lists.kamailio.org<mailto:sr-users-bounces at lists.kamailio.org>> On Behalf Of Karsten Horsmann
Sent: Sunday, December 20, 2020 10:14 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>>
Subject: Re: [SR-Users] ndb_redis with keydb master/master

Hi,

Maybe you got some inspiration from Yufei Tao presentation

https://youtu.be/p56F2fw483I

about an HA Setup with Kamailio. There is redis in a cross subscription manner in use.


Kind regards
Karsten Horsmann

David VILLAUME <david.villaume at sewan.fr<mailto:david.villaume at sewan.fr>> schrieb am Mi., 16. Dez. 2020, 09:18:
Hello,

I consider using keydb-server in an active/action setup without sentinel.
Do you know if there is a way to declare both hosts in ndb_redis with the same server name (target use : topos) ?

Regards,
David

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/f1e4d5e0/attachment.htm>

From spady77 at gmail.com  Mon Dec 21 12:03:46 2020
From: spady77 at gmail.com (Gert dal Pozzo)
Date: Mon, 21 Dec 2020 04:03:46 -0700 (MST)
Subject: [SR-Users] MSTeams Kamailio with PBX Hold Refer issue
In-Reply-To: <1620937435.3504796.1606899523387@mail.yahoo.com>
References: <1620937435.3504796.1606899523387@mail.yahoo.com>
Message-ID: <1608548626248-0.post@n5.nabble.com>

Hi, could you share you conf?
Regards




--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From miconda at gmail.com  Tue Dec 22 09:59:51 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Tue, 22 Dec 2020 09:59:51 +0100
Subject: [SR-Users] How to use port number using $env in listen
In-Reply-To: <CA+mcf=v8fOufD6xxvJEmmY-DqX3TUUpwbs5JgNX6jrUqZcNuxw@mail.gmail.com>
References: <CA+mcf=u8Sn8Yq=U8FLKAzoMs+kLmy1-GabpMOatFx2MUaw6ESA@mail.gmail.com>
 <75dbba1f-cba1-a440-1a14-168cc15d8ca5@gmail.com>
 <CA+mcf=vLp1gBgikgpCWu8uVNb0O2hsgg_RiqXk9uRVAvMQnJVg@mail.gmail.com>
 <CA+mcf=v8fOufD6xxvJEmmY-DqX3TUUpwbs5JgNX6jrUqZcNuxw@mail.gmail.com>
Message-ID: <f0b36ac4-ed8a-df13-f3fd-97d2b171f75d@gmail.com>

You have to put the the #!subst and listen after loading pv module.

Probably env and def variable should be relocated to core, not having
SIP/runtime dependency, to facilitate their use during start up.

Cheers,
Daniel

On 22.12.20 06:58, Syed Shahryar wrote:
> Any updates on this?
>
> On Tue, Dec 15, 2020 at 8:13 PM Syed Shahryar <syedshahryar at gmail.com
> <mailto:syedshahryar at gmail.com>> wrote:
>
>     I am new to Kamailio so may be doing something wrong. I looked
>     at?https://www.kamailio.org/wiki/cookbooks/5.4.x/core
>     <https://www.kamailio.org/wiki/cookbooks/5.4.x/core>.
>
>     I tried the following combinations but getting errors in all cases:
>
>     #!subst "/EVAPI_PORT/$env(EVAPI_PORT)/"
>     #!substdef "/EVAPI_PORT/$env(EVAPI_PORT)/"
>     #!substdefs "/EVAPI_PORT/$env(EVAPI_PORT)/"
>
>     *Errors:*
>     ?0(6) ERROR: <core> [core/pvapi.c:924]: pv_parse_spec2(): error
>     searching pvar "env"
>     ?0(6) ERROR: <core> [core/pvapi.c:1127]: pv_parse_spec2(): wrong
>     char [E/69] in [$env(EVAPI_PORT)/] at [5 (5)]
>     ?0(6) ERROR: <core> [core/re.c:170]: parse_repl(): bad specifier
>     in replace part /$env(EVAPI_PORT)/
>     ?0(6) ERROR: <core> [core/ppcfg.c:69]: pp_subst_add(): bad subst
>     expression: /EVAPI_PORT/$env(EVAPI_PORT)/
>
>     At a later step, I would like to do:
>     #!define EVAPI_LISTEN "0.0.0.0:EVAPI_PORT"
>
>     And use EVAP_LISTEN in mod_param for the evapi module.
>
>     And something similar to above for TLS settings.
>
>
>     On Tue, Dec 15, 2020 at 12:41 PM Daniel-Constantin Mierla
>     <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>         Hello,
>
>         as written on the tracker, look at using #!subst or #!substdef
>         (see core cookbook), they should be able to get the
>         substitution value from environment using $env(NAME).
>
>         The master branch introduced #!defenv as a (simpler) alternative.
>
>         Cheers,
>         Daniel
>
>         On 12.12.20 05:33, Syed Shahryar wrote:
>>         I tried many combinations of the following but I keep getting
>>         syntax errors:
>>
>>         listen=tls:TLS_IP:$env(TLS_PORT) advertise
>>         PUBLIC_IP:$env(TLS_PORT)
>>
>>
>>         TLS_IP and?PUBLIC_IP are constants defined at the top using
>>         #!define. And,?TLS_PORT is supposed to be the env variable.
>>
>>
>>         -- 
>>         --
>>         This message contains confidential information and is
>>         intended only for the individual named. If you are not the
>>         named addressee, you should not disseminate, distribute or
>>         copy this email. Please notify the sender immediately by
>>         email if you have received this email by mistake and delete
>>         this email from your system. Email transmission cannot be
>>         guaranteed to be secure or error-free, as information could
>>         be intercepted, corrupted, lost, destroyed, arrive late or
>>         incomplete, or contain viruses. The sender, therefore, does
>>         not accept liability for any errors or omissions in the
>>         contents of this message which arise as a result of email
>>         transmission. If verification is required, please request a
>>         hard-copy version.
>>
>>         _______________________________________________
>>         Kamailio (SER) - Users Mailing List
>>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>         -- 
>         Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>         www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>         Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
>
>
>
>     -- 
>     --
>     This message contains confidential information and is intended
>     only for the individual named. If you are not the named addressee,
>     you should not disseminate, distribute or copy this email. Please
>     notify the sender immediately by email if you have received this
>     email by mistake and delete this email from your system. Email
>     transmission cannot be guaranteed to be secure or error-free, as
>     information could be intercepted, corrupted, lost, destroyed,
>     arrive late or incomplete, or contain viruses. The sender,
>     therefore, does not accept liability for any errors or omissions
>     in the contents of this message which arise as a result of email
>     transmission. If verification is required, please request a
>     hard-copy version.
>
>
>
> -- 
> --
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee, you
> should not disseminate, distribute or copy this email. Please notify
> the sender immediately by email if you have received this email by
> mistake and delete this email from your system. Email transmission
> cannot be guaranteed to be secure or error-free, as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
> or contain viruses. The sender, therefore, does not accept liability
> for any errors or omissions in the contents of this message which
> arise as a result of email transmission. If verification is required,
> please request a hard-copy version.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/ea1fb029/attachment.htm>

From jv at voiper.es  Tue Dec 22 16:16:07 2020
From: jv at voiper.es (Javier Valencia)
Date: Tue, 22 Dec 2020 16:16:07 +0100
Subject: [SR-Users] uac.reg_refresh command
Message-ID: <7ce008ee-101e-f53d-be52-bf6a0a39f783@voiper.es>

Hello,

I'm playing with RPC on my Kamailio 4.4.7, and I getting rare behaivor 
with *uac.reg_refresh* command.

When I run it thru kamcmd like docs describes, this is without *l_uuid* 
parameter, I'm geting "*error: 500 - Invalid Parameters*" output. And 
when I run with *l_uuid* parameter, I get no output. But in both cases, 
Kamalio don't refresh data from DB.

But I run this command thru HTTP (JSONRPC-S), both call modes are 
equivalent. With or without l_uuid parameter geting no output and 
refresh data from DB.

It's a normal behaivor?

Regards, JV


-- 
Logo <http://www.voiper.es/>

	
Javier Valencia | CTO
Centro de Negocios Mart?n Buend?a
Camino de las Ca?adas, n? 1C, Portal 1, 2?G
29649 Mijas (M?laga)

# 	951562080 (T) <tel:951562080> | 687486759 (M) <tel:687486759>
# 	www.voiper.es <http://www.voiper.es/>

------------------------------------------------------------------------

AVISO LEGAL
-----------

Este mensaje contiene informaci?n confidencial destinada para ser le?da
exclusivamente por el destinatario. Queda prohibida la reproducci?n,
publicaci?n, divulgaci?n, total o parcial del mensaje as? como el uso no
autorizados por el emisor. En caso de recibir el mensaje por error, se ruega
su comunicaci?n al remitente lo antes posible. Por favor, indique
inmediatamente si usted o su empresa no aceptan comunicaciones de este tipo
por Internet.

Las opiniones, conclusiones y dem?s informaci?n incluida en este mensaje que
no est? relacionada con asuntos profesionales de SMART RECARGAS, S.L, se
entender? que nunca se ha dado, ni est? respaldado por el mismo.

Responsable del Tratamiento de Datos
------------------------------------
SMART RECARGAS , SL
Camino de las Ca?adas, 1C PORTAL 1 2? G
29651 MIJAS COSTA (MALAGA)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/a5df1d3d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pnajlcheljfdnplm.png
Type: image/png
Size: 7800 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/a5df1d3d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mgpmecmcmklhbbmd.png
Type: image/png
Size: 334 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/a5df1d3d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfonakepkffflccb.png
Type: image/png
Size: 453 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/a5df1d3d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jv.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/a5df1d3d/attachment.vcf>

From jv at voiper.es  Tue Dec 22 16:34:15 2020
From: jv at voiper.es (Javier Valencia)
Date: Tue, 22 Dec 2020 16:34:15 +0100
Subject: [SR-Users] Unload UAC remote registry
Message-ID: <9eed44fd-74b1-d151-4fa8-ec3b73e9878f@voiper.es>

Hello,

I'm on Kamailio 4.4.7 and I'm trying to do uac.reg_refresh over a row 
non existing on DB to try to unload, but data still persist on Kamailio.

How to unload only one registry from UACs remote registrations when 
delete a record from DB without do a uac.reg_reload?

UAC remote registrations is above 2k rows, I don't know if it's much or not.

Regards, JV


-- 
Logo <http://www.voiper.es/>

	
Javier Valencia | CTO
Centro de Negocios Mart?n Buend?a
Camino de las Ca?adas, n? 1C, Portal 1, 2?G
29649 Mijas (M?laga)

# 	951562080 (T) <tel:951562080> | 687486759 (M) <tel:687486759>
# 	www.voiper.es <http://www.voiper.es/>

------------------------------------------------------------------------

AVISO LEGAL
-----------

Este mensaje contiene informaci?n confidencial destinada para ser le?da
exclusivamente por el destinatario. Queda prohibida la reproducci?n,
publicaci?n, divulgaci?n, total o parcial del mensaje as? como el uso no
autorizados por el emisor. En caso de recibir el mensaje por error, se ruega
su comunicaci?n al remitente lo antes posible. Por favor, indique
inmediatamente si usted o su empresa no aceptan comunicaciones de este tipo
por Internet.

Las opiniones, conclusiones y dem?s informaci?n incluida en este mensaje que
no est? relacionada con asuntos profesionales de SMART RECARGAS, S.L, se
entender? que nunca se ha dado, ni est? respaldado por el mismo.

Responsable del Tratamiento de Datos
------------------------------------
SMART RECARGAS , SL
Camino de las Ca?adas, 1C PORTAL 1 2? G
29651 MIJAS COSTA (MALAGA)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/4674f918/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kbekhpmlkhceidnp.png
Type: image/png
Size: 7800 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/4674f918/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daijmglepokljpdj.png
Type: image/png
Size: 334 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/4674f918/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddfhgjokkgpndgkm.png
Type: image/png
Size: 453 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/4674f918/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jv.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/4674f918/attachment.vcf>

From syedshahryar at gmail.com  Tue Dec 22 18:07:04 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Tue, 22 Dec 2020 12:07:04 -0500
Subject: [SR-Users] How to use port number using $env in listen
In-Reply-To: <f0b36ac4-ed8a-df13-f3fd-97d2b171f75d@gmail.com>
References: <CA+mcf=u8Sn8Yq=U8FLKAzoMs+kLmy1-GabpMOatFx2MUaw6ESA@mail.gmail.com>
 <75dbba1f-cba1-a440-1a14-168cc15d8ca5@gmail.com>
 <CA+mcf=vLp1gBgikgpCWu8uVNb0O2hsgg_RiqXk9uRVAvMQnJVg@mail.gmail.com>
 <CA+mcf=v8fOufD6xxvJEmmY-DqX3TUUpwbs5JgNX6jrUqZcNuxw@mail.gmail.com>
 <f0b36ac4-ed8a-df13-f3fd-97d2b171f75d@gmail.com>
Message-ID: <CA+mcf=uekkEigPN2fe5w-47R5wpYJ+1LSR3UiswNmuGpGSzQrQ@mail.gmail.com>

I ran different combinations of the following simple configuration file but
still getting errors on 'listen':

#!KAMAILIO

loadmodule "pv.so"

#!define TLS_IP "0.0.0.0"

// #!define TLS_PORT $env(TLS_PORT)
//#!substdefs "/TLS_PORT/$env(TLS_PORT)/"
#!defenv TLS_PORT=TLS_PORT

#listen=udp:TLS_IP:TLS_PORT name "UDP_SOCKET"
listen=udp:TLS_IP:$env(TLS_PORT) name "UDP_SOCKET"


//// ERROR Lines ////

kamailio         |  0(6) CRITICAL: <core> [core/cfg.y:3588]: yyerror_at():
parse error in config file /usr/local/etc/kamailio/kamailio.test.cfg, line
11, column 19-26: syntax error

kamailio         |  0(6) CRITICAL: <core> [core/cfg.y:3588]: yyerror_at():
parse error in config file /usr/local/etc/kamailio/kamailio.test.cfg, line
11, column 19-26: ip address, interface name or hostname expected

kamailio         |  0(6) CRITICAL: <core> [core/cfg.y:3588]: yyerror_at():
parse error in config file /usr/local/etc/kamailio/kamailio.test.cfg, line
11, column 28-31:

kamailio         | ERROR: bad config file (3 errors)



>> Probably env and def variable should be relocated to core, not having
SIP/runtime dependency, to facilitate their use during start up.
Good idea!


On Tue, Dec 22, 2020 at 3:59 AM Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> You have to put the the #!subst and listen after loading pv module.
>
> Probably env and def variable should be relocated to core, not having
> SIP/runtime dependency, to facilitate their use during start up.
>
> Cheers,
> Daniel
>
> On 22.12.20 06:58, Syed Shahryar wrote:
>
> Any updates on this?
>
> On Tue, Dec 15, 2020 at 8:13 PM Syed Shahryar <syedshahryar at gmail.com>
> wrote:
>
>> I am new to Kamailio so may be doing something wrong. I looked at
>> https://www.kamailio.org/wiki/cookbooks/5.4.x/core.
>>
>> I tried the following combinations but getting errors in all cases:
>>
>> #!subst "/EVAPI_PORT/$env(EVAPI_PORT)/"
>> #!substdef "/EVAPI_PORT/$env(EVAPI_PORT)/"
>> #!substdefs "/EVAPI_PORT/$env(EVAPI_PORT)/"
>>
>> *Errors:*
>>  0(6) ERROR: <core> [core/pvapi.c:924]: pv_parse_spec2(): error searching
>> pvar "env"
>>  0(6) ERROR: <core> [core/pvapi.c:1127]: pv_parse_spec2(): wrong char
>> [E/69] in [$env(EVAPI_PORT)/] at [5 (5)]
>>  0(6) ERROR: <core> [core/re.c:170]: parse_repl(): bad specifier in
>> replace part /$env(EVAPI_PORT)/
>>  0(6) ERROR: <core> [core/ppcfg.c:69]: pp_subst_add(): bad subst
>> expression: /EVAPI_PORT/$env(EVAPI_PORT)/
>>
>> At a later step, I would like to do:
>> #!define EVAPI_LISTEN "0.0.0.0:EVAPI_PORT"
>>
>> And use EVAP_LISTEN in mod_param for the evapi module.
>>
>> And something similar to above for TLS settings.
>>
>>
>> On Tue, Dec 15, 2020 at 12:41 PM Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> as written on the tracker, look at using #!subst or #!substdef (see core
>>> cookbook), they should be able to get the substitution value from
>>> environment using $env(NAME).
>>>
>>> The master branch introduced #!defenv as a (simpler) alternative.
>>>
>>> Cheers,
>>> Daniel
>>> On 12.12.20 05:33, Syed Shahryar wrote:
>>>
>>> I tried many combinations of the following but I keep getting syntax
>>> errors:
>>>
>>> listen=tls:TLS_IP:$env(TLS_PORT) advertise PUBLIC_IP:$env(TLS_PORT)
>>>
>>>
>>> TLS_IP and PUBLIC_IP are constants defined at the top using #!define.
>>> And, TLS_PORT is supposed to be the env variable.
>>>
>>>
>>> --
>>> --
>>> This message contains confidential information and is intended only for
>>> the individual named. If you are not the named addressee, you should not
>>> disseminate, distribute or copy this email. Please notify the sender
>>> immediately by email if you have received this email by mistake and delete
>>> this email from your system. Email transmission cannot be guaranteed to be
>>> secure or error-free, as information could be intercepted, corrupted, lost,
>>> destroyed, arrive late or incomplete, or contain viruses. The sender,
>>> therefore, does not accept liability for any errors or omissions in the
>>> contents of this message which arise as a result of email transmission. If
>>> verification is required, please request a hard-copy version.
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> --
>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Funding: https://www.paypal.me/dcmierla
>>>
>>>
>>
>> --
>> --
>> This message contains confidential information and is intended only for
>> the individual named. If you are not the named addressee, you should not
>> disseminate, distribute or copy this email. Please notify the sender
>> immediately by email if you have received this email by mistake and delete
>> this email from your system. Email transmission cannot be guaranteed to be
>> secure or error-free, as information could be intercepted, corrupted, lost,
>> destroyed, arrive late or incomplete, or contain viruses. The sender,
>> therefore, does not accept liability for any errors or omissions in the
>> contents of this message which arise as a result of email transmission. If
>> verification is required, please request a hard-copy version.
>>
>
>
> --
> --
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee, you should not
> disseminate, distribute or copy this email. Please notify the sender
> immediately by email if you have received this email by mistake and delete
> this email from your system. Email transmission cannot be guaranteed to be
> secure or error-free, as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender,
> therefore, does not accept liability for any errors or omissions in the
> contents of this message which arise as a result of email transmission. If
> verification is required, please request a hard-copy version.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>

-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201222/11a5b041/attachment.htm>

From jv at voiper.es  Wed Dec 23 11:54:07 2020
From: jv at voiper.es (Javier Valencia)
Date: Wed, 23 Dec 2020 11:54:07 +0100
Subject: [SR-Users] UAC module registrations interval
Message-ID: <c0eebf0b-5eaa-0d6b-de12-ca8fb0ddbdc3@voiper.es>

Hi there,

I'm using Kamailio 4.4.7 with UAC remote registrations module.

In my database have all rows with expires column value's 3600, and my 
PBX (asterisk) min, max and default expires to 3600. But I can see how 
Kamailio it's sending REGISTER each 150segs.

UAC module parameters values;

modparam("uac", "reg_db_url", "mysql://XXX")
modparam("uac", "reg_db_table", "uacreg")
modparam("uac", "reg_contact_addr", "XXX")
modparam("uac", "reg_timer_interval", 5)
modparam("uac", "reg_retry_interval", 60)

My uacreg table it's above 2k rows.

Regards, JV


-- 
Logo <http://www.voiper.es/>

	
Javier Valencia | CTO
Centro de Negocios Mart?n Buend?a
Camino de las Ca?adas, n? 1C, Portal 1, 2?G
29649 Mijas (M?laga)

# 	951562080 (T) <tel:951562080> | 687486759 (M) <tel:687486759>
# 	www.voiper.es <http://www.voiper.es/>

------------------------------------------------------------------------

AVISO LEGAL
-----------

Este mensaje contiene informaci?n confidencial destinada para ser le?da
exclusivamente por el destinatario. Queda prohibida la reproducci?n,
publicaci?n, divulgaci?n, total o parcial del mensaje as? como el uso no
autorizados por el emisor. En caso de recibir el mensaje por error, se ruega
su comunicaci?n al remitente lo antes posible. Por favor, indique
inmediatamente si usted o su empresa no aceptan comunicaciones de este tipo
por Internet.

Las opiniones, conclusiones y dem?s informaci?n incluida en este mensaje que
no est? relacionada con asuntos profesionales de SMART RECARGAS, S.L, se
entender? que nunca se ha dado, ni est? respaldado por el mismo.

Responsable del Tratamiento de Datos
------------------------------------
SMART RECARGAS , SL
Camino de las Ca?adas, 1C PORTAL 1 2? G
29651 MIJAS COSTA (MALAGA)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/f91896d8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bphoacepadfekcpd.png
Type: image/png
Size: 7800 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/f91896d8/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kjpjgcgchgibdpfn.png
Type: image/png
Size: 334 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/f91896d8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jjmbjnjodfgkcfab.png
Type: image/png
Size: 453 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/f91896d8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jv.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/f91896d8/attachment.vcf>

From eschmidbauer at gmail.com  Wed Dec 23 15:26:18 2020
From: eschmidbauer at gmail.com (E. Schmidbauer)
Date: Wed, 23 Dec 2020 07:26:18 -0700
Subject: [SR-Users] Unload UAC remote registry
In-Reply-To: <9eed44fd-74b1-d151-4fa8-ec3b73e9878f@voiper.es>
References: <9eed44fd-74b1-d151-4fa8-ec3b73e9878f@voiper.es>
Message-ID: <CAJwe+CCYv2JHB9jR=-gSwnVV83rsJY5dP+VpkE+Gnk7XaCC77g@mail.gmail.com>

You could use RPC.
I built a wrapper service for RPC which exposes REST endpoints. Take a look
here:
 https://github.com/voipxswitch/kamailio-jsonrpc-client

On Tue, Dec 22, 2020, 8:34 AM Javier Valencia <jv at voiper.es> wrote:

> Hello,
>
> I'm on Kamailio 4.4.7 and I'm trying to do uac.reg_refresh over a row non
> existing on DB to try to unload, but data still persist on Kamailio.
>
> How to unload only one registry from UACs remote registrations when delete
> a record from DB without do a uac.reg_reload?
>
> UAC remote registrations is above 2k rows, I don't know if it's much or
> not.
>
> Regards, JV
>
>
> --
> [image: Logo] <http://www.voiper.es/>
> Javier Valencia | CTO
> Centro de Negocios Mart?n Buend?a
> Camino de las Ca?adas, n? 1C, Portal 1, 2?G
> 29649 Mijas (M?laga)
> [image: #] 951562080 (T) <951562080> | 687486759 (M) <687486759>
> [image: #] www.voiper.es
> ------------------------------
>
> AVISO LEGAL
> -----------
>
> Este mensaje contiene informaci?n confidencial destinada para ser le?da
> exclusivamente por el destinatario. Queda prohibida la reproducci?n,
> publicaci?n, divulgaci?n, total o parcial del mensaje as? como el uso no
> autorizados por el emisor. En caso de recibir el mensaje por error, se ruega
> su comunicaci?n al remitente lo antes posible. Por favor, indique
> inmediatamente si usted o su empresa no aceptan comunicaciones de este tipo
> por Internet.
>
> Las opiniones, conclusiones y dem?s informaci?n incluida en este mensaje que
> no est? relacionada con asuntos profesionales de SMART RECARGAS, S.L, se
> entender? que nunca se ha dado, ni est? respaldado por el mismo.
>
> Responsable del Tratamiento de Datos
> ------------------------------------
> SMART RECARGAS , SL
> Camino de las Ca?adas, 1C PORTAL 1 2? G
> 29651 MIJAS COSTA (MALAGA)
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/0f6d4465/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kbekhpmlkhceidnp.png
Type: image/png
Size: 7800 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/0f6d4465/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daijmglepokljpdj.png
Type: image/png
Size: 334 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/0f6d4465/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddfhgjokkgpndgkm.png
Type: image/png
Size: 453 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/0f6d4465/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kbekhpmlkhceidnp.png
Type: image/png
Size: 7800 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201223/0f6d4465/attachment-0003.png>

From fred at palner.com  Wed Dec 23 16:20:23 2020
From: fred at palner.com (Fred Posner)
Date: Wed, 23 Dec 2020 10:20:23 -0500
Subject: [SR-Users] MID-Registrar Example
In-Reply-To: <1608582343976-0.post@n5.nabble.com>
References: <1608259112948-0.post@n5.nabble.com>
 <db567cdd-4c66-f2bd-d528-b5d5a1aaf49a@evaristesys.com>
 <CAJwe+CBQqv8ai+kc8qLu80oSHO+rXZZFydJe6HiStp_LgLYJSw@mail.gmail.com>
 <b023a785-ea2b-b1ce-daba-9378d5e969f2@evaristesys.com>
 <cd5fba24-99fd-0173-6c85-fa2db4d648fd@gmail.com>
 <1608582343976-0.post@n5.nabble.com>
Message-ID: <563ce782-4968-3491-d0e9-3377363eabdd@palner.com>

On 12/21/20 3:25 PM, moisesynfante wrote:
> Thank you for your answer. 
> 
> I'm going for the second scenario. I will try the solutions provided in the
> links and let you know if I made it work!
> 

I posted an example built off the edge proxy config. Remember, many ways
to approach this and many things to consider for security before going
to a prod environment.

This would be an example of a simple pass-through and then keeping regs
to the kamailio at 60 sec while keeping the pass-through to the
registrar at an hour (or what they provide as an expire).

https://github.com/fredposner/scripts/blob/master/kamailio/mid-registrar.cfg

-- fred

Fred Posner
fred at palner.com
https://www.palner.com


From fosdem-rtc-admin at freertc.org  Wed Dec 23 20:53:35 2020
From: fosdem-rtc-admin at freertc.org (FOSDEM RTC Team)
Date: Wed, 23 Dec 2020 20:53:35 +0100 (CET)
Subject: [SR-Users] Fwd: [CFP] FOSDEM 2021, RTC devroom, speakers,
 volunteers neeeded
References: <8a889518-4558-11eb-8a0e-7b0d1f2b0241@freertc.org>
Message-ID: <20201223195335.1AFCC18046D2@ws3.office.readytechnology.co.uk>

FOSDEM - Real Time Communications devroom CfP
=============================================

NOTE: we have extended the deadline but we will give preference
to people who submitted earlier when we set the time for each
talk.  Please submit your proposal ASAP so that you can get
your preferred time slot.

Overview
--------

[FOSDEM](https://fosdem.org) is one of the world's premier meetings of
free software developers, with over five thousand people attending each
year. FOSDEM 2021 takes place 6-7 February 2021 and for the very first
time, it will be online.

This document contains information about:

-   Real-Time Communications developer room (devroom)
-   speaking opportunities
-   volunteering

New rules for the online edition
--------------------------------

This year FOSDEM will be fully online instead of being held in Brussels,
here are the most important things to know about this (quite
significant) change:

-   The reference time will be Brussels local time (CET)
-   Talks will be pre-recorded in advance, and streamed during the event
-   The Q/A session will be live
-   A facility will be provided for people watching to chat between
    themselves
-   A facility will be provided for people watching to submit questions

Call for participation - Real Time Communications (RTC)
-------------------------------------------------------

The Real-Time devroom is about all things involving real-time
communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP,
codecs, peer-to-peer, privacy and encryption.

**We are looking for speakers for the devroom and volunteers who can
help manage the scheduling and live Q&A sessions.**

The devroom is only on Saturday, 6th of February 2021.

To discuss the devroom, volunteer or ask questions, please join the
[Free-RTC mailing
list](http://lists.freertc.org/mailman/listinfo/discuss).

### Key dates

-   20th Dec: Submission deadline (extended to 8 January)
-   24th Dec: Announcement of selected talks
-   15th Jan: Presentations upload deadline
-   6th & 7th Feb: Conference dates (online)
-   6th Feb: RTC devroom date (online)

### Speaking opportunities

Note: if you used FOSDEM Pentabarf before, please use the same
account/username

Real-Time Communications devroom: deadline 23:59 UTC on 20th of
December. Please use the
[Pentabarf](https://penta.fosdem.org/submission/FOSDEM21/) system to
submit a talk proposal for the devroom. On the "General" tab, please
look for the "Track" option and choose "Real Time Communications
devroom".

### First-time speaking?

FOSDEM devrooms are a welcoming environment for people who have never
given a talk before. Please feel free to contact the devroom
administrators personally if you would like to ask any questions about
it.

This year this is more true than ever, being able to record your
presentation offline without an audience in front can greatly help build
up one's confidence!

### Submission guidelines

The Pentabarf system will ask for many of the essential details. Please
remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:

-   The purpose of your talk
-   Any other talk applications (devrooms, lightning talks, main track)
-   Availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the URL of a
feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and devroom themes,
presentations aimed at developers of free and open source software about
RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
devroom administrators based on the number of received proposals. As the
two previous devrooms have been combined into one, we may decide to give
shorter slots than in previous years so that more speakers can
participate.

Please note FOSDEM aims to record and live-stream all talks. The CC-BY
license is used.

### Recording help

The devroom organization is able to provide help with recording your
session. The recording would be performed at a scheduled time with one
of us, so you won't be alone giving your presentation. Minimal edits
will be possible, but the ideal plan is to record it in one shot.

Thanks Dan Jenkins for providing us with the means to do this!

Volunteers needed
-----------------

To make the devroom run successfully, we are looking for volunteers.
This year many things be done for the first time, so all the help we can
get is more than welcome.

Spread the word and discuss
---------------------------

If you know of any mailing lists where this CfP would be relevant,
please forward this document. If this devroom excites you, please blog
or microblog about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:

-   All projects https://planet.freertc.org planet at freertc.org
-   XMPP https://planet.jabber.org ralphm at ik.nu
-   SIP https://planet.sip5060.net planet at sip5060.net

Please also link to the Planet sites from your own blog or web site as
this helps everybody in the free real-time communications community.

Contact
-------

For any private queries, contact us directly using the address
**fosdem-rtc-admin at freertc.org** and for any other queries please ask on
the [Free-RTC mailing
list](http://lists.freertc.org/mailman/listinfo/discuss).

The devroom administration team:

-   Sa?l Ibarra Corretg? <s at saghul.net>
-   Ralph Meijer <ralphm at ik.nu>
-   Daniel-Constantin Mierla <miconda at gmail.com>
-   Daniel Pocock <daniel at pocock.pro>
-   Guus der Kinderen <guus.der.kinderen at gmail.com>



From miconda at gmail.com  Thu Dec 24 19:08:52 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 24 Dec 2020 19:08:52 +0100
Subject: [SR-Users] Merry Christmas and Happy Holidays!
Message-ID: <71ac0e84-a7c0-5242-013c-b9f16324a606@gmail.com>

A year that was very tough for the entire world is getting close to its
end, no doubt that was the most challenging in our life so far for many
of us, however, with a distributed, friendly and collaborative
community, Kamailio project continued to develop consistently, bringing
out a new major release. I trust it helped people and companies world
wide to to connect with the dear ones and build a better way of living.

The season holidays are ahead, time to rest a bit, spend time with
family and friends, being online or face to face.? As usual, I take this
chance to express my thanks and greetings to all the friends,
developers, supporting companies and community members that made 2020
another great year for Kamailio project.


Enjoy the holidays! Merry Christmas!

Daniel

* Santa is flying Kamailio! *

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda



From federico.cabiddu at gmail.com  Fri Dec 25 20:44:11 2020
From: federico.cabiddu at gmail.com (Federico Cabiddu)
Date: Fri, 25 Dec 2020 20:44:11 +0100
Subject: [SR-Users] [sr-dev] Merry Christmas and Happy Holidays!
In-Reply-To: <71ac0e84-a7c0-5242-013c-b9f16324a606@gmail.com>
References: <71ac0e84-a7c0-5242-013c-b9f16324a606@gmail.com>
Message-ID: <CAFOaF_j8z1w6bPAaXSwkn3=9A0-vzUr1d-vYQ0dp5jwXAdEiRg@mail.gmail.com>

Merry Christmas to all this beautiful community.
And best wishes for 2021!

Federico

On Thu, 24 Dec 2020, 19:09 Daniel-Constantin Mierla, <miconda at gmail.com>
wrote:

> A year that was very tough for the entire world is getting close to its
> end, no doubt that was the most challenging in our life so far for many
> of us, however, with a distributed, friendly and collaborative
> community, Kamailio project continued to develop consistently, bringing
> out a new major release. I trust it helped people and companies world
> wide to to connect with the dear ones and build a better way of living.
>
> The season holidays are ahead, time to rest a bit, spend time with
> family and friends, being online or face to face.  As usual, I take this
> chance to express my thanks and greetings to all the friends,
> developers, supporting companies and community members that made 2020
> another great year for Kamailio project.
>
>
> Enjoy the holidays! Merry Christmas!
>
> Daniel
>
> * Santa is flying Kamailio! *
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>
>
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> sr-dev at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201225/f5396521/attachment.htm>

From david.villasmil.work at gmail.com  Fri Dec 25 22:14:39 2020
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Fri, 25 Dec 2020 22:14:39 +0100
Subject: [SR-Users] [sr-dev] Merry Christmas and Happy Holidays!
In-Reply-To: <CAFOaF_j8z1w6bPAaXSwkn3=9A0-vzUr1d-vYQ0dp5jwXAdEiRg@mail.gmail.com>
References: <71ac0e84-a7c0-5242-013c-b9f16324a606@gmail.com>
 <CAFOaF_j8z1w6bPAaXSwkn3=9A0-vzUr1d-vYQ0dp5jwXAdEiRg@mail.gmail.com>
Message-ID: <CAFGRPVrO4roJm59=dDob3xZhZacz=qhsdN52G-fchyr+t0S2Vg@mail.gmail.com>

Merry Christmas (or whatever you celebrate) to everyone!

On Fri, 25 Dec 2020 at 20:44, Federico Cabiddu <federico.cabiddu at gmail.com>
wrote:

> Merry Christmas to all this beautiful community.
> And best wishes for 2021!
>
> Federico
>
> On Thu, 24 Dec 2020, 19:09 Daniel-Constantin Mierla, <miconda at gmail.com>
> wrote:
>
>> A year that was very tough for the entire world is getting close to its
>> end, no doubt that was the most challenging in our life so far for many
>> of us, however, with a distributed, friendly and collaborative
>> community, Kamailio project continued to develop consistently, bringing
>> out a new major release. I trust it helped people and companies world
>> wide to to connect with the dear ones and build a better way of living.
>>
>> The season holidays are ahead, time to rest a bit, spend time with
>> family and friends, being online or face to face.  As usual, I take this
>> chance to express my thanks and greetings to all the friends,
>> developers, supporting companies and community members that made 2020
>> another great year for Kamailio project.
>>
>>
>> Enjoy the holidays! Merry Christmas!
>>
>> Daniel
>>
>> * Santa is flying Kamailio! *
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> sr-dev at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> sr-dev at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201225/9d1d690f/attachment.htm>

From syedshahryar at gmail.com  Fri Dec 25 22:46:54 2020
From: syedshahryar at gmail.com (Syed Shahryar)
Date: Fri, 25 Dec 2020 16:46:54 -0500
Subject: [SR-Users] how does rtjson work?
Message-ID: <CA+mcf=s1jjWbbT2h9kCuz3vDMAJns82W2RCoY=Zhy3teMwm7AQ@mail.gmail.com>

My use case is such that I want to be able to send a SIP MESSAGE destined
for a single username to multiple users. In order to be able to map that
target username to multiple usernames, I tried using rtjson and evapi/http
(to generate the routing json), but none of them worked.

Is it the right approach? Is there any other way to programmatically
generate multiple targets for SIP request? I am familiar with dynamic
routing but I need more flexibility.

Initially, I tried sending the request to a different username but that
didn't work and got the following message in the http async result route.

kamailio    | 19(25) ERROR: nathelper [nathelper.c:1461]: sdp_1918():
Unable to parse sdp body
kamailio    | 19(25) NOTICE: <core> [core/kemi.c:124]:
sr_kemi_core_notice(): In evapi msg branch
kamailio    | 28(34) NOTICE: {2 6661 MESSAGE q6hikd6tumsr1dh35kvj} <core>
[core/kemi.c:124]: sr_kemi_core_notice(): In evapi reply branch

The message was received on the originally requested to user and also $tu still
points to the original user instead of the new user even after executing
the following code.

KSR.rtjson.init_routes(response);
KSR.rtjson.push_routes();
KSR.nathelper.fix_nated_contact();

In http response, I receive the following and don't see any rtjson errors
when init_routes is executed on it.

{"version":"1.0","routing":"parallel","routes":[{"headers":{"from":{"display":"test_1","uri":"sip:
*test_1*@test.com:9908"},"to":{"display":"test_4","uri":"sip:*test_4*@
test.com:9908
"},"extra":""},"branch_flags":8,"fr_timer":5000,"fr_inv_timer":30000}]}

Please note that the request was sent to *test_2*@test.com. I have tried
other combinations of above but nothing works.

I have already searched on Google and read relevant articles and blog
posts.

Thanks
-- 
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by email if you have received this email by mistake and delete
this email from your system. Email transmission cannot be guaranteed to be
secure or error-free, as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission. If
verification is required, please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201225/3dfe14fb/attachment.htm>

From rob.van.den.bulk at gmail.com  Sat Dec 26 19:49:42 2020
From: rob.van.den.bulk at gmail.com (rob.van.den.bulk at gmail.com)
Date: Sat, 26 Dec 2020 19:49:42 +0100
Subject: [SR-Users] app_lua
Message-ID: <001c01d6dbb7$dfe986d0$9fbc9470$@gmail.com>

Hallo, 

 

I try to install the module app_lua in Kamailio 5.3.

 

ls: cannot access '/usr/lib/liblua*': No such file or directory

ls: cannot access '/usr/lib/liblua*': No such file or directory

CC (gcc) [M app_lua.so]         app_lua_mod.o

In file included from app_lua_mod.c:32:

app_lua_api.h:25:10: fatal error: lua.h: No such file or directory

#include <lua.h>

          ^~~~~~~

compilation terminated.

make[2]: *** [../../Makefile.rules:100: app_lua_mod.o] Error 1

make[1]: *** [Makefile:511: modules] Error 1

make[1]: Leaving directory '/usr/local/src/kamailio-5.3/kamailio/src'

make: *** [Makefile:34: all] Error 2

 

Any help appreciated

 

Greeting Rob van den Bulk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201226/2789b577/attachment.htm>

From abalashov at evaristesys.com  Sat Dec 26 19:57:01 2020
From: abalashov at evaristesys.com (Alex Balashov)
Date: Sat, 26 Dec 2020 13:57:01 -0500
Subject: [SR-Users] app_lua
In-Reply-To: <001c01d6dbb7$dfe986d0$9fbc9470$@gmail.com>
References: <001c01d6dbb7$dfe986d0$9fbc9470$@gmail.com>
Message-ID: <A3016FF3-456D-4D5F-9D3B-FFED8AA046DC@evaristesys.com>

It sounds like you need to install the Lua development package / headers.

?
Sent from mobile, with due apologies for brevity and errors.

> On Dec 26, 2020, at 1:50 PM, rob.van.den.bulk at gmail.com wrote:
> 
> ?
> Hallo,
>  
> I try to install the module app_lua in Kamailio 5.3.
>  
> ls: cannot access '/usr/lib/liblua*': No such file or directory
> ls: cannot access '/usr/lib/liblua*': No such file or directory
> CC (gcc) [M app_lua.so]         app_lua_mod.o
> In file included from app_lua_mod.c:32:
> app_lua_api.h:25:10: fatal error: lua.h: No such file or directory
> #include <lua.h>
>           ^~~~~~~
> compilation terminated.
> make[2]: *** [../../Makefile.rules:100: app_lua_mod.o] Error 1
> make[1]: *** [Makefile:511: modules] Error 1
> make[1]: Leaving directory '/usr/local/src/kamailio-5.3/kamailio/src'
> make: *** [Makefile:34: all] Error 2
>  
> Any help appreciated
>  
> Greeting Rob van den Bulk
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201226/65ee126b/attachment.htm>

From rob.van.den.bulk at gmail.com  Sat Dec 26 20:30:17 2020
From: rob.van.den.bulk at gmail.com (rob.van.den.bulk at gmail.com)
Date: Sat, 26 Dec 2020 20:30:17 +0100
Subject: [SR-Users] app_lua
In-Reply-To: <A3016FF3-456D-4D5F-9D3B-FFED8AA046DC@evaristesys.com>
References: <001c01d6dbb7$dfe986d0$9fbc9470$@gmail.com>
 <A3016FF3-456D-4D5F-9D3B-FFED8AA046DC@evaristesys.com>
Message-ID: <003d01d6dbbd$8af4cfd0$a0de6f70$@gmail.com>

I check

 

Cheers

 

Van: sr-users <sr-users-bounces at lists.kamailio.org> Namens Alex Balashov
Verzonden: zaterdag 26 december 2020 19:57
Aan: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Onderwerp: Re: [SR-Users] app_lua

 

It sounds like you need to install the Lua development package / headers.

?

Sent from mobile, with due apologies for brevity and errors.





On Dec 26, 2020, at 1:50 PM, rob.van.den.bulk at gmail.com <mailto:rob.van.den.bulk at gmail.com>  wrote:

?

Hallo, 

 

I try to install the module app_lua in Kamailio 5.3.

 

ls: cannot access '/usr/lib/liblua*': No such file or directory

ls: cannot access '/usr/lib/liblua*': No such file or directory

CC (gcc) [M app_lua.so]         app_lua_mod.o

In file included from app_lua_mod.c:32:

app_lua_api.h:25:10: fatal error: lua.h: No such file or directory

#include <lua.h>

          ^~~~~~~

compilation terminated.

make[2]: *** [../../Makefile.rules:100: app_lua_mod.o] Error 1

make[1]: *** [Makefile:511: modules] Error 1

make[1]: Leaving directory '/usr/local/src/kamailio-5.3/kamailio/src'

make: *** [Makefile:34: all] Error 2

 

Any help appreciated

 

Greeting Rob van den Bulk

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org> 
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201226/ebafe418/attachment.htm>

From rob.van.den.bulk at gmail.com  Sat Dec 26 21:53:41 2020
From: rob.van.den.bulk at gmail.com (rob.van.den.bulk at gmail.com)
Date: Sat, 26 Dec 2020 21:53:41 +0100
Subject: [SR-Users] app_lua
In-Reply-To: <A3016FF3-456D-4D5F-9D3B-FFED8AA046DC@evaristesys.com>
References: <001c01d6dbb7$dfe986d0$9fbc9470$@gmail.com>
 <A3016FF3-456D-4D5F-9D3B-FFED8AA046DC@evaristesys.com>
Message-ID: <004401d6dbc9$3188d9d0$949a8d70$@gmail.com>

Thanks

 

Works!

 

Cheers Rob.

 

 

Van: sr-users <sr-users-bounces at lists.kamailio.org> Namens Alex Balashov
Verzonden: zaterdag 26 december 2020 19:57
Aan: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Onderwerp: Re: [SR-Users] app_lua

 

It sounds like you need to install the Lua development package / headers.

?

Sent from mobile, with due apologies for brevity and errors.





On Dec 26, 2020, at 1:50 PM, rob.van.den.bulk at gmail.com <mailto:rob.van.den.bulk at gmail.com>  wrote:

?

Hallo, 

 

I try to install the module app_lua in Kamailio 5.3.

 

ls: cannot access '/usr/lib/liblua*': No such file or directory

ls: cannot access '/usr/lib/liblua*': No such file or directory

CC (gcc) [M app_lua.so]         app_lua_mod.o

In file included from app_lua_mod.c:32:

app_lua_api.h:25:10: fatal error: lua.h: No such file or directory

#include <lua.h>

          ^~~~~~~

compilation terminated.

make[2]: *** [../../Makefile.rules:100: app_lua_mod.o] Error 1

make[1]: *** [Makefile:511: modules] Error 1

make[1]: Leaving directory '/usr/local/src/kamailio-5.3/kamailio/src'

make: *** [Makefile:34: all] Error 2

 

Any help appreciated

 

Greeting Rob van den Bulk

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org> 
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201226/0fc17450/attachment.htm>

From hw at skalatan.de  Sat Dec 26 21:57:53 2020
From: hw at skalatan.de (Henning Westerholt)
Date: Sat, 26 Dec 2020 20:57:53 +0000
Subject: [SR-Users] [Kamailio-Business] Merry Christmas and Happy
 Holidays!
In-Reply-To: <71ac0e84-a7c0-5242-013c-b9f16324a606@gmail.com>
References: <71ac0e84-a7c0-5242-013c-b9f16324a606@gmail.com>
Message-ID: <AM0PR05MB659566AEFF9571192F400B62C5DB0@AM0PR05MB6595.eurprd05.prod.outlook.com>

Hello,

it was indeed an interesting year. Thank you all as well for the support in the last year.

I wish you Merry Christmas, happy holidays and a good start to 2021.

Henning


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


-----Original Message-----
From: business <business-bounces at lists.kamailio.org> On Behalf Of Daniel-Constantin Mierla
Sent: Thursday, December 24, 2020 7:09 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>; Kamailio (SER) - Devel Mailing List <sr-dev at lists.kamailio.org>; business at lists.kamailio.org
Subject: [Kamailio-Business] Merry Christmas and Happy Holidays!

A year that was very tough for the entire world is getting close to its end, no doubt that was the most challenging in our life so far for many of us, however, with a distributed, friendly and collaborative community, Kamailio project continued to develop consistently, bringing out a new major release. I trust it helped people and companies world wide to to connect with the dear ones and build a better way of living.

The season holidays are ahead, time to rest a bit, spend time with family and friends, being online or face to face.? As usual, I take this chance to express my thanks and greetings to all the friends, developers, supporting companies and community members that made 2020 another great year for Kamailio project.


Enjoy the holidays! Merry Christmas!

Daniel

* Santa is flying Kamailio! *

--
Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda


_______________________________________________
Kamailio (OpenSER) - business mailing list
business at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/business
http://lists.openser-project.org/cgi-bin/mailman/listinfo/business

From mihai at mokalife.ro  Sun Dec 27 13:18:49 2020
From: mihai at mokalife.ro (Mihai Cezar)
Date: Sun, 27 Dec 2020 14:18:49 +0200
Subject: [SR-Users] Read $fd from mysql?
Message-ID: <CANk_n4bcJVLs+q+A7+L72TXkJsQ_muOekHk2H8Sd+_NPebtsxQ@mail.gmail.com>

Hello,

I am redirecting the agents/reps to their asterisk server based on the
hostname which they connect, and, i wonder if it's possible to read from db
instead of the file cause it's getting big ;)

# Dispatch requests
route[DISPATCH] {
        switch ($fd){
                        case "oro.streamlinepbx.nl":
                                if (!ds_select_dst("1", "4")) {
                                        send_reply(503, "Service
Unavailable $fd");
                                        exit;
                                }
                                break;
                        case "oro3.streamlinepbx.nl":
                                if (!ds_select_dst("2", "4")) {
                                        send_reply(503, "Service
Unavailable $fd");
                                        exit;
                                }
                                break;
                      ............
                        default:
                            log("unknow destination?");
                            send_reply(503, "No service defined");
                            xlog("--- SCRIPT: going to <$ru> via <$du>
...Exiting");
                            exit;
                }

        xlog("--- SCRIPT: going to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");
        t_on_failure("RTF_DISPATCH");
        route(RELAY);
        exit;
}

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201227/0dd03835/attachment.htm>

From cezar at mokalife.ro  Sun Dec 27 13:19:33 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Sun, 27 Dec 2020 14:19:33 +0200
Subject: [SR-Users] [Kamailio-Business] Merry Christmas and Happy
 Holidays!
In-Reply-To: <AM0PR05MB659566AEFF9571192F400B62C5DB0@AM0PR05MB6595.eurprd05.prod.outlook.com>
References: <71ac0e84-a7c0-5242-013c-b9f16324a606@gmail.com>
 <AM0PR05MB659566AEFF9571192F400B62C5DB0@AM0PR05MB6595.eurprd05.prod.outlook.com>
Message-ID: <CANk_n4bgXwvB7teL-4zA6Bkgj+fQQFkwHTsYbQpaRaVpYmpmmw@mail.gmail.com>

Merry Christmas !

On Sat, Dec 26, 2020 at 10:59 PM Henning Westerholt <hw at skalatan.de> wrote:

> Hello,
>
> it was indeed an interesting year. Thank you all as well for the support
> in the last year.
>
> I wish you Merry Christmas, happy holidays and a good start to 2021.
>
> Henning
>
>
> --
> Henning Westerholt ? https://skalatan.de/blog/
> Kamailio services ? https://gilawa.com
>
>
> -----Original Message-----
> From: business <business-bounces at lists.kamailio.org> On Behalf Of
> Daniel-Constantin Mierla
> Sent: Thursday, December 24, 2020 7:09 PM
> To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>;
> Kamailio (SER) - Devel Mailing List <sr-dev at lists.kamailio.org>;
> business at lists.kamailio.org
> Subject: [Kamailio-Business] Merry Christmas and Happy Holidays!
>
> A year that was very tough for the entire world is getting close to its
> end, no doubt that was the most challenging in our life so far for many of
> us, however, with a distributed, friendly and collaborative community,
> Kamailio project continued to develop consistently, bringing out a new
> major release. I trust it helped people and companies world wide to to
> connect with the dear ones and build a better way of living.
>
> The season holidays are ahead, time to rest a bit, spend time with family
> and friends, being online or face to face.  As usual, I take this chance to
> express my thanks and greetings to all the friends, developers, supporting
> companies and community members that made 2020 another great year for
> Kamailio project.
>
>
> Enjoy the holidays! Merry Christmas!
>
> Daniel
>
> * Santa is flying Kamailio! *
>
> --
> Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda --
> www.linkedin.com/in/miconda
>
>
> _______________________________________________
> Kamailio (OpenSER) - business mailing list
> business at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/business
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/business
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201227/b07e7498/attachment.htm>

From ulus_egemen at hotmail.com  Sun Dec 27 13:29:41 2020
From: ulus_egemen at hotmail.com (egemen ulus)
Date: Sun, 27 Dec 2020 12:29:41 +0000
Subject: [SR-Users] Read $fd from mysql?
In-Reply-To: <CANk_n4bcJVLs+q+A7+L72TXkJsQ_muOekHk2H8Sd+_NPebtsxQ@mail.gmail.com>
References: <CANk_n4bcJVLs+q+A7+L72TXkJsQ_muOekHk2H8Sd+_NPebtsxQ@mail.gmail.com>
Message-ID: <AM0PR03MB4372B9EB6D099202E09BAB5F8EDA0@AM0PR03MB4372.eurprd03.prod.outlook.com>

I would say "sqlops" would be helpful for your case. You can fetch any variable from db with proper query.

Regards
EU.

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: sr-users <sr-users-bounces at lists.kamailio.org> on behalf of Mihai Cezar <mihai at mokalife.ro>
Sent: Sunday, December 27, 2020 3:18:49 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Subject: [SR-Users] Read $fd from mysql?

Hello,

I am redirecting the agents/reps to their asterisk server based on the hostname which they connect, and, i wonder if it's possible to read from db instead of the file cause it's getting big ;)

# Dispatch requests
route[DISPATCH] {
        switch ($fd){
                        case "oro.streamlinepbx.nl<http://oro.streamlinepbx.nl>":
                                if (!ds_select_dst("1", "4")) {
                                        send_reply(503, "Service Unavailable $fd");
                                        exit;
                                }
                                break;
                        case "oro3.streamlinepbx.nl<http://oro3.streamlinepbx.nl>":
                                if (!ds_select_dst("2", "4")) {
                                        send_reply(503, "Service Unavailable $fd");
                                        exit;
                                }
                                break;
                      ............
                        default:
                            log("unknow destination?");
                            send_reply(503, "No service defined");
                            xlog("--- SCRIPT: going to <$ru> via <$du> ...Exiting");
                            exit;
                }

        xlog("--- SCRIPT: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n");
        t_on_failure("RTF_DISPATCH");
        route(RELAY);
        exit;
}

Thanks,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201227/74a3dca4/attachment.htm>

From daniel.donoghue at freespee.com  Sun Dec 27 13:32:34 2020
From: daniel.donoghue at freespee.com (Daniel Donoghue)
Date: Sun, 27 Dec 2020 13:32:34 +0100
Subject: [SR-Users] Read $fd from mysql?
In-Reply-To: <CANk_n4bcJVLs+q+A7+L72TXkJsQ_muOekHk2H8Sd+_NPebtsxQ@mail.gmail.com>
References: <CANk_n4bcJVLs+q+A7+L72TXkJsQ_muOekHk2H8Sd+_NPebtsxQ@mail.gmail.com>
Message-ID: <05CBF4B7-EAB8-41BC-A0E3-A15FEBE39A12@freespee.com>

Hi,

Have you tried using sqlops?

Something like...

...
modparam("sqlops","sqlcon","ca=>dbdriver://username:password at dbhost/dbname")
...
sql_query("ca", "select dst_grp from lookup_table where from_domain=$(fd{s.escape.common})?, "ra");
if($dbr(ra=>rows)>0) {
  ds_select_dst("$dbr(ra=>[0,0])", "4");
}
sql_result_free("ra");
......



Alternatively, you could set up some naptr/srv records for all the from domains and simply relay to those, using dns instead of dispatcher, if you?re not already using them.


Blessings,
?
Daniel Donoghue



> On 27 Dec 2020, at 13:18, Mihai Cezar <mihai at mokalife.ro> wrote:
> 
> Hello, 
> 
> I am redirecting the agents/reps to their asterisk server based on the hostname which they connect, and, i wonder if it's possible to read from db instead of the file cause it's getting big ;)
> 
> # Dispatch requests
> route[DISPATCH] {
>         switch ($fd){
>                         case "oro.streamlinepbx.nl <http://oro.streamlinepbx.nl/>":
>                                 if (!ds_select_dst("1", "4")) {
>                                         send_reply(503, "Service Unavailable $fd");
>                                         exit;
>                                 }
>                                 break;
>                         case "oro3.streamlinepbx.nl <http://oro3.streamlinepbx.nl/>":
>                                 if (!ds_select_dst("2", "4")) {
>                                         send_reply(503, "Service Unavailable $fd");
>                                         exit;
>                                 }
>                                 break;
>                       ............
>                         default:
>                             log("unknow destination?");
>                             send_reply(503, "No service defined");
>                             xlog("--- SCRIPT: going to <$ru> via <$du> ...Exiting");
>                             exit;
>                 }
> 
>         xlog("--- SCRIPT: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n");
>         t_on_failure("RTF_DISPATCH");
>         route(RELAY);
>         exit;
> }
> 
> Thanks,
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201227/19a7413e/attachment.htm>

From cezar at mokalife.ro  Sun Dec 27 15:11:52 2020
From: cezar at mokalife.ro (Mihai Cezar)
Date: Sun, 27 Dec 2020 16:11:52 +0200
Subject: [SR-Users] Read $fd from mysql?
In-Reply-To: <05CBF4B7-EAB8-41BC-A0E3-A15FEBE39A12@freespee.com>
References: <CANk_n4bcJVLs+q+A7+L72TXkJsQ_muOekHk2H8Sd+_NPebtsxQ@mail.gmail.com>
 <05CBF4B7-EAB8-41BC-A0E3-A15FEBE39A12@freespee.com>
Message-ID: <CANk_n4baGyYjD1x6Zt0H54m-dbsKxrutmgHHROCVd6t9_qNQqg@mail.gmail.com>

Thanks Daniel, it looks like sqlops was what I needed!
Don't know how DNS SRV records can help, as the host from($fd) points to
private IP's

On Sun, Dec 27, 2020 at 2:34 PM Daniel Donoghue <
daniel.donoghue at freespee.com> wrote:

> Hi,
>
> Have you tried using sqlops?
>
> Something like...
>
> ...
> modparam("sqlops","sqlcon","ca=>dbdriver://username:password at dbhost/dbname")
> ...
> sql_query("ca", "select dst_grp from lookup_table where from_domain=$(fd{s.escape.common})?, "ra");
> if($dbr(ra=>rows)>0) {
>   ds_select_dst("$dbr(ra=>[0,0])", "4");
> }
> sql_result_free("ra");
> ......
>
>
>
>
> Alternatively, you could set up some naptr/srv records for all the from
> domains and simply relay to those, using dns instead of dispatcher, if
> you?re not already using them.
>
>
> Blessings,
> ?
> Daniel Donoghue
>
>
>
> On 27 Dec 2020, at 13:18, Mihai Cezar <mihai at mokalife.ro> wrote:
>
> Hello,
>
> I am redirecting the agents/reps to their asterisk server based on the
> hostname which they connect, and, i wonder if it's possible to read from db
> instead of the file cause it's getting big ;)
>
> # Dispatch requests
> route[DISPATCH] {
>         switch ($fd){
>                         case "oro.streamlinepbx.nl":
>                                 if (!ds_select_dst("1", "4")) {
>                                         send_reply(503, "Service
> Unavailable $fd");
>                                         exit;
>                                 }
>                                 break;
>                         case "oro3.streamlinepbx.nl":
>                                 if (!ds_select_dst("2", "4")) {
>                                         send_reply(503, "Service
> Unavailable $fd");
>                                         exit;
>                                 }
>                                 break;
>                       ............
>                         default:
>                             log("unknow destination?");
>                             send_reply(503, "No service defined");
>                             xlog("--- SCRIPT: going to <$ru> via <$du>
> ...Exiting");
>                             exit;
>                 }
>
>         xlog("--- SCRIPT: going to <$ru> via <$du> (attrs:
> $xavp(_dsdst_=>attrs))\n");
>         t_on_failure("RTF_DISPATCH");
>         route(RELAY);
>         exit;
> }
>
> Thanks,
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201227/792a4430/attachment.htm>

From michelpelletier07 at gmail.com  Mon Dec 28 15:20:18 2020
From: michelpelletier07 at gmail.com (Michel Pelletier)
Date: Mon, 28 Dec 2020 08:20:18 -0600
Subject: [SR-Users] How to implement a self-sustained Presence server
Message-ID: <CADvnLS9oQuvkKqA6KUBKEOPrikAupm70p0kwXHFxixVguyvJpg@mail.gmail.com>

Hi,

What is the recommended practice for implementing a self-sustained Presence
server from my current Kamailio configuration?  That is I want the Presence
module to be fed status updates as Kamailio is routing calls and handling
registrations.  So when a user registers, his phone is ringing, he is on
the phone, etc.., the Presence module gets notified and can update its
subscribers accordingly.  Must I add snippets of codes to all of these
events and generate local Publish messages, or is there a better way?

I'm using the latest version 5.4.x.

Regards,

Michel Pelletier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201228/3d992e59/attachment.htm>

From jv at voiper.es  Mon Dec 28 16:40:53 2020
From: jv at voiper.es (Javier Valencia)
Date: Mon, 28 Dec 2020 16:40:53 +0100
Subject: [SR-Users] Kamailio suddenly stops
Message-ID: <8923e192-7773-ce6d-709e-125a68a7630f@voiper.es>

Hi there!

When I start my webrtc kamailio suddenly stops.

I can see this on syslog:

    Dec 28 16:08:53 webrtc /usr/sbin/kamailio[803]: CRITICAL: <core>
    [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed
    pointer (0x7f55756c2ab8), called from tls: tls_init.c:
    ser_free(323), first free tls: tls_init.c: ser_malloc(293) - ignoring
    Dec 28 16:08:53 webrtc /usr/sbin/kamailio[803]: CRITICAL: <core>
    [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed
    pointer (0x7f55756c3138), called from tls: tls_init.c:
    ser_free(323), first free tls: tls_init.c: ser_malloc(293) - ignoring

    ... omit vervose ...

    Dec 28 16:08:53 webrtc /usr/sbin/kamailio[803]: CRITICAL: <core>
    [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed
    pointer (0x7f55756c1f38), called from tls: tls_init.c:
    ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring

    ...omit verbose ...

    Dec 28 16:08:53 webrtc /usr/sbin/kamailio[803]: CRITICAL: <core>
    [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed
    pointer (0x7f557569f250), called from tls: tls_init.c:
    ser_free(323), first free tls: tls_init.c: ser_realloc(299) - ignoring
    Dec 28 16:08:53 webrtc /usr/sbin/kamailio[803]: CRITICAL: <core>
    [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed
    pointer (0x7f557565cf60), called from tls: tls_init.c:
    ser_free(323), first free tls: tls_init.c: ser_malloc(293) - ignoring
    Dec 28 16:08:53 webrtc /usr/sbin/kamailio[803]: INFO: <core>
    [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized

OS info:

    root at webrtc:/etc/kamailio# lsb_release -a
    No LSB modules are available.
    Distributor ID:??? Debian
    Description:??? Debian GNU/Linux 10 (buster)
    Release:??? 10
    Codename:??? buster

    root at webrtc:/etc/kamailio# free -m
     ????????????? total??????? used??????? free????? shared
    buff/cache?? available
    Mem:????????? 16041???????? 134?????? 15551 108???????? 356?????? 15524
    Swap:?????????? 974?????????? 0???????? 974

Kamailio version:

    version: kamailio 5.4.3 (x86_64/linux)
    flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
    DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC,
    Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
    FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
    USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
    ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
    1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
    poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
    id: unknown
    compiled with gcc 8.3.0

Kamailio params:

    SHM_MEMORY=512
    PKG_MEMORY=32

SSL info:

    root at webrtc:/etc/kamailio# apt show openssl
    Package: openssl
    Version: 1.1.1d-0+deb10u4
    Priority: optional
    Section: utils
    Maintainer: Debian OpenSSL Team
    <pkg-openssl-devel at lists.alioth.debian.org>
    Installed-Size: 1.495 kB
    Depends: libc6 (>= 2.15), libssl1.1 (>= 1.1.1)
    Suggests: ca-certificates
    Homepage: https://www.openssl.org/
    Download-Size: 843 kB
    APT-Manual-Installed: no
    APT-Sources: http://security.debian.org/debian-security
    buster/updates/main amd64 Packages
    Description: juego de herramientas Secure Sockets Layer - utilidad
    criptogr?fica
     ?Este paquete forma parte de la implementaci?n del proyecto OpenSSL
    de los
     ?protocolos criptogr?ficos SSL y TLS para la comunicaci?n segura a
    trav?s de
     ?Internet.
     ?.
     ?Contiene el binario de prop?sito general para la l?nea de ?rdenes
     ?/usr/bin/openssl,
     ??til para operaciones criptogr?ficas como:
     ? * creaci?n de par?metros clave RSA, DH y DSA;
     ? * creaci?n de certificados X.509, CSR y CRL;
     ? * calcular res?menes de mensajes;
     ? * cifrado y descifrado con cifras;
     ? * probar clientes y servidores SSL/TLS;
     ? * gesti?n de correo firmado o cifrado S/MIME.

Should I use another version of openssl, or maybe use gnutls?

Regards,

Javier Valencia


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201228/f83f24d8/attachment.htm>

From eschmidbauer at gmail.com  Mon Dec 28 18:57:08 2020
From: eschmidbauer at gmail.com (E. Schmidbauer)
Date: Mon, 28 Dec 2020 12:57:08 -0500
Subject: [SR-Users] How to implement a self-sustained Presence server
In-Reply-To: <CADvnLS9oQuvkKqA6KUBKEOPrikAupm70p0kwXHFxixVguyvJpg@mail.gmail.com>
References: <CADvnLS9oQuvkKqA6KUBKEOPrikAupm70p0kwXHFxixVguyvJpg@mail.gmail.com>
Message-ID: <CAJwe+CCm98+z6A-3xkJ0Q5OJuyp7ZzhbiqEE3h_kWxV0ASu5HQ@mail.gmail.com>

You could try
https://www.kamailio.org/docs/modules/devel/modules/pua_dialoginfo
I did not have much luck with the module (it seemed to have intermittent
issues with BLF lighting up/down) but I also did not invest a ton of time
figuring it out.
I ultimately took a different approach, which is to *extract* the presence
out of other services (e.g. FreeSWITCH via ESL) using custom code and then
publishing the presence updates via modules such as evapi
<https://www.kamailio.org/docs/modules/devel/modules/evapi> or nsq
<https://www.kamailio.org/docs/modules/devel/modules/nsq> or xhttp
<https://www.kamailio.org/docs/modules/devel/modules/xhttp> combined with
pua_json <https://www.kamailio.org/docs/modules/devel/modules/pua_json> and
presence <https://www.kamailio.org/docs/modules/devel/modules/presence>
 modules.
This approach seemed to provide the flexibility I needed and allowed me to
expose an external API for controlling presence (e.g. fire MWI updates,
parking lot update, etc...)
I hope this helps!
Thanks,
Emmanuel



On Mon, Dec 28, 2020 at 9:20 AM Michel Pelletier <
michelpelletier07 at gmail.com> wrote:

> Hi,
>
> What is the recommended practice for implementing a self-sustained
> Presence server from my current Kamailio configuration?  That is I want the
> Presence module to be fed status updates as Kamailio is routing calls and
> handling registrations.  So when a user registers, his phone is ringing, he
> is on the phone, etc.., the Presence module gets notified and can update
> its subscribers accordingly.  Must I add snippets of codes to all of these
> events and generate local Publish messages, or is there a better way?
>
> I'm using the latest version 5.4.x.
>
> Regards,
>
> Michel Pelletier
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201228/b1a9c44d/attachment.htm>

From michelpelletier07 at gmail.com  Mon Dec 28 14:36:06 2020
From: michelpelletier07 at gmail.com (Michel Pelletier)
Date: Mon, 28 Dec 2020 07:36:06 -0600
Subject: [SR-Users] Self-sustained Presence server.
Message-ID: <CADvnLS8b7-Hwd55=DFVQHJUxhNF735MTet1kUJ=F5Ss_EPoN=Q@mail.gmail.com>

Hi,

What is the recommended practice for implementing a self-sustained Presence
server from my current Kamailio configuration.  That is I want the Presence
module to be fed status updates from the same Kamailio that is routing the
calls.  So when a user registers, his phone is ringing, he is busy, on the
phone, etc.., the Presence module gets notified and can update subscribers
accordingly.  Must I add snippets of codes to all of these events and
generate local Publish messages, or is there a better way?

I'm using the latest version 5.4.x.

Regards,

Michel Pelletier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201228/907d2f30/attachment.htm>

From jutsco at gmail.com  Tue Dec 29 10:11:44 2020
From: jutsco at gmail.com (=?UTF-8?Q?Jukka_Heikkil=C3=A4?=)
Date: Tue, 29 Dec 2020 11:11:44 +0200
Subject: [SR-Users] Kamailio as a presence watcher
Message-ID: <CACKEAnF_4w2NYu6S+XzVRPhfhM7+9aTjNEC3dSNfWGfQDHPmUA@mail.gmail.com>

Hello,

I'm working with IMS network and VoLTE related services. My problem is
that I would like to use Kamailio as a presence watcher but I haven't
managed to make it happen yet. The approach would be that once
Kamailio gets 3rd party registration from S-CSCF the Kamailio would
send SUBSCRIBE back to S-CSCF to subscribe the presence of
subscription. Once a subscription place or get calls the status of
subscription would be updated to Kamailio and to the database where it
can be fetched. I have checked presence and pua modules, but haven't
found a way to make it work as expected.

Is there way to do that or is this totally incompatible approach to do that?

Best Regards,
Jukka Heikkil?
jutsco at gmail.com


From chiefkeeft at gmail.com  Tue Dec 29 21:23:24 2020
From: chiefkeeft at gmail.com (Zhan Bazarov)
Date: Tue, 29 Dec 2020 13:23:24 -0700 (MST)
Subject: [SR-Users] Presence - issue with NOTIFY "terminated" state
Message-ID: <1609273404886-0.post@n5.nabble.com>

Hello everyone! I faced some unfortunately issue with presence module. Let me
describe setup scheme a bit: I'm publishing dialog states via pua_dialoginfo
from one kamailio server(for calls proccessing itself) to another one
kamailio(standalone kamailio just for handling presence,blf,mwi etc) 

So, about issue, let's say we have device A which has outgoing subscription
to extension which belongs to device B and device C(both devices has same
extension but different usernames, webrtc+sip phone, effectively its the
same Phone, I'm using pubruri_avps to change entities from usernames to
extension) . And, in some cases,for examle, when thirtparty is making call
to this extension(B,C devices) and making CANCEL after couple seconds - I
see the PUBLISH from callserver to presence server with state "terminated',
I see 200ok response.. but presence server isn't sending NOTIFY to device A
about state "terminated", everything is good with "trying" and "early"
states...

That problem is happening 1 of 50 tries.. I've tried a lot of things to fix
that - still are not succeed.

p.s. everything is good from logs/sip point of view...  And also, when I
disable the webrtc device - I'm not able to reproduce that issue anymore.
Looks like something wrong with case, when you have multiple different
username behind the same presentity. 

Maybe someone had same issue and may help me. Thanks! 



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html


From denys.pozniak at gmail.com  Wed Dec 30 10:23:24 2020
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Wed, 30 Dec 2020 11:23:24 +0200
Subject: [SR-Users] [Presence] publ_cache=2 usage
Message-ID: <CA+x3AxrJd_kdtrGOVRBPDqn=+oz=Ke77FUNYCGuunD+MsLv+AA@mail.gmail.com>

Hello!

Could somebody explain how the parameters *publ_cache=2* and
*subs_db_mode* depend
on each other?
Do I understand correctly that only the following modes of *subs_db_mode* are
allowed 0,1,2?






*subs_db_mode:0 - This disables database completely. Only memory will be
used. Subscriptions will not survive restart. Use this value if you need a
really fast presence module and subscription persistence is not necessary
or is provided by other means.1 - Write-Through scheme. Subscriptions are
updated synchronously in database and in memory(used for read operations).
Use this scheme if speed is not top priority, but it's important that no
subscriptions will be lost during crash or reboot or if you have an
external application that reads the state of the subscriptions from
database and they need to be updated synchronously.2 - Write-Back scheme.
This is a combination of previous two schemes. All changes are made to
memory and database synchronization is done in the timer. The timer deletes
all expired contacts and flushes all modified or new subscriptions to
database. Use this scheme if you encounter high-load peaks and want them to
process as fast as possible. Latency of this mode is much lower than
latency of mode 1, but slightly higher than latency of mode 0. To control
the interval at which data is flushed to database, set the db_update_period
parameter.3 - DB-Only scheme. No memory cache is kept, all operations being
directly performed with the database. The timer deletes all expired
subscriptions from database. The mode is useful if you configure more
servers sharing the same DB without any replication at SIP level. The mode
may be slower due the high number of DB operation.*
-- 

BR,
Denys Pozniak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/2fe0889f/attachment.htm>

From jv at voiper.es  Wed Dec 30 10:30:02 2020
From: jv at voiper.es (Javier Valencia)
Date: Wed, 30 Dec 2020 10:30:02 +0100
Subject: [SR-Users] list myself values
Message-ID: <a2456db1-302e-a629-e815-aa8fd39b5077@voiper.es>

Hi, a question from a Kamailio newbie.

How can I list or show variable *myself* values?

Regards, JV



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/e2723a9a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jv.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/e2723a9a/attachment.vcf>

From danielhermann.ndon at outlook.com  Wed Dec 30 15:15:19 2020
From: danielhermann.ndon at outlook.com (Daniel Hermann N'don)
Date: Wed, 30 Dec 2020 14:15:19 +0000
Subject: [SR-Users] using kamailio 5.4 with the websocket or xmlhttprequest
Message-ID: <MWHPR05MB291167705F86195717CA7E3181D70@MWHPR05MB2911.namprd05.prod.outlook.com>

Hello everyone, I'm a beginner in kamailio technology, and I would like to know how to communicate with kamailio from the web.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/bbd33686/attachment.htm>

From Antony.Stone at kamailio.open.source.it  Wed Dec 30 15:35:16 2020
From: Antony.Stone at kamailio.open.source.it (Antony Stone)
Date: Wed, 30 Dec 2020 15:35:16 +0100
Subject: [SR-Users] using kamailio 5.4 with the websocket or
 xmlhttprequest
In-Reply-To: <MWHPR05MB291167705F86195717CA7E3181D70@MWHPR05MB2911.namprd05.prod.outlook.com>
References: <MWHPR05MB291167705F86195717CA7E3181D70@MWHPR05MB2911.namprd05.prod.outlook.com>
Message-ID: <202012301535.16629.Antony.Stone@kamailio.open.source.it>

On Wednesday 30 December 2020 at 15:15:19, Daniel Hermann N'don wrote:

> Hello everyone, I'm a beginner in kamailio technology, and I would like to
> know how to communicate with kamailio from the web.

Please define "communicate".

What are you trying to achieve?

Antony.

-- 
"Can you keep a secret?"
"Well, I shouldn't really tell you this, but... no."


                                                   Please reply to the list;
                                                         please *don't* CC me.


From danielhermann.ndon at outlook.com  Wed Dec 30 18:12:01 2020
From: danielhermann.ndon at outlook.com (Daniel Hermann N'don)
Date: Wed, 30 Dec 2020 17:12:01 +0000
Subject: [SR-Users] using kamailio 5.4 with the websocket or
 xmlhttprequest
In-Reply-To: <202012301535.16629.Antony.Stone@kamailio.open.source.it>
References: <MWHPR05MB291167705F86195717CA7E3181D70@MWHPR05MB2911.namprd05.prod.outlook.com>,
 <202012301535.16629.Antony.Stone@kamailio.open.source.it>
Message-ID: <MWHPR05MB29119A032BEDA31EBDF33E9D81D70@MWHPR05MB2911.namprd05.prod.outlook.com>

how to send request to kamailio from the web?
and how to show received xhttp request ?
________________________________
De : sr-users <sr-users-bounces at lists.kamailio.org> de la part de Antony Stone <Antony.Stone at kamailio.open.source.it>
Envoy? : mercredi 30 d?cembre 2020 14:35
? : Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Objet : Re: [SR-Users] using kamailio 5.4 with the websocket or xmlhttprequest

On Wednesday 30 December 2020 at 15:15:19, Daniel Hermann N'don wrote:

> Hello everyone, I'm a beginner in kamailio technology, and I would like to
> know how to communicate with kamailio from the web.

Please define "communicate".

What are you trying to achieve?

Antony.

--
"Can you keep a secret?"
"Well, I shouldn't really tell you this, but... no."


                                                   Please reply to the list;
                                                         please *don't* CC me.

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/2b6bcf24/attachment.htm>

From nicolas.chaigneau at capgemini.com  Wed Dec 30 18:14:53 2020
From: nicolas.chaigneau at capgemini.com (Chaigneau, Nicolas)
Date: Wed, 30 Dec 2020 17:14:53 +0000
Subject: [SR-Users] Using a specific log level for "script" ?
Message-ID: <AM9PR02MB6547E8E35EEC6DCC82B22904E6D70@AM9PR02MB6547.eurprd02.prod.outlook.com>

Hello,


Is it possible to set a specific log level for the Kamailio script ?
I've seen that the < debugger > module allows to do that with modules or < core > :

https://kamailio.org/docs/modules/5.4.x/modules/debugger.html#dbg.p.mod_level


So I've tried to do :

modparam("debugger", "mod_level_mode", 1)
modparam("debugger", "mod_hash_size", 5)
modparam("debugger", "mod_level", "my_module=3") // this works
modparam("debugger", "mod_level", "core=3") // also works
modparam("debugger", "mod_level", "script=3") // nope...


But it doesn't seem to work for < script >... :/


Regards,
Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/1da77854/attachment.htm>

From singla.rohit111 at gmail.com  Thu Dec 31 12:30:20 2020
From: singla.rohit111 at gmail.com (Rohit Kumar)
Date: Thu, 31 Dec 2020 17:00:20 +0530
Subject: [SR-Users] Unable to connect sip with Kamailio
In-Reply-To: <mailman.3.1609412402.22225.sr-users@lists.kamailio.org>
References: <mailman.3.1609412402.22225.sr-users@lists.kamailio.org>
Message-ID: <CAADsAQo7WX+CJq9_T69F+s0Gthfj8ohtoXK5Z5swcZwDYsyn7A@mail.gmail.com>

Hello everyone,

I'm beginner in Kamailio, I want to connect my asterisk Server with
Kamailio. Can you please help me in this context. I shall be very thankful
to you.

Regards,
Rohit Kumar

On Thu, Dec 31, 2020, 16:31 <sr-users-request at lists.kamailio.org> wrote:

> Send sr-users mailing list submissions to
>         sr-users at lists.kamailio.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> or, via email, send a message with subject or body 'help' to
>         sr-users-request at lists.kamailio.org
>
> You can reach the person managing the list at
>         sr-users-owner at lists.kamailio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sr-users digest..."
>
>
> Today's Topics:
>
>    1. using kamailio 5.4 with the websocket or xmlhttprequest
>       (Daniel Hermann N'don)
>    2. Re: using kamailio 5.4 with the websocket or xmlhttprequest
>       (Antony Stone)
>    3. Re: using kamailio 5.4 with the websocket or xmlhttprequest
>       (Daniel Hermann N'don)
>    4. Using a specific log level for "script" ? (Chaigneau, Nicolas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 30 Dec 2020 14:15:19 +0000
> From: Daniel Hermann N'don <danielhermann.ndon at outlook.com>
> To: "sr-users at lists.kamailio.org" <sr-users at lists.kamailio.org>
> Subject: [SR-Users] using kamailio 5.4 with the websocket or
>         xmlhttprequest
> Message-ID:
>         <
> MWHPR05MB291167705F86195717CA7E3181D70 at MWHPR05MB2911.namprd05.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello everyone, I'm a beginner in kamailio technology, and I would like to
> know how to communicate with kamailio from the web.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/bbd33686/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 30 Dec 2020 15:35:16 +0100
> From: Antony Stone <Antony.Stone at kamailio.open.source.it>
> To: "Kamailio \(SER\) - Users Mailing List"
>         <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] using kamailio 5.4 with the websocket or
>         xmlhttprequest
> Message-ID: <202012301535.16629.Antony.Stone at kamailio.open.source.it>
> Content-Type: Text/Plain;  charset="iso-8859-15"
>
> On Wednesday 30 December 2020 at 15:15:19, Daniel Hermann N'don wrote:
>
> > Hello everyone, I'm a beginner in kamailio technology, and I would like
> to
> > know how to communicate with kamailio from the web.
>
> Please define "communicate".
>
> What are you trying to achieve?
>
> Antony.
>
> --
> "Can you keep a secret?"
> "Well, I shouldn't really tell you this, but... no."
>
>
>                                                    Please reply to the
> list;
>                                                          please *don't* CC
> me.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 30 Dec 2020 17:12:01 +0000
> From: Daniel Hermann N'don <danielhermann.ndon at outlook.com>
> To: "Kamailio (SER) - Users Mailing List"
>         <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] using kamailio 5.4 with the websocket or
>         xmlhttprequest
> Message-ID:
>         <
> MWHPR05MB29119A032BEDA31EBDF33E9D81D70 at MWHPR05MB2911.namprd05.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> how to send request to kamailio from the web?
> and how to show received xhttp request ?
> ________________________________
> De : sr-users <sr-users-bounces at lists.kamailio.org> de la part de Antony
> Stone <Antony.Stone at kamailio.open.source.it>
> Envoy? : mercredi 30 d?cembre 2020 14:35
> ? : Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
> Objet : Re: [SR-Users] using kamailio 5.4 with the websocket or
> xmlhttprequest
>
> On Wednesday 30 December 2020 at 15:15:19, Daniel Hermann N'don wrote:
>
> > Hello everyone, I'm a beginner in kamailio technology, and I would like
> to
> > know how to communicate with kamailio from the web.
>
> Please define "communicate".
>
> What are you trying to achieve?
>
> Antony.
>
> --
> "Can you keep a secret?"
> "Well, I shouldn't really tell you this, but... no."
>
>
>                                                    Please reply to the
> list;
>                                                          please *don't* CC
> me.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/2b6bcf24/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 30 Dec 2020 17:14:53 +0000
> From: "Chaigneau, Nicolas" <nicolas.chaigneau at capgemini.com>
> To: "Kamailio (SER) - Users Mailing List"
>         <sr-users at lists.kamailio.org>
> Subject: [SR-Users] Using a specific log level for "script" ?
> Message-ID:
>         <
> AM9PR02MB6547E8E35EEC6DCC82B22904E6D70 at AM9PR02MB6547.eurprd02.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
>
>
> Is it possible to set a specific log level for the Kamailio script ?
> I've seen that the < debugger > module allows to do that with modules or <
> core > :
>
>
> https://kamailio.org/docs/modules/5.4.x/modules/debugger.html#dbg.p.mod_level
>
>
> So I've tried to do :
>
> modparam("debugger", "mod_level_mode", 1)
> modparam("debugger", "mod_hash_size", 5)
> modparam("debugger", "mod_level", "my_module=3") // this works
> modparam("debugger", "mod_level", "core=3") // also works
> modparam("debugger", "mod_level", "script=3") // nope...
>
>
> But it doesn't seem to work for < script >... :/
>
>
> Regards,
> Nicolas.
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.kamailio.org/pipermail/sr-users/attachments/20201230/1da77854/attachment-0001.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> sr-users mailing list
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ------------------------------
>
> End of sr-users Digest, Vol 187, Issue 30
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201231/521b0629/attachment.htm>

From miconda at gmail.com  Thu Dec 31 14:00:55 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 31 Dec 2020 14:00:55 +0100
Subject: [SR-Users] Using a specific log level for "script" ?
In-Reply-To: <AM9PR02MB6547E8E35EEC6DCC82B22904E6D70@AM9PR02MB6547.eurprd02.prod.outlook.com>
References: <AM9PR02MB6547E8E35EEC6DCC82B22904E6D70@AM9PR02MB6547.eurprd02.prod.outlook.com>
Message-ID: <7d8bbe25-5cd7-698f-359e-5740d77154e7@gmail.com>


On 30.12.20 18:14, Chaigneau, Nicolas wrote:
>
> Hello,
>
> ?
>
> ?
>
> Is it possible to set a specific log level for the Kamailio script??
>
> I?ve seen that the ??debugger?? module allows to do that with modules
> or ??core???:
>
> ?
>
> https://kamailio.org/docs/modules/5.4.x/modules/debugger.html#dbg.p.mod_level
> <https://kamailio.org/docs/modules/5.4.x/modules/debugger.html#dbg.p.mod_level>
>
> ?
>
> ?
>
> So I?ve tried to do?:
>
> ?
>
> modparam("debugger", "mod_level_mode", 1)
>
> modparam("debugger", "mod_hash_size", 5)
>
> modparam("debugger", "mod_level", "my_module=3") // this works
>
> modparam("debugger", "mod_level", "core=3") // also works
>
> modparam("debugger", "mod_level", "script=3") // nope?
>
> ?
>
> ?
>
> But it doesn?t seem to work for ??script??? :/
>
> ?
>
> ?
>
> Regards,
>
> Nicolas.
>
> ?
>
> This message contains information that may be privileged or
> confidential and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not
> the intended recipient, you are not authorized to read, print, retain,
> copy, disseminate, distribute, or use this message or any part
> thereof. If you receive this message in error, please notify the
> sender immediately and delete all copies of this message.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201231/3184d4c2/attachment.htm>

From miconda at gmail.com  Thu Dec 31 14:04:11 2020
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Thu, 31 Dec 2020 14:04:11 +0100
Subject: [SR-Users] Using a specific log level for "script" ?
In-Reply-To: <AM9PR02MB6547E8E35EEC6DCC82B22904E6D70@AM9PR02MB6547.eurprd02.prod.outlook.com>
References: <AM9PR02MB6547E8E35EEC6DCC82B22904E6D70@AM9PR02MB6547.eurprd02.prod.outlook.com>
Message-ID: <75f504c6-0fae-7361-2acc-4be99c6e3e0c@gmail.com>

Hello,

the log messages that have "script" in the prefix are from kamailio.cfg
routing blocks, not from the C code.

You can remove, change their log level, ... by editing the kamailio.cfg.
The script log messages are printed by the functions exported from xlog
module.

Cheers,
Daniel

On 30.12.20 18:14, Chaigneau, Nicolas wrote:
>
> Hello,
>
> ?
>
> ?
>
> Is it possible to set a specific log level for the Kamailio script??
>
> I?ve seen that the ??debugger?? module allows to do that with modules
> or ??core???:
>
> ?
>
> https://kamailio.org/docs/modules/5.4.x/modules/debugger.html#dbg.p.mod_level
> <https://kamailio.org/docs/modules/5.4.x/modules/debugger.html#dbg.p.mod_level>
>
> ?
>
> ?
>
> So I?ve tried to do?:
>
> ?
>
> modparam("debugger", "mod_level_mode", 1)
>
> modparam("debugger", "mod_hash_size", 5)
>
> modparam("debugger", "mod_level", "my_module=3") // this works
>
> modparam("debugger", "mod_level", "core=3") // also works
>
> modparam("debugger", "mod_level", "script=3") // nope?
>
> ?
>
> ?
>
> But it doesn?t seem to work for ??script??? :/
>
> ?
>
> ?
>
> Regards,
>
> Nicolas.
>
> ?
>
> This message contains information that may be privileged or
> confidential and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not
> the intended recipient, you are not authorized to read, print, retain,
> copy, disseminate, distribute, or use this message or any part
> thereof. If you receive this message in error, please notify the
> sender immediately and delete all copies of this message.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201231/30b6f12d/attachment.htm>

From nicolas.chaigneau at capgemini.com  Thu Dec 31 17:47:22 2020
From: nicolas.chaigneau at capgemini.com (Chaigneau, Nicolas)
Date: Thu, 31 Dec 2020 16:47:22 +0000
Subject: [SR-Users] Using a specific log level for "script" ?
In-Reply-To: <75f504c6-0fae-7361-2acc-4be99c6e3e0c@gmail.com>
References: <AM9PR02MB6547E8E35EEC6DCC82B22904E6D70@AM9PR02MB6547.eurprd02.prod.outlook.com>
 <75f504c6-0fae-7361-2acc-4be99c6e3e0c@gmail.com>
Message-ID: <AM9PR02MB654733456FEA16F8C80544C8E6D60@AM9PR02MB6547.eurprd02.prod.outlook.com>

Thanks Daniel for the explaination !

I found something in a Kamailio sample script that does what I want to do, e.g. :

#!ifdef WITH_DEBUG_SCRIPT
                               xlog("L_INFO", "Request-URI: $ru\n");
#!endif


This allows me to log ? debug ? information from the script as INFO when the flag WITH_DEBUG_SCRIPT is set.
It's a bit clumsy but it works. :)

(I don't know if having the xlog exported functions changed so they go look at the configuration of the debugger module would be complicated, or even feasible - would be nice though ! ^^)


Cheers!
Nicolas.

De : Daniel-Constantin Mierla <miconda at gmail.com>
Envoy? : jeudi 31 d?cembre 2020 14:04


Hello,

the log messages that have "script" in the prefix are from kamailio.cfg routing blocks, not from the C code.

You can remove, change their log level, ... by editing the kamailio.cfg. The script log messages are printed by the functions exported from xlog module.

Cheers,
Daniel
On 30.12.20 18:14, Chaigneau, Nicolas wrote:
Hello,


Is it possible to set a specific log level for the Kamailio script ?
I've seen that the ? debugger ? module allows to do that with modules or ? core ? :

https://kamailio.org/docs/modules/5.4.x/modules/debugger.html#dbg.p.mod_level


So I've tried to do :

modparam("debugger", "mod_level_mode", 1)
modparam("debugger", "mod_hash_size", 5)
modparam("debugger", "mod_level", "my_module=3") // this works
modparam("debugger", "mod_level", "core=3") // also works
modparam("debugger", "mod_level", "script=3") // nope...


But it doesn't seem to work for ? script ?... :/


Regards,
Nicolas.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201231/103dcb60/attachment.htm>