"Authorization" error message for unsucessful call

[tsim]

Using the QUADM8L, all going well until we had to swap to new router: iConnect Access 624W R07-02 OPEN. I have 2 IP-pstn lines (999 and 998) and system shows registered OK. When making a IP-pstn call via 999 or 998, I get the recording that says 'trying to connect, please wait' and it then says 'access to this number blocked'. I use the routing table with 5 or 7 prefix so that this can route to the correct IP-pstn.

I use the 'Force' for Nat traversal with IP UDP and RTP parameters using Manual.

I am puzzled as to why the QUAD box is doing this; I had a very good run using the old Linksys router for calling but then the registration of Yealink T28 remorely was a nightmare, off and on. Now it registers smoothly but suddenly discovered my calls are actually routed to FXOs instead of the routed IP-pstn and further the selected 5 or 7 prefix is failing. However the 504 prefix routing works well for routing calls to use FXO2, etc. I think this is not co-incidental but could be wrong here.

May I have some pointers as to where this has gone wrong? Thanks.

[I am not sure if the log below is useful, let me know if other details are required]

++++++++++ taken from unsuccessful call statistics:
14-Oct-2010 14:21:38 "qma110L" 110 9nnnnnn@byo.engin.com.au:5060 "Authorization"
14-Oct-2010 13:41:40 "qma110L" 110 9xxxxxx@byo.engin.com.au:5060 "Authorization"

+++++++++++ SIP system log extract
REGISTER sip:192.168.0.65 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.188:5062;branch=z9hG4bK1415258534
From: "110X" <sip:110X@192.168.0.65>;tag=729112010
To: "110X" <sip:110X@192.168.0.65>
Call-ID: 1924286499@192.168.0.188
CSeq: 9 REGISTER
Contact: <sip:110X@192.168.0.188:5062>
Authorization: Digest username="110X", realm="quadro", nonce="89994438608ac7e9d9d8270c02d442cd", uri="sip:192.168.0.65", response="78d1b12e49f384a04911d09ac4ed53d7", algorithm=MD5, opaque="1287032874"
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink SIP-T28P 2.43.0.50
Expires: 3600
Content-Length: 0

***************************** SIP message buffer end ******************************

16:57:56 Registrar # GetAORByName #user: 110X, host 192.168.0.188 user count 1
16:57:56 Try to send SIP message # (14/10/2010 05:57:56:055 GMT) # UDP # 435 bytes # buff size 0 # from: 192.168.0.65:5060 # to: 192.168.0.188:5062

***************************** SIP message buffer start *****************************
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.188:5062;branch=z9hG4bK1415258534
To: "110X" <sip:110X@192.168.0.65>
From: "110X" <sip:110X@192.168.0.65>;tag=729112010
CSeq: 9 REGISTER
Call-ID: 1924286499@192.168.0.188
Server: Epygi Quadro SIP User Agent/v5.2.7 (QUADROM-8L/26X/12LI/26XI)
WWW-Authenticate: Digest realm="quadro",nonce="d5ee3b438897f4e667ae3c6280a1 658d",opaque="1287035876"
Content-Length: 0

+++++++++++++++++++++++

[tsim]

RESOLVED (I think?):

1. investigated bit and pieces of this forum and tried a few things.
2. deleted the VoIP pstn entries in routing table and user management.
3. deleted the 'blank' (record 0) in routing table via Configuration wizard with blank prefix.
4. re-created using VoIP wizards the 2 IP-pstn lines with different prefixes.
5. now it works but noticed that the post-dial delay is longer and it 'please wait, trying to connect..' and it actually connects thereafter; is it due to the routing rule too far down the routing table?

6. re-booted the Quad box and also the router.

Would appreciate comments from more experienced epygi users, thanks.

[hrant]

The delay and "please wait, trying to connect..." cannot be caused by the position of the rule in call routing table. You are getting that message in case if ITSP dealys the reply on IVITE message sent from Quadro for more than 10 seconds. If the issue persists, download the SIP logs from Quadro and send to ITSP for analysis.

[tsim]

