From mcc at nexbridge.co.uk  Wed Jul 13 08:13:42 2022
From: mcc at nexbridge.co.uk (Malcolm Chamberlain)
Date: Wed, 13 Jul 2022 09:13:42 +0100
Subject: [OpenSIPS-Business] FW: OpenSIPS Contact Form -
	https://www.opensips-solutions.com/contact.html
In-Reply-To: <00a901d89511$a13f1c00$e3bd5400$@nexbridge.co.uk>
References: <9d942298a06127059ca6884882729ea9@www.opensips-solutions.com>
 <081cf45a-bc62-c145-34bf-c3a4e3c738c3@opensips.org>
 <007b01d87cd5$20396420$60ac2c60$@nexbridge.co.uk>
 <b065d711-3495-204a-12c4-8555bdbf1062@opensips.org>
 <006c01d87fd9$0a9fb860$1fdf2920$@nexbridge.co.uk>
 <019601d88afe$b58aac00$20a00400$@nexbridge.co.uk>
 <00a901d89511$a13f1c00$e3bd5400$@nexbridge.co.uk>
Message-ID: <007301d89690$782a8860$687f9920$@nexbridge.co.uk>

Hi Bogdan,

Just noticed that you are part of the business mailing list so have registered in case you were not receiving my previous email

I would be grateful if you or someone within OpenSIPS can advise further regarding an SBC solution that OpenSIPS maybe able to provide (please read below) and if Control Panel 9 application will give us the control of the SBC for configuration purposes of the platform and for onboarding new endpoints and routing.

I would also be grateful if you can confirm if OpenSIPS SBCs is certified with Microsoft Teams DR?

I will look forward to your reply.

Thanks,

Malcolm

Malcolm Chamberlain
Senior Voice Engineer

Nexbridge Communications Ltd
C/O Ascendis
Unit 3, Building 2
The Colony Wilmslow
Altrincham Road
Wilmslow
SK9 4LY

e: support at nexbridge.co.uk
w: https://nexbridge.co.uk
t: +44 (0) 3456 800 800

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may not be used or disclosed except for the purpose for which it has been sent. If you have received this email in error, please notify the system administrator info at nexbridge.co.uk quoting the sender's address. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this email and must delete the message and any documents. Please advise immediately if you or your employer do not consent to email for messages of this kind. Unless expressly stated, opinions in this message are those of the individual sender and not of Nexbridge Communications Ltd (Nexbridge). Nexbridge accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Nexbridge domain. 
Please reply to this email to continue this support thread, do not send a separate email. To update this ticket, reply to this email or login to your account for a complete archive of all your support requests and responses.

-----Original Message-----
From: Malcolm Chamberlain <mcc at nexbridge.co.uk>
Sent: 14 June 2022 11:25
To: 'Bogdan-Andrei Iancu' <bogdan at opensips.org>; 'OpenSIPS Support' <office at opensips-solutions.com>
Subject: RE: OpenSIPS Contact Form - https://www.opensips-solutions.com/contact.html

Hi Bogdan,

Many thanks for coming back to me on this, I have left out some parts of this current network so not to confuse but will explain in more detail which will hopefully clear up some things.

I totally agree about using a single SBC cluster to house all services/customer and supplier trunks however the current setup we have we are not able to interconnect IN platform into the network.

I have joined this company only 6 months ago and what the existing network does is simply act as a carrier so basically we have 2x Opensips SBCs which are configured as an inbound and outbound SBC, these SBCs are only used to interconnect to our Carriers so Inbound numbers we get from our carriers will come into on our inbound SBCs only and for any termination calls we send to our carriers we will use the outbound SBCs only.

We have multiple Asterix servers, we have inbound Asterix servers that hang off the Inbound SBC and outbound servers that hang off the outbound SBCs, customer SIP trunks connect to these Asterix servers and the reason why we use them is for billing mainly as we don’t use CDRs from the SBCs.

We are trying to introduce an IN platform where customers can log in to a web interface and managed their inbound numbers, failover routing etc where an Inbound DDI will pass through the IN platform, the IN platform will look up the inbound DDI and will provide the routing information which the customer will see as route ID 'BT' for example but behind that will be like a 4 digit route prefix for example 3002, the IN platform will add the route prefix back to the dialled number for example 300202077481372, when that routes back to the SBC there will be an egress match for 3002 which will point that number out to the BT trunks on the outbound SBC via the outbound Asterix server.

Again, if the SIP switches does not need to be in the call flow ie a 302 Move Here scenario then the routing information is contained within the CONTACT header which is sent back to the SBC from the IN platform and then the SIP switch removes itself from the call flow, the CDR from that call appears to show that the call had originated from the carrier and then onto the termination trunk directly.

