Genesys Cloud - Main

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.

Hi Catelyn

I found the following on the resource center where you can limit the maximum number of calls and also configure the max calls reason code.

You could enable this and make the max concurrent calls on the test trunk to 0 which will then not allow any calls.

https://help.genesys.cloud/articles/configure-maximum-call-settings/

Not sure if this might help.  Hopefully someone else in the community has additional ideas on how to best achieve this.

Regards

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.

Hi Catelyn

I'm wondering why you need to change disabled the trunk?

Stephan idea is interesting, I believe it could work.

Hi Catelyn

I found the following on the resource center where you can limit the maximum number of calls and also configure the max calls reason code.

You could enable this and make the max concurrent calls on the test trunk to 0 which will then not allow any calls.

https://help.genesys.cloud/articles/configure-maximum-call-settings/

Not sure if this might help.  Hopefully someone else in the community has additional ideas on how to best achieve this.

Regards

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.

Hi Catelyn

I found the following on the resource center where you can limit the maximum number of calls and also configure the max calls reason code.

You could enable this and make the max concurrent calls on the test trunk to 0 which will then not allow any calls.

https://help.genesys.cloud/articles/configure-maximum-call-settings/

Not sure if this might help.  Hopefully someone else in the community has additional ideas on how to best achieve this.

Regards

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.

Hi Stephan,

Thankyou for your message. In theory, you may be on the right track, however from the reasoning I have stated with Kiao, this was not the intent of the query.

What you refer to is limiting the number of calls that are transacting via a single SIP Trunk, where a SIP 603 (Decline) event would be raised, indicating the trunk is unavailable to new SIP transactions.

The query that I was raising was around the SIP Events that were raised when a Trunk was deliberately taken out of service, so to emulate its unavailability.

This was needed to be able to test and ensure that call delivery failover to our secondary Trunk would work, should a call delivery failures be experienced on the Primary Trunk.

What was NOT expected was that a SIP 403 would be returned to the carrier, which indicates a permission related issue, rather than Delivery Denial, similar to SIP 603 Denial events.

I am hoping this makes sense...

Thanks again,

Catelyn

Hi Catelyn

I found the following on the resource center where you can limit the maximum number of calls and also configure the max calls reason code.

You could enable this and make the max concurrent calls on the test trunk to 0 which will then not allow any calls.

https://help.genesys.cloud/articles/configure-maximum-call-settings/

Not sure if this might help.  Hopefully someone else in the community has additional ideas on how to best achieve this.

Regards

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.

Good Day Catelyn

Thank you for the explanation.  Unfortunately I am not aware of any additional configuration where this can be changed on Genesys.  According to my understanding from the information available on resource center, the 403 error returned when the trunk is taken out of service is normal behavior.

Do you have an SBC device between your SIP provider and Genesys or do they connect directly to cloud?  Reason I'm asking is that this might be something that can be achieved on an SBC device.  Alternatively, is it not possible for the SIP provider to treat 403 errors as retryable error codes?  Perhaps the SIP provider can simulate this and do the failover routing on their side if possible.

Hopefully someone else in the community has some other ideas that might help.

Regards

Hi Stephan,

Thankyou for your message. In theory, you may be on the right track, however from the reasoning I have stated with Kiao, this was not the intent of the query.

What you refer to is limiting the number of calls that are transacting via a single SIP Trunk, where a SIP 603 (Decline) event would be raised, indicating the trunk is unavailable to new SIP transactions.

The query that I was raising was around the SIP Events that were raised when a Trunk was deliberately taken out of service, so to emulate its unavailability.

This was needed to be able to test and ensure that call delivery failover to our secondary Trunk would work, should a call delivery failures be experienced on the Primary Trunk.

What was NOT expected was that a SIP 403 would be returned to the carrier, which indicates a permission related issue, rather than Delivery Denial, similar to SIP 603 Denial events.

I am hoping this makes sense...

Thanks again,

Catelyn

Hi Catelyn

I found the following on the resource center where you can limit the maximum number of calls and also configure the max calls reason code.

You could enable this and make the max concurrent calls on the test trunk to 0 which will then not allow any calls.

https://help.genesys.cloud/articles/configure-maximum-call-settings/

