[SR-Users] topos module - possible bug

Sergey Basov sergey.v.basov at gmail.com
Wed May 10 07:09:56 CEST 2017


Hi Pete,

I think you can try with latest nightly build.
Daniel has committed fix at 08 March late evening.
So I think it included in latest nightly build.

--
Best regards,
Sergey Basov                     e-mail: sergey.v.basov at gmail.com

2017-05-08 16:37 GMT+03:00 Sergey Basov <sergey.v.basov at gmail.com>:

> Hi.
>
> No.  Daniel does not merged fix yet.
> And he needs some time to backport it to 5.0 branch
>
> --
> WBR
> Sergey Basov
>
> 8 мая 2017 г. 4:34 PM пользователь "Pete Kelly" <pkelly at gmail.com>
> написал:
>
> Is this fix in the nightly .deb build?
>>
>> I've just tested the latest and it's still broken
>>
>> On 8 May 2017 at 07:50, Sergey Basov <sergey.v.basov at gmail.com> wrote:
>>
>>> Hi, Daniel.
>>>
>>> I have created pool request
>>>
>>> https://github.com/kamailio/kamailio/pull/1124
>>> --
>>> Best regards,
>>> Sergey Basov                     e-mail: sergey.v.basov at gmail.com
>>>
>>>
>>> 2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>> > Try to make a pull request for it and if all ok it will be merged.
>>> >
>>> > Cheers,
>>> > Daniel
>>> >
>>> >
>>> > On 06.05.17 17:20, Sergey Basov wrote:
>>> >> I found issue cause.
>>> >>
>>> >> After I have changed line 792 of the file tps_msg.c
>>> >> from
>>> >> if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
>>> >>
>>> >> to
>>> >> if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
>>> >>
>>> >> now route header are restores in from:
>>> >>
>>> >> Route: <sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4
>>> Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9
>>> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE
>>> AAgcAAAABAAAAAAAAAAAAAAAA>
>>> >> Route: <sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr>
>>> >>
>>> >> Now ACK are routed correctly.
>>> >>
>>> >> Seems that earlier, before fix b_rr store into DB, we does not see
>>> >> this issue, because only last route header was saved...
>>> >> But after fix, we have all route records so we nned to restore it into
>>> >> wright way.
>>> >>
>>> >> Now I have worked scheme with 3 kamailio in a row, on first of them
>>> >> enabled topos on other only topoh module.
>>> >>
>>> >> Daniel, I will send to you latest dump in separate e-mail.
>>> >>
>>> >> Thank you.
>>> >>
>>> >> --
>>> >> Best regards,
>>> >> Sergey Basov                     e-mail: sergey.v.basov at gmail.com
>>> >>
>>> >>
>>> >> 2017-05-05 23:16 GMT+03:00 Sergey Basov <sergey.v.basov at gmail.com>:
>>> >>> I think it is because wrong order of Route: header after restoring...
>>> >>>
>>> >>> With topoh enabled I have:
>>> >>>
>>> >>> Route: <sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5d
>>> Uv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9
>>> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE
>>> AAgcAAAABAAAAAAAAAAAAAAAA>
>>> >>> Route: <sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr>
>>> >>>
>>> >>> But with topos enabled I have:
>>> >>>
>>> >>> Route: <sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr>,<sip:10.56.42
>>> .37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5c
>>> e1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlc
>>> j1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAA
>>> AAAAAAAAAAAA>
>>> >>>
>>> >>> And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
>>> >>>
>>> >>> Can you fix it? Or I going in to wrong directuon?
>>> >>>
>>> >>> Thank you.
>>> >>> --
>>> >>> Best regards,
>>> >>> Sergey Basov                     e-mail: sergey.v.basov at gmail.com
>>> >>>
>>> >>>
>>> >>> 2017-05-05 20:32 GMT+03:00 Sergey Basov <sergey.v.basov at gmail.com>:
>>> >>>> Hi Daniel
>>> >>>>
>>> >>>> Semms now we have ankther problem...
>>> >>>>
>>> >>>> b_rr weites in db correctly.
>>> >>>> But when ack is sending from A side it try to send to B side to
>>> cantact ip,
>>> >>>> ignoring record-route headers...
>>> >>>>
>>> >>>> I will try to debug this.
>>> >>>>
>>> >>>> If you have any idea I can test it.
>>> >>>>
>>> >>>> Thank you.
>>> >>>>
>>> >>>> --
>>> >>>> WBR
>>> >>>> Sergey Basov
>>> >>>>
>>> >>>> 28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov"
>>> >>>> <sergey.v.basov at gmail.com> написал:
>>> >>>>
>>> >>>>> Hi Daniel.
>>> >>>>>
>>> >>>>> Seems all is ok now.
>>> >>>>>
>>> >>>>> I applyed your patch and add my additional debug string.
>>> >>>>>
>>> >>>>> Now result is:
>>> >>>>>
>>> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
>>> >>>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
>>> b_rr:
>>> >>>>>
>>> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>>> k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>> >>>>>
>>> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
>>> >>>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
>>> b_rr:
>>> >>>>>
>>> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>>> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.
>>> sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReR
>>> XWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTs
>>> XnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTs
>>> XnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](349)
>>> >>>>>
>>> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
>>> >>>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
>>> b_rr:
>>> >>>>>
>>> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>>> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.
>>> sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReR
>>> XWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTs
>>> XnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTs
>>> XnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.
>>> 56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
>>> did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjU
>>> wNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>>> QAAAAOAAAAAAAAAAAAAAAA>](556)
>>> >>>>>
>>> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
>>> >>>>> [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr:
>>> [](0) -
>>> >>>>> b_rr:
>>> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>>> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.
>>> sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReR
>>> XWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTs
>>> XnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTs
>>> XnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.
>>> 56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
>>> did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjU
>>> wNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>>> QAAAAOAAAAAAAAAAAAAAAA>](556)
>>> >>>>> - s_rr: [](0)
>>> >>>>>
>>> >>>>>
>>> >>>>> Seems this issue is solved.
>>> >>>>>
>>> >>>>> Can you apply this patch to 5.0 branch?
>>> >>>>> Then may be Pete Kelly will install nightly build of the 5.0.1 and
>>> >>>>> confirm that issu is solved.
>>> >>>>>
>>> >>>>> I does not have such count of sbc for test )
>>> >>>>>
>>> >>>>> Thank you Daniel.
>>> >>>>> --
>>> >>>>> Best regards,
>>> >>>>> Sergey Basov                     e-mail: sergey.v.basov at gmail.com
>>> >>>>>
>>> >>>>>
>>> >>>>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
>>> miconda at gmail.com>:
>>> >>>>>> Hello,
>>> >>>>>>
>>> >>>>>> many thanks Sergey for troubleshooting, it saved a lot of time!
>>> >>>>>> Hopefully I caught the issue. Can you test with latest master
>>> branch and
>>> >>>>>> let me know if works?
>>> >>>>>>
>>> >>>>>> Cheers,
>>> >>>>>> Daniel
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On 28.04.17 14:57, Sergey Basov wrote:
>>> >>>>>>> Some more debug
>>> >>>>>>>
>>> >>>>>>> after adding debug output after each iteration I got:
>>> >>>>>>>
>>> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
>>> >>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
>>> b_rr:
>>> >>>>>>>
>>> >>>>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>>> k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
>>> >>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
>>> b_rr:
>>> >>>>>>>
>>> >>>>>>> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZA
>>> eLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.
>>> zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn
>>> TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXn
>>> TsFnTsXnTsXnTsXnTsXnTsXn>](348)
>>> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
>>> >>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
>>> b_rr:
>>> >>>>>>>
>>> >>>>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
>>> -4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h
>>> 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>>> AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>> >>>>>>>
>>> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
>>> >>>>>>> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr:
>>> [](0) -
>>> >>>>>>> b_rr:
>>> >>>>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
>>> -4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h
>>> 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>>> AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>> >>>>>>> - s_rr: [](0)
>>> >>>>>>>
>>> >>>>>>> So size are computed correctly, but part of record-routes
>>> >>>>>>> disappears.... And we can see correct size of the record but
>>> only last
>>> >>>>>>> part of the record-routes
>>> >>>>>>>
>>> >>>>>>> Hope it helps
>>> >>>>>>> --
>>> >>>>>>> Best regards,
>>> >>>>>>> Sergey Basov                     e-mail:
>>> sergey.v.basov at gmail.com
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <
>>> sergey.v.basov at gmail.com>:
>>> >>>>>>>> One more detail
>>> >>>>>>>>
>>> >>>>>>>> When debug=3 I see in logs (look at size of record and it
>>> contents)
>>> >>>>>>>>
>>> >>>>>>>> Apr 28 14:16:44 csbc-uat /usr/sbin/kamailio[13287]: DEBUG: topos
>>> >>>>>>>> [tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr:
>>> [](0) -
>>> >>>>>>>> b_rr: [](0) - s_rr:
>>> >>>>>>>>
>>> >>>>>>>> [<sip:10.56.42.33;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOf
>>> IVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX
>>> 14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9B
>>> RxjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:
>>> 5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;
>>> did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14CTU
>>> wNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYG
>>> AUeXl/dRU2PChyPXBob25l;nat=yes>](453)
>>> >>>>>>>>
>>> >>>>>>>> 453 - is a real size of shown header
>>> >>>>>>>>
>>> >>>>>>>> s_rr parses normal, but b_rr
>>> >>>>>>>>
>>> >>>>>>>> Apr 28 14:16:48 csbc-uat /usr/sbin/kamailio[13273]: DEBUG: topos
>>> >>>>>>>> [tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr:
>>> [](0) -
>>> >>>>>>>> b_rr:
>>> >>>>>>>> [<sip:10.56.42.33:5090;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfI
>>> VTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9
>>> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>>> AAAQAAAAOAAAAAAAAAAAAAAAA>](553)
>>> >>>>>>>> - s_rr: [](0)
>>> >>>>>>>>
>>> >>>>>>>> 553 - seems a real correct size of the recordroute header and it
>>> >>>>>>>> differs from size with \0 at the end
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> --
>>> >>>>>>>> Best regards,
>>> >>>>>>>> Sergey Basov                     e-mail:
>>> sergey.v.basov at gmail.com
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <
>>> sergey.v.basov at gmail.com>:
>>> >>>>>>>>> Hi All.
>>> >>>>>>>>>
>>> >>>>>>>>> I just try to pass call throught 3 kamailio.
>>> >>>>>>>>> I got result like yours
>>> >>>>>>>>>
>>> >>>>>>>>> If you need testers for patch - I am ready )
>>> >>>>>>>>>
>>> >>>>>>>>> --
>>> >>>>>>>>> Best regards,
>>> >>>>>>>>> Sergey Basov                     e-mail:
>>> sergey.v.basov at gmail.com
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla
>>> >>>>>>>>> <miconda at gmail.com>:
>>> >>>>>>>>>> There seems to be an issue saving the record-route list for
>>> b-side
>>> >>>>>>>>>> in
>>> >>>>>>>>>> topos_d table -- first two are saved but then there are only 0
>>> >>>>>>>>>> characters
>>> >>>>>>>>>> instead of the rest of record routes:
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> '<sip:192.168.252.75;r2=on;lr=on;ftag=A1;did=072.87c;rtpi=1;
>>> nat=no;rtpi=1>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
>>> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
>>> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
>>> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
>>> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
>>> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0'
>>> >>>>>>>>>>
>>> >>>>>>>>>>  I will have to dig a bit into the code.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Cheers, Daniel
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> On 27.04.17 14:30, Pete Kelly wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>> Yes no problem. I wanted to come but the life schedule would
>>> not
>>> >>>>>>>>>> allow it
>>> >>>>>>>>>> this time.
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> On 27 April 2017 at 13:11, Daniel-Constantin Mierla
>>> >>>>>>>>>> <miconda at gmail.com>
>>> >>>>>>>>>> wrote:
>>> >>>>>>>>>>> Hello,
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> time, I need more time :-) ... with Kamailio World Conference
>>> >>>>>>>>>>> around the
>>> >>>>>>>>>>> corner, I am caught in a lot of admin tasks...
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Daniel
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On 27.04.17 13:11, Pete Kelly wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Hi Daniel
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Is there anything else you need on this?
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On 26 April 2017 at 15:06, Pete Kelly <pkelly at gmail.com>
>>> wrote:
>>> >>>>>>>>>>>> Hi Daniel
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> It's CSeq 1, fromtag A1
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> DB attached
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla
>>> >>>>>>>>>>>> <miconda at gmail.com>
>>> >>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>> Can you paste here the from tag or cseq for the dialog you
>>> are
>>> >>>>>>>>>>>>> referring
>>> >>>>>>>>>>>>> to? Because the number of frames are not matching my pcap
>>> viewer.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Send also the db dump, they should reveal if something is
>>> broken
>>> >>>>>>>>>>>>> there.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Cheers,
>>> >>>>>>>>>>>>> Daniel
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> On 26.04.17 14:46, Pete Kelly wrote:
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Ah I see why it is confusing
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> This setup maintains a Call-ID through an SBC downstream,
>>> so the
>>> >>>>>>>>>>>>> INVITE's you see have the same Call-ID but they have a
>>> different
>>> >>>>>>>>>>>>> fromtag/cseq, Wireshark shows them all as one call which is
>>> >>>>>>>>>>>>> annoying when
>>> >>>>>>>>>>>>> looking at the viewer!
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> If you check the first call only between 252.70 and 252.75
>>> you
>>> >>>>>>>>>>>>> will see
>>> >>>>>>>>>>>>> INVITE (frame 4), 200OK (frame 16) with lots of RR headers.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> The ACK generated by topos (frame 21) only contains 1 Route
>>> >>>>>>>>>>>>> header, it
>>> >>>>>>>>>>>>> should contain more so the request can hop through the
>>> proxy
>>> >>>>>>>>>>>>> chain as shown
>>> >>>>>>>>>>>>> in frame 16.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> I see the example from Sergey is working, but there is
>>> only 1 RR
>>> >>>>>>>>>>>>> header
>>> >>>>>>>>>>>>> in this example - as you can see from my example the topos
>>> module
>>> >>>>>>>>>>>>> uses the
>>> >>>>>>>>>>>>> first RR header but ignores the other 5.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> I have the DB dump and logfiles from this call too if
>>> useful.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Pete
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> On 26 April 2017 at 12:41, Daniel-Constantin Mierla
>>> >>>>>>>>>>>>> <miconda at gmail.com>
>>> >>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>> As I could notice upon a quick look, there seems to be
>>> two calls
>>> >>>>>>>>>>>>>> -- two
>>> >>>>>>>>>>>>>> INVITE requests having same call id but different cseq.
>>> Can you
>>> >>>>>>>>>>>>>> confirm
>>> >>>>>>>>>>>>>> this is the case? Because the capture doesn't seem to
>>> have all
>>> >>>>>>>>>>>>>> the
>>> >>>>>>>>>>>>>> incoming/outgoing messages, some are missing.
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Cheers,
>>> >>>>>>>>>>>>>> Daniel
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> On 26.04.17 12:59, Sergey Basov wrote:
>>> >>>>>>>>>>>>>>> You give to us very hard callflow...
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Without any pauses between responces..
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Some requests go through 127.0.0.1... But responces from
>>> >>>>>>>>>>>>>>> 127.0.0.1
>>> >>>>>>>>>>>>>>> not present.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> There are peers from which invites not present in dump.
>>> I can
>>> >>>>>>>>>>>>>>> not see
>>> >>>>>>>>>>>>>>> ful path of the initial Invite, but there is responses.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> I will send dump in next email directly.
>>> >>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>> Best regards,
>>> >>>>>>>>>>>>>>> Sergey Basov                     e-mail:
>>> >>>>>>>>>>>>>>> sergey.v.basov at gmail.com
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly at gmail.com
>>> >:
>>> >>>>>>>>>>>>>>>> Attached is the pcap from latest nightly.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> As you can see (frame 21) the ACK is incorrect, I
>>> believe it
>>> >>>>>>>>>>>>>>>> should
>>> >>>>>>>>>>>>>>>> specify
>>> >>>>>>>>>>>>>>>> all the hops from the 200OK (frame 16) so that the hop
>>> by hop
>>> >>>>>>>>>>>>>>>> ACK
>>> >>>>>>>>>>>>>>>> can be
>>> >>>>>>>>>>>>>>>> routed via the proxy chain.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> topoh module works fine.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> Pete
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> On 26 April 2017 at 05:18, Sergey Basov
>>> >>>>>>>>>>>>>>>> <sergey.v.basov at gmail.com>
>>> >>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>> I dont know how nightly builds are done.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Just try with latest 5.0.1 nightly and send new dump.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> As I understud topos module done to remove record-route
>>> >>>>>>>>>>>>>>>>> headers to
>>> >>>>>>>>>>>>>>>>> hide
>>> >>>>>>>>>>>>>>>>> topology...  Am I wright,  Daniel?
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> And try to disable topos module and enable topoh
>>> module. Will
>>> >>>>>>>>>>>>>>>>> it
>>> >>>>>>>>>>>>>>>>> all work
>>> >>>>>>>>>>>>>>>>> as you expecrs?
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>> WBR
>>> >>>>>>>>>>>>>>>>> Sergey Basov
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> 25 апр. 2017 г. 11:31 PM пользователь "Pete Kelly"
>>> >>>>>>>>>>>>>>>>> <pkelly at gmail.com>
>>> >>>>>>>>>>>>>>>>> написал:
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> I have tried with 5.0.1 from today (25th April).
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> Are you saying build for 26th will have some fixes?
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> On 25 April 2017 at 18:59, Sergey Basov
>>> >>>>>>>>>>>>>>>>>> <sergey.v.basov at gmail.com>
>>> >>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>> Actualy latest fixes to 180/183/200,  ACK and memory
>>> leak
>>> >>>>>>>>>>>>>>>>>>> was
>>> >>>>>>>>>>>>>>>>>>> pushed to
>>> >>>>>>>>>>>>>>>>>>> 5.0 and master branch.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> So, please try with latest 5.0.1 nightly.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>> WBR
>>> >>>>>>>>>>>>>>>>>>> Sergey Basov
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> 25 апр. 2017 г. 8:55 PM пользователь "Pete Kelly"
>>> >>>>>>>>>>>>>>>>>>> <pkelly at gmail.com>
>>> >>>>>>>>>>>>>>>>>>> написал:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> Call is with sipp but first goes through another
>>> SBC to
>>> >>>>>>>>>>>>>>>>>>>> clean up
>>> >>>>>>>>>>>>>>>>>>>> the
>>> >>>>>>>>>>>>>>>>>>>> SIP (in case of problems with sipp via headers etc).
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> The traces I've done are actually with 4.4.
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> Will they be OK or would you prefer 5.0.1? The
>>> problem is
>>> >>>>>>>>>>>>>>>>>>>> exactly the
>>> >>>>>>>>>>>>>>>>>>>> same on both.
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> On 25 April 2017 at 16:25, Sergey Basov
>>> >>>>>>>>>>>>>>>>>>>> <sergey.v.basov at gmail.com>
>>> >>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>> Hi.
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> Can you send dump of the call with kamailio 5.0.1
>>> >>>>>>>>>>>>>>>>>>>>> nightly?
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> And does you make call using sipp?
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>>>> WBR
>>> >>>>>>>>>>>>>>>>>>>>> Sergey Basov
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> 25 апр. 2017 г. 5:57 PM пользователь "Pete Kelly"
>>> >>>>>>>>>>>>>>>>>>>>> <pkelly at gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>> написал:
>>> >>>>>>>>>>>>>>>>>>>>>> Looks like from last night:
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> 5.0.1+0~20170425013247.36+trusty
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> On 25 April 2017 at 15:42, Daniel-Constantin
>>> Mierla
>>> >>>>>>>>>>>>>>>>>>>>>> <miconda at gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>> Hello,
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> to be sure, it is 5.0.1 build from last night or
>>> quite
>>> >>>>>>>>>>>>>>>>>>>>>>> recent? There
>>> >>>>>>>>>>>>>>>>>>>>>>> were some fixes in the past days to topos module.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>> >>>>>>>>>>>>>>>>>>>>>>> Daniel
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> On 25.04.17 15:59, Pete Kelly wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Daniel
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Sorry for the delayed response to this, the ACK
>>> is for
>>> >>>>>>>>>>>>>>>>>>>>>>> a
>>> >>>>>>>>>>>>>>>>>>>>>>> 200OK yes
>>> >>>>>>>>>>>>>>>>>>>>>>> and the problem still persists in latest 4.4 and
>>> the
>>> >>>>>>>>>>>>>>>>>>>>>>> 5.0.1
>>> >>>>>>>>>>>>>>>>>>>>>>> nightly build.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> I have all DB entries/kam logs/pcap files.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> If you check the attached pcap, 192.168.70.70 and
>>> >>>>>>>>>>>>>>>>>>>>>>> 192.168.252.70 are
>>> >>>>>>>>>>>>>>>>>>>>>>> the same instance of Kamailio, it is being used
>>> to
>>> >>>>>>>>>>>>>>>>>>>>>>> bridge the
>>> >>>>>>>>>>>>>>>>>>>>>>> 2 networks.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Frame 34 shows the 200OK with lots of
>>> Record-Route etc,
>>> >>>>>>>>>>>>>>>>>>>>>>> and
>>> >>>>>>>>>>>>>>>>>>>>>>> frame 35
>>> >>>>>>>>>>>>>>>>>>>>>>> shows topos in action.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> However the ACK that is relayed in Frame 38
>>> seems to be
>>> >>>>>>>>>>>>>>>>>>>>>>> missing all
>>> >>>>>>>>>>>>>>>>>>>>>>> the Route information that was supplied in the
>>> 200OK,
>>> >>>>>>>>>>>>>>>>>>>>>>> this
>>> >>>>>>>>>>>>>>>>>>>>>>> causes the ACK to
>>> >>>>>>>>>>>>>>>>>>>>>>> be relayed directly to the Contact, breaking the
>>> proxy
>>> >>>>>>>>>>>>>>>>>>>>>>> chain.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Pete
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> On 22 February 2017 at 18:31, Daniel-Constantin
>>> Mierla
>>> >>>>>>>>>>>>>>>>>>>>>>> <miconda at gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> is the ACK for 200ok? Or an ack for a negative
>>> >>>>>>>>>>>>>>>>>>>>>>>> response?
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Can you get a pcap for such situation with all
>>> >>>>>>>>>>>>>>>>>>>>>>>> messages
>>> >>>>>>>>>>>>>>>>>>>>>>>> related to
>>> >>>>>>>>>>>>>>>>>>>>>>>> the call?
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>> >>>>>>>>>>>>>>>>>>>>>>>> Daniel
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> On 22/02/2017 17:20, Pete Kelly wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> I am using the topos module when bridging 2
>>> networks
>>> >>>>>>>>>>>>>>>>>>>>>>>> with
>>> >>>>>>>>>>>>>>>>>>>>>>>> Kamailio.
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> The INVITE/200OK part of the transaction is
>>> working
>>> >>>>>>>>>>>>>>>>>>>>>>>> fine
>>> >>>>>>>>>>>>>>>>>>>>>>>> (i.e. the
>>> >>>>>>>>>>>>>>>>>>>>>>>> Contact on both sides matches correctly the
>>> >>>>>>>>>>>>>>>>>>>>>>>> corresponding
>>> >>>>>>>>>>>>>>>>>>>>>>>> network).
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> However when the ACK is sent into Kamailio,
>>> instead of
>>> >>>>>>>>>>>>>>>>>>>>>>>> realising
>>> >>>>>>>>>>>>>>>>>>>>>>>> the next hop is myself and skipping it,
>>> Kamailio is
>>> >>>>>>>>>>>>>>>>>>>>>>>> sending
>>> >>>>>>>>>>>>>>>>>>>>>>>> the ACK directly
>>> >>>>>>>>>>>>>>>>>>>>>>>> to itself as a packet, causing the call setup to
>>> >>>>>>>>>>>>>>>>>>>>>>>> break.
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Does anyone have any advice for this situation?
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>>>>>>>>>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER)
>>> -
>>> >>>>>>>>>>>>>>>>>>>>>>>> sr-users
>>> >>>>>>>>>>>>>>>>>>>>>>>> mailing
>>> >>>>>>>>>>>>>>>>>>>>>>>> list
>>> >>>>>>>>>>>>>>>>>>>>>>>> sr-users at lists.sip-router.org
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> http://lists.sip-router.org/cg
>>> i-bin/mailman/listinfo/sr-users
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>>>>>>> Daniel-Constantin Mierla
>>> >>>>>>>>>>>>>>>>>>>>>>>> www.twitter.com/miconda --
>>> www.linkedin.com/in/miconda
>>> >>>>>>>>>>>>>>>>>>>>>>>> Kamailio Advanced Training - Mar 6-8 (Europe)
>>> and Mar
>>> >>>>>>>>>>>>>>>>>>>>>>>> 20-22
>>> >>>>>>>>>>>>>>>>>>>>>>>> (USA) -
>>> >>>>>>>>>>>>>>>>>>>>>>>> www.asipto.com
>>> >>>>>>>>>>>>>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>> >>>>>>>>>>>>>>>>>>>>>>>> www.kamailioworld.com
>>> >>>>>>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>>>>>> Daniel-Constantin Mierla
>>> >>>>>>>>>>>>>>>>>>>>>>> www.twitter.com/miconda --
>>> www.linkedin.com/in/miconda
>>> >>>>>>>>>>>>>>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) -
>>> >>>>>>>>>>>>>>>>>>>>>>> www.asipto.com
>>> >>>>>>>>>>>>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>> >>>>>>>>>>>>>>>>>>>>>>> www.kamailioworld.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.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> >>>>>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) -
>>> www.asipto.com
>>> >>>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>> >>>>>>>>>>>>>> www.kamailioworld.com
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>> --
>>> >>>>>>>>>>>>> Daniel-Constantin Mierla
>>> >>>>>>>>>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> >>>>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) -
>>> www.asipto.com
>>> >>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>> >>>>>>>>>>>>> www.kamailioworld.com
>>> >>>>>>>>>>> --
>>> >>>>>>>>>>> Daniel-Constantin Mierla
>>> >>>>>>>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> >>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) -
>>> www.asipto.com
>>> >>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>> www.kamailioworld.com
>>> >>>>>>>>>>
>>> >>>>>>>>>> --
>>> >>>>>>>>>> Daniel-Constantin Mierla
>>> >>>>>>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> >>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
>>> >>>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>> www.kamailioworld.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.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> >>>>>> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
>>> >>>>>> Kamailio World Conference - May 8-10, 2017 -
>>> www.kamailioworld.com
>>> >>>>>>
>>> >
>>> > --
>>> > Daniel-Constantin Mierla
>>> > www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> > Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
>>> > Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
>>> >
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170510/522efc22/attachment.html>


More information about the sr-users mailing list