We have been informed by the existing voice team that we are not able to introduce the IN platform to their existing SBCs as these have been tailored to work with the Asterix servers and that we need to introduce an SBC that will interconnect to both their existing Inbound/Outbound SBCs so  that we can connect the IN platform to the new SBC and configure routing on the new SBC for prefix routing so for example we will need to configure the routing like this:

Existing Inbound SBC receives +44 -> this will pass onto the new SBC as 397202077481372 which we will match on 3792 and then strip and pass on the dialled number 02077481372 which will send the inbound call to the IN platform -> the IN platform does the database lookup and locates the route ID or prefix and passes that call back as either a 302 or non 302 scenario but will send the dialled digits back to the new SBC as for example 300202077481372 -> on the new SBC there will be a match of 3002 and that will forward that call onto the existing outbound SBC by stripping the 3002 and passing out the 02077481372.

For customers that want to use the IN platform these customers will connect to the new SBC and for any inbound DDIs we will need to pass onto them from the IN platform they will have dedicated route prefixes so if customer require to receive their own inbound DDIs as they are managing the onward service for these numbers then the same routing principle above applies however we would route these calls from the new SBC to the customers SIP trunk.

My previous company had the IN platform and used a single Genband S3 SBC where all customers/carriers and internal service trunks were all connected so the SBC handled the routing, billing, trunk load balancing, call admission control and CPS limiting so for this new SBC we need to have the same SBC setup to do the same thing and to handle a 302 Move Here scenario and so our question is based on what I have described above, could we get this with an OpenSips SBC, how much would it cost to deploy it, could the SBC be clustered for 1+1 control and can we have a MI or Web interface that we can configure the SBC with routing and trunk administration in order to build SIP trunk and routing without the need for command line control?

I have attached a full diagram on how the network looks like now and what it would look like with adding both the new SBC and IN platform into the network.

Please let me know your thoughts.

Many thanks,

Malcolm 



Malcolm Chamberlain
Senior Voice Engineer

Nexbridge Communications Ltd
C/O Ascendis
Unit 3, Building 2
The Colony Wilmslow
Altrincham Road
Wilmslow
SK9 4LY

e: support at nexbridge.co.uk
w: https://nexbridge.co.uk
t: +44 (0) 3456 800 800

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may not be used or disclosed except for the purpose for which it has been sent. If you have received this email in error, please notify the system administrator info at nexbridge.co.uk quoting the sender's address. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this email and must delete the message and any documents. Please advise immediately if you or your employer do not consent to email for messages of this kind. Unless expressly stated, opinions in this message are those of the individual sender and not of Nexbridge Communications Ltd (Nexbridge). Nexbridge accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Nexbridge domain. 
Please reply to this email to continue this support thread, do not send a separate email. To update this ticket, reply to this email or login to your account for a complete archive of all your support requests and responses.

Note: Nexbridge operates a 48-hour working-day SLA on all support requests. You can view our network status at status.nexbridge.co.uk.

-----Original Message-----
From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Sent: 13 June 2022 17:08
To: Malcolm Chamberlain <mcc at nexbridge.co.uk>; 'OpenSIPS Support' <office at opensips-solutions.com>
Subject: Re: OpenSIPS Contact Form - https://www.opensips-solutions.com/contact.html

HI Malcolm,

Thanks for the really detailed description here. I may say I got a feeling on your platform here, but with some gaps (mainly to the actual logic to replace prefixes, etc, rather than the chaining in the call flow).
Now, the question is why using like 3 OpenSIPS SBC components, while you can actually put all that logic into a single component, to simplify the whole routing.

Also, what is the target of the project here? as you mentioned the components (blue boxes) are more or less in place.

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 27-30 Sept 2022, Athens
   https://www.opensips.org/events/Summit-2022Athens/

