Dialplan cisco spa112 spa122

[JHRciscoata122]

Hello,

I bought a spa122 and several spa112's for replacing ata's in the field.

Is it possible in these devices to use the following parts in a dialplan.

Example 1:
*1xxxxxxxxxx<:@fwdnat.pulver.com:5082;uid=jsmith;pwd=xy
z
Example 2:
*1xxxxxxxxxx<:@fwd.pulver.com;nat;uid=jsmith;pwd=xyz
Example 3:
[39]11<:@gw0>

I tried this, and it failed.

Also: in a spa1[12]2 there are 2 lines, I would like to use them intermixed, f.i. 1 phone line used, also 2 external (VOIP) lines to be used, connecting to the 1 phone line. So in the end 2 external numbers connecting to 1 dect phone.

Hope somebody can help.

Thanks,

[Dan Lukes]

Read DialPlan string for SPA122 with <@sip-operator;uid/usr=; pwd= > including the comments. Try again using those new informations. If it will fail again ask again, but be more specific saying "it failed".  Turn on syslog&debug and capture them as well as SIP packets send from device.

[JHRciscoata122]

Hi Dan,

I tried several options,

The easiest one on line1:

( xx.<:@192.168.8.2:5060;usr=filled;pwd=notreal> )

this line targets not the 192...2 but the sip registerd sip account.

Adding the account details to the second line, it will register, so this account works. Disabled it again, using line1 with the mentioned dialplan, does not work on the spa122. Also tried the same test on a pap2t, also did not work.

Can I conclude that the pap2t and the spa122 does not have these dialplan options in place?

The mentioned gw0 in the example, there is no field for this in the pap2t nor spa122.

[Dan Lukes]

All examples confirmed to be working in the thread I referenced has used uid= not the usr=

Also, they user DNS name of the server, not the IP address.

So start with the syntax verified to be working. Then you may modify, step by step, verifying it's still working after every round.

Can I conclude that the pap2t and the spa122 does not have these dialplan options in place?

According my own test described in the thread referenced above I verified it is working on 1.3.2 firmware of SPA112. And Patrick claimed: "The SPA1xx and SPA232D share the same/similar dialplan rules as the PAP2T, SPA2102, and SPA3012". So I assume it works for SPA122 and PAP2T as well.

[JHRciscoata122]

 tried on different ways:

Changed all the settings:

registered to sip.registeredprovider1.net username password

dialplan:  ( xx.<:@sip.voipprovider2.net:5060;uid=changed;pwd=changed> )    the xx. was NOT supported (bad scripting in spa ??)

I now use  ( xxxxxxxxxx<:@sip.voipprovider2.net:5060;uid=changed;pwd=changed> )

bold=changed

de spa ata is now using the @sip parameters.   (first hurdle taken)

still no connection to the voip2 provider.

I put a hub and wireshark device in place, between the spa and the home-network.

Logged the dialing out using config mentioned above.

Searched for invite packages: just 1 found.

Next package is http 404 answer.

from WIKI:  https://en.wikipedia.org/wiki/List_of_SIP_response_codes

404 Not Found

The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.^[1]:§21.4.5

Invite package:

sip:dailednumber@voipprovider2:5060

from:  sip:useridregisteredvoip1@registeredprovider1

To:    dailednumber@voipprovider2:5060

Remote Party-ID:  sip:useridvoip1@registeredprovider1

with a remark   Unrecognised SIP Header (Remote-Party-ID)  Security Level: Note    Group Undecoded.

attachment wireshark packet   (changed for sensative data)

Hope you can help.

Regards,

PS  No information found in the packets regarding UID and passwords  (Only to syslog server)

[Howard Wittenberg]

I have no experience with the SPA112, however I have tested the dial plan examples with the SPA3102.  With the SPA3102 it always sends the sip Invite to the <:@ip_address:port> but when you try to use the uid= (or usr=) and the psd= the SPA3102 does not use them correctly for authentication and the sip invite will fail.  The example that uses fwdnat.pulver.com and fwd.pulver.com would work because those were to a free service offered by internet pioneer Jeff Pulver (service long gone) that didn't authenticate properly.

