<div dir="ltr">Hi Daniel<div><br>It's CSeq 1, fromtag A1</div><div><br></div><div>DB attached</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 April 2017 at 15:03, 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">
<div bgcolor="#FFFFFF" text="#000000">
<p>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.</p>
<p>Send also the db dump, they should reveal if something is broken
there.</p>
<p>Cheers,<br>
Daniel<br>
</p><div><div class="h5">
<br>
<div class="m_7597433176232979363moz-cite-prefix">On 26.04.17 14:46, Pete Kelly wrote:<br>
</div>
<blockquote type="cite">
<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="m_7597433176232979363HOEnZb">
<div class="m_7597433176232979363h5"><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">pkelly@gmail.com</a>><br>
>>>>>>> написал:<br>
>>>>>>>> Looks like from last
night:<br>
>>>>>>>><br>
>>>>>>>>
5.0.1+0~20170425013247.36+trus<wbr>ty<br>
>>>>>>>><br>
>>>>>>>> On 25 April 2017 at
15:42, Daniel-Constantin Mierla<br>
>>>>>>>> <<a href="mailto:miconda@gmail.com" target="_blank">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" target="_blank">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" target="_blank">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/cg<wbr>i-bin/mailman/listinfo/sr-user<wbr>s</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" target="_blank">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/cgi<wbr>-bin/mailman/listinfo/sr-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>
</blockquote>
<br>
<pre class="m_7597433176232979363moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="m_7597433176232979363moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a class="m_7597433176232979363moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - May 22-24 (USA) - <a class="m_7597433176232979363moz-txt-link-abbreviated" href="http://www.asipto.com" target="_blank">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a class="m_7597433176232979363moz-txt-link-abbreviated" href="http://www.kamailioworld.com" target="_blank">www.kamailioworld.com</a></pre>
</div></div></div>
</blockquote></div><br></div>