On 6/10/22 5:19 PM, Malcolm Chamberlain wrote:
> Hi Bogdan-Andrei,
>
> Many thanks for coming back to me, it is very much appreciated.
>
> Apologies for not explaining myself clearly before, I have put together a diagram (attached) and have provided an overview of each stage of the call flow for a better understanding on what we are looking at doing and hopefully what you may be able to advise on what would be the best option based on our setup.
>
> We are using OpenSIPS SBCs but these are broken out for Inbound and Outbound and not bi-directional routing.
>
> For illustration purposes the SBC that we require to interact with our SIP switches/IN Platform and Customer SIP trunks I have labelled as 'Tech X SBC'.
>
> The purpose of the IN platform is basically a routing database so all Inbound number routing lookups are performed on that server and we will use a prefix based system on the 'Tech X' SBC to route these calls to Carriers and Customer SIP trunks.
>
> Stage 1: Call comes in from our PSTN carrier into our Inbound SBC as +44, This SBC is an Open Sips SBC, we only interconnect with our carriers so we don’t interconnect with our customers on the same SBC and is used for carriers routing calls to us Inbound only.
>
> Stage 2: The Open Sips SBC simply passes the call onto what we will call for now Tech X SBC which will have an Inbound DDI match of +44 but will strip +44 and add prefix of 3972 with a leading 0, there should be an egress match for 39720 for the SIP switch trunks but before its routes out of the TechX SBC to the SIP switches will strip the 4 digit prefix of 3792 and just pass out the leading 0 to both SIP switches which are load balance, so for example:
>
> OpenSIPs SBC to TECH X SBC inbound match of +44 plus all non-match digits , strip +44 and replace with 39720 plus all non-match digits.
>
> Tech X SBC to SIP switches Outbound match of 39720 plus all non-match digits, strip 37920 and replace with 0 plus all non-match digits.
>
> The SBC will have interconnects with both SIP switches which will need to be load balanced so calls can be routed to both trunks 50/50 and if we were to lose one of the trunks or if SIP option requests had failed then the SBC will have the ability to route all calls out to the 2nd trunk until that trunk is fully restored and then will continue to route calls out to both trunks.
>
> Stage 3: The SIP switches will pass the call to our Intelligent Network platform that will basically perform a database look up table that will match the DDI number and will add the routing prefix and number we need to forward out to, so for example 02077481372 -> database matches DDI and finds that we need to add route prefix 300102077481372, if there is just a single route within the routing schedule on the IN platform then the SIP switches will perform a 302 Move Here request back to the Tech X SBC and within the CONTACT header back to the Tech X SBC will show 300102077481372 and the IP address of the Tech X SBC and then will remove itself from the call flow as a 'stateless' transaction. When the request comes back into the Tech X SBC there will be an Ingress match for prefix 3001 which there will be an egress match for 3001 which will be stripped off which is mapped to Customer SIP trunk A and B again in load share state.
> If the customer decides to translate from 02077481372 to a PSTN, mobile or International number then the IN platform again checks for the inbound DDI match and then adds the prefix for the Carrier which could be 3002 and again is the only route option in the schedule then this will be sent back to the Tech X SBC as a 302 Move Here request as above.
>
> If there is more than a single route option within the schedule for the inbound DDI on the IN platform then the SIP switches are required to stay in the call flow so that if the first route option fails the IN platform will try the second route option, This is known as a Non-302 Move Here scenario so this will send a second invite back to the Tech X SBC from the SIP switch with the prefix and number in the To header so for example 300202077480000.
>
> Tech X SBC to SIP Switch: 02077481372
> IN platform adds 3002 and translates the inbound DDI with 02077480000 
> SIP switch sends back to Tech X SBC with 300202077480000 in the To 
> header
>
> Stage 4: On the ingress routing plan back to the Tech X SBC, will be a match for 3002 plus all non-match digits of which we will strip the 3002 prefix and pass back to the open Sips SBC as +442077480000, the Open Sips SBC has an ingress match of 3002 and passes that call onto the Carrier trunk removing the 3002 prefix.
>
> As you can see from the diagram we have Inbound and Outbound Open SIPs SBCs but for the IN platform and customer SIP trunks, we want to connect this to a separate SBC cluster and send calls to and from the Tech X SBC from either of the open Sips SBCs.
>
> So questions on this setup are below:
>
> 1. Can the open Sips SBC support this setup?
> 2. Can the open Sips SBC handle 302 re-direct requests?
> 3. Can the open Sips be clustered for failover and if so, how does this work?
> 4. Can the open Sips SBC do load balancing when distributing calls to more than SIP trunk?
> 5. Can the open Sips SBC perform simple digit manipulations ie stripping/adding for both DDI and CLI?
> 6. Can the open Sips SBC manage Call Admission Control at a trunk level?
> 7. Can the open Sips SBC manage Calls Per Second at a trunk level?
> 8. Is there a Management Interface/GUI that we can use to configure the SBC and SIP trunk configurations?
> 9. Can the SBC do billing/CDR generation.
> 10. What are the costs to supply and install an OpenSIPs cluster SBC?
> 11 Can the open sips platform support Topology hiding?
>
> I think I have covered all questions for now but I would appreciate if you can go over my diagram and steps and of course if you have any further questions please feel free to contact me or we can set up a meeting on Teams.
>
> Many thanks,
>
> Malcolm
>
>
> Malcolm Chamberlain
> Senior Voice Engineer
>
> Nexbridge Communications Ltd
> C/O Ascendis
> Unit 3, Building 2
> The Colony Wilmslow
> Altrincham Road
> Wilmslow
> SK9 4LY
>
> e: support at nexbridge.co.uk
> w: https://nexbridge.co.uk
> t: +44 (0) 3456 800 800
>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may not be used or disclosed except for the purpose for which it has been sent. If you have received this email in error, please notify the system administrator info at nexbridge.co.uk quoting the sender's address. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this email and must delete the message and any documents. Please advise immediately if you or your employer do not consent to email for messages of this kind. Unless expressly stated, opinions in this message are those of the individual sender and not of Nexbridge Communications Ltd (Nexbridge). Nexbridge accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Nexbridge domain.
> Please reply to this email to continue this support thread, do not send a separate email. To update this ticket, reply to this email or login to your account for a complete archive of all your support requests and responses.
>
> Note: Nexbridge operates a 48-hour working-day SLA on all support requests. You can view our network status at status.nexbridge.co.uk.
>
> -----Original Message-----
> From: Bogdan-Andrei Iancu <bogdan at opensips.org>
> Sent: 09 June 2022 15:49
> To: mcc at nexbridge.co.uk; OpenSIPS Support 
> <office at opensips-solutions.com>
> Subject: Re: OpenSIPS Contact Form -
> https://www.opensips-solutions.com/contact.html
>
> Hello Malcolm
>
> Thank you for reaching us.
>
> To be honest, it is not clear for me what is the call flow(s) you are targeting - do you have a diagram or so showing more clearly (a picture makes like 1000 words :) ) ?
>
> We have 2 separate products, the SBC and the Trunking. The SBC is a border element, able to pass traffic between internal and external sides, with some LB and failover capabilities on the internal side (towards core servers).
>
> The Trunking is more a like routing component able to route (based on DIDs and prefixes) between trunks (customers doing bulk traffic) and carriers (origination and termination for PSTN traffic).
>
> I can provide more info on those two, but again, I'm trying to clarify in my head the call flow you need to have.
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>     https://www.opensips-solutions.com
> OpenSIPS Summit 27-30 Sept 2022, Athens
>     https://www.opensips.org/events/Summit-2022Athens/
>
> On 6/8/22 3:50 PM, Malcolm Chamberlain wrote:
>> ​Hi,
>>
>> I am currently looking at SBC's on the market and have come across 
>> your SBC products and in particular the SIPGene Trunking solution.
>>
>> What we have are trying to configure is a numbering database customer 
>> frontend portal where we can route calls from an SBC to a set of SIP 
>> servers which are able to re-direct calls by means of a 302 move here 
>> so that the numbering database provides the routing details to send 
>> back to the SBC for onward routing to an APP server or a re-invite 
>> scenario where the SIP server is required to stay withing the call flow.
>>
>> The SBC will need to load balance/percenatage split call routing to 
>> multiple SIP servers or SIP trunks where the same routing profile is 
>> applied so that if a SIP trunk where unreachable then calls will 
>> automatically fail over to trunks that have the same routing options 
>> applied or SIP option failures, we will also need the ability to 
>> cluster the SBC for automatic failover should the primary SBC fail so 
>> some sort of heartbeat/sync monitoring.
>>
>> Will this be a software of physical or both product? also it mentions 
>> configuration using a WEB interface, is that the OpenSips Control 
>> Panel GUI?
>>
>> If you can provide some further detail on this that would be appreciated.
>>
>> Thanks,
>>
>> Malcolm Chamberlain





