[SR-Users] Help with rewriting headers for NAT manually
Chad
ccolumbu at hotmail.com
Mon Jan 17 15:05:00 CET 2022
Michael,
Thank you for the feedback.
--
^C
On 1/16/22 4:02 PM, Michael Young wrote:
> Chad,
>
> In my experience, if you carrier partner is one of the bigger carriers, and\or you use multiple carriers, Kamailio is
> the best solution available. With some of the smaller carriers\resellers it just makes more sense to use Asterisk rather
> than argue with them about how they are ignoring and breaking RFCs. While Asterisk can be inefficient, it generally
> "just works" in those situations. Based on what I have read of your situation in the list I think I can guess which
> company you are working with. Their "SBC" is Freeswitch-based. I have had a similar debate with them about RFCs, and
> yes, you are better off with Asterisk in that case.
>
> Michael
>
>
> On 1/16/2022 5:20 PM, Chad wrote:
>> I have been reading a lot more about the problem and it seems my mangle/unmangle solution is basically B2BUA.
>> So I need a B2BUA solution and it seems like Kamailio does not really do B2BUA.
>> Instead of installing something else I don't know (SEMS or Sippy), it makes more sense to find something that can
>> handle it all.
>> I have read that opensips has B2BUA functionality built in, so I am seriously considering simply replacing Kamailio
>> with opensips.
>> In reality my system has such a low load I can probably replace Kamailio with Asterisk as a B2BUA and it would be
>> fine, but from what I have read Asterisk is very inefficient for B2BUA.
>>
>> --
>> ^C
>>
>>
>> On 1/16/22 1:38 PM, Ovidiu Sas wrote:
>>> Have you tried using the mask_ip param:
>>> https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
>>> <https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>
>>>
>>> -ovidiu
>>>
>>> On Sun, Jan 16, 2022 at 16:09 Chad <ccolumbu at hotmail.com <mailto:ccolumbu at hotmail.com>> wrote:
>>>
>>> I found a sample config file using topoh, which I copied (with some changes) and added the topoh module to my
>>> config.
>>> It works fine, but it does not solve the problem.
>>> In fact it has the exact same problem, because all the topoh module does is replace one private IP with another
>>> in the
>>> 2nd (top most) Record-Route header.
>>> So the carrier still changes the ACK to the public IP and the call is still broken in the exact same way.
>>> It was super easy to add, but does not work, 1 possible solution down.
>>>
>>> --
>>> ^C
>>>
>>>
>>> On 1/16/22 8:26 AM, Ovidiu Sas wrote:
>>> > Most of the time, if you get the right person on the carrier's side
>>> > and you explain the situation, they will come up with a solution.
>>> > If not, you need to break the RFC in a way that will counterpart their breakage.
>>> >
>>> > The carrier is also using a SIP proxy (maybe kamailio, who knows).
>>> > In the old days, the default kamailio config was using
>>> > fix_nated_contact() to deal with NATed devices and this is exactly the
>>> > behavior that you are seeing.
>>> > The recommended way to deal with NATed devices is to use
>>> > add_contact_alias([ip_addr, port, proto]) which is RFC compliant.
>>> >
>>> > There are several solution for this scenario:
>>> > - mangle the signaling to allow proper routing on your end
>>> > - use a B2BUA in between your kamailio and carrier
>>> > - configure kamailio to use one of the topology hiding modules:
>>> > topoh, topos, topos_redis
>>> > - maybe something else ... :)
>>> >
>>> > There's no right or wrong approach, one must be comfortable with the
>>> > chosen solution to be able to maintain it.
>>> >
>>> > -ovidiu
>>> >
>>> > On Sat, Jan 15, 2022 at 9:14 PM Chad <ccolumbu at hotmail.com <mailto:ccolumbu at hotmail.com>> wrote:
>>> >>
>>> >> Ok so in short I was not doing anything wrong (although I had some miss-configurations), but the carrier is
>>> (i.e. they
>>> >> are a bad actor). When they said I was doing it wrong, they did not mean in the RFC sense they meant in the
>>> "to work
>>> >> with us" sense. Now in order for me to get it to work with their SBC I have to mangle the contact on the way
>>> out an
>>> >> unmangle it on the return in Kamailio somehow, as I originally purposed.
>>> >> However I have no idea how to do that :)
>>> >>
>>> >> Shouldn't we (the Kamailio community) assume there are lots of bad actors out there and possibly many
>>> Kamailio users
>>> >> with this exact same issue (I personally know of at least 2 bad actor carriers right now) and create some
>>> kind of
>>> >> template or snippet that we can publicly publish on the Kamailio docs or wiki for all of the Kamailio community
>>> to use
>>> >> for this use case?
>>> >>
>>> >> I have been fighting with carriers about this for years and they always said I was doing it wrong and I don't
>>> know the
>>> >> SIP RFC well enough to fight back. So why not build a solution for everyone out there that has to deal with a
>>> bad actor?
>>> >>
>>> >> --
>>> >> ^C
>>> >>
>>> >>
>>> >> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>>> >>> As expected, your carrier is bogus and "thinks" it knows better.
>>> >>> Your carrier is treating your setup as a dumb endpoint and is
>>> >>> re-writing the Contact header:
>>> >>> You provide this contact header in 200 OK:
>>> >>> Contact: <sip:928#######@10.###.###.104:5060>
>>> >>> The carrier should set the RURI in ACK like this:
>>> >>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>>> >>> Instead, your ACK is sent to you like this:
>>> >>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>> >>>
>>> >>> The RURI in ACK should point to the private IP of the asterisk server,
>>> >>> not to the public IP of the kamailio server.
>>> >>> You need to ask the carrier to follow the SIP RFC and not treat your
>>> >>> endpoints like dumb SIP endpoints.
>>> >>>
>>> >>> There's a high chance that they won't do it :)
>>> >>> Your best chance is to manually mangle the URI in Contact in the 200
>>> >>> OK in a way that when you receive the ACK with the mangled RURI, you
>>> >>> can restore the original URI and let kamailio do the proper routing to
>>> >>> the private IP of the asterisk serverr.
>>> >>> You should be able to achieve this by using one of the following functions:
>>> >>> https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
>>> <https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
>>> >>> https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact
>>> <https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact>
>>> >>> https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode
>>> <https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode>
>>> >>>
>>> >>> Regards,
>>> >>> Ovidiu Sas
>>> >>>
>>> >>> On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu at hotmail.com <mailto:ccolumbu at hotmail.com>> wrote:
>>> >>>>
>>> >>>> I changed the listen per your advice and here is the 200 and ACK.
>>> >>>> I get no audio and the the call disconnects and I see this is the Asterisk log:
>>> >>>> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout reached on transmission
>>> >>>> 5ab1525b3712f34c2ab272ae55e649e5 at 10.44.109.143:5060
>>> <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060> for seqno 102 (Critical Response) -- See
>>> >>>> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
>>> <https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>
>>> >>>> Packet timed out after 6401ms with no response
>>> >>>> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call
>>> 5ab1525b3712f34c2ab272ae55e649e5 at 10.44.109.143:5060 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>
>>> - no
>>> >>>> reply to our critical packet (see https://wiki.asterisk.org/wik <https://wiki.asterisk.org/wik>
>>> >>>>
>>> >>>> FYI 10.###.###.254 is the private virtual IP on the Kamailio server and 10.###.###.104 is the asterisk box.
>>> >>>>
>>> >>>> SIP/2.0 200 OK
>>> >>>> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0
>>> >>>> Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1
>>> >>>> Record-Route: <sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0>
>>> >>>> Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0>
>>> >>>> Record-Route: <sip:64.###.###.###;lr;ftag=as04035ef0>
>>> >>>> From: "Anonymous" <sip:anonymous at anonymous.invalid:5060>;tag=as04035ef0
>>> >>>> To: <sip:928#######@64.###.###.###:5060>;tag=as7047ed05
>>> >>>> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5 at 10.44.###.###:5060
>>> >>>> CSeq: 102 INVITE
>>> >>>> Server: Asterisk PBX 16.18.0
>>> >>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
>>> >>>> Supported: replaces, timer
>>> >>>> Contact: <sip:928#######@10.###.###.104:5060>
>>> >>>> Content-Type: application/sdp
>>> >>>> Content-Length: 274
>>> >>>>
>>> >>>> v=0
>>> >>>> o=root 1911037741 1911037741 IN IP4 209.###.###.###
>>> >>>> s=Asterisk PBX 16.18.0
>>> >>>> c=IN IP4 209.###.###.###
>>> >>>> t=0 0
>>> >>>> m=audio 11384 RTP/AVP 0 101
>>> >>>> a=rtpmap:0 PCMU/8000
>>> >>>> a=rtpmap:101 telephone-event/8000
>>> >>>> a=fmtp:101 0-16
>>> >>>> a=ptime:20
>>> >>>> a=maxptime:150
>>> >>>> a=sendrecv
>>> >>>> a=nortpproxy:yes
>>> >>>>
>>> >>>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>> >>>> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2
>>> >>>> Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1
>>> >>>> Max-Forwards: 67
>>> >>>> From: "Anonymous" <sip:anonymous at anonymous.invalid:5060>;tag=as04035ef0
>>> >>>> To: <sip:928#######@64.###.###.###:5060>;tag=as7047ed05
>>> >>>> Contact: <sip:anonymous at 206.###.###.###:5060;transport=udp>
>>> >>>> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5 at 10.44.###.###:5060
>>> >>>> CSeq: 102 ACK
>>> >>>> User-Agent: packetrino
>>> >>>> Content-Length: 0
>>> >>>> Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0>
>>> >>>> Route: <sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> ^C
>>> >>>>
>>> >>>>
>>> >>>> On 1/15/22 10:21 AM, Ovidiu Sas wrote:
>>> >>>>> This is false. The IP in the Contact header must be routable by the
>>> >>>>> SIP hop from the top Record-Route header in the reply.
>>> >>>>> The carrier (and it seems that they have a PROXY also) must be able to
>>> >>>>> route to their adjacent SIP hop, which is your public IP (the IP in
>>> >>>>> the second Record-Route header).
>>> >>>>> It seems that the carrier is not taking into account that they might
>>> >>>>> interface with other proxies.
>>> >>>>> Most likely, your carrier expects to interface with a simple SIP UA,
>>> >>>>> not with another proxy. This is a pretty common setup for most of the
>>> >>>>> carriers, although many new carrier implementations are taking care of
>>> >>>>> the proxy to proxy calls.
>>> >>>>>
>>> >>>>> It would be helpful to see the ACK that is sent by the carrier in
>>> >>>>> response to your 200ok (after you fix your config and you have your
>>> >>>>> private IP listed in the Record-Route header).
>>> >>>>>
>>> >>>>> -ovidiu
>>> >>>>>
>>> >>>>> On Sat, Jan 15, 2022 at 12:33 PM Chad <ccolumbu at hotmail.com <mailto:ccolumbu at hotmail.com>> wrote:
>>> >>>>>>
>>> >>>>>> Hmm, I don't think you are right that the Contact header can be a private IP even if the RR is correct.
>>> >>>>>> I did some research on it and I found several places saying it must be a routable IP which is what the
>>> carrier also said.
>>> >>>>>>
>>> >>>>>> "The Contact header contains the SIP URI where the client wants to be contacted for subsequent requests.
>>> That means that
>>> >>>>>> the host part of the URI must be globally reachable by anyone.
>>> >>>>>> If your contact contains a private IP (behind a NAT?) then it is wrong, because other peers cannot reach you
>>> with that."
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> ^C
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On 1/15/22 9:05 AM, Ovidiu Sas wrote:
>>> >>>>>>> You have a different problem then.
>>> >>>>>>> Having private IPs in Contact is fine. You need to lose route the
>>> >>>>>>> calls (kamailio will add two Record-Route headers) and the origination
>>> >>>>>>> server will set the RURI to the private IP from Contact, but it will
>>> >>>>>>> send the in-dialog requests to the public IP of kamailio. This has
>>> >>>>>>> nothing to do with virtual IPs.
>>> >>>>>>> Maybe you have a buggy client that doesn't do proper loose routing.
>>> >>>>>>>
>>> >>>>>>> -ovidiu
>>> >>>>>>>
>>> >>>>>>> On Sat, Jan 15, 2022 at 11:50 AM Chad <ccolumbu at hotmail.com <mailto:ccolumbu at hotmail.com>> wrote:
>>> >>>>>>>>
>>> >>>>>>>> Ovidiu,
>>> >>>>>>>> Thank you again for your response.
>>> >>>>>>>> One is public (an internet IP) and one is private (a 10.x ip).
>>> >>>>>>>> Apparently this is a known problem with virtual IPs, it does not work.
>>> >>>>>>>> When the asterisk server responds to the invite it sends a contact header with the private IP and Kamailio
>>> does not
>>> >>>>>>>> rewrite it to the advertised public IP. So the originating server sees the private IP in the Contact
>>> header and tries to
>>> >>>>>>>> send the traffic to the 10.x IP (which is non-routable) and the call dies.
>>> >>>>>>>> I have been trying things for a long time to fix this (years) what you are saying will not fix it because
>>> of the virtual
>>> >>>>>>>> IPs.
>>> >>>>>>>> If it was a normal IP it would work fine. It has something to do with the routing table and how mhomed
>>> detects networks.
>>> >>>>>>>>
>>> >>>>>>>> --
>>> >>>>>>>> ^C
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
>>> >>>>>>>>> Hello Chad,
>>> >>>>>>>>>
>>> >>>>>>>>> The floating IPs that you have, are they both private IPs or one
>>> >>>>>>>>> private IP and the other one a public IP?
>>> >>>>>>>>>
>>> >>>>>>>>> If you have to two floating private IPs, then you need a config like this:
>>> >>>>>>>>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
>>> >>>>>>>>> listen=FLOATING_UDP_PRIVATE2
>>> >>>>>>>>>
>>> >>>>>>>>> In the config, before relaying the initial INVITE you need to detect
>>> >>>>>>>>> the direction of the call and set $fs accordingly:
>>> >>>>>>>>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {
>>> >>>>>>>>> $fs = udp:FLOATING_UDP_PRIVATE1
>>> >>>>>>>>> }
>>> >>>>>>>>> else {
>>> >>>>>>>>> $fs = udp:FLOATING_UDP_PRIVATE2
>>> >>>>>>>>> }
>>> >>>>>>>>>
>>> >>>>>>>>> If you have a floating private IPs and a floating public IP, then you
>>> >>>>>>>>> need a config like this:
>>> >>>>>>>>> listen=FLOATING_UDP_PRIVATE
>>> >>>>>>>>> listen=FLOATING_UDP_PUBLIC
>>> >>>>>>>>>
>>> >>>>>>>>> There should be no need to force the socket, but if you do, there's no
>>> >>>>>>>>> harm (actually it's better and faster).
>>> >>>>>>>>>
>>> >>>>>>>>> Hope this clarifies things and helps,
>>> >>>>>>>>> -ovidiu
>>> >>>>>>>>>
>>> >>>>>>>>> On Sat, Jan 15, 2022 at 9:48 AM Chad <ccolumbu at hotmail.com <mailto:ccolumbu at hotmail.com>> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>> Ovidiu,
>>> >>>>>>>>>> Thank you for your response.
>>> >>>>>>>>>>
>>> >>>>>>>>>> I have done that, in addition to the linux ip_nonlocal_bind I have also set the Kamailio ip_free_bind=1
>>> and it does not
>>> >>>>>>>>>> work.
>>> >>>>>>>>>> Here are my relevant config lines:
>>> >>>>>>>>>> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
>>> >>>>>>>>>> listen=LISTEN_UDP_PUBLIC
>>> >>>>>>>>>>
>>> >>>>>>>>>> mhomed=1
>>> >>>>>>>>>> ip_free_bind=1
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have been using it for a long time
>>> and have
>>> >>>>>>>>>> rebooted as well):
>>> >>>>>>>>>> net.ipv4.ip_nonlocal_bind=1
>>> >>>>>>>>>> --
>>> >>>>>>>>>> ^C
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
>>> >>>>>>>>>>> Hello Chad,
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> You can add a listen directive to your config for the virtual IPs
>>> >>>>>>>>>>> (both public and private) and then you don't need to manually modify
>>> >>>>>>>>>>> any headers or use force_send_socket().
>>> >>>>>>>>>>> You need to enable non local IP binding so kamailio can start on the
>>> >>>>>>>>>>> server that doesn't have the virtual IP:
>>> >>>>>>>>>>> echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
>>> >>>>>>>>>>> To make the change permanent, edit your sysctl.conf file and enable it there:
>>> >>>>>>>>>>> net/ipv4/ip_nonlocal_bind = 1
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Regards
>>> >>>>>>>>>>> Ovidiu Sas
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On Sat, Jan 15, 2022 at 4:16 AM Chad <ccolumbu at hotmail.com <mailto:ccolumbu at hotmail.com>> wrote:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup.
>>> >>>>>>>>>>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our
>>> private IP asterisk
>>> >>>>>>>>>>>> servers (via dispatcher).
>>> >>>>>>>>>>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created
>>> by keepalived.
>>> >>>>>>>>>>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the
>>> traffic.
>>> >>>>>>>>>>>> We run linux Debian 10 for the OS.
>>> >>>>>>>>>>>> Also we do not use a DB at all, everything is done with local config files.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> The problem is that when traffic goes out the Contact header has a private IP in it, like:
>>> >>>>>>>>>>>> Contact: <sip:##########@10.10.10.###]:5060 <http://10.10.10.#%23%23]:5060>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> There are 2 possible solutions to this:
>>> >>>>>>>>>>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so
>>> that mhomed and
>>> >>>>>>>>>>>> fix_nated_contact work as usual.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> 2. Create a manual header rewrite system.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> If solution #2:
>>> >>>>>>>>>>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out,
>>> and on the way back
>>> >>>>>>>>>>>> rewrite it back to the internal server that the call is already connected to.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with
>>> another persistant
>>> >>>>>>>>>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field
>>> or something).
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Thank you all for your time.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> --
>>> >>>>>>>>>>>> ^C
>>> >>>>>>>>>>>> Chad
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> __________________________________________________________
>>> >>>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> >>>>>>>>>>>> * sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>> >>>>>>>>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>> >>>>>>>>>>>> Edit mailing list options or unsubscribe:
>>> >>>>>>>>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> --
>>> >>>>>>>>>>> VoIP Embedded, Inc.
>>> >>>>>>>>>>> http://www.voipembedded.com <http://www.voipembedded.com>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> __________________________________________________________
>>> >>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> >>>>>>>>>>> * sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>> >>>>>>>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>> >>>>>>>>>>> Edit mailing list options or unsubscribe:
>>> >>>>>>>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>
>>> >>>
>>> >>>
>>> >
>>> >
>>> >
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com <http://www.voipembedded.com>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
More information about the sr-users
mailing list