[SR-Users] topos module - possible bug

Sergey Basov sergey.v.basov at gmail.com
Fri Apr 28 14:37:56 CEST 2017 

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 at gmail.com


2017-04-28 14:46 GMT+03:00 Sergey Basov <sergey.v.basov at 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 at gmail.com
>
>
> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla <miconda at 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 at 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 at gmail.com> wrote:
>>>>
>>>> Hi Daniel
>>>>
>>>> It's CSeq 1, fromtag A1
>>>>
>>>> DB attached
>>>>
>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla <miconda at 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 at 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 at gmail.com
>>>>>> >
>>>>>> >
>>>>>> > 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>

More information about the sr-users mailing list