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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA>
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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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>om>:
> > 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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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>om>:
> >>> 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=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYGAUeXl/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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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>om>:
> >>>> 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
> >