From mcc at nexbridge.co.uk  Wed Jul 13 12:03:28 2022
From: mcc at nexbridge.co.uk (Malcolm Chamberlain)
Date: Wed, 13 Jul 2022 13:03:28 +0100
Subject: [OpenSIPS-Business] New Project Proposal Query
In-Reply-To: <007301d89690$782a8860$687f9920$@nexbridge.co.uk>
References: <9d942298a06127059ca6884882729ea9@www.opensips-solutions.com>
 <081cf45a-bc62-c145-34bf-c3a4e3c738c3@opensips.org>
 <007b01d87cd5$20396420$60ac2c60$@nexbridge.co.uk>
 <b065d711-3495-204a-12c4-8555bdbf1062@opensips.org>
 <006c01d87fd9$0a9fb860$1fdf2920$@nexbridge.co.uk>
 <019601d88afe$b58aac00$20a00400$@nexbridge.co.uk>
 <00a901d89511$a13f1c00$e3bd5400$@nexbridge.co.uk>
 <007301d89690$782a8860$687f9920$@nexbridge.co.uk>
Message-ID: <00f601d896b0$90aa73d0$b1ff5b70$@nexbridge.co.uk>

Replying with subject header for clarity.

Thanks,

Malcolm

Malcolm Chamberlain
Senior Voice Engineer

Nexbridge Communications Ltd
C/O Ascendis
Unit 3, Building 2
The Colony Wilmslow
Altrincham Road
Wilmslow
SK9 4LY