The example parameters were introduced originally for the SPA3102 and the SPA3102 Administration guide says clearly that they were for the SPA3102.  I do not believe they were for the PAP2 or the SPA2102 and they certainly do not work with my SPA1001.

Looking at the log data you posted, if I am not mistaken, the log data you posted looks like 
the call is being sent to sip.yyVOIP2.nl:5060 and the UserID being sent is yyUserIDREGISTEREDvoip1

[JHRciscoata122]

Looking at the log data you posted, if I am not mistaken, the log data you posted looks like 
the call is being sent to sip.yyVOIP2.nl:5060 and the UserID being sent is yyUserIDREGISTEREDvoip1

This is correct:

SO basically: the invite is from VoipRegistered  to the VoipProvider2  and NOT

from local to VoipProvider2.  So this packet Invite will not work, if the UserIDvoip2 and PW are not provided to VoipProvider2.

So before invite there has to be some kind of logon to Voipprovider2 before sending an invite. The Spa1x2 does not sent this kind of request.

Can anybody from cisco help ???

[Dan Lukes]

It's very hard to read TXT output of Wireshark. I'm unable to reconstruct the content of INVITE packet in full.

No information found in the packets regarding UID and passwords

In most common scenario they doesn't appear in first INVITE. SIP use "digest" authentication, so the client require challenge to compute the response. So initial INVITE can't contain valid digest response and is sent without it. If server wish for client authentication, then it respond with "401 Unauthorized" code. Such response contain digest challenge. Client use it to compute digest response then he will fire second INVITE with proper Authorization header set.

Unfortunately, in your's particular case server has responded 404. It may mean that dailednumber@voipprovider2:5060 is not known target to the server - and no authorization will change such conclusion.

It may mean that yyUserIDREGISTEREDvoip1 is not known to server as well. Exact reason for 404 may be disclosed by server's administrator only. Unless we know the exact reason, it's hard to decide future steps.

Well. What's now ? This issue interests me, but I'm out of my test lab. So now you are on your own, sorry. I wish I will do more tests related to it. I will post the results then.

[JHRciscoata122]

Hi All,

Thanks for helping.

Within the @voip2 dialing sequence:
I see 3 lines in Wireshark.

1.  Invite  (to voip2)

2. 404 not found. (from voip2)

3  Ack request. (to voip2)

Wiresharked the register process (during startup spa)

1. register

2. 401 unauthorized  (as mentioned by Dan) with a nonce string in MD5.

3. register again  with a responce string on the nonce also in MD5 (containing I think, username and password)

4. packet   200 OK  1 binding

So this is the process. 

Register with UserIDvoip1 to VoipProvider1, 401 unauth. , again register.

The same process has to be done when using @voip2 in dialplan, but is not.

note:

I see in packet 1 from and to are the same when registering. (useridvoip1@voip1),  this is not the case when using "dialplan @voip2"

This could be it ???? from and to the same in first packet ??

[Dan Lukes]

Well, some servers are using different approach. They don't require authorization of INVITE packet, but it require the INVITE has been sent from registered client. With no registration it's not possible to place calls at all and no ad-hoc authorization of INVITE is neither required nor accepted.

Unfortunately, only fully configured extension can register on SPA*. No way to trigger registration from dialplan.

So, if the server in question accept calls from registered clients only, then you can't place call to them using dialplan definition.

Well, may be ...

... just idea - if you configure second extension to be registered to voip2 server, then you may use dial-plan of extension 1 to route specified numbers to extension 2 server. Try it ...

[JHRciscoata122]

Hi Dan,

Allready did, on line 1 I have registerVoip1 and on line 2 registerVoip2.

In both dialplans I use the same structure,  in 1 @voip2,  and in line2 @voip1.

This did not help. maybe because the ports are 5060 and 5061. The server is seeing this as different entries.

Maybe the protocol needs to ad-hoc register and after the call ad-hoc de-register.

note:

the first packet in an @voipx plan, is running  dialednumber@voip2 (registered on voip1)

What happens at server of voip2:   somebody (not know to the server) stating, I want to dial "dialednumber" to your service.  The number is not know, the from is not known (=voip1), so no indication that i'm that somebody, even though I have credentials, but the server is stopping the comm. at that point.

