Hi all
Just enabled topos with redis backend (topos/topos_redis/ndb_redis)
The interesting bits of the calls are going from kamailio (5.3.5) to Asterisk with topos enabled for that leg
All seems to be ok until the far end (Asterisk) sends a BYE. At which point kamailo passes message to WITHINDLG, in loose_route comes up false (-1) and the BYE gets missed, falling through to the “404 Not here” at the end of WITHINDLG.
I’m guessing that loose_route should be able to “see inside” topos, or should I be throwing loose_route away when using topos?
Happy to upgrade to 5.4 and do diags if it appears to be a bug.
Best regards
Mark
--
Mark Boyce
Dark Origins Ltd
Hey guys,
I'm trying to configure a Kamailio to work with a browser softphone based on SIPJS using WebRTC.
So far it works great on Firefox but have a specific problem with chrome, when I want to make call from the softphone to another extension.
After anwsering the call Chrome/the softphone sends a BYE immediately, because this line "a=rtcp-mux" is missing in the OK.
The Kamailio is a proxy. Behind the Kamailio there is an Asterisk, which is responsible for the pbx-features.
Those are my rtpengine Flags for the Invite:
rtpengine_manage: replace-origin replace-session-connection trust-address via-branch=extra rtcp-mux-demux DTLS=off SDES-on ICE=remove RTP/AVP
And those are the flags for the response, in this case the OK:
rtpengine_manage: replace-origin replace-session-connection rtcp-mux-offer rtcp-mux-accept generate-mid DTLS=off SDES-on ICE=force RTP/SAVPF direction=internal direction=external loop-protect
It seems that the Kamailio ignores ths "rtcp-mux-offer rtcp-mux-accept" in the response. Can you help me get it to work?
Here is the SIP-Dialog. The call is from extension 201 to the extension 2.
INVITE:
INVITE sip:2@mydomain SIP/2.0
Via: SIP/2.0/WSS g4n0lpfirgpv.invalid;branch=z9hG4bK5104892
To: <sip:2@mydomain.com>
From: <sip:201@mydomain.com>;tag=aqplr71k05
CSeq: 2 INVITE
Call-ID: sde09v49f8gqtt59oddn
Max-Forwards: 70
Proxy-Authorization: Digest algorithm=MD5, username="201", realm="mydomain.com", nonce="sfdsdfdsfsdfdsfsdfaseqww", uri="sip:2@mydomain.com", response="81rewtrega23423r"
Contact: <sip:kf6iduon@g4n0lpfirgpv.invalid;transport=ws;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: SIPJS
Content-Type: application/sdp
Content-Length: 1916
v=0
o=- 5826889093965459811 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO
m=audio 54274 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 mycomputerIP
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1577908739 1 udp 2113937151 efd6d297-d186-4c07-87d8-933e5846a82d.local 54274 typ host generation 0 network-cost 999
a=candidate:842163049 1 udp 1677729535 mycomputerIP 54274 typ srflx raddr 0.0.0.0 rport 0 generation 0 network-cost 999
a=ice-ufrag:Ktxl
a=ice-pwd:x5xDUb41GeOXAcHNQlra4yUN
a=ice-options:trickle
a=fingerprint:sha-256 2C:7C:32:AF:34:A3:9D:AE:C7:FD:92:68:DD:D8:AB:82:DB:F0:32:51:14:97:20:60:66:5C:2F:CF:B7:98:B8:A8
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO dc187be3-4cd0-4129-98e4-f804cd8d2c94
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:2376769177 cname:RgPkYyxDrEJTpmO2
a=ssrc:2376769177 msid:Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO dc187be3-4cd0-4129-98e4-f804cd8d2c94
a=ssrc:2376769177 mslabel:Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO
a=ssrc:2376769177 label:dc187be3-4cd0-4129-98e4-f804cd8d2c94
RINGING:
SIP/2.0 180 Ringing
Via: SIP/2.0/WSS g4n0lpfirgpv.invalid;rport=60196;received=mycomputerIP;branch=z9hG4bK5104892
Record-Route: <sip:internalIP;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws>
Record-Route: <sip:externalIP;transport=ws;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws>
From: <sip:201@mydomain.com>;tag=aqplr71k05
To: <sip:2@mydomain.com>;tag=as64fe0fc8
Call-ID: sde09v49f8gqtt59oddn
CSeq: 2 INVITE
Server: myserver
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <mycontact>
P-Asserted-Identity: "Phone 2" <sip:2@mydomain.com>
Content-Length: 0
OK:
SIP/2.0 200 OK
Via: SIP/2.0/WSS g4n0lpfirgpv.invalid;rport=60196;received=mycomputerIP;branch=z9hG4bK5104892
Record-Route: <sip:internal-ip;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws>
Record-Route: <sip:external-ip;transport=ws;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws>
From: <sip:201@mydomain.com>;tag=aqplr71k05
To: <sip:2@mydomain.com>;tag=as64fe0fc8
Call-ID: sde09v49f8gqtt59oddn
CSeq: 2 INVITE
Server: myserver
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <mycontact>
P-Asserted-Identity: "Phone 2" <sip:2@mydomain.com>
Content-Type: application/sdp
Content-Length: 806
v=0
o=root 882840402 882840402 IN IP4 externalIP
s=Asterisk PBX 11.22.0
c=IN IP4 externalIP
t=0 0
a=rtpengine:4d633e3022f5
m=audio 16416 RTP/SAVPF 111 9 8 0 126
a=maxptime:60
a=mid:0
a=rtpmap:111 opus/48000/2
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:111 maxplaybackrate=16000; stereo=0; sprop-stereo=0; useinbandfec=0
a=fmtp:126 0-16
a=sendrecv
a=rtcp:16417
a=setup:active
a=fingerprint:sha-1 B1:67:4B:B8:47:89:E8:49:CD:DD:F8:FF:41:5C:83:72:D9:DE:4D:45
a=ptime:20
a=ice-ufrag:WBZN8m7c
a=ice-pwd:mKVR6Jv0G0pvrTv7OfEm2wPW9Q
a=ice-options:trickle
a=candidate:3kddB3zBUV2n2jt0 1 UDP 2130706431 externalIP 16416 typ host
a=candidate:3kddB3zBUV2n2jt0 2 UDP 2130706430 externalIP 16417 typ host
a=end-of-candidates
I hope, you can help me with this. If you have further question, I will try to answer them as best I can.
Greetings,
Ben
Hello,
the branch 5.4 was created, therefore the master branch is open for
adding new features, to be part of future release series v5.5.x.
Any bug fix committed to master that applies to 5.4.x or older stable
branches should be backported as usual with "git cherry-pick -x ..." to
appropriate branches like 5.4 or 5.3.
Expect that v5.4.0 will be released in a few weeks from now.
Based on the workflow used during the past years, the next future
release v5.5.0 should be out after another 8-10 months of development,
plus 1-2 months of testing, so sometime in the first part of 2021.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello,
the branch 5.4 has been created, to be used for releasing v5.4.x series.
To check out this branch, the following commands can be used:
git clone https://github.com/kamailio/kamailio kamailio-5.4
cd kamailio-5.34
git checkout -b 5.4 origin/5.4
Pushing commits in this branch:
git push origin 5.4:5.4
Note that 5.4 is an official stable branch, so only bug fixes, missing
kemi exports (discuss on sr-dev if not sure) or improvements to
documentation or helper tools can be pushed to this branch.
As usual, if there is a bug fixed, commit and push first to master
branch and then cherry pick to 5.4 branch:
git cherry-pick -x COMMITID
In few weeks, the first release from branch 5.4 will be out,
respectively Kamailio v5.4.0.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello list,
Hope you all doing fine!
I have a case where I want to drop a local generated request but it looks
like you can't drop the request from the tm:local-request route. I found
this ticket https://github.com/kamailio/kamailio/issues/980, but I could
not find somewhere in the docs or emails definitely saying that drop() is
not supported from tm:local-request....
And in case we definitely can't drop the request in there, any ideas on how
to avoid a local generated request of going out? I am specifically
interested in dropping Registers from the uacreg module under certain
situations, but I don't want to disable it or delete it from the DB....
Thank you,
Kind regards,
Patrick Wakano
Hi
I need an urgent help, I accidentally pipe the output to the kamailio
config, and now I lost the copy of my latest setting, is there a
chance that I can dump the running config back to file?
Thanks
PLEASE HELP
RBK
Hello,
so far it looks pretty calm during the testing phase, some static
analysis didn't reveal any new major issues (well, this is done also
during development phase). Therefore, if nothing else is proposed or
shows up, I am considering to create the git branch 5.4 next week on
Thursday -- this branch will hold the code for 5.4.x release series.
After branching 5.4, the master branch will be open again for new
features. The 5.4.0 enters the release candidate phase, likely to have
the first release out in 1-2 weeks after branching.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hello,
on Wednesday, July 8, 2020, there will be some work on Kamailio project
infrastructure. Therefore there could be short intervals of downtime for
online resources like the web server, wiki, documentation and downloads
portals, mailing lists or the GIT repository mirror.
Once the maintenance work is finished, we will post an update.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hi,
I would like to use Kamailio for load balancing incoming carrier traffic. We do currently IP authentication and call logic in Yate boxes. Ideally I would like to distribute calls with 30X redirects with the Kamailio dispatcher so that IP authentication and all logic can stay in the Yate boxes.
However I have doubts that 30X redirects are generally accepted in interconnects. What is your experience with this?
What is the possible alternative to redirects if one wants to keep IP authentication and call logic in the boxes behind the Kamailio SIP router? E.g. how can one reliably check the carrier source IPs behind Kamailio? Custom headers injected by Kamailio?
Of cause I can check source IPs with a database lookup in Kamailio but I try to avoid that as this makes the setup much more complicated and error prone.
Thank you for your ideas.
Gerry
Update: Disabling the topoh module on the proxy which produces the error
seems to stop the failure from manifesting. I'll try using topos_redis
instead, but should this be treated as a bug?
BR,
George
On Wed, 8 Jul 2020 at 12:37, George Diamantopoulos <georgediam(a)gmail.com>
wrote:
> Hello again,
>
> Indeed $mb seems to contain garbage:
>
> SCRIPT_MB: ACK <BC><EA><8F> SIP/2.0#015#012Via: SIP/2.0/UDP
> 172.30.154.189;TH=dcv;branch=z9hG4bK629b.6af9302cd78dc58dffe817e60124f4ed.0#015#012Route:
> <sip:RJ2U2c7mrFzQjgG5SSvyE8RVS9omgAA=@172.30.155.1
> ;lr;received=sip:2.2.2.2:32768
> ;ob;r2=on>,<sip:RJ2U2c7mrFzQjgG5SSvyE8RVS9omgAA=@3.3.3.3
> ;lr;received=sip:2.2.2.2:32768;ob;r2=on>#015#012Max-Forwards:
> 68#015#012From: "Anonymous" <sip:unknown@voip.domain.com>;tag=as4bc9e324#015#012To:
> <sip:voip-test-user-02@voip.domain.com>;tag=jw7z5s0zvc#015#012Call-ID:
> 0138c6370346d1dd7f1b47f604b01f92(a)voip.domain.com#015#012CSeq
> <http://0138c6370346d1dd7f1b47f604b01f92@voip.domain.com#015%23012CSeq>:
> 102 ACK#015#012Content-Length: 0#015#012TH: dch#015#012#015#012
>
> How can this be possible? Capturing traffic on wire shows the RURI I
> pasted in my original message and there are no script operations on the
> RURI before sanity_check() (message buffer above is printed just before
> sanity_check() is run in REQINIT).
>
> BR,
> George
>
> On Wed, 8 Jul 2020 at 11:18, George Diamantopoulos <georgediam(a)gmail.com>
> wrote:
>
>> I'll post the message buffer ASAP, but in the meantime I don't see how
>> config operations could affect the RURI. Here's everything that's happening
>> until the sanity check involved:
>>
>> request_route {
>>
>> if(is_method("KDMQ")) {
>> dmq_handle_message();
>> }
>>
>> # no connect for sending replies
>> set_reply_no_connect();
>>
>> if($ua =~ "friendly-scanner|sipcli|sipvicious|VaxSIPUserAgent") {
>> # silent drop for scanners - uncomment next line if want to reply
>> # sl_send_reply("200", "OK");
>> exit;
>> }
>>
>> if (!mf_process_maxfwd_header("10")) {
>> force_rport();
>> sl_send_reply("483","Too Many Hops");
>> exit;
>> }
>>
>> # OPTIONS and NOTIFYs directed to myself
>> if(is_method("OPTIONS|NOTIFY") && uri==myself && $rU==$null) {
>> force_rport();
>> sl_send_reply("200","Keepalive");
>> exit;
>> }
>>
>> # All keep-alive methods regardless of destination
>> if ( $hdr(Event) == "keep-alive") {
>> force_rport();
>> sl_send_reply("200","Keepalive");
>> exit;
>> }
>>
>> if(!sanity_check("17895", "7")) {
>> xlog("Malformed SIP request from $si:$sp\n");
>> exit;
>> }
>>
>> BR,
>> George
>>
>> On Wed, 8 Jul 2020 at 10:58, Daniel-Constantin Mierla <miconda(a)gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> check your config operations, because the R-URI seems to be the next
>>> string (without quotes): "<BC><EA><8F>"
>>>
>>> You can try to print $mb in such case to see the entire SIP message
>>> buffer.
>>>
>>> Cheers,
>>> Daniel
>>> On 08.07.20 09:48, George Diamantopoulos wrote:
>>>
>>> Hello Daniel,
>>>
>>> Thanks for the reply. Indeed there is, not sure how I managed to miss
>>> that. And it wasn't about the schema after all:
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - <core>
>>> [core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<BC><EA><8F>>
>>> (3)
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - <core>
>>> [core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<BC><EA><8F>>
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING:
>>> {1 <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>> [sanity.c:282]: check_ruri_scheme(): failed to parse request uri
>>> [<BC><EA><8F>]
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR: {1
>>> <null> 172.30.154.189 102 ACK
>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - <script>: Malformed
>>> SIP request from 172.30.154.189:5060
>>>
>>> Still, not sure what the problem is though...
>>>
>>> BR,
>>> George
>>>
>>> On Wed, 8 Jul 2020 at 09:30, Daniel-Constantin Mierla <miconda(a)gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> when the ruri scheme check fails, there should be another debug message
>>>> saying that. Have you pasted all log messages for the failure case?
>>>>
>>>> Cheers,
>>>> Daniel
>>>> On 07.07.20 22:23, George Diamantopoulos wrote:
>>>>
>>>> Sorry, I realised I copy pasted wrong log messages for Call 1. Here's
>>>> the relevant part showing success for call 1 in contrast with Call 2:
>>>>
>>>> grep 2a859fcc4e1c8f840191a81d7c16e76d kamailio.log | egrep
>>>> 'check_ruri_scheme|w_sanity_check' | grep ACK
>>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
>>>> {1 <null> 172.30.154.189 102 ACK
>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
>>>> {1 <null> 172.30.154.189 102 ACK
>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>> [sanity.c:297]: check_ruri_scheme(): check_ruri_scheme passed
>>>> Jul 7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
>>>> {1 <null> 172.30.154.189 102 ACK
>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1
>>>>
>>>> On Tue, 7 Jul 2020 at 21:34, George Diamantopoulos <
>>>> georgediam(a)gmail.com> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I'm not 100% sure this is the only culprit in an issue I'm
>>>>> investigating, but superficially it appears that RURI scheme sanity module
>>>>> checks from the default config (flags 17895 in REQINIT) fail if the
>>>>> RURI in an ACK following a 487 includes parameters. Example from two calls
>>>>> from a kamailio instance acting as registrar/usrloc server, INVITE RURIs
>>>>> are after usrloc lookup:
>>>>>
>>>>> Call 1: INVITE sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
>>>>> Call 2: INVITE sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08
>>>>> SIP/2.0
>>>>>
>>>>> These INVITEs produce no complaints. Later, the same registrar
>>>>> produces ACKs to acknowledge 487 (thus, same transaction ACKs) responses
>>>>> from the next proxy in the path following a CANCEL:
>>>>>
>>>>> Call 1: ACK sip:voip-test-gd@172.17.173.14:5063 SIP/2.0
>>>>> Call 2: ACK sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08
>>>>> SIP/2.0
>>>>>
>>>>> The next proxy (which produced/relayed the 487) processes the ACK for
>>>>> Call 1 successfully, but sanity_check at the proxy drops the request for
>>>>> Call 2 with:
>>>>>
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>>>> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 08679c4228983f9e65f3b47f767b6e07(a)voip.domain.com - sanity
>>>>> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
>>>>>
>>>>> whereas Call 1 seems OK:
>>>>>
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>>> [sanity.c:305]: check_required_headers(): check_required_headers entered
>>>>> DEBUG: {1 <null> 172.30.154.189 102 ACK
>>>>> 2a859fcc4e1c8f840191a81d7c16e76d(a)voip.domain.com - sanity
>>>>> [sanity.c:313]: check_required_headers(): check_required_headers passed
>>>>>
>>>>> Could this be a bug in sanity module? Is there anything one can do in
>>>>> config which could result in illegal ACKs being produced for hop-by-hop
>>>>> transactions? schema appears to be sip: in both cases...
>>>>>
>>>>> Thank you. Best regards,
>>>>> George
>>>>>
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing Listsr-users@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
>>>>
>>>> --
>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Funding: https://www.paypal.me/dcmierla
>>>
>>>