e: support at nexbridge.co.uk
w: https://nexbridge.co.uk
t: +44 (0) 3456 800 800

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may not be used or disclosed except for the purpose for which it has been sent. If you have received this email in error, please notify the system administrator info at nexbridge.co.uk quoting the sender's address. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this email and must delete the message and any documents. Please advise immediately if you or your employer do not consent to email for messages of this kind. Unless expressly stated, opinions in this message are those of the individual sender and not of Nexbridge Communications Ltd (Nexbridge). Nexbridge accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Nexbridge domain. 
Please reply to this email to continue this support thread, do not send a separate email. To update this ticket, reply to this email or login to your account for a complete archive of all your support requests and responses.

Note: Nexbridge operates a 48-hour working-day SLA on all support requests. You can view our network status at status.nexbridge.co.uk.

-----Original Message-----
From: Malcolm Chamberlain <mcc at nexbridge.co.uk> 
Sent: 13 July 2022 09:14
To: business at lists.opensips.org
Subject: FW: OpenSIPS Contact Form - https://www.opensips-solutions.com/contact.html

Hi Bogdan,

Just noticed that you are part of the business mailing list so have registered in case you were not receiving my previous email

I would be grateful if you or someone within OpenSIPS can advise further regarding an SBC solution that OpenSIPS maybe able to provide (please read below) and if Control Panel 9 application will give us the control of the SBC for configuration purposes of the platform and for onboarding new endpoints and routing.

I would also be grateful if you can confirm if OpenSIPS SBCs is certified with Microsoft Teams DR?

I will look forward to your reply.

Thanks,

Malcolm

Malcolm Chamberlain
Senior Voice Engineer

Nexbridge Communications Ltd
C/O Ascendis
Unit 3, Building 2
The Colony Wilmslow
Altrincham Road
Wilmslow
SK9 4LY

e: support at nexbridge.co.uk
w: https://nexbridge.co.uk
t: +44 (0) 3456 800 800

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may not be used or disclosed except for the purpose for which it has been sent. If you have received this email in error, please notify the system administrator info at nexbridge.co.uk quoting the sender's address. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this email and must delete the message and any documents. Please advise immediately if you or your employer do not consent to email for messages of this kind. Unless expressly stated, opinions in this message are those of the individual sender and not of Nexbridge Communications Ltd (Nexbridge). Nexbridge accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Nexbridge domain. 
Please reply to this email to continue this support thread, do not send a separate email. To update this ticket, reply to this email or login to your account for a complete archive of all your support requests and responses.

-----Original Message-----
From: Malcolm Chamberlain <mcc at nexbridge.co.uk>
Sent: 14 June 2022 11:25
To: 'Bogdan-Andrei Iancu' <bogdan at opensips.org>; 'OpenSIPS Support' <office at opensips-solutions.com>
Subject: RE: OpenSIPS Contact Form - https://www.opensips-solutions.com/contact.html

Hi Bogdan,

Many thanks for coming back to me on this, I have left out some parts of this current network so not to confuse but will explain in more detail which will hopefully clear up some things.

I totally agree about using a single SBC cluster to house all services/customer and supplier trunks however the current setup we have we are not able to interconnect IN platform into the network.

I have joined this company only 6 months ago and what the existing network does is simply act as a carrier so basically we have 2x Opensips SBCs which are configured as an inbound and outbound SBC, these SBCs are only used to interconnect to our Carriers so Inbound numbers we get from our carriers will come into on our inbound SBCs only and for any termination calls we send to our carriers we will use the outbound SBCs only.

We have multiple Asterix servers, we have inbound Asterix servers that hang off the Inbound SBC and outbound servers that hang off the outbound SBCs, customer SIP trunks connect to these Asterix servers and the reason why we use them is for billing mainly as we don’t use CDRs from the SBCs.

We are trying to introduce an IN platform where customers can log in to a web interface and managed their inbound numbers, failover routing etc where an Inbound DDI will pass through the IN platform, the IN platform will look up the inbound DDI and will provide the routing information which the customer will see as route ID 'BT' for example but behind that will be like a 4 digit route prefix for example 3002, the IN platform will add the route prefix back to the dialled number for example 300202077481372, when that routes back to the SBC there will be an egress match for 3002 which will point that number out to the BT trunks on the outbound SBC via the outbound Asterix server.

Again, if the SIP switches does not need to be in the call flow ie a 302 Move Here scenario then the routing information is contained within the CONTACT header which is sent back to the SBC from the IN platform and then the SIP switch removes itself from the call flow, the CDR from that call appears to show that the call had originated from the carrier and then onto the termination trunk directly.

We have been informed by the existing voice team that we are not able to introduce the IN platform to their existing SBCs as these have been tailored to work with the Asterix servers and that we need to introduce an SBC that will interconnect to both their existing Inbound/Outbound SBCs so  that we can connect the IN platform to the new SBC and configure routing on the new SBC for prefix routing so for example we will need to configure the routing like this:

