cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1041
Views
0
Helpful
12
Replies

Discussion SPA232D’s FXO port drops the PSTN dial tone within 4 seconds - Part 2

Hi Dan & Howard

For the easy trace-ability I have created another new discussion (same Title - Part 2) as the previous one is unable to trace anymore as all new posts are going missing once submitted.

Will try to get more details thru another SysLog trace and provide you all soon.

12 Replies 12

Dan Lukes
VIP Alumni
VIP Alumni

OK. Link to

Hi Dan

Here how I tried the following 5 tests. (attached 'Delayed Dial Ver 2.txt')

See whether you can trace them. My Log file only less than 5 minutes span.

1.) 0332287 190 - Echo Tone on 7th Digit - Call landed to right destination this time
2.) 07775 36172 - Echo Tone on 4th Digit - Call landed to right destination this time
3.) 0332287 190 - Echo Tone on 7th Digit - Call landed to right destination this time
4.) 077753 6172 - Echo Tone on 5th Digit - Dial tone Timed Out
5.) 0332287 190 - Echo Tone on 7th Digit - Dial tone Timed Out

 

 

I divided the one summary file to five related to each particular call, attached on bottom. Also constant and unimportant parts on the left of each row has been removed to make them more readable.

The log analysis disclosed the logs are incomplete. There are missing messages inside. For example there's a gap 4:35.682-4:37.5827:04.544-7:06.619 or 7:56.758-7:59.737 (just incomplete list). So some timing for unrecorded events need's to be extrapolated from other known data (grey data in the table bottom are extrapolated data). Missing records are not severe issue itself, but it reveal unreliability of the network. I assume not only syslog message may be lost in transmit, but audio packets as well. Two seconds network blackout may deteriorate audio quality and may broke even transmission of DTMF ...

 

Following table show timing of most important events. The column named A is time from OffHook to digit with echo, the column named B is time from first digit to digit with echo. "Last" is the time of last digit dialed, C is offset from OffHook.

Call#OffHookDigit 1Digit w/echoABLastC
14:34.0194:39:6294:49.86315.84410.2344:52.43716.418
25:14.0185:17.1075:25.71811.7008.6115:32.25518.237
36:00.3816:02.8936:15.71615.33512.8236:19.27318.819
47:04.5297:07.8677:20.86216.33312.9957:27.57023.041
57:56.7897:59.7378:15.07218.28315.3358:18.53521.746

 

Unfortunately, those timing data doesn't give me the answers I wished for. Neither A nor B seems to be (almost) constant, in advance, they are so large thus echo seems not to be caused by analog echo on audio path. 

But echo doesn't occur even after still the same digit, so it's not firmware bug (or it's an complex firmware bug that can't be confirmed by simple observing of timing data).

Even worse, some calls has been completed despite echo has occurred, thus it seems the "wrong dialing" may not be related to echo at all. So we may be on death path.

The only new information observed from logs is that dialing timeout seems to occur 20 seconds past off-hook. But is not so important information - and is unrelated to the issue itself.

Well, It's time to confess - I have no further idea how to solve (or either analyze) the issue, unless it's complex issue caused by network unreliability mentioned above ...

So sorry.

 

This post contain information related to other's site thus it may contain information considered Sensitive or Confidential.

Hi Dan et al

Understood the situation & thanks for all the efforts taken so far towards the resolution.

Let me understand one thing here.. You, Howard & the experts here are commenting and taking up the issues is as a part  of Cisco's service or support management appointees or you all are freelance team whom provide the expertise in the forum (totally out side of cisco and sitting at your own locations etc.. etc) ? Or is this your paid job ?

As above In such ambiguous technicalities ... how to move forward ? Are you recommending cisco to consider the findings and go for an analysis for a next firmware patch ? OR they have their own process to follow when identifying bugs those leads to patching ?

Meaning this forum is totally independent and this is for a people like me to bring issues and get on the ground analysis then close it ?

Please explain bit more your obligations and the interests here.

 

 

 

