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?
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.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
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@gmail.com mailto:miconda@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@lists.sip-router.org <mailto:sr-users@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>
Looks like from last night:
5.0.1+0~20170425013247.36+trusty
On 25 April 2017 at 15:42, Daniel-Constantin Mierla miconda@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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.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 Mierlawww.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
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@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@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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.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 Mierlawww.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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.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 Mierlawww.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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.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 Mierlawww.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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.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 Mierlawww.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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@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@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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierlawww.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 Mierlawww.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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@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@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@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@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 listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Daniel-Constantin Mierlawww.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 Mierlawww.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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@gmail.com
2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
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@gmail.com
2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>
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@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@gmail.com
2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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
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@gmail.com mailto:miconda@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@gmail.com <mailto:sergey.v.basov@gmail.com> > > > 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:miconda@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@gmail.com <mailto:miconda@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@lists.sip-router.org <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@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>
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com
2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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 Mierlawww.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
Hi Daniel
Is there anything else you need on this?
On 26 April 2017 at 15:06, Pete Kelly pkelly@gmail.com wrote:
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com
2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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 Mierlawww.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
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@gmail.com mailto:pkelly@gmail.com> wrote:
Hi Daniel It's CSeq 1, fromtag A1 DB attached On 26 April 2017 at 15:03, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@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@gmail.com <mailto:miconda@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@gmail.com <mailto:sergey.v.basov@gmail.com> > > > 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:miconda@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@gmail.com <mailto:miconda@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@lists.sip-router.org <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@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>
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@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@gmail.com wrote:
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com
2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@lists.sip-router.org >>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-user
s
>>>>>>>> >>>>>>>> -- >>>>>>>> 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@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 Mierlawww.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 Mierlawww.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
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@gmail.com mailto:miconda@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@gmail.com <mailto:pkelly@gmail.com>> wrote: Hi Daniel It's CSeq 1, fromtag A1 DB attached On 26 April 2017 at 15:03, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@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@gmail.com <mailto:miconda@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@gmail.com <mailto:sergey.v.basov@gmail.com> > > > 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:sergey.v.basov@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@gmail.com <mailto:pkelly@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@gmail.com <mailto:miconda@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@gmail.com <mailto:miconda@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@lists.sip-router.org <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@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 <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>
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@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla miconda@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@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@gmail.com wrote:
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com
2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla miconda@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@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@gmail.com wrote:
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com > > > 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Some more debug
after adding debug output after each iteration I got:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](348) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554) - s_rr: [](0)
So size are computed correctly, but part of record-routes disappears.... And we can see correct size of the record but only last part of the record-routes
Hope it helps -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
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@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla miconda@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@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@gmail.com wrote:
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com > > > > > > 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time! Hopefully I caught the issue. Can you test with latest master branch and let me know if works?
Cheers, Daniel
On 28.04.17 14:57, Sergey Basov wrote:
Some more debug
after adding debug output after each iteration I got:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](348) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
- s_rr: [](0)
So size are computed correctly, but part of record-routes disappears.... And we can see correct size of the record but only last part of the record-routes
Hope it helps
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
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@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla miconda@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@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@gmail.com wrote:
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com >>> >>> >>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556) - s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch? Then may be Pete Kelly will install nightly build of the 5.0.1 and confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel. -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time! Hopefully I caught the issue. Can you test with latest master branch and let me know if works?
Cheers, Daniel
On 28.04.17 14:57, Sergey Basov wrote:
Some more debug
after adding debug output after each iteration I got:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](348) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
- s_rr: [](0)
So size are computed correctly, but part of record-routes disappears.... And we can see correct size of the record but only last part of the record-routes
Hope it helps
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
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@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla miconda@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@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@gmail.com wrote: > Hi Daniel > > It's CSeq 1, fromtag A1 > > DB attached > > On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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@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@gmail.com >>>> >>>> >>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@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
Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly. But when ack is sending from A side it try to send to B side to cantact ip, ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
-- WBR Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" < sergey.v.basov@gmail.com> написал:
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr- BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr- BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn, sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY; did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr- BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn, sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY; did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA](556)
- s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch? Then may be Pete Kelly will install nightly build of the 5.0.1 and confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time! Hopefully I caught the issue. Can you test with latest master branch and let me know if works?
Cheers, Daniel
On 28.04.17 14:57, Sergey Basov wrote:
Some more debug
after adding debug output after each iteration I got:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](84)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.
sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ. zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP. TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](348)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-
4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-
4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
- s_rr: [](0)
So size are computed correctly, but part of record-routes disappears.... And we can see correct size of the record but only last part of the record-routes
Hope it helps
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
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=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3 Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR xjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,sip:212.58.160.253: 5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn; did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3 Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR xjYGAUeXl/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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](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@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla <
miconda@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@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@gmail.com wrote: >> Hi Daniel >> >> It's CSeq 1, fromtag A1 >> >> DB attached >> >> On 26 April 2017 at 15:03, Daniel-Constantin Mierla <
miconda@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@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@gmail.com
>>>>> >>>>> >>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@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
I think it is because wrong order of Route: header after restoring...
With topoh enabled I have:
Route: sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
But with topos enabled I have:
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA
And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
Can you fix it? Or I going in to wrong directuon?
Thank you. -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly. But when ack is sending from A side it try to send to B side to cantact ip, ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
-- WBR Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" sergey.v.basov@gmail.com написал:
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
- s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch? Then may be Pete Kelly will install nightly build of the 5.0.1 and confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time! Hopefully I caught the issue. Can you test with latest master branch and let me know if works?
Cheers, Daniel
On 28.04.17 14:57, Sergey Basov wrote:
Some more debug
after adding debug output after each iteration I got:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](348) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
- s_rr: [](0)
So size are computed correctly, but part of record-routes disappears.... And we can see correct size of the record but only last part of the record-routes
Hope it helps
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
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@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla miconda@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@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@gmail.com wrote: >>> Hi Daniel >>> >>> It's CSeq 1, fromtag A1 >>> >>> DB attached >>> >>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>> miconda@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@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@gmail.com >>>>>> >>>>>> >>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@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
I found issue cause.
After I have changed line 792 of the file tps_msg.c from if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
to if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
now route header are restores in from:
Route: sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
Now ACK are routed correctly.
Seems that earlier, before fix b_rr store into DB, we does not see this issue, because only last route header was saved... But after fix, we have all route records so we nned to restore it into wright way.
Now I have worked scheme with 3 kamailio in a row, on first of them enabled topos on other only topoh module.
Daniel, I will send to you latest dump in separate e-mail.
Thank you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
I think it is because wrong order of Route: header after restoring...
With topoh enabled I have:
Route: sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
But with topos enabled I have:
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA
And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
Can you fix it? Or I going in to wrong directuon?
Thank you.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly. But when ack is sending from A side it try to send to B side to cantact ip, ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
-- WBR Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" sergey.v.basov@gmail.com написал:
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
- s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch? Then may be Pete Kelly will install nightly build of the 5.0.1 and confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time! Hopefully I caught the issue. Can you test with latest master branch and let me know if works?
Cheers, Daniel
On 28.04.17 14:57, Sergey Basov wrote:
Some more debug
after adding debug output after each iteration I got:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](348) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
- s_rr: [](0)
So size are computed correctly, but part of record-routes disappears.... And we can see correct size of the record but only last part of the record-routes
Hope it helps
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
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@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com > > > 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla > miconda@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@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@gmail.com wrote: >>>> Hi Daniel >>>> >>>> It's CSeq 1, fromtag A1 >>>> >>>> DB attached >>>> >>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>> miconda@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@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@gmail.com >>>>>>> >>>>>>> >>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@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
Try to make a pull request for it and if all ok it will be merged.
Cheers, Daniel
On 06.05.17 17:20, Sergey Basov wrote:
I found issue cause.
After I have changed line 792 of the file tps_msg.c from if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
to if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
now route header are restores in from:
Route: sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
Now ACK are routed correctly.
Seems that earlier, before fix b_rr store into DB, we does not see this issue, because only last route header was saved... But after fix, we have all route records so we nned to restore it into wright way.
Now I have worked scheme with 3 kamailio in a row, on first of them enabled topos on other only topoh module.
Daniel, I will send to you latest dump in separate e-mail.
Thank you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
I think it is because wrong order of Route: header after restoring...
With topoh enabled I have:
Route: sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
But with topos enabled I have:
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA
And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
Can you fix it? Or I going in to wrong directuon?
Thank you.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly. But when ack is sending from A side it try to send to B side to cantact ip, ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
-- WBR Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" sergey.v.basov@gmail.com написал:
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
- s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch? Then may be Pete Kelly will install nightly build of the 5.0.1 and confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time! Hopefully I caught the issue. Can you test with latest master branch and let me know if works?
Cheers, Daniel
On 28.04.17 14:57, Sergey Basov wrote:
Some more debug
after adding debug output after each iteration I got:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](348) Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554)
- s_rr: [](0)
So size are computed correctly, but part of record-routes disappears.... And we can see correct size of the record but only last part of the record-routes
Hope it helps
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com: > 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@gmail.com > > > 2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com >> >> >> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >> miconda@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@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@gmail.com wrote: >>>>> Hi Daniel >>>>> >>>>> It's CSeq 1, fromtag A1 >>>>> >>>>> DB attached >>>>> >>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>> miconda@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@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@gmail.com >>>>>>>> >>>>>>>> >>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@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
Hi, Daniel.
I have created pool request
https://github.com/kamailio/kamailio/pull/1124 -- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Try to make a pull request for it and if all ok it will be merged.
Cheers, Daniel
On 06.05.17 17:20, Sergey Basov wrote:
I found issue cause.
After I have changed line 792 of the file tps_msg.c from if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
to if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
now route header are restores in from:
Route: sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
Now ACK are routed correctly.
Seems that earlier, before fix b_rr store into DB, we does not see this issue, because only last route header was saved... But after fix, we have all route records so we nned to restore it into wright way.
Now I have worked scheme with 3 kamailio in a row, on first of them enabled topos on other only topoh module.
Daniel, I will send to you latest dump in separate e-mail.
Thank you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
I think it is because wrong order of Route: header after restoring...
With topoh enabled I have:
Route: sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
But with topos enabled I have:
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA
And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
Can you fix it? Or I going in to wrong directuon?
Thank you.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly. But when ack is sending from A side it try to send to B side to cantact ip, ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
-- WBR Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" sergey.v.basov@gmail.com написал:
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](556)
- s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch? Then may be Pete Kelly will install nightly build of the 5.0.1 and confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time! Hopefully I caught the issue. Can you test with latest master branch and let me know if works?
Cheers, Daniel
On 28.04.17 14:57, Sergey Basov wrote: > Some more debug > > after adding debug output after each iteration I got: > > Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos > [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: > > [sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*](84) > Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos > [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: > > [sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](348) > Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos > [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr: > > [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554) > > Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos > [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) - > b_rr: > [sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA](554) > - s_rr: [](0) > > So size are computed correctly, but part of record-routes > disappears.... And we can see correct size of the record but only last > part of the record-routes > > Hope it helps > -- > Best regards, > Sergey Basov e-mail: sergey.v.basov@gmail.com > > > 2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com: >> 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@gmail.com >> >> >> 2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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@gmail.com >>> >>> >>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >>> miconda@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@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@gmail.com wrote: >>>>>> Hi Daniel >>>>>> >>>>>> It's CSeq 1, fromtag A1 >>>>>> >>>>>> DB attached >>>>>> >>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>>> miconda@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@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@gmail.com >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@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
Is this fix in the nightly .deb build?
I've just tested the latest and it's still broken
On 8 May 2017 at 07:50, Sergey Basov sergey.v.basov@gmail.com wrote:
Hi, Daniel.
I have created pool request
https://github.com/kamailio/kamailio/pull/1124
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Try to make a pull request for it and if all ok it will be merged.
Cheers, Daniel
On 06.05.17 17:20, Sergey Basov wrote:
I found issue cause.
After I have changed line 792 of the file tps_msg.c from if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
to if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
now route header are restores in from:
Route: <sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-
WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAg EAAgcAAAABAAAAAAAAAAAAAAAA>
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
Now ACK are routed correctly.
Seems that earlier, before fix b_rr store into DB, we does not see this issue, because only last route header was saved... But after fix, we have all route records so we nned to restore it into wright way.
Now I have worked scheme with 3 kamailio in a row, on first of them enabled topos on other only topoh module.
Daniel, I will send to you latest dump in separate e-mail.
Thank you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
I think it is because wrong order of Route: header after restoring...
With topoh enabled I have:
Route: <sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5dUv;
did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAg EAAgcAAAABAAAAAAAAAAAAAAAA>
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
But with topos enabled I have:
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,<sip:10.56.
42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf= AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA>
And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
Can you fix it? Or I going in to wrong directuon?
Thank you.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly. But when ack is sending from A side it try to send to B side to
cantact ip,
ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
-- WBR Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" sergey.v.basov@gmail.com написал:
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr- BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr- BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn, sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY; did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0)
b_rr: [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr- BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn, sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY; did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA](556)
- s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch? Then may be Pete Kelly will install nightly build of the 5.0.1 and confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
miconda@gmail.com>:
> Hello, > > many thanks Sergey for troubleshooting, it saved a lot of time! > Hopefully I caught the issue. Can you test with latest master
branch and
> let me know if works? > > Cheers, > Daniel > > > On 28.04.17 14:57, Sergey Basov wrote: >> Some more debug >> >> after adding debug output after each iteration I got: >> >> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>> >> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](84)
>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>> >> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.
sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ. zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP. TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](348)
>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>> >> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-
4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>> >> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>> b_rr: >> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-
4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>> - s_rr: [](0) >> >> So size are computed correctly, but part of record-routes >> disappears.... And we can see correct size of the record but only
last
>> part of the record-routes >> >> Hope it helps >> -- >> Best regards, >> Sergey Basov e-mail: sergey.v.basov@gmail.com >> >> >> 2017-04-28 15:37 GMT+03:00 Sergey Basov <sergey.v.basov@gmail.com
:
>>> 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=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3 Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR xjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,sip:212.58.160.253: 5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn; did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3 Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR xjYGAUeXl/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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](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@gmail.com >>> >>> >>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <sergey.v.basov@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@gmail.com
>>>> >>>> >>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >>>> miconda@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@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@gmail.com
wrote:
>>>>>>> Hi Daniel >>>>>>> >>>>>>> It's CSeq 1, fromtag A1 >>>>>>> >>>>>>> DB attached >>>>>>> >>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>>>> miconda@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@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@gmail.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@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@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@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
Hi.
No. Daniel does not merged fix yet. And he needs some time to backport it to 5.0 branch
-- WBR Sergey Basov
8 мая 2017 г. 4:34 PM пользователь "Pete Kelly" pkelly@gmail.com написал:
Is this fix in the nightly .deb build?
I've just tested the latest and it's still broken
On 8 May 2017 at 07:50, Sergey Basov sergey.v.basov@gmail.com wrote:
Hi, Daniel.
I have created pool request
https://github.com/kamailio/kamailio/pull/1124
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Try to make a pull request for it and if all ok it will be merged.
Cheers, Daniel
On 06.05.17 17:20, Sergey Basov wrote:
I found issue cause.
After I have changed line 792 of the file tps_msg.c from if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
to if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
now route header are restores in from:
Route: <sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4
Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE AAgcAAAABAAAAAAAAAAAAAAAA>
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
Now ACK are routed correctly.
Seems that earlier, before fix b_rr store into DB, we does not see this issue, because only last route header was saved... But after fix, we have all route records so we nned to restore it into wright way.
Now I have worked scheme with 3 kamailio in a row, on first of them enabled topos on other only topoh module.
Daniel, I will send to you latest dump in separate e-mail.
Thank you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
I think it is because wrong order of Route: header after restoring...
With topoh enabled I have:
Route: <sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5d
Uv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE AAgcAAAABAAAAAAAAAAAAAAAA>
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
But with topos enabled I have:
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,<sip:10.56.42
.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434. 5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXN lcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAA AAAAAAAAAAAAAA>
And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
Can you fix it? Or I going in to wrong directuon?
Thank you.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly. But when ack is sending from A side it try to send to B side to
cantact ip,
ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
-- WBR Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" sergey.v.basov@gmail.com написал:
> Hi Daniel. > > Seems all is ok now. > > I applyed your patch and add my additional debug string. > > Now result is: > > Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos > [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
> > [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
> > Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos > [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
> > [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk. dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
> > Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos > [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
> > [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk. dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,< sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRU Y;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9O jUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQAAAAOAAAAAAAAAAAAAAAA>](556)
> > Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos > [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr:
[](0) -
> b_rr: > [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk. dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,< sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRU Y;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9O jUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQAAAAOAAAAAAAAAAAAAAAA>](556)
> - s_rr: [](0) > > > Seems this issue is solved. > > Can you apply this patch to 5.0 branch? > Then may be Pete Kelly will install nightly build of the 5.0.1 and > confirm that issu is solved. > > I does not have such count of sbc for test ) > > Thank you Daniel. > -- > Best regards, > Sergey Basov e-mail: sergey.v.basov@gmail.com > > > 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
miconda@gmail.com>:
>> Hello, >> >> many thanks Sergey for troubleshooting, it saved a lot of time! >> Hopefully I caught the issue. Can you test with latest master
branch and
>> let me know if works? >> >> Cheers, >> Daniel >> >> >> On 28.04.17 14:57, Sergey Basov wrote: >>> Some more debug >>> >>> after adding debug output after each iteration I got: >>> >>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>> >>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>> >>> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZA
eLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ. zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXn TsFnTsXnTsXnTsXnTsXnTsXn>](348)
>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>> >>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>> >>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>>> b_rr: >>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>> - s_rr: [](0) >>> >>> So size are computed correctly, but part of record-routes >>> disappears.... And we can see correct size of the record but only
last
>>> part of the record-routes >>> >>> Hope it helps >>> -- >>> Best regards, >>> Sergey Basov e-mail: sergey.v.basov@gmail.com >>> >>> >>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <sergey.v.basov@gmail.com
:
>>>> 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.1TlqHP7frDwZWwhcyKAcOf
IVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX 14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYGAUeXl/ dRU2PChyPXBob25l;nat=yes>,sip:212.58.160.253:5061; transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIV Tn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14 CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRx jYGAUeXl/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.1TlqHP7frDwZWwhcyKAcOfI
VTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAQAAAAOAAAAAAAAAAAAAAAA>](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@gmail.com
>>>> >>>> >>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <
sergey.v.basov@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@gmail.com
>>>>> >>>>> >>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >>>>> miconda@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@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@gmail.com
wrote:
>>>>>>>> Hi Daniel >>>>>>>> >>>>>>>> It's CSeq 1, fromtag A1 >>>>>>>> >>>>>>>> DB attached >>>>>>>> >>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>>>>> miconda@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@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@gmail.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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@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@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@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@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@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@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@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@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@lists.sip-router.org >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://lists.sip-router.org/cg
i-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@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@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
Hi Pete,
I think you can try with latest nightly build. Daniel has committed fix at 08 March late evening. So I think it included in latest nightly build.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 16:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi.
No. Daniel does not merged fix yet. And he needs some time to backport it to 5.0 branch
-- WBR Sergey Basov
8 мая 2017 г. 4:34 PM пользователь "Pete Kelly" pkelly@gmail.com написал:
Is this fix in the nightly .deb build?
I've just tested the latest and it's still broken
On 8 May 2017 at 07:50, Sergey Basov sergey.v.basov@gmail.com wrote:
Hi, Daniel.
I have created pool request
https://github.com/kamailio/kamailio/pull/1124
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Try to make a pull request for it and if all ok it will be merged.
Cheers, Daniel
On 06.05.17 17:20, Sergey Basov wrote:
I found issue cause.
After I have changed line 792 of the file tps_msg.c from if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
to if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
now route header are restores in from:
Route: <sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4
Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE AAgcAAAABAAAAAAAAAAAAAAAA>
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
Now ACK are routed correctly.
Seems that earlier, before fix b_rr store into DB, we does not see this issue, because only last route header was saved... But after fix, we have all route records so we nned to restore it into wright way.
Now I have worked scheme with 3 kamailio in a row, on first of them enabled topos on other only topoh module.
Daniel, I will send to you latest dump in separate e-mail.
Thank you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
I think it is because wrong order of Route: header after restoring...
With topoh enabled I have:
Route: <sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5d
Uv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE AAgcAAAABAAAAAAAAAAAAAAAA>
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
But with topos enabled I have:
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,<sip:10.56.42
.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5c e1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlc j1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAA AAAAAAAAAAAA>
And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060
Can you fix it? Or I going in to wrong directuon?
Thank you.
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com: > Hi Daniel > > Semms now we have ankther problem... > > b_rr weites in db correctly. > But when ack is sending from A side it try to send to B side to
cantact ip,
> ignoring record-route headers... > > I will try to debug this. > > If you have any idea I can test it. > > Thank you. > > -- > WBR > Sergey Basov > > 28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" > sergey.v.basov@gmail.com написал: > >> Hi Daniel. >> >> Seems all is ok now. >> >> I applyed your patch and add my additional debug string. >> >> Now result is: >> >> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>> >> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>> >> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>> >> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED. sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReR XWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
>> >> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>> >> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED. sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReR XWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10. 56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY; did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjU wNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA QAAAAOAAAAAAAAAAAAAAAA](556)
>> >> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>> b_rr: >> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED. sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReR XWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTs XnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10. 56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY; did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjU wNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA QAAAAOAAAAAAAAAAAAAAAA](556)
>> - s_rr: [](0) >> >> >> Seems this issue is solved. >> >> Can you apply this patch to 5.0 branch? >> Then may be Pete Kelly will install nightly build of the 5.0.1 and >> confirm that issu is solved. >> >> I does not have such count of sbc for test ) >> >> Thank you Daniel. >> -- >> Best regards, >> Sergey Basov e-mail: sergey.v.basov@gmail.com >> >> >> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
miconda@gmail.com>:
>>> Hello, >>> >>> many thanks Sergey for troubleshooting, it saved a lot of time! >>> Hopefully I caught the issue. Can you test with latest master
branch and
>>> let me know if works? >>> >>> Cheers, >>> Daniel >>> >>> >>> On 28.04.17 14:57, Sergey Basov wrote: >>>> Some more debug >>>> >>>> after adding debug output after each iteration I got: >>>> >>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>> >>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>> >>>> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZA
eLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ. zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXn TsFnTsXnTsXnTsXnTsXnTsXn>](348)
>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>> >>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>>> >>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>>>> b_rr: >>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>>> - s_rr: [](0) >>>> >>>> So size are computed correctly, but part of record-routes >>>> disappears.... And we can see correct size of the record but
only last
>>>> part of the record-routes >>>> >>>> Hope it helps >>>> -- >>>> Best regards, >>>> Sergey Basov e-mail:
sergey.v.basov@gmail.com
>>>> >>>> >>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <
sergey.v.basov@gmail.com>:
>>>>> 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.1TlqHP7frDwZWwhcyKAcOf
IVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX 14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9B RxjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,sip:212.58.160.253: 5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn; did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14CTU wNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYG AUeXl/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.1TlqHP7frDwZWwhcyKAcOfI
VTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAQAAAAOAAAAAAAAAAAAAAAA>](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@gmail.com
>>>>> >>>>> >>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <
sergey.v.basov@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@gmail.com
>>>>>> >>>>>> >>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >>>>>> miconda@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@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@gmail.com
wrote:
>>>>>>>>> Hi Daniel >>>>>>>>> >>>>>>>>> It's CSeq 1, fromtag A1 >>>>>>>>> >>>>>>>>> DB attached >>>>>>>>> >>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>>>>>> miconda@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@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@gmail.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly@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@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@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@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@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@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@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@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@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@lists.sip-router.org >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://lists.sip-router.org/cg
i-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@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@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
Thanks, I will do.
On 10 May 2017 at 06:09, Sergey Basov sergey.v.basov@gmail.com wrote:
Hi Pete,
I think you can try with latest nightly build. Daniel has committed fix at 08 March late evening. So I think it included in latest nightly build.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 16:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi.
No. Daniel does not merged fix yet. And he needs some time to backport it to 5.0 branch
-- WBR Sergey Basov
8 мая 2017 г. 4:34 PM пользователь "Pete Kelly" pkelly@gmail.com написал:
Is this fix in the nightly .deb build?
I've just tested the latest and it's still broken
On 8 May 2017 at 07:50, Sergey Basov sergey.v.basov@gmail.com wrote:
Hi, Daniel.
I have created pool request
https://github.com/kamailio/kamailio/pull/1124
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
Try to make a pull request for it and if all ok it will be merged.
Cheers, Daniel
On 06.05.17 17:20, Sergey Basov wrote:
I found issue cause.
After I have changed line 792 of the file tps_msg.c from if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) {
to if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) {
now route header are restores in from:
Route: <sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4
Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE AAgcAAAABAAAAAAAAAAAAAAAA>
Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr
Now ACK are routed correctly.
Seems that earlier, before fix b_rr store into DB, we does not see this issue, because only last route header was saved... But after fix, we have all route records so we nned to restore it
into
wright way.
Now I have worked scheme with 3 kamailio in a row, on first of them enabled topos on other only topoh module.
Daniel, I will send to you latest dump in separate e-mail.
Thank you.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com: > I think it is because wrong order of Route: header after
restoring...
> > With topoh enabled I have: > > Route: <sip:10.56.42.37:5070;lr;ftag=IpXq-LwNvJF6WrkOcmZNf9WjmGjK5d
Uv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE AAgcAAAABAAAAAAAAAAAAAAAA>
> Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr > > But with topos enabled I have: > > Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr,<sip:10.56.42
.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434.5c e1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlc j1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAA AAAAAAAAAAAA>
> > And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060 > > Can you fix it? Or I going in to wrong directuon? > > Thank you. > -- > Best regards, > Sergey Basov e-mail: sergey.v.basov@gmail.com > > > 2017-05-05 20:32 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com: >> Hi Daniel >> >> Semms now we have ankther problem... >> >> b_rr weites in db correctly. >> But when ack is sending from A side it try to send to B side to
cantact ip,
>> ignoring record-route headers... >> >> I will try to debug this. >> >> If you have any idea I can test it. >> >> Thank you. >> >> -- >> WBR >> Sergey Basov >> >> 28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" >> sergey.v.basov@gmail.com написал: >> >>> Hi Daniel. >>> >>> Seems all is ok now. >>> >>> I applyed your patch and add my additional debug string. >>> >>> Now result is: >>> >>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>> >>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>> >>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>> >>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
>>> >>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>> >>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.5 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did= d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA 7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAA AOAAAAAAAAAAAAAAAA](556)
>>> >>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>> [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>>> b_rr: >>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.5 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did= d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA 7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAA AOAAAAAAAAAAAAAAAA](556)
>>> - s_rr: [](0) >>> >>> >>> Seems this issue is solved. >>> >>> Can you apply this patch to 5.0 branch? >>> Then may be Pete Kelly will install nightly build of the 5.0.1 and >>> confirm that issu is solved. >>> >>> I does not have such count of sbc for test ) >>> >>> Thank you Daniel. >>> -- >>> Best regards, >>> Sergey Basov e-mail: sergey.v.basov@gmail.com >>> >>> >>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
miconda@gmail.com>:
>>>> Hello, >>>> >>>> many thanks Sergey for troubleshooting, it saved a lot of time! >>>> Hopefully I caught the issue. Can you test with latest master
branch and
>>>> let me know if works? >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 28.04.17 14:57, Sergey Basov wrote: >>>>> Some more debug >>>>> >>>>> after adding debug output after each iteration I got: >>>>> >>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>>> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>>> >>>>> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZA
eLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ. zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXn TsFnTsXnTsXnTsXnTsXnTsXn>](348)
>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>>> >>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>>>> >>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos >>>>> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>>>>> b_rr: >>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>>>> - s_rr: [](0) >>>>> >>>>> So size are computed correctly, but part of record-routes >>>>> disappears.... And we can see correct size of the record but
only last
>>>>> part of the record-routes >>>>> >>>>> Hope it helps >>>>> -- >>>>> Best regards, >>>>> Sergey Basov e-mail:
sergey.v.basov@gmail.com
>>>>> >>>>> >>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <
sergey.v.basov@gmail.com>:
>>>>>> 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.1TlqHP7frDwZWwhcyKAcOf
IVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX 14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9B RxjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,sip:212.58.160.253:506 1;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIV Tn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3 Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3A nBlfGJ9BRxjYGAUeXl/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.1TlqHP7frDwZWwhcyKAcOfI
VTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAQAAAAOAAAAAAAAAAAAAAAA>](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@gmail.com
>>>>>> >>>>>> >>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <
sergey.v.basov@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@gmail.com
>>>>>>> >>>>>>> >>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >>>>>>> miconda@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@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@gmail.com
wrote:
>>>>>>>>>> Hi Daniel >>>>>>>>>> >>>>>>>>>> It's CSeq 1, fromtag A1 >>>>>>>>>> >>>>>>>>>> DB attached >>>>>>>>>> >>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>>>>>>> miconda@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@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@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly@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@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@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@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@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@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@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@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@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@lists.sip-router.org >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://lists.sip-router.org/cg
i-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@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@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
Hello.
Pete, did you test this?
I am using this module after patch into production for 20 days without any provlems.
But, I have applied one more patch to fix contact before 200ok. Pool request is active till now) Without it, I have problems with terminating sip calls before 200ok.
-- WBR Sergey Basov
17 мая 2017 г. 4:51 PM пользователь "Pete Kelly" pkelly@gmail.com написал:
Thanks, I will do.
On 10 May 2017 at 06:09, Sergey Basov sergey.v.basov@gmail.com wrote:
Hi Pete,
I think you can try with latest nightly build. Daniel has committed fix at 08 March late evening. So I think it included in latest nightly build.
-- Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 16:37 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com:
Hi.
No. Daniel does not merged fix yet. And he needs some time to backport it to 5.0 branch
-- WBR Sergey Basov
8 мая 2017 г. 4:34 PM пользователь "Pete Kelly" pkelly@gmail.com написал:
Is this fix in the nightly .deb build?
I've just tested the latest and it's still broken
On 8 May 2017 at 07:50, Sergey Basov sergey.v.basov@gmail.com wrote:
Hi, Daniel.
I have created pool request
https://github.com/kamailio/kamailio/pull/1124
Best regards, Sergey Basov e-mail: sergey.v.basov@gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla <miconda@gmail.com
: Try to make a pull request for it and if all ok it will be merged.
Cheers, Daniel
On 06.05.17 17:20, Sergey Basov wrote: > I found issue cause. > > After I have changed line 792 of the file tps_msg.c > from > if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) { > > to > if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) { > > now route header are restores in from: > > Route: <sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4
Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE AAgcAAAABAAAAAAAAAAAAAAAA>
> Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr > > Now ACK are routed correctly. > > Seems that earlier, before fix b_rr store into DB, we does not see > this issue, because only last route header was saved... > But after fix, we have all route records so we nned to restore it
into
> wright way. > > Now I have worked scheme with 3 kamailio in a row, on first of them > enabled topos on other only topoh module. > > Daniel, I will send to you latest dump in separate e-mail. > > Thank you. > > -- > Best regards, > Sergey Basov e-mail: sergey.v.basov@gmail.com > > > 2017-05-05 23:16 GMT+03:00 Sergey Basov sergey.v.basov@gmail.com: >> I think it is because wrong order of Route: header after
restoring...
>> >> With topoh enabled I have: >> >> Route: <sip:10.56.42.37:5070;lr;ftag=
IpXq-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAA AAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=A AAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA>
>> Route: sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr >> >> But with topos enabled I have: >> >> Route: <sip:KITS1.MSS.LIFE.COM:5060;t
>> >> And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060 >> >> Can you fix it? Or I going in to wrong directuon? >> >> Thank you. >> -- >> Best regards, >> Sergey Basov e-mail: sergey.v.basov@gmail.com >> >> >> 2017-05-05 20:32 GMT+03:00 Sergey Basov <sergey.v.basov@gmail.com : >>> Hi Daniel >>> >>> Semms now we have ankther problem... >>> >>> b_rr weites in db correctly. >>> But when ack is sending from A side it try to send to B side to
cantact ip,
>>> ignoring record-route headers... >>> >>> I will try to debug this. >>> >>> If you have any idea I can test it. >>> >>> Thank you. >>> >>> -- >>> WBR >>> Sergey Basov >>> >>> 28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" >>> sergey.v.basov@gmail.com написал: >>> >>>> Hi Daniel. >>>> >>>> Seems all is ok now. >>>> >>>> I applyed your patch and add my additional debug string. >>>> >>>> Now result is: >>>> >>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>> >>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>>> >>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>> >>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn](349)
>>>> >>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers -
b_rr:
>>>> >>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.5 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d4 1.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7d XNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAO AAAAAAAAAAAAAAAA](556)
>>>> >>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >>>> [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>>>> b_rr: >>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>,sip:127.0.0.8;line=sr-BRwEk.dED.s RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn,sip:10.5 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d4 1.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7d XNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAO AAAAAAAAAAAAAAAA](556)
>>>> - s_rr: [](0) >>>> >>>> >>>> Seems this issue is solved. >>>> >>>> Can you apply this patch to 5.0 branch? >>>> Then may be Pete Kelly will install nightly build of the 5.0.1
and
>>>> confirm that issu is solved. >>>> >>>> I does not have such count of sbc for test ) >>>> >>>> Thank you Daniel. >>>> -- >>>> Best regards, >>>> Sergey Basov e-mail:
sergey.v.basov@gmail.com
>>>> >>>> >>>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <
miconda@gmail.com>:
>>>>> Hello, >>>>> >>>>> many thanks Sergey for troubleshooting, it saved a lot of time! >>>>> Hopefully I caught the issue. Can you test with latest master
branch and
>>>>> let me know if works? >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>> On 28.04.17 14:57, Sergey Basov wrote: >>>>>> Some more debug >>>>>> >>>>>> after adding debug output after each iteration I got: >>>>>> >>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG:
topos
>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers
- b_rr:
>>>>>> >>>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
k2ZS1uoLBVfSPhqYZXlvyga*>](84)
>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG:
topos
>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers
- b_rr:
>>>>>> >>>>>> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZA
eLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ. zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXn TsFnTsXnTsXnTsXnTsXnTsXn>](348)
>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG:
topos
>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers
- b_rr:
>>>>>> >>>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>>>>> >>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG:
topos
>>>>>> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr:
[](0) -
>>>>>> b_rr: >>>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB
-4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>>>>>> - s_rr: [](0) >>>>>> >>>>>> So size are computed correctly, but part of record-routes >>>>>> disappears.... And we can see correct size of the record but
only last
>>>>>> part of the record-routes >>>>>> >>>>>> Hope it helps >>>>>> -- >>>>>> Best regards, >>>>>> Sergey Basov e-mail:
sergey.v.basov@gmail.com
>>>>>> >>>>>> >>>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <
sergey.v.basov@gmail.com>:
>>>>>>> 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.1TlqHP7frDwZWwhcyKAcOf
IVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX 14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9B RxjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,sip:212.58.160.253:506 1;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIV Tn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14 CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR xjYGAUeXl/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.1TlqHP7frDwZWwhcyKAcOfI
VTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAQAAAAOAAAAAAAAAAAAAAAA>](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@gmail.com
>>>>>>> >>>>>>> >>>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <
sergey.v.basov@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@gmail.com
>>>>>>>> >>>>>>>> >>>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >>>>>>>> miconda@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@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@gmail.com
wrote:
>>>>>>>>>>> Hi Daniel >>>>>>>>>>> >>>>>>>>>>> It's CSeq 1, fromtag A1 >>>>>>>>>>> >>>>>>>>>>> DB attached >>>>>>>>>>> >>>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >>>>>>>>>>> miconda@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@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@gmail.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly <
pkelly@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@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@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@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@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@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@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@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@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@lists.sip-router.org >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://lists.sip-router.org/cg
i-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@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@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 -
Pete Kelly -
Sergey Basov