Can Cisco SPA-122 combine 2 different VOIP accounts on 1 line?

[postmaster]

I have 2 VOIP-accounts of which I use one for incoming calls and one for outgoing calls.

I used to have a Zyxel modem (P-2812HNU-F1) in which I could easliy configure the two SIP-accounts to use the same RJ11-port.

In that way I only needed to connect one physical telephone (a Philips DECT with 4 handsets and an answering machine).

I now have a new internet provider and thus a new modem (ZTE ZXHN H369A). In this modem I cannot configure my own VOIP-accounts because these are reserved for the propriety network of the new provider. That is the reason I bought the Cisco ATA.

The Cisco works fine. I can configure the accounts and calling and being called works fine. But user account 1 seems to be completely fixed to line 1 and user account 2 to line 2.

If this is correct it means that I cannot direct the incoming line of VOIP account 1 and outgoing line of VOIP account 2 tot the same telephone port.

CallForward is no option as far as I can see, because it will mean that all incoming calls from the incoming line account have to be directed to the other account, with extra costs of putting these calls through. I have 2 accounts because I could not find an account that is cost effective for both incoming and outgoing lines.

Looking at the amount of configuration options there must be a better way. Or is this ATA not the right solution for my problem?

[Dan Lukes]

user account 1 seems to be completely fixed to line 1 and user account 2 to line 2.

True in general, but there are some tricks possible.

1. Read Administrator Guide for detailed description of "Synchronized Ring" option.It may allow you to plug phone to "outgoing" port, but receive rings for calls from other account. Unfortunately, there are some reports that this feature doesn't work properly. Read this thread for more. Try it by self. Firmware upgrade to most recent version may help.
2. Read DialPlan string for SPA122 with <@sip-operator;uid/usr=; pwd= > including the comments. It may allow you to plug phone to "incomming" port, but route outgoing calls to other account. It's somewhat undocumented feature, thus it may or may not work for you well.

[postmaster]

Dan,

Thanks for these suggestion. I looked at the threads and already tried some settings, but I did not get very far yet.

The dial plan looks most promising. But I cannot get the string right. And looking at other threads that I found I start to believe that routing calls to another VOIP-account only works with ATA's that use gateways.

I tried this string:

(*xx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.|xxxxxxxxxx<:@sip.voipbuster.com:5060;uid=myuserid;pwd=mypassword>)

The first part "(*xx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx." is the default string that the ATA really seems to need, because it doesn't work without it. That is, it does not work with an empty dial plan.

The last part starting with "|xxxxxxxxxx" is what I added. This extra part has effect, because without this part a 10-digit number is dialed using the VOIP-account form the line itself. But adding this part leads to something like a "line is busy"-sound. This sound is produced rapidly. It appears to me that it is to short time to get a connection to voipbuster.

I understand that these are "undocumented features" and that the syntax of "uid" and "pwd" is not even certain (should it be "usr", does it need "<" around it, etc. That makes it difficult to experiment with.

Where can I go from here?

P.S. The "Synchronized Ring" option did not have any effect. And I personally doubt whether it is possible for the ATA to reroute the incoming call to "the other line" when it is picked up.

[Dan Lukes]

The first part "(*xx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx." is the default string that the ATA really seems to need, because it doesn't work without it

It mean the particular call is approved by a rule from default plan. When you remove default rules, your customized rule either doesn't match, or phone is unable to dial the resulting target.

OK ...

At the first, we need to discover single rule dial plan with no attempt to rewrite, that will match the number you are dialing.

Configure just (xxxxxxxxxx). It must allow you to dial (despite improper VOIP account)  before you can continue.

You can change it to (xxxxxxxxxx<:@sip.voipbuster.com:5060;uid=myuserid;pwd=mypassword>) then.

If it will not work, read note bellow. If it will not help, turn on syslog&debug and capture messages. Also, capture SIP packets and DNS request transmitted from SPA122 during the call attempt. It will allow us to analyze what's wrong.

it does not work with an empty dial plan

Not surprising - if there's no rule at all, no rule can approve the dialed number, thus, no dialing is possible.

the syntax of "uid" and "pwd" is not even certain (should it be "usr", does it need "<" around it, etc. That makes it difficult to experiment with.

According my own comment in the other thread I mentioned, I successfully verified the following syntax is working:

50xx<:@kgw.xxxxx.cz:5060;uid=50xx;pwd=xyz>

so even

(xxxxxxxxxx<:@sip.voipbuster.com:5060;uid=myuserid;pwd=mypassword>)

should work as long as xxxxxxxxxx match the number you are dialing.

---

Note: Despite the "Dial Plan" routing trick, the myuserid/mypassword on sip.voipbuster.com still needs to be configured, enabled and registered on second extension.

[postmaster]

Dan,

I am thankful for the effort you are putting in to it.

But hours of experimenting did not bring me any result up till now.

The SIP logs don't seem to work. I did get the kernel and system logs running (with loads of information and notice lines). So the connection with my syslog server was working fine.  But setting the SIP debug option of either Line1 or Line2 to "line1"or "Full" did not result in any information. This leaves me in the blind!

I think I did everything I could (including upgrading the firmware to v1.4.1). But this is not what I expected form a Cisco ATA and I give up!

;-(

[Dan Lukes]

You should capture SIP packets on the wire. SPA122 will not help you with it so much.

Unfortunately, you didn't disclosed even syslog records you captured thus no further advice possible. It seems the game is over and we lost.

We can continue later, if you will change the mind.