Genesys Cloud - Main

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

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

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

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

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

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