Re: [asterisk-dev] One sip stack to rule them all....
The Real-Time Text feature of Asterisk does not work with PJSIP. Or at least it is not documented how its redundant transport support is configured. See: https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=4260034 for how it once worked. (There are bugs in the release 11 and 13 implementations of redundant transmission of real-time text with chan_sip as well, but it worked in earlier releases. ) Den 2017-10-08 kl. 16:55, skrev James Finstrom: One does not simply depricate a sip stack. Ok so at devcon there was a discussion of depricating chan_sip. This may sound a lot worse than it actually is. Chan_sip has been essentially untouched in 4ish years. It does not receive bug fixes. It is just sort of a barge floating in the ocean. So one of the things that is needed to finally put Chan sip to bed is feature parody. Someone brought up CCSS. What features do you feel you would lose going from chan_sip to pjsip. Are there any bugs in pjsip that keep you from migrating? -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Load on SIP MESSAGE how many per sec asterisk can Handle
Hi Bala, I don't know enough about the message processing in Asterisk to give hints on that level. I only wanted to indicate that it could be network transmission time that sets the limit to the throughput for MESSAGE. There will be at least 4 transmissions on SIP level, to share the 70 milliseconds interval you have. Thus 17 milliseconds transmission time per SIP network transmission. Maybe that is the speed limit of your network. Gunnar Den 2017-06-12 kl. 21:08, skrev bala murugan: Hi Gunnar , Each message is addressed to unique and single URI and as expected by protocol after receiving 202 for each message . Then it is expected rate because the protocol requires end - to - end confirmation by 200 OK or 202 before sending next MESSAGE. [Bala] any idea what this means expected rate ? whether 14 is accepted or only 5 is accpeted . First sum the network transmission times involved in the MESSAGE transaction and calculate how many such transactions you can theoretically get through. Right now @ 14/sec we see the msg_queue is backedup and the message processing thread which is single threaded @ the moment now / taskprocessing thread is not keeping up Please advice . thanks, Bala On Mon, Jun 12, 2017 at 2:41 PM, Gunnar Hellström <gunnar.hellst...@omnitor.se <mailto:gunnar.hellst...@omnitor.se>> wrote: Hi Bala, You did not answer my question: Do you send these MESSAGE between the same two SIP URI:s? Then it is expected rate because the protocol requires end - to - end confirmation by 200 OK or 202 before sending next MESSAGE. If you send to many URI:s, then expected throughput might be higher. Regards Gunnar Den 2017-06-12 kl. 18:23, skrev bala murugan: Thanks Gunnar , This is load test to understand how many message it can handle and where the bottleneck is . 14 MESSAGE / sec - takes longer time for the Message to be processed , not sure if there is some kind of delay in picking up the message from the queue and also it will never be realtime with this rate . Checking if this is already improved or if there is a way to improve this to handle by adding more taskprocessors on the ast_msg_queue or reading more messages from the queue etc. btw i have good system resources like CPU(16 core),memory(32GB) etc I dont know how this asterisk taskprocessor works or implemented . thanks, bala On Wed, May 24, 2017 at 3:18 AM, Gunnar Hellström <gunnar.hellst...@omnitor.se <mailto:gunnar.hellst...@omnitor.se>> wrote: Den 2017-05-23 kl. 23:58, skrev bala murugan: Hi , Is anyone aware of how many SIP MESSAGE per sec asterisk can handle , is there a benchmark has this been load tested and results available some where , if there is can you some one share it please . The reason is we ran 16 per sec and we see the ast_msg_queue is backing up with lot of messages This may depend on your test setup. Are you sending between a fixed pair of URI:s, or multiple? Have you considered this rule from RFC 3428? " A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI." So, if you are sending between one pair of URI:s, the sender needs to wait for a final response before sending next MESSAGE. With usual network delays that can mean a maximum of about 5 MESSAGE per second or so. With multiple URIs on both sides, the figure should be higher. Regards Gunnar thanks, Bala -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev <http://lists.digium.com/mailman/listinfo/asterisk-dev> -- --------- Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46 708 204 288 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Load on SIP MESSAGE how many per sec asterisk can Handle
Hi Bala, You did not answer my question: Do you send these MESSAGE between the same two SIP URI:s? Then it is expected rate because the protocol requires end - to - end confirmation by 200 OK or 202 before sending next MESSAGE. If you send to many URI:s, then expected throughput might be higher. Regards Gunnar Den 2017-06-12 kl. 18:23, skrev bala murugan: Thanks Gunnar , This is load test to understand how many message it can handle and where the bottleneck is . 14 MESSAGE / sec - takes longer time for the Message to be processed , not sure if there is some kind of delay in picking up the message from the queue and also it will never be realtime with this rate . Checking if this is already improved or if there is a way to improve this to handle by adding more taskprocessors on the ast_msg_queue or reading more messages from the queue etc. btw i have good system resources like CPU(16 core),memory(32GB) etc I dont know how this asterisk taskprocessor works or implemented . thanks, bala On Wed, May 24, 2017 at 3:18 AM, Gunnar Hellström <gunnar.hellst...@omnitor.se <mailto:gunnar.hellst...@omnitor.se>> wrote: Den 2017-05-23 kl. 23:58, skrev bala murugan: Hi , Is anyone aware of how many SIP MESSAGE per sec asterisk can handle , is there a benchmark has this been load tested and results available some where , if there is can you some one share it please . The reason is we ran 16 per sec and we see the ast_msg_queue is backing up with lot of messages This may depend on your test setup. Are you sending between a fixed pair of URI:s, or multiple? Have you considered this rule from RFC 3428? " A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI." So, if you are sending between one pair of URI:s, the sender needs to wait for a final response before sending next MESSAGE. With usual network delays that can mean a maximum of about 5 MESSAGE per second or so. With multiple URIs on both sides, the figure should be higher. Regards Gunnar thanks, Bala -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev <http://lists.digium.com/mailman/listinfo/asterisk-dev> -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Load on SIP MESSAGE how many per sec asterisk can Handle
Den 2017-05-23 kl. 23:58, skrev bala murugan: Hi , Is anyone aware of how many SIP MESSAGE per sec asterisk can handle , is there a benchmark has this been load tested and results available some where , if there is can you some one share it please . The reason is we ran 16 per sec and we see the ast_msg_queue is backing up with lot of messages This may depend on your test setup. Are you sending between a fixed pair of URI:s, or multiple? Have you considered this rule from RFC 3428? " A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI." So, if you are sending between one pair of URI:s, the sender needs to wait for a final response before sending next MESSAGE. With usual network delays that can mean a maximum of about 5 MESSAGE per second or so. With multiple URIs on both sides, the figure should be higher. Regards Gunnar thanks, Bala -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