I'm volunteer with no relationship to Cisco. I have even no support contract, thus no access to Cisco's support (we tried it, but we has been dissatisfied with the support provided by Cisco).

Just few years ago, at the times of Linksys department, the firmware developers (or at least employee with deep-in knowledge of matter) has been active here. Of course, their time has been so valuable to respond those RTFM questions, thus volunteers in this forum, including me, saved their time responding all those simple questions (or question responded already in the past). As the reward, engineers has been responding our questions (e.g. those responded by no one, or those that require in-deep knowledge of hardware design and firmware source code). If a bug has been discovered, they work actively with us on patch. I remember I created testing environment for remote engineer as well as tested (almost online) patched firmwares to verify the issue has been solved. God bless all of them. It has been reason to be here - I helped others to become satisfied customer, and Cisco, as a reward, helped me to solve my issues.

As Cisco dropped the Linksys division, it work no longer such way. Answers from someone wearing Cisco Emplyee badge are so rare to be mentioned. I no longer asks here as no one will responds, also I don't place firmware bugs analysis here. It's waste of time. We are left alone here.

To say true, just few discussions provide an valuable experience to me (yes, this one is an example, so I burned a lot of hours on it) during past two years. It's rather matter of habit I'm still responding here.

Yes, I has been elected Cisco Support VIP twice. Yes, it's honor, but it's just honor. It doesn't mean I have access to anyone who can respond complex questions nor I have access to a resource you have no access to. OK, OK, I'm damned liar. As VIP I have free access to CTE (it's pretty expensive it you consider you are interested) - unfortunately, it doesn't cover SMB segment - thus it have zero value for the area I'm most active in.

Are you recommending cisco to consider the findings and go for an analysis for a next firmware patch ?

No, I know no one that knows someone that can make such kind of recommendation.

OR they have their own process to follow when identifying bugs those leads to patching ?

I can't confirm nor reject it. If such process exists, it's internal process and we are allowed to know nothing about it. If it exist at all, it seems to be rather random or very low priority process as so many discovered bugs, even those affecting security, are/has been left untouched for months or years.

how to move forward ?

You know I'm not affiliated with Cisco. Thus I can forget claims good for marketing only and I can say just true.

You are on your own, like all of us here. Try to call SMB Support Center, it will not harm, but doesn't wish for solution from them so much. They may help, but according my experience, your issue is so technical and complex, so they will not understood it. You will receive ticket number as the only feedback ever.

Hard to advice something useful. Try other solutions.

  1. You discovered the PAP2T+SPA3102 works. Who care they are EOL ? Use them.
  2. Avoid long-line DTMF dialing (e.g. use SIP signalling to deliver called number). It will require a SIP proxy.
  3. Consider professional converters (but beware that any solution depend on quality and reliability of Internet connection).
  4. Use ISDN instead of POTS line, if available in Gampaha (I'm not familiar with such region enough).
  5. Try use a VoIP provider to terminate calls to Sri Lanka. It may not be Sri Lanka's local one. I assume your current price from Malaysia to Sri Lanka is about $0.72 per minute. There are international operators offering calls to Sri Lanka for less than $0.14 per minute.

Note that no advice may help. As I said, you are on yours own. But it's the best I know. Sorry, it's so hard to debug issues remotely, on the other end of known world ;-)

I am also a volunteer.  I am not affiliated with Cisco in any way.

As for something else to try, if you were to implement "One Stage Dialing" you could stop sending dtmf digits over the network.  With one stage dialing the number the distant spa is to dial is sent as part of the Sip INVITE. The SPA receives the number and automatically dials the number.  Implementing One Stage Dialing, though, would be a major change to your configuration. 

To switch from your configuration to one stage dialing you either need to register to a sip server that has your distant SPA setup as an outgoing trunk, or communicate directly between your calling adapter and the distant SPA.  If you did either of these you would stop using your current voip provider for this type of call.

Registering to another PBX type server is probably the easiest way to test this concept.  For an example, you get an account at PBXes.org.  The account is free up to a certain monthly calling limit.  They have an extension/trunk feature they call Sub PBX which allows inbound and outbound calling.  You setup an account and register your calling SPA as the main or regular extension in this new account.  You setup a "Sub PBX" in this new account and register your distant PSTN Line Tab configuration to the Sub PBX.  In this new PBXes account you setup Internal Routing to route all outgoing calls (i.e. from your main extension) to the Sub PBX.  Now when you dial a number on your calling SPA that you want your distant spa to dial the server sends that number in a Sip Invite to your distant spa.  There is a way to put password authentication on the this type of call with HTTP Authentication.  Going thru a distant server you could experience a fairly significant propagation delay, but you have such a delay now going thru your current voip provider.

The other alternative, sending the call direct from one SPA to the other, is more complex.
  
Just a comment: I noticed that with the three calls that were completed OK you have stopped that practice of dialing the # at the end of the call.

Hi Dan & Howard.

Thanks for sharing the details. I am very impressed to see your commitment here you being individuals whom doesn’t have any contracts with Cisco. Sharing the knowledge across the world is very good thing but what is the tangible gain you getting out of this other than the own satisfaction (may be) ? I cannot think much around this. However I guess you have your own jobs for living. Having those obligations I am unable to understand how you guys are dedicating for the service this much. I know I am NOT the only one whom posting questions in the forum. In case if you get any offer from Cisco Small business unit, would you consider? (I am sorry if I am not allowed to talk about offers/jobs related matters in the technical forums like this) Or does all these support functions have been out sourced by now to India or somewhere ?

Going to Howard’s proposal – Let me read and understand how I would change the setup as you proposed. (PBXes.org). Looks like its totally new thing to me but looks interesting.

We are off-topic here and I'm moderator of the forum, thus I should not support such kind of discussion. We should move to Cisco Cafe or so. Well. I'm giving up on it.

what is the tangible gain you getting out of this

I claimed there's little gain now. But it's a sort of training. I'm supporting a lot of SPA-based VoIP installations over world , but they are well designed and pretty stable. Almost no issues with.

But issues may strike, So I should be ready all the times. Solving others issues is the way to stay in touch. Also, if customer is asking a new feature I'm not supporting yet, I would like to know the request needs to be rejected because such feature is known to be poorly implemented. As a example, from now I will reject all requests asking to implement cheap calls trunk to Sri Lanka ;-)

how you guys are dedicating for the service this much

Consider me "family doctor". ;-)