Existing Inbound SBC receives +44 -> this will pass onto the new SBC as 397202077481372 which we will match on 3792 and then strip and pass on the dialled number 02077481372 which will send the inbound call to the IN platform -> the IN platform does the database lookup and locates the route ID or prefix and passes that call back as either a 302 or non 302 scenario but will send the dialled digits back to the new SBC as for example 300202077481372 -> on the new SBC there will be a match of 3002 and that will forward that call onto the existing outbound SBC by stripping the 3002 and passing out the 02077481372.

For customers that want to use the IN platform these customers will connect to the new SBC and for any inbound DDIs we will need to pass onto them from the IN platform they will have dedicated route prefixes so if customer require to receive their own inbound DDIs as they are managing the onward service for these numbers then the same routing principle above applies however we would route these calls from the new SBC to the customers SIP trunk.

My previous company had the IN platform and used a single Genband S3 SBC where all customers/carriers and internal service trunks were all connected so the SBC handled the routing, billing, trunk load balancing, call admission control and CPS limiting so for this new SBC we need to have the same SBC setup to do the same thing and to handle a 302 Move Here scenario and so our question is based on what I have described above, could we get this with an OpenSips SBC, how much would it cost to deploy it, could the SBC be clustered for 1+1 control and can we have a MI or Web interface that we can configure the SBC with routing and trunk administration in order to build SIP trunk and routing without the need for command line control?

I have attached a full diagram on how the network looks like now and what it would look like with adding both the new SBC and IN platform into the network.

Please let me know your thoughts.

Many thanks,

Malcolm 



Malcolm Chamberlain
Senior Voice Engineer

Nexbridge Communications Ltd
C/O Ascendis
Unit 3, Building 2
The Colony Wilmslow
Altrincham Road
Wilmslow
SK9 4LY

e: support at nexbridge.co.uk
w: https://nexbridge.co.uk
t: +44 (0) 3456 800 800

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may not be used or disclosed except for the purpose for which it has been sent. If you have received this email in error, please notify the system administrator info at nexbridge.co.uk quoting the sender's address. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this email and must delete the message and any documents. Please advise immediately if you or your employer do not consent to email for messages of this kind. Unless expressly stated, opinions in this message are those of the individual sender and not of Nexbridge Communications Ltd (Nexbridge). Nexbridge accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Nexbridge domain. 
Please reply to this email to continue this support thread, do not send a separate email. To update this ticket, reply to this email or login to your account for a complete archive of all your support requests and responses.

Note: Nexbridge operates a 48-hour working-day SLA on all support requests. You can view our network status at status.nexbridge.co.uk.

-----Original Message-----
From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Sent: 13 June 2022 17:08
To: Malcolm Chamberlain <mcc at nexbridge.co.uk>; 'OpenSIPS Support' <office at opensips-solutions.com>
Subject: Re: OpenSIPS Contact Form - https://www.opensips-solutions.com/contact.html

HI Malcolm,

Thanks for the really detailed description here. I may say I got a feeling on your platform here, but with some gaps (mainly to the actual logic to replace prefixes, etc, rather than the chaining in the call flow).
Now, the question is why using like 3 OpenSIPS SBC components, while you can actually put all that logic into a single component, to simplify the whole routing.

Also, what is the target of the project here? as you mentioned the components (blue boxes) are more or less in place.

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 27-30 Sept 2022, Athens
   https://www.opensips.org/events/Summit-2022Athens/

