Does code 603 issue Retry-After header?

[RBS]

Right now it must be either blank or "0", because upstream keeps immediately retrying, producing 50+ retries, all with different UUID.

Can you think of a way to set it to maybe 5 min (300) or have any control over the response headers?

Considering code 603 is a re-triable error, the mess it produces is actually operating normally as designed, because it's not receiving any do-not-retry responses.

 

[YiannisH_3CX]

Hello @RBS

Can you explain what the issue is with an example so we can better try and help?

 

[RBS]

Blacklisted numbers. When SIP provider & Upstream receive code 603, it keeps retrying several times per second.

They can't do anything because 603 didn't come with any further instructions attached (aka 'retry-after=?' header), so they are just doing their job, re-trying again.

While being very explicit with its intentions, "reject" doesn't really have instructions not to try again, as code 403 does, for example.

Imagine the mess in call logs this all leaves behind.

 

[YiannisH_3CX]

The RFC states clearly that the retry-after header MAY by used so it is not mandatory. Where the RFC is not clear is what happens when the retry-after is missing but the logical assumption is that if it is not stated when the next retry should take place then there should be no retry.
We had this conversation with providers as well and we ended up agreeing that if the retry-after header is missing then the provider should not retry.
I am guessing you are not using a supported provider.

 

[RBS]

Before we close the book on this issue, could you point out who should be able to fix this.
The Provider (Telnyx) or Upstream (Peerless Networks)?

Thank you Yiannis

 

[YiannisH_3CX]

We have tested Telnyx and when 603 Decline is received by Telnyx then there is no re-invite (calling from one Telnyx account to another) so i would assume it is the upstream provider that does the re-invite.

 

[RBS]

Does this "code of honor" go up the chain all the way to the originating carrier? Or it's all up to our upstream only?

 

[YiannisH_3CX]

There is no "code of honour" between all providers regarding this and we cannot guarantee that every provider will handle this the same. With the providers that we did have this discussion however we arrived at the same conclusion.

 

[RBS]

If you have anything to say directly to our Upstream/Provider regarding a solution to this issue, they are watching this thread. Please, any ideas at all.

 

[YiannisH_3CX]

If you have anything to say directly to our Upstream/Provider regarding a solution to this issue, they are watching this thread. Please, any ideas at all.

The RFC states clearly that the retry-after header MAY by used so it is not mandatory. Where the RFC is not clear is what happens when the retry-after is missing but the logical assumption is that if it is not stated when the next retry should take place then there should be no retry.