My "family" assumes I'm ready to help if necessary, but if I'm doing my work well, the "necessary" times should be rare as much as possible. Of course, I need to be ready, thus I'm spending the time to perpetual self-education.

 

 

Hi Howard

Looks interesting and its a new experience.

As an update ..............

 

Good

Don't know why mobile numbers would be any different than land line numbers unless you have some special dial plans setup.  

Edit:  PBXes has a "Dial Rules"  dial plan entry on the Sub PBX setup.  I would see if that has any effect on what you are doing.

Hi Howard

Looks interesting and its a new experience.

As an update ..............

I managed to hook to FXO (PSTN) with my SPA3012 locally. When I dial the destination number it goes thru. But when I dial a mobile number, I could hear it ring the VOIP ring once internally & then connects to another VOIP dial tone, but NOT dial out the local mobile number. This is a bit of ad-hoc behavior. But sometimes it dials the Mobile numbers as well. However Land lines are dialing in one-shot without any issue. I guess I need to explore more how to setup etc. Its lot for me based on my opinion. Lets see how it goes. If all these OK then I can apply to my problematic SPA232D.

Yes as you said it takes little more latency to ring/connect but acceptable. Echo test showed me its NOT bad...

 

Dan Lukes
VIP Alumni
VIP Alumni

Note the EOL/EOS has been announced for SPA232D.

Consider it Cisco's response to your issue ...

Thanks Dan. So that means there will NOT be any new patches and fixes will be developed.

Already highlighted to Cisco Small Business unit for them to consider a replacement fo this with any cisco refurbished SPA3102. Lets wait and see.