On 6/10/22 5:19 PM, Malcolm Chamberlain wrote:
> Hi Bogdan-Andrei,
>
> Many thanks for coming back to me, it is very much appreciated.
>
> Apologies for not explaining myself clearly before, I have put together a diagram (attached) and have provided an overview of each stage of the call flow for a better understanding on what we are looking at doing and hopefully what you may be able to advise on what would be the best option based on our setup.
>
> We are using OpenSIPS SBCs but these are broken out for Inbound and Outbound and not bi-directional routing.
>
> For illustration purposes the SBC that we require to interact with our SIP switches/IN Platform and Customer SIP trunks I have labelled as 'Tech X SBC'.
>
> The purpose of the IN platform is basically a routing database so all Inbound number routing lookups are performed on that server and we will use a prefix based system on the 'Tech X' SBC to route these calls to Carriers and Customer SIP trunks.
>
> Stage 1: Call comes in from our PSTN carrier into our Inbound SBC as +44, This SBC is an Open Sips SBC, we only interconnect with our carriers so we don’t interconnect with our customers on the same SBC and is used for carriers routing calls to us Inbound only.
>
> Stage 2: The Open Sips SBC simply passes the call onto what we will call for now Tech X SBC which will have an Inbound DDI match of +44 but will strip +44 and add prefix of 3972 with a leading 0, there should be an egress match for 39720 for the SIP switch trunks but before its routes out of the TechX SBC to the SIP switches will strip the 4 digit prefix of 3792 and just pass out the leading 0 to both SIP switches which are load balance, so for example:
>
> OpenSIPs SBC to TECH X SBC inbound match of +44 plus all non-match digits , strip +44 and replace with 39720 plus all non-match digits.
>
> Tech X SBC to SIP switches Outbound match of 39720 plus all non-match digits, strip 37920 and replace with 0 plus all non-match digits.
>
> The SBC will have interconnects with both SIP switches which will need to be load balanced so calls can be routed to both trunks 50/50 and if we were to lose one of the trunks or if SIP option requests had failed then the SBC will have the ability to route all calls out to the 2nd trunk until that trunk is fully restored and then will continue to route calls out to both trunks.
>
> Stage 3: The SIP switches will pass the call to our Intelligent Network platform that will basically perform a database look up table that will match the DDI number and will add the routing prefix and number we need to forward out to, so for example 02077481372 -> database matches DDI and finds that we need to add route prefix 300102077481372, if there is just a single route within the routing schedule on the IN platform then the SIP switches will perform a 302 Move Here request back to the Tech X SBC and within the CONTACT header back to the Tech X SBC will show 300102077481372 and the IP address of the Tech X SBC and then will remove itself from the call flow as a 'stateless' transaction. When the request comes back into the Tech X SBC there will be an Ingress match for prefix 3001 which there will be an egress match for 3001 which will be stripped off which is mapped to Customer SIP trunk A and B again in load share state.
> If the customer decides to translate from 02077481372 to a PSTN, mobile or International number then the IN platform again checks for the inbound DDI match and then adds the prefix for the Carrier which could be 3002 and again is the only route option in the schedule then this will be sent back to the Tech X SBC as a 302 Move Here request as above.
>
> If there is more than a single route option within the schedule for the inbound DDI on the IN platform then the SIP switches are required to stay in the call flow so that if the first route option fails the IN platform will try the second route option, This is known as a Non-302 Move Here scenario so this will send a second invite back to the Tech X SBC from the SIP switch with the prefix and number in the To header so for example 300202077480000.
>
> Tech X SBC to SIP Switch: 02077481372
> IN platform adds 3002 and translates the inbound DDI with 02077480000 
> SIP switch sends back to Tech X SBC with 300202077480000 in the To 
> header
>
> Stage 4: On the ingress routing plan back to the Tech X SBC, will be a match for 3002 plus all non-match digits of which we will strip the 3002 prefix and pass back to the open Sips SBC as +442077480000, the Open Sips SBC has an ingress match of 3002 and passes that call onto the Carrier trunk removing the 3002 prefix.
>
> As you can see from the diagram we have Inbound and Outbound Open SIPs SBCs but for the IN platform and customer SIP trunks, we want to connect this to a separate SBC cluster and send calls to and from the Tech X SBC from either of the open Sips SBCs.
>
> So questions on this setup are below:
>
> 1. Can the open Sips SBC support this setup?
> 2. Can the open Sips SBC handle 302 re-direct requests?
> 3. Can the open Sips be clustered for failover and if so, how does this work?
> 4. Can the open Sips SBC do load balancing when distributing calls to more than SIP trunk?
> 5. Can the open Sips SBC perform simple digit manipulations ie stripping/adding for both DDI and CLI?
> 6. Can the open Sips SBC manage Call Admission Control at a trunk level?
> 7. Can the open Sips SBC manage Calls Per Second at a trunk level?
> 8. Is there a Management Interface/GUI that we can use to configure the SBC and SIP trunk configurations?
> 9. Can the SBC do billing/CDR generation.
> 10. What are the costs to supply and install an OpenSIPs cluster SBC?
> 11 Can the open sips platform support Topology hiding?
>
> I think I have covered all questions for now but I would appreciate if you can go over my diagram and steps and of course if you have any further questions please feel free to contact me or we can set up a meeting on Teams.
>
> Many thanks,
>
> Malcolm
>
>
> Malcolm Chamberlain
> Senior Voice Engineer
>
> Nexbridge Communications Ltd
> C/O Ascendis
> Unit 3, Building 2
> The Colony Wilmslow
> Altrincham Road
> Wilmslow
> SK9 4LY
>
> e: support at nexbridge.co.uk
> w: https://nexbridge.co.uk
> t: +44 (0) 3456 800 800
>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may not be used or disclosed except for the purpose for which it has been sent. If you have received this email in error, please notify the system administrator info at nexbridge.co.uk quoting the sender's address. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this email and must delete the message and any documents. Please advise immediately if you or your employer do not consent to email for messages of this kind. Unless expressly stated, opinions in this message are those of the individual sender and not of Nexbridge Communications Ltd (Nexbridge). Nexbridge accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Nexbridge domain.
> Please reply to this email to continue this support thread, do not send a separate email. To update this ticket, reply to this email or login to your account for a complete archive of all your support requests and responses.
>
> Note: Nexbridge operates a 48-hour working-day SLA on all support requests. You can view our network status at status.nexbridge.co.uk.
>
> -----Original Message-----
> From: Bogdan-Andrei Iancu <bogdan at opensips.org>
> Sent: 09 June 2022 15:49
> To: mcc at nexbridge.co.uk; OpenSIPS Support 
> <office at opensips-solutions.com>
> Subject: Re: OpenSIPS Contact Form -
> https://www.opensips-solutions.com/contact.html
>
> Hello Malcolm
>
> Thank you for reaching us.
>
> To be honest, it is not clear for me what is the call flow(s) you are targeting - do you have a diagram or so showing more clearly (a picture makes like 1000 words :) ) ?
>
> We have 2 separate products, the SBC and the Trunking. The SBC is a border element, able to pass traffic between internal and external sides, with some LB and failover capabilities on the internal side (towards core servers).
>
> The Trunking is more a like routing component able to route (based on DIDs and prefixes) between trunks (customers doing bulk traffic) and carriers (origination and termination for PSTN traffic).
>
> I can provide more info on those two, but again, I'm trying to clarify in my head the call flow you need to have.
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>     https://www.opensips-solutions.com
> OpenSIPS Summit 27-30 Sept 2022, Athens
>     https://www.opensips.org/events/Summit-2022Athens/
>
> On 6/8/22 3:50 PM, Malcolm Chamberlain wrote:
>> ​Hi,
>>
>> I am currently looking at SBC's on the market and have come across 
>> your SBC products and in particular the SIPGene Trunking solution.
>>
>> What we have are trying to configure is a numbering database customer 
>> frontend portal where we can route calls from an SBC to a set of SIP 
>> servers which are able to re-direct calls by means of a 302 move here 
>> so that the numbering database provides the routing details to send 
>> back to the SBC for onward routing to an APP server or a re-invite 
>> scenario where the SIP server is required to stay withing the call flow.
>>
>> The SBC will need to load balance/percenatage split call routing to 
>> multiple SIP servers or SIP trunks where the same routing profile is 
>> applied so that if a SIP trunk where unreachable then calls will 
>> automatically fail over to trunks that have the same routing options 
>> applied or SIP option failures, we will also need the ability to 
>> cluster the SBC for automatic failover should the primary SBC fail so 
>> some sort of heartbeat/sync monitoring.
>>
>> Will this be a software of physical or both product? also it mentions 
>> configuration using a WEB interface, is that the OpenSips Control 
>> Panel GUI?
>>
>> If you can provide some further detail on this that would be appreciated.
>>
>> Thanks,
>>
>> Malcolm Chamberlain






