Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

DialPlan string for SPA122 with <@sip-operator;uid/usr= ; pwd= >

Hello!

Look this document:

ADMINISTRATION

GUIDE

Cisco SPA100 Series Phone Adapters

SPA112 and SPA122

http://www.cisco.com/en/US/docs/voice_ip_comm/csbpvga/spa100-200/admin_guide/SPA100_AG_OL-25117.pdf

Pages 95-96:

Example 1:

*1xxxxxxxxxx<:@fwdnat.pulver.com:5082;uid=jsmith;pwd=xy z

Example 2:

*1xxxxxxxxxx<:@fwd.pulver.com;nat;uid=jsmith;pwd=xyz

At first, I think, after that must be >

But it's not work.

Are You sure that SPA122 with actual soft/firmware - works correctly with @net uid= pwd= in DialPlan?

Read this http://www.cisco.com/en/US/docs/voice_ip_comm/csbpvga/spa100-200/admin_guide/spa232d_ag_78-20305.pdf

ADMINISTRATION

GUIDE

Cisco SPA232D Mobility Enhanced Phone Adapter

Pages 116,207.

Examples like before but also:

<8,:1408>xxxxxxx<:@pstn.cisco.com:5061;usr=joe;pwd=joe_pwd;nat>

Here You see not only uid but also usr.

In other pdf for family like SPA122 device You also see uid or usr.

So uid= or usr= for SPA122?

Possible there must be ="..." like in some examples for some ATA-family manuals? Or without " " ?

So What string with @ and pwd in DialPlan is right for SPA122?

Or when You made firmware were it works correctly like engaged in documentation for SPA122?

Everyone's tags (6)
3 REPLIES
Cisco Employee

Re: DialPlan string for SPA122 with <@sip-operator;uid/usr= ; pw

Hi Name,

Thanks for letting us know about the errors in the ATA guides. The SPA1xx and SPA232D share the same/similar dialplan rules as the PAP2T, SPA2102, and SPA3012. It looks like an example was added that was not properly reviewed so I'll file a CDETS for each document and get the dialplan strings corrected.

A better description of the dialplan starts on page 43 in the Digit Sequences section of the http://www.cisco.com/en/US/docs/voice_ip_comm/csbpvga/spa100-200/admin_guide/SPA100_AG_OL-25117.pdf guide.

To address the issues here:

SPA112 and SPA122

http://www.cisco.com/en/US/docs/voice_ip_comm/csbpvga/spa100-200/admin_guide/SPA100_AG_OL-25117.pdf

Pages 95-96:

Example 1:

*1xxxxxxxxxx<:@fwdnat.pulver.com:5082;uid=jsmith;pwd=xy z

Example 2:

*1xxxxxxxxxx<:@fwd.pulver.com;nat;uid=jsmith;pwd=xyz

   Should be:

Example 1:

[comment: I believe that in the example, the author is trying to show that ";" is used as a delimeter between sequence elements but omitted to show the parenthesis around the dialplan and only showed one sequence so no "|" (pipe symbol) is shown. The author also appears to have forgotten the closing angle bracket ">" around the substitution sequence so I've corrected below.

See page 43 of the SPA1xx admin guide that you'd linked to for more details.]

(*1xxxxxxxxxx<:@fwdnat.pulver.com:5082;uid=jsmith;pwd=xyz>)  [note: space is removed between y and z in xyz in the password]

The example is trying to show that if the user dials any number starting with "*", followed by "1" and any 10 other numbers, the entire dialed sequence is replaced with @fwdnat.pulver.com:5082;uid=jsmith;pwd=xyz [note: I'll test this and report back later]

Example 2:

similar comments and corrections as above

Thanks,

Patrick---

New Member

Re: DialPlan string for SPA122 with <@sip-operator;uid/usr= ; pw

Thanks, Patrick! Shall wait for your checks!

Also attention for USR= or UID= variants there and look all your software SIP manuals: in DialPlans there is nat or nat=yes or nat=no - what's right? Or without 'nat' word when there are no NAT.

And nat word - before uid/usr= ;pwd= Or after?

Please edit Theme: DialPlan string for SPA122 with <@sip-operator;uid/usr= ; pwd= >

Must be: <:@sip-operator;uid/usr= ; pwd= >  -- With ':'

Remember about setting:

Make Call Without Reg: yes/no. I think there must be yes for it.

VIP Gold

Re: DialPlan string for SPA122 with <@sip-operator;uid/usr= ; pw

Example 1: *1xxxxxxxxxx<:@fwdnat.pulver.com:5082;uid=jsmith;pwd=xy z

The example is trying to show that if the user dials any number starting with "*", followed by "1" and any 10 other numbers, the entire dialed sequence is replaced with @fwdnat.pulver.com:5082;uid=jsmith;pwd=xyz [note: I'll test this and report back later]

Because of other thread I tried it by self (on SPA112 fw ver. 1.3.2). And it seems your conclusion ("entire dialed sequence is replaced") is wrong.

I have phone connected to Line 1 and I used following Dial Plan:

(1xxx|50xx<:@kgw.xxxxx.cz:5060;uid=50xx;pwd=xyz>|<51:88@kgw.xxxxx.cz:5060;uid=51xx;pwd=xyz>xx|52xx<52:89@kgw.xxxxx.cz:5060;uid=52xx;pwd=xyz>)

  1. Calling 1002 the INVITE has been sent as obvious - according the configuration of Line 1.
  2. Calling 5002 the INVITE for 5002@kgw.xxxxx.cz:5060 has been sent to kgw.xxxxx.cz
  3. Calling 5102 the INVITE for 88@kgw.xxxxx.cz:5060 has been sent to kgw.xxxxx.cz
  4. Calling 5202 the INVITE has been sent same way as 1002 - it seems that substitution part has been ignored entirely.

Unfortunately, substitute string containing :@ construct is not documented in Administrator Guide beyond one example located outside of paragraph dedicated to Dial Plan. So it's not possible to decide if behavior observed in cases 2-3 follow documentation or not. All three cases needs to be considered "undocumented feature" now. Production use should not rely on undocumented features as they can change anytime.

Example 2: *1xxxxxxxxxx<:@fwd.pulver.com;nat;uid=jsmith;pwd=xyz

Such example is wrong not only because the same reason as Example 1 but also because the port number is NOT optional. Dial Plan parser (at least in fw 1.3.2) expect the server name start past '@' and end on first ':' character. If no port number is present like in Example 2 then entire string is considered server name (e.g. DNS request for the A record named fwd.pulver.com;nat;uid=jsmith;pwd=xyz can be seen on the wire which obviously fail).

Again, as exact syntax of format is not documented, it's not possible to decide if it is intentional behavior or parser's bug.

2569
Views
0
Helpful
3
Replies
CreatePlease login to create content