How to prevent retries when 603 declined in received

Asterisk Asterisk Support
1

hi,

We have a complaint from callback system users that when they return a 603 Declined to us (on DID peered calls) we continue to send retries to them.

This results in multiple callbacks being initiated to their user/caller.

[QUOTE]
When our system rejects a call to 1646xxxxxx@sip.xxxxxxx.com it receives a new call from the same number almost immediately. It means that either the caller redials immediately after getting busy tones (that is
unlikely) or the DID provider (This is us) does not properly support ‘603 Decline’.
From the SIP RFC:

21.6.2 603 Decline
The callee’s machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request.

Therefore the calling side (DID provider) should stop trying to deliver the call, but they do not. You can forward this explanation to them that should be enough for understanding the issue.
[UNQUOTE]

Is there a simple way to prevent retries being sent in this instance?

we are using asterisk 1.6 and 1.8 versions, with asterisk realtime.

any tips would be exteemily welcome.

thank you

2

I don’t think Asterisk retries an invite after any validly identified final response.

Could you provide a verbose dial plan trace to confirm that it is not your dial plan that is retrying.

If you are sure that the SIP channel is initiating the retry, you need to provide “sip set debug on” and “core set debug 5 chan_sip” output (including the debug category) to be able to understand what Asterisk is actually doing.

Is this a retransmission of the invite (which would imply that no response had been matched with the request, or or is this a new call, which I believe could only happen as a result of dialplan action.

3

thanx for your response. I will have to get a user to AUTH one of our phones for their callback system - i can then get a tcp dump and respond.

4

Actault, I think you are correct. The error is in our extensions.conf dialplan.

extensions.conf looks like this:

[general]
autofallthrough=yes
[globals]
[trunk]
switch => Realtime/trunk@extensions
exten => _X.-CONGESTION,n,Hangup
exten => _X.,n,Hangup

I see an error when i ‘reload’ saying that the next sequences on line 6 and 7 are invalid.

The ‘Realtime/trunk@extensions’ only has one entry per extension in the database, such as :

exten :44203318xxxx

priority : 1

app : Dial

appdata : SIP/44203318xxxx@sip.xxxxxx.com,60

Perhaps I need to add :

exten :_X.-CONGESTION

priority : n

app : Dial

appdata : Hangup

or something like that to the end of the database table(??)

any ideas would be very welcome

thank you

5

Made some addition to the realtime extnsions database table, and will see if this has resolved the issue.

INSERTINTOasterisk.extensions (
id ,
context ,
exten ,
priority ,
app ,
appdata
)
VALUES (
NULL ,‘trunk’,’_X.-CONGESTION’,‘2’,‘Hangup’,’’
), (
NULL ,‘trunk’,’_X.’,‘2’,‘Hangup’,’’
);

6

You have a very incomplete dialplan. Either the author didn’t understand that X-xxxxx only works if you use Goto (X-${DIALSTATUS},1) after the Dial, or that code is being provided by an Asterisk GUI, in which case your problems are probably with the GUI, and not with Asterisk.

,n, in dialplan lines is processed at the time the file is read, and causes then next priority number to be used. The realtime logic is processed in real time, so will not establish a baseline priority number when the file is parsed. Also note that n is calculated regardless of what is in the preceding fields, so:

exten => 1,1…
exten => 2,1…
exten => 1,n
exten => 2,n…

will result in extension 2 having a priority one and 3, but no priority one, so the dialplan will stop after the first step.

7

hi,

The dialplan is written by hand not GUI.

The ‘exten => _X.-CONGESTION,n,Hangup’ was added by myself trying to resolve this issue i am trying to solve, and has now been removed.

I suspect my problem may be that I had the ‘Hangup’ in extensions.conf after the switch to realtime/extensions (??)

I now have

context: trunk

exten: _X.

priority: 2

app: Hangup

added to the extensions database table. Is it likely this will resolve the issue, or could you provide some hint as to where i should look.

Thank you for your assistance

8

With autofallthrough, you shouldn’t need an explicit hangup.

As I said above, one needs verbose CLI output to see what is actually be executed, and if the dialplan isn’t explicitly retrying, you need to provide debugging output from the channel driver, including the actual SIP headers exchanged.

9

This issue was resolved after the callback user authed one of our callerIDs on their system.

A tcpdump revealed that no sip response was being recieved by our server, and later confirmed to be firewall related (according to user).

Now all is fine following some change on theur side.

The following is the sip exchange to their callback system:

OUR IP USER IP SIP/SDP 1047 Request: INVITE sip:4420xxxxxxxx@sip.xxxxxxx.com, with session description
USER IP OUR IP SIP 420 Status: 100 trying – your call is important to us
USER IP OUR IP SIP/SDP 775 Status: 183 Session Progress, with session description
OUR IP USER IP SIP 412 Request: CANCEL sip:4420xxxxxxx@sip.xxxxxxx.com
USER IP OUR IP SIP 433 Status: 200 canceling
USER IP OUR IP SIP 398 Status: 487 Request Terminated
OUR IP USER IP SIP 453 Request: ACK sip:4420xxxxxxx@sip.xxxxxxx.com