From bogdan at opensips.org  Thu Jul 14 15:24:16 2022
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 14 Jul 2022 18:24:16 +0300
Subject: [OpenSIPS-Business] OpenSIPS 3.3.0 goes stable
Message-ID: <c0fdb5df-a7ab-b8a7-7a6a-816aa922e8ed@opensips.org>

<https://www.opensips.org/About/Version-Overview-3-3-0>


    OpenSIPS 3.3.0


    goes from beta to stable



*It got stable!*

There was a month and a half of work, of testing, of reporting and of 
fixing, but we did it! The OpenSIPS 3.3 release passed all the tests and 
exams and now it is labelled as a stable release, the new flagship of 
the OpenSIPS project.


Download it now <https://www.opensips.org/Downloads/Downloads>

*3.3 Philosophy*

The OpenSIPS 3.3 is to address more, in depth, the topic of *Instant 
Messaging*, in the context of SIP. And this is done through two major 
perspectives: from the Unified Communication perspective, by aligning IM 
with the voice and presence capabilities in OpenSIPS, and from the IMS 
perspective, mainly as support/integration with RCS (Rich Communication 
Services). So key features

  * MSRP relay
  * MSRP User Agent
  * MSRP gateway (to SIP Message)
  * Contact Center (OmniChannel)
  * RCS Support
  * Diameter extensions
  * Status/Report support
  * SDP demux and more RTP Relaying

Read more on 3.3
<https://www.opensips.org/About/Version-Overview-3-3-0>


Do you want to learn more on OpenSIPS 3.3?

Join us for the *OpenSIPS Summit 2022 in Athens* 
<https://www.opensips.org/events/Summit-2022Athens/>, for 4 days of 
conferencing, workshops, training and design clinics


Download and enjoy it as it's freshly baked for you!

Any questions? do not hesitate to contact us <mailto:team at opensips.org>!

------------------------------------------------------------------------


-- 
Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/business/attachments/20220714/3543c1ec/attachment.html>