<div dir="ltr">Ah I see why it is confusing<div><br></div><div>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!</div><div><br></div><div>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.</div><div><br>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.</div><div><br></div><div>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.</div><div><br>I have the DB dump and logfiles from this call too if useful.</div><div><br>Pete</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 April 2017 at 12:41, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I could notice upon a quick look, there seems to be two calls -- two<br>
INVITE requests having same call id but different cseq. Can you confirm<br>
this is the case? Because the capture doesn't seem to have all the<br>
incoming/outgoing messages, some are missing.<br>
<br>
Cheers,<br>
Daniel<br>
<div class="HOEnZb"><div class="h5"><br>
On 26.04.17 12:59, Sergey Basov wrote:<br>
> You give to us very hard callflow...<br>
><br>
> Without any pauses between responces..<br>
><br>
> Some requests go through 127.0.0.1... But responces from 127.0.0.1 not present.<br>
><br>
> There are peers from which invites not present in dump. I can not see<br>
> ful path of the initial Invite, but there is responses.<br>
><br>
> I will send dump in next email directly.<br>
> --<br>
> Best regards,<br>
> Sergey Basov e-mail: <a href="mailto:sergey.v.basov@gmail.com">sergey.v.basov@gmail.com</a><br>
><br>
><br>
> 2017-04-26 11:01 GMT+03:00 Pete Kelly <<a href="mailto:pkelly@gmail.com">pkelly@gmail.com</a>>:<br>
>> Attached is the pcap from latest nightly.<br>
>><br>
>> As you can see (frame 21) the ACK is incorrect, I believe it should specify<br>
>> all the hops from the 200OK (frame 16) so that the hop by hop ACK can be<br>
>> routed via the proxy chain.<br>
>><br>
>> topoh module works fine.<br>
>><br>
>> Pete<br>
>><br>
>> On 26 April 2017 at 05:18, Sergey Basov <<a href="mailto:sergey.v.basov@gmail.com">sergey.v.basov@gmail.com</a>> wrote:<br>
>>> I dont know how nightly builds are done.<br>
>>><br>
>>> Just try with latest 5.0.1 nightly and send new dump.<br>
>>><br>
>>> As I understud topos module done to remove record-route headers to hide<br>
>>> topology... Am I wright, Daniel?<br>
>>><br>
>>> And try to disable topos module and enable topoh module. Will it all work<br>
>>> as you expecrs?<br>
>>><br>
>>> --<br>
>>> WBR<br>
>>> Sergey Basov<br>
>>><br>
>>> 25 апр. 2017 г. 11:31 PM пользователь "Pete Kelly" <<a href="mailto:pkelly@gmail.com">pkelly@gmail.com</a>><br>
>>> написал:<br>
>>><br>
>>>> I have tried with 5.0.1 from today (25th April).<br>
>>>><br>
>>>> Are you saying build for 26th will have some fixes?<br>
>>>><br>
>>>> On 25 April 2017 at 18:59, Sergey Basov <<a href="mailto:sergey.v.basov@gmail.com">sergey.v.basov@gmail.com</a>> wrote:<br>
>>>>> Actualy latest fixes to 180/183/200, ACK and memory leak was pushed to<br>
>>>>> 5.0 and master branch.<br>
>>>>><br>
>>>>> So, please try with latest 5.0.1 nightly.<br>
>>>>><br>
>>>>> --<br>
>>>>> WBR<br>
>>>>> Sergey Basov<br>
>>>>><br>
>>>>> 25 апр. 2017 г. 8:55 PM пользователь "Pete Kelly" <<a href="mailto:pkelly@gmail.com">pkelly@gmail.com</a>><br>
>>>>> написал:<br>
>>>>><br>
>>>>>> Call is with sipp but first goes through another SBC to clean up the<br>
>>>>>> SIP (in case of problems with sipp via headers etc).<br>
>>>>>><br>
>>>>>> The traces I've done are actually with 4.4.<br>
>>>>>><br>
>>>>>> Will they be OK or would you prefer 5.0.1? The problem is exactly the<br>
>>>>>> same on both.<br>
>>>>>><br>
>>>>>> On 25 April 2017 at 16:25, Sergey Basov <<a href="mailto:sergey.v.basov@gmail.com">sergey.v.basov@gmail.com</a>><br>
>>>>>> wrote:<br>
>>>>>>> Hi.<br>
>>>>>>><br>
>>>>>>> Can you send dump of the call with kamailio 5.0.1 nightly?<br>
>>>>>>><br>
>>>>>>> And does you make call using sipp?<br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> WBR<br>
>>>>>>> Sergey Basov<br>
>>>>>>><br>
>>>>>>> 25 апр. 2017 г. 5:57 PM пользователь "Pete Kelly" <<a href="mailto:pkelly@gmail.com">pkelly@gmail.com</a>><br>
>>>>>>> написал:<br>
>>>>>>>> Looks like from last night:<br>
>>>>>>>><br>
>>>>>>>> 5.0.1+0~20170425013247.36+<wbr>trusty<br>
>>>>>>>><br>
>>>>>>>> On 25 April 2017 at 15:42, Daniel-Constantin Mierla<br>
>>>>>>>> <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<br>
>>>>>>>>> Hello,<br>
>>>>>>>>><br>
>>>>>>>>> to be sure, it is 5.0.1 build from last night or quite recent? There<br>
>>>>>>>>> were some fixes in the past days to topos module.<br>
>>>>>>>>><br>
>>>>>>>>> Cheers,<br>
>>>>>>>>> Daniel<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> On 25.04.17 15:59, Pete Kelly wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Hi Daniel<br>
>>>>>>>>><br>
>>>>>>>>> Sorry for the delayed response to this, the ACK is for a 200OK yes<br>
>>>>>>>>> and the problem still persists in latest 4.4 and the 5.0.1 nightly build.<br>
>>>>>>>>><br>
>>>>>>>>> I have all DB entries/kam logs/pcap files.<br>
>>>>>>>>><br>
>>>>>>>>> If you check the attached pcap, 192.168.70.70 and 192.168.252.70 are<br>
>>>>>>>>> the same instance of Kamailio, it is being used to bridge the 2 networks.<br>
>>>>>>>>><br>
>>>>>>>>> Frame 34 shows the 200OK with lots of Record-Route etc, and frame 35<br>
>>>>>>>>> shows topos in action.<br>
>>>>>>>>><br>
>>>>>>>>> However the ACK that is relayed in Frame 38 seems to be missing all<br>
>>>>>>>>> the Route information that was supplied in the 200OK, this causes the ACK to<br>
>>>>>>>>> be relayed directly to the Contact, breaking the proxy chain.<br>
>>>>>>>>><br>
>>>>>>>>> Pete<br>
>>>>>>>>><br>
>>>>>>>>> On 22 February 2017 at 18:31, Daniel-Constantin Mierla<br>
>>>>>>>>> <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<br>
>>>>>>>>>> Hello,<br>
>>>>>>>>>><br>
>>>>>>>>>> is the ACK for 200ok? Or an ack for a negative response?<br>
>>>>>>>>>><br>
>>>>>>>>>> Can you get a pcap for such situation with all messages related to<br>
>>>>>>>>>> the call?<br>
>>>>>>>>>><br>
>>>>>>>>>> Cheers,<br>
>>>>>>>>>> Daniel<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> On 22/02/2017 17:20, Pete Kelly wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>> Hi<br>
>>>>>>>>>><br>
>>>>>>>>>> I am using the topos module when bridging 2 networks with Kamailio.<br>
>>>>>>>>>><br>
>>>>>>>>>> The INVITE/200OK part of the transaction is working fine (i.e. the<br>
>>>>>>>>>> Contact on both sides matches correctly the corresponding network).<br>
>>>>>>>>>><br>
>>>>>>>>>> However when the ACK is sent into Kamailio, instead of realising<br>
>>>>>>>>>> the next hop is myself and skipping it, Kamailio is sending the ACK directly<br>
>>>>>>>>>> to itself as a packet, causing the call setup to break.<br>
>>>>>>>>>><br>
>>>>>>>>>> Does anyone have any advice for this situation?<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> ______________________________<wbr>_________________<br>
>>>>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing<br>
>>>>>>>>>> list<br>
>>>>>>>>>> <a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
>>>>>>>>>> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
>>>>>>>>>><br>
>>>>>>>>>> --<br>
>>>>>>>>>> Daniel-Constantin Mierla<br>
>>>>>>>>>> <a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
>>>>>>>>>> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) -<br>
>>>>>>>>>> <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - <a href="http://www.kamailioworld.com" rel="noreferrer" target="_blank">www.kamailioworld.com</a><br>
>>>>>>>>> --<br>
>>>>>>>>> Daniel-Constantin Mierla<br>
>>>>>>>>> <a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) - <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - <a href="http://www.kamailioworld.com" rel="noreferrer" target="_blank">www.kamailioworld.com</a><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> ______________________________<wbr>_________________<br>
>>>>>>>> Kamailio (SER) - Users Mailing List<br>
>>>>>>>> <a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
>>>>>>>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
>>>>>>>><br>
<br>
--<br>
Daniel-Constantin Mierla<br>
<a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
Kamailio Advanced Training - May 22-24 (USA) - <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
Kamailio World Conference - May 8-10, 2017 - <a href="http://www.kamailioworld.com" rel="noreferrer" target="_blank">www.kamailioworld.com</a><br>
<br>
</div></div></blockquote></div><br></div>