Thanks, I just tried to test by:
1. disable the IP-pstn sip account on the Quadro M8L.
2. setting up on my Yealink T28 IP phone the IP-pstn sip account in Account 2, dialled a local number and got an immediate connection with hardly any post-dial delay.
3. I did another test via the Quadro M8L IP-pstn and the long post-dial delay was present. It was about 10 to 12 secs with the messages 'trying to connect, please wait', it did that 3 times before connecting the call.

Inference:
a. same Internet connection and router was used in the above cases so potential router issue may be remote.
b. Now I recall, the only other significant change was that I started to create several call routing rules, e.g. for mobiles, 1300, 1800, 19 dialling. We did have to change our router and initially thought that this could be the issue. Except for the long post-delay, it does connect the calls and at times, say 1 out of 20, the calls get connected without post-dial delay.
c. FYI, we have 2 X FXO lines and using these to call out does not have any post-dial delay.
d. Given the above, it seems that the IP-pstn provider has no bearing in this long post-dial delay.

I would hate to delete all call routing entries to test whether this may be the issue especially things are working well except for the post-dial delay on the IP lines.

Any ideas on where else to look for is much appreciated.

[hrant]

To exclude the side-effects please create a routing rule with 899 pattern to sip.epygi.com and make a test call to that number to see if you there is any delay in this case.

[tsim]

Hi hrant,

Thanks. Tested as suggested:
i. 899 got a "No dialled does not exist". From documentation, 899 should get a response from epygi but maybe I have not have this setup. In the crt, 8* is present and I assume was created as a system default.
ii. 8 310 230 00 has same 'Please wait, trying to connect', 3 times before connecting to the epygi user: KS Com. I am not familiar with how this works but saw this sip number on one of the post and it works!

++++++++++++++++ from SIP log for dialing 31023000, 30 secs delay??
16:39:20 Registrar # GetAORByName #user: qma110L, host 192.168.0.188 user count 1
16:39:20 Registrar # GetAORByName #user: qma110L, host 192.168.0.188 user count 1
16:39:20 Registrar # GetAORByName #user: qma110L, host user count 1
16:39:20 Registrar # GetAORByName #user: qma110L, host 192.168.0.188 user count 1
16:39:20 Registrar # GetAORByName #user: 31023000, host sip.epygi.com user count 0
16:39:20 Registrar # GetAORByName #user: 31023000, host user count 0
16:39:50 Registrar # GetAORByName #user: 31023000, host sip.epygi.com user count 0
++++++++++++++++

I have also attached extract of the crt and sip logs FYI. This is quite a puzzzle and thanks for your suggestions.

[KSComs]

Interesting TSIM

I have a test account with Engin and it works without a problem using a 2x 5.2.12 firmware.. what codecs are you using and are you locking the service down to a specific address and assigning a NAT Exclusion table or not to that service?

Kevin

[tsim]

Hi Kevin,

Thanks for your comments. What is strange here is that prior to the change of router and adding more entries in the crt, it was going very well with no post-dial delays for several weeks. No other updates were done on the Quadro. The router 'factor' is co-incidental and I would rule this out so what is left appears to be the crt after population of the entries. I did setup an account on the yealink T28 phone under the same router and it works with no post-dial delay; this rukes out the router, I guess.

I used the epygi sip number (yours, apologies if this affected you) for test and got the same post-dial delay.

I have not used the NAT Exclusion or lockdown to a specific address, unchanged since I first installed the Quadro M8L.

Hope that explains.

[tsim]

Researching the forum, I came across a thread in 2008 that is somewhat close to this issue:
http://support.epygi.com/forum/showt...l+delay&page=2

Our difference is that we have no post-dial delay on internal extension and also using FXO. There does not appear to be a conclusion/resolution in this thread, anybody there can update the outcomes? Maybe this can help us in resolving the IP-pstn long post-dial delay.

[hrant]

Please enable the "developer logging" on Quadro, push the "mark all logs" button on the same GUI page, make a test call via Engine, download the system logs from Quadro and attach them to private message to me. I'll try to help you to resolve the issue with delay.