Hello.
Pete, did you test this?
I am using this module after patch into production for 20 days without any provlems.
But, I have applied one more patch to fix contact before 200ok. Pool request is active till now) Without it, I have problems with terminating sip calls before 200ok.
-- WBR Sergey Basov
17 мая 2017 г. 4:51 PM пользователь "Pete Kelly" pkelly@gmail.com написал:
Thanks, I will do.
On 10 May 2017 at 06:09, Sergey Basov sergey.v.basov@gmail.com wrote:
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@gmail.com
2017-05-08 16:37 GMT+03:00 Sergey Basov sergey.v.basov@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@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@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@gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla <miconda@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@gmail.com > > > 2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@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-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAA AAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=A AAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA>
>> Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr >> >> But with topos enabled I have: >> >> Route: <sip:KITS1.MSS.LIFE.COM:5060;t
>> >> 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@gmail.com >> >> >> 2017-05-05 20:32 GMT+03:00 Sergey Basov <sergey.v.basov@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@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.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.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.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.5 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d4 1.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7d XNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAO AAAAAAAAAAAAAAAA](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.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.5 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d4 1.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7d XNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAO AAAAAAAAAAAAAAAA](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@gmail.com
>>>> >>>> >>>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
miconda@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@gmail.com
>>>>>> >>>>>> >>>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <
sergey.v.basov@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:506 1;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIV Tn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14 CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR xjYGAUeXl/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@gmail.com
>>>>>>> >>>>>>> >>>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <
sergey.v.basov@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@gmail.com
>>>>>>>> >>>>>>>> >>>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >>>>>>>> miconda@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@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@gmail.com
wrote:
>>>>>>>>>>> Hi Daniel >>>>>>>>>>> >>>>>>>>>>> It's CSeq 1, fromtag A1 >>>>>>>>>>> >>>>>>>>>>> DB attached >>>>>>>>>>> >>>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>>>>>>>> miconda@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@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@gmail.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly <
pkelly@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@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@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@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@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@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@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@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@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@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@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@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