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
>>>