[SR-Users] topos module - possible bug
Daniel-Constantin Mierla
miconda at gmail.com
Wed Apr 26 16:03:55 CEST 2017
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 -- 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/20170426/a4cee237/attachment.html>
More information about the sr-users
mailing list