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(a)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(a)gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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-
WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAg
EAAgcAAAABAAAAAAAAAAAAAAAA>
> 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(a)gmail.com
>
>
> 2017-05-05 23:16 GMT+03:00 Sergey Basov <sergey.v.basov(a)gmail.com>om>:
>> 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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAg
EAAgcAAAABAAAAAAAAAAAAAAAA>
>> 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.5ce1;vsf=
AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA>
>>
>> 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(a)gmail.com
>>
>>
>> 2017-05-05 20:32 GMT+03:00 Sergey Basov <sergey.v.basov(a)gmail.com>om>:
>>> 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(a)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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXne7YnTuP.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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,
<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,
<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](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(a)gmail.com
>>>>
>>>>
>>>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
miconda(a)gmail.com>gt;:
>>>>> 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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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.
sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.
zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn
TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.
TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;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(a)gmail.com
>>>>>
>>>>>
>>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <sergey.v.basov(a)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.1TlqHP7frDwZWwhcyKAcOfIVTn;
did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3
Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR
xjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:
5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;
did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3
Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;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.1TlqHP7frDwZWwhcyKAcOfIVTn;
did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](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(a)gmail.com
>>>>>>
>>>>>>
>>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov
<sergey.v.basov(a)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(a)gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla
>>>>>>>> <miconda(a)gmail.com>om>:
>>>>>>>>> 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(a)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(a)gmail.com>
wrote:
>>>>>>>>>>> Hi
Daniel
>>>>>>>>>>>
>>>>>>>>>>> It's CSeq 1, fromtag A1
>>>>>>>>>>>
>>>>>>>>>>> DB attached
>>>>>>>>>>>
>>>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin
Mierla
>>>>>>>>>>> <miconda(a)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(a)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(a)gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete
Kelly <pkelly(a)gmail.com>om>:
>>>>>>>>>>>>>>> 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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.sip-router.org
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
http://lists.sip-router.org/ cgi-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(a)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(a)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