[SR-Users] topos module - possible bug

Daniel-Constantin Mierla miconda at gmail.com
Thu Apr 27 14:11:00 CEST 2017


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
> <mailto: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 <mailto: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 <mailto: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 <mailto:sergey.v.basov at gmail.com>
>>             >
>>             >
>>             > 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly at gmail.com
>>             <mailto: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
>>             <mailto: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 <mailto: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
>>             <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>             <mailto:sr-users at lists.sip-router.org>
>>             >>>>>>>>>>
>>             http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>             <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>>             >>>>>>>>>>
>>             >>>>>>>>>> --
>>             >>>>>>>>>> Daniel-Constantin Mierla
>>             >>>>>>>>>> www.twitter.com/miconda
>>             <http://www.twitter.com/miconda> --
>>             www.linkedin.com/in/miconda
>>             <http://www.linkedin.com/in/miconda>
>>             >>>>>>>>>> Kamailio Advanced Training - Mar 6-8 (Europe)
>>             and Mar 20-22 (USA) -
>>             >>>>>>>>>> www.asipto.com <http://www.asipto.com>
>>             >>>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>             www.kamailioworld.com <http://www.kamailioworld.com>
>>             >>>>>>>>> --
>>             >>>>>>>>> Daniel-Constantin Mierla
>>             >>>>>>>>> www.twitter.com/miconda
>>             <http://www.twitter.com/miconda> --
>>             www.linkedin.com/in/miconda
>>             <http://www.linkedin.com/in/miconda>
>>             >>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) -
>>             www.asipto.com <http://www.asipto.com>
>>             >>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
>>             www.kamailioworld.com <http://www.kamailioworld.com>
>>             >>>>>>>>
>>             >>>>>>>>
>>             >>>>>>>> _______________________________________________
>>             >>>>>>>> Kamailio (SER) - Users Mailing List
>>             >>>>>>>> sr-users at lists.kamailio.org
>>             <mailto:sr-users at lists.kamailio.org>
>>             >>>>>>>>
>>             https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>             <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>             >>>>>>>>
>>
>>             --
>>             Daniel-Constantin Mierla
>>             www.twitter.com/miconda <http://www.twitter.com/miconda>
>>             -- www.linkedin.com/in/miconda
>>             <http://www.linkedin.com/in/miconda>
>>             Kamailio Advanced Training - May 22-24 (USA) -
>>             www.asipto.com <http://www.asipto.com>
>>             Kamailio World Conference - May 8-10, 2017 -
>>             www.kamailioworld.com <http://www.kamailioworld.com>
>>
>>
>
>         -- 
>         Daniel-Constantin Mierla
>         www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>         Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com <http://www.asipto.com>
>         Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170427/eccaf964/attachment.html>


More information about the sr-users mailing list