How can I in the ad-hock mode tell the server he has to challenge me for the credentials.

The thing is that the ata/spa is sending the from: userIDvoip1@voip1 and it should be, userIDvoip2@voip2, so the voip2 server knows thats me.

Just a thought.

[Dan Lukes]

Maybe the protocol needs to ad-hoc register and after the call ad-hoc de-register.

The REGISTER exist because server needs to know where to send INVITE related to calls incomming to client. It's the main purpose of REGISTER despite it may be (mis-)used as a sort of authorization as well.

Short-timed REGISTER just for the purpose of outging call is nonsense. I doesn't wish it is the way the voip2 server is working regardless the vopi2 server is unknown to me.

Well, it seems you need some support from voip2 server administrator. You need to know what condition you needs to be fulfill to be allowed to place an outgoing call ...

We may try to found a way to fulfill them then.

Now we know that server doesn't accept calls from us, but we don't know why. It's so hard to workaround unknown issue ...

[JHRciscoata122]

If you want, I could sent you the wireshark files, but then in a PM.

[Dan Lukes]

OK, I got the captured packets. I will disclose them here, so anyone can analyze the issue by self. Sensitive data has been obfuscated, but it is still possible to identify relationship of different strings.

1) Original INVITE sent by SPA112

INVITE sip:05xxxxxx01@sip.txxxxxxt.nl:5060 SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.12:5061;branch=z9hG4bK-522d2f1a
From: "hxxxxxxe" <sip:7xxxxxx5@sip.cxxxxxxt.net>;tag=e855561122f8b131o1
To: <sip:05xxxxxx01@sip.txxxxxxt.nl:5060>
Remote-Party-ID: "hxxxxxxe" <sip:7xxxxxx5@sip.cxxxxxxt.net>;screen=yes;party=calling
Call-ID: 230c5f91-add135b1@xxx.xxx.xxx.12
CSeq: 101 INVITE
Max-Forwards: 70
Contact: "hxxxxxxe" <sip:7xxxxxx5@xxx.xxx.xxx.12:5061;ref=7xxxxxx5>
Expires: 240
User-Agent: Cisco/SPA112-1.3.5(004p_XU001)
Content-Length: 333
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 5490063 5490063 IN IP4 xxx.xxx.xxx.12
s=-
c=IN IP4 xxx.xxx.xxx.12
t=0 0
m=audio 16426 RTP/AVP 0 2 8 18 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729a/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv

2) Server response

SIP/2.0 404 Not Found
From: "hxxxxxxe"<sip:7xxxxxx5@sip.cxxxxxxt.net>;tag=e855561122f8b131o1
To: <sip:05xxxxxx01@sip.txxxxxxt.nl:5060>;tag=7f29dc97eee0-100007f-13c4-55013-3747042-2ce6ecd1-3747042
Call-ID: 230c5f91-add135b1@xxx.xxx.xxx.12
CSeq: 101 INVITE
Via: SIP/2.0/UDP xxx.xxx.xxx.12:5061;branch=z9hG4bK-522d2f1a
Content-Length: 0

Such response has been ACKed by phone, the content of ACK packet is unimportant.

Unfortunately, it confirm our previous conclusion. The server didn't asked for authentication, it has rejected the INVITE.  It's necesarry to ask server's administrator for help. We need to know if it is possible to place call using authenticated INVITE at all - or not. In the second case we are out of luck, in the first case we need to know how it can be done.

[Dan Miley]

so, a couple items,

@gw0 referrs to the PSTN line on a spa3102 or spa232d, since your spa 112/122 does not have a pstn line, it  probably does not make sense to support in the device.

if your provider does not support IP dialing without register, you might try purchasing a 2 line analog phone.  that way you can pick your outbound line on the phone set itself, and answer either line.

here's a few phones, http://www.bestbuy.com/site/telephones-communications/multi-line-telephones/abcat0802005.c?id=abcat0802005 ; googling '2 line phone'

Note: these will require wiring changes to allow both lines to go through your internal cable plant to the phone.

You may also be able to get your provider to ring both lines with either DID number.  you might want to check with them to see what the options are for what you want to accomplish.

Dan