Not sure if this might help.  Hopefully someone else in the community has additional ideas on how to best achieve this.

Regards

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.

Hi Stephan,

Thanks again for your input.

Sadly, no this is a Genesys Cloud solution, where the Genesys hosted Edge Servers are playing host to all BYOC Trunks. As such alternate SBC capability not open to us...

Yes, your suggestion makes perfect sense. Unfortunately it is not an option at this point...

I am however VERY KEEN to obtain Genesys thoughts here, as quite frankly, I see this as a Genesys related issue, but not specifically a Genesys Fault, in a literal sense... However SIP 404 or SIP 403 are certainly NOT the responses that would be expected, under SIP delivery standards...

But then again, MOST "standards" are seen by SOME as guidelines... :-)

Never the less, the conversation has been exceedingly supportive, and appreciated...

Cheers,

Catelyn

Good Day Catelyn

Thank you for the explanation.  Unfortunately I am not aware of any additional configuration where this can be changed on Genesys.  According to my understanding from the information available on resource center, the 403 error returned when the trunk is taken out of service is normal behavior.

Do you have an SBC device between your SIP provider and Genesys or do they connect directly to cloud?  Reason I'm asking is that this might be something that can be achieved on an SBC device.  Alternatively, is it not possible for the SIP provider to treat 403 errors as retryable error codes?  Perhaps the SIP provider can simulate this and do the failover routing on their side if possible.

Hopefully someone else in the community has some other ideas that might help.

Regards

Hi Stephan,

Thankyou for your message. In theory, you may be on the right track, however from the reasoning I have stated with Kiao, this was not the intent of the query.

What you refer to is limiting the number of calls that are transacting via a single SIP Trunk, where a SIP 603 (Decline) event would be raised, indicating the trunk is unavailable to new SIP transactions.

The query that I was raising was around the SIP Events that were raised when a Trunk was deliberately taken out of service, so to emulate its unavailability.

This was needed to be able to test and ensure that call delivery failover to our secondary Trunk would work, should a call delivery failures be experienced on the Primary Trunk.

What was NOT expected was that a SIP 403 would be returned to the carrier, which indicates a permission related issue, rather than Delivery Denial, similar to SIP 603 Denial events.

I am hoping this makes sense...

Thanks again,

Catelyn

Hi Catelyn

I found the following on the resource center where you can limit the maximum number of calls and also configure the max calls reason code.

You could enable this and make the max concurrent calls on the test trunk to 0 which will then not allow any calls.

https://help.genesys.cloud/articles/configure-maximum-call-settings/

Not sure if this might help.  Hopefully someone else in the community has additional ideas on how to best achieve this.

Regards

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.

In both of our existing Genesys Cloud Tenants we integrate with a BYOC SIP Carrier, who we have worked with for many years. This has extended from our legacy Genesys Engage platforms, to the Genesys Cloud platform we use actively today.

Prior to today, the support for platform Geolocation was not available to us, and as a result there was a single BYOC SIP Trunk that was established in both Cloud tenants.

Today, thanks to the fact that our carrier now has now introduced multi-location resiliency, we now have the ability to integrate with more than one BYOC SIP Trunk, allowing for a location resiliency integrating back to both of our Genesys Cloud tenants

However it introduced an issue that was not identified before today, where in the event that a SIP Trunk is taken Out of Service, in our case enabling us to validate Trunk failover, the results returned to a Carrier is a SIP 403 (Forbidden) response code, after which the carrier terminates the call. This would make sense, if it was an Access denial, however is not logical, for a trunk that is simply configured to be unavailable "at the moment".

I must emphasize that the ONLY time this happens is when the Trunk is manually taken Out Of Service, within the configuration of that specific SIP Trunk.

Is there a way that this can be altered the response code to be a more appropriate SIP Response, specifically when a Trunk is manually configured to be Out of Service??

Under normal circumstances, and specifically using something that is closer to a Standard SIP call handling, I would expect that a SIP Error 503 (Service Unavailable) would be returned to the Carrier, rather than SIP 403.

The question is therefore what is needed, to enable a more appropriate approach to SIP Call Rejection, when a Trunk has been manually disabled.