<div dir="ltr">May be i was unable to explain my question fully. I was thinking in other direction. <br>Anyway Thank you.</div><div class="gmail_extra"><br><div class="gmail_quote">On 8 March 2016 at 03:25, SamyGo <span dir="ltr"><<a href="mailto:govoiper@gmail.com" target="_blank">govoiper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Satesh,<br><br><div>So I'm not sure what you're talking about - did you post in mailing list about the problem. Was it something that can't be done or has no answer to it ? Were some other alterations tried to the approach ?<br><br></div><div>As far as I know even if you multi-home an opensips you can still force_send_socket() and if it is not forced then Operating System tells the correct interface to use to send packets out. Right now I can only assume things. <br><br></div><div>@Aqs, given your own experiences and engagement in the mailing list I don't think there is any big thing to explain in there. <br></div><div><br>The First layer is nothing but a dispatcher loaded in it pointing to N number of servers.<br>Take an example: <a href="http://www.opensips.org/Documentation/Tutorials-Redirect" target="_blank">http://www.opensips.org/Documentation/Tutorials-Redirect</a><br><br>Now modify it to use dispatcher, <br><br><font face="monospace, monospace">request_route {<br>...<br> if(!ds_select_dst("1","4")) { /* See new version of ds_select_dst(), there are partitions involved etc */<br> sl_send_reply("503","Service Unavailable");<br> }<br> <br> /* modify Contact Header... */<br><br> sl_send_reply("302","Moved Temporarily"); <br>}<br><br></font>And I think thats pretty much it, the Sender will get a 302, with a new Contact header and then it is supposed to talk to that new server.<font face="monospace, monospace"><br></font>Again its the business logic and depends from usage to usage. This is not the only way to increase capacity or efficiency. Sometimes UACs/UASs don't like Redirecting and this method flops.<br><br>Regards,<br>sammy<font face="monospace, monospace"><br><br></font></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 3:14 PM, Aqs Younas <span dir="ltr"><<a href="mailto:aqsyounas@gmail.com" target="_blank">aqsyounas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px;font-weight:bold;white-space:nowrap">Hi, SamyGo</span><br><br>I have seen many people doing two layer opensips setup. First layer as stateless dispatcher and other layer for business logic. <br>I just wonder why not just one layer of opensips doing business logic. I am unable to understand this two layer concept.<div> <br>Can you explain this a bit. <br><br>Thanks in advance. <br> </div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 7 March 2016 at 20:35, SamyGo <span dir="ltr"><<a href="mailto:govoiper@gmail.com" target="_blank">govoiper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Oh, I thought it was a typo, 200,000 CPS ! Well I'd say to not spend much time thinking about t_relay() rather spend energy on designing an architecture that can give you the flexibility and scalability options.<div><br>For example:<br>A DNS SRV pointing to a layer of stateless dispatcher OpenSIPS. These stateless OpenSIPS just don't care about any business logic just do a rough load-balancing and "redirect" to the second layer OpenSIPS. <br>The second layer of OpenSIPS do the business logic and stay in call i.e use t_relay() <br><br>That is a simple example in which you can add as many OpenSIPS at both layers to manage your 200K CPS. </div><div><br></div><div>There could be way too many different ways of handling your 200K CPS load, it all depends on your business logic, type of SIP requests and calls etc, location of the end users/regions, methods to tweak your business logic i.e use of caches and NoSQL DBs, and so much that only you may know at this point. <br><br>Please go through this link: <a href="http://www.opensips.org/About/PerformanceTests" target="_blank">http://www.opensips.org/About/PerformanceTests</a> to see results for different types of configurations. However, do keep in mind that those results may be done on older versions of OpenSIPS and you may want to stress test your setup separately to know what are your capabilities.</div><div><br></div><div>Regards,</div><div>Sammy</div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 8:54 AM, Satish Patel <span dir="ltr"><<a href="mailto:satish.txt@gmail.com" target="_blank">satish.txt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>We have 200,000 CPS and more in future. Just worried about t_relay() and its performance. Any idea?<br><br><div>--</div>Sent from my iPhone</div><div><div><div><br>On Mar 6, 2016, at 2:44 PM, SamyGo <<a href="mailto:govoiper@gmail.com" target="_blank">govoiper@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I'd ask you to read difference between Load_balancer and Dispatcher module. Dispatcher module is not an accurate measure but it is the only option when it comes to load balancing REGISTER requests. <div><br>Dispatcher is hence very light weight as compared to Load Balancer. For a 200 CPS calls Load Balancer or Dispatcehr won't be putting any bigger impact relative to the business logic itself. For example doing alot of DB queries, engaging various other modules etc these things really define how light or heavy your system is going to be.</div><div><br></div><div>Regards,</div><div>Sammy</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 10:36 AM, Satish Patel <span dir="ltr"><<a href="mailto:satish.txt@gmail.com" target="_blank">satish.txt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any thought on it???<br>
<div><div><br>
On Fri, Mar 4, 2016 at 1:30 PM, Satish Patel <<a href="mailto:satish.txt@gmail.com" target="_blank">satish.txt@gmail.com</a>> wrote:<br>
> We have dispatcher and we are using very simple code block like following<br>
><br>
> if (method=="REGISTER" || method=="INVITE" ) {<br>
> ds_select_dst("1", "2");<br>
> t_relay();<br>
> }<br>
><br>
> Does t_relay will keep all transaction in memory? and what will be the<br>
> performance issue? we have ~200k cps calls.. what will be the impact?<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Users mailing list</span><br><span><a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a></span><br><span><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a></span><br></div></blockquote></div></div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>