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
>