Re: SPA122 Caller id for Tiscali (ITA) Provider

dwnf.fm76 · ‎01-29-2021

Hello,

I have a problem with my SPA122 configuration with the Italian provider Tiscali.

The out coming calls work fine, but for the in coming calls, the phone ring, the audio is ok, but the caller id is not displayed when the phone ring.

The provider service is active, because with the provider modem or with software as 3CX the number is correctly displayed, but with the spa122 the phone display "unknown number". (the physical phone is always the same)

The provider documentation reported as CLID method the PAI-FROM, but I don't find the exactly value in the SPA122 configuration page.

In my spa122 sip properties, I try all the method for the Caller ID Header but not work.

In a Wireshark trace in the filed from and in the P-Asserted-Identity the number is correctly provided (00393381234567)

INVITE sip:003902123456789@10.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.101.102:5060;branch=z9hG4bK65432f7c6eab90f3dea1taN1
To: <sip:003902123456789@100.100.101.102;user=phone>
From: <tel:00393381234567>;tag=ztesipyy66KHR8Gz9zzxTn_AdVPWO*2-6-20481*hade.2
Call-ID: fnSByXLcX81DQZ28tredan6djib@zteims
CSeq: 1000 INVITE
Max-Forwards: 63
Contact: <sip:00393381234567@100.100.101.102:5060;zte-did=2-6-20481-2296-12>
P-Called-Party-ID: "?"<sip:003902123456789@ims.tiscali.net;user=phone>
Supported: 100rel,timer
P-Early-Media: supported
P-Asserted-Identity: <tel:3381234567>
X-ZTE-Cookie: 7zs4rm22;id=27AC777065E1300400@10.253.2.205
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,MESSAGE
Min-SE: 90
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
Content-Length: 193
Content-Disposition: session

Do any know where is the issue? is a problem with my configuration or the provided method of caller id is not supported?

Thank You

Fabio

Dan Lukes · ‎01-29-2021

Off-topic here. SPA122 is ATAs, Gateways,and Accessories

There are two things that needs to work. First, caller id needs to bew correctly transferred from a call control server (PBX) to SPA122. Check status page during call, it shows the caller number. Do this work for you correctly ? Well, then we can continue. Once the caller id is known to SPA112, it needs to be delivered to the analog phone. Unfortunatelly, there's not single standard for it. Caller ID transmission is implemented using different technologies and standards. SPA122 and phone needs to use same protocol to make it working. Check what CID protocol is supported by your phone then set it on SPA122.

dwnf.fm76 · ‎01-30-2021

Hello,

In the page information the field Last Caller Number: is always empty. I think that the problem isn't the phone, because in the line 2 of spa122 there's another ISP configured with the same telephone model, and all work fine.

If I swap the two phones the problem is the same with the other phone. The Caller ID method in the regional page is the same for the two line. It seems that the problemi is that the SPA122 don't recognize the P-Asserted-Identity: <tel:3381234567> as caller number.

On the line 2 the caller id is inside the filed from:

From: "3381234567"

and the SPA122 send correctly the number to the phone.

Dan Lukes · ‎02-01-2021

May be the captured LOG of SPA122 Voice Application will disclose more, but I suspect it's the format of number used by Tiscali behind. I see tel:00393381234567 in From: and tel:3381234567 in P-Asserted-Identity

I'm unsure the "tel" URI scheme is supported at all by SPA122, I have no PBX that uses it so I can't try

But even if tel: URI is supported, it may not work as both headers specify the number incorrectly.

The following i taken from RFC3966:

... all phone numbers MUST use the global form unless they cannot be represented as such.  If the local-number format is
used, it MUST be qualified by the 'phone-context' parameter.

Unfortunately, neither 00393381234567 nor 3381234567 are valid E.164 (e.g. global form) numbers. And they are not local-numbers as well as they lacks mandatory phone-context. The correct form is

tel:+393381234567

or

tel:3381234567;phone-context=ims.tiscali.net

while the local form should be avoided because the number can be represented global form

Related: Debug and syslog Messages from SPA1x2 and SPA232D ATA

dwnf.fm76 · ‎02-07-2021

Hello Dan,

I tryed to resolve this issue with a 3cx pabx software between the SPA122 and my provider.
The software retrieve correctly the caller number and send it to spa122 that visualize te number 0039xxxxx.
Unfortunately the provider can't change this caller id and form, and from debug that you suggest I don't find any error...
Do you know if there is a way for ask to Cisco the implementation for this method in the next firmware?

Thank You

Dan Lukes · ‎02-08-2021

from debug that you suggest I don't find any error...

As you considered not to disclose the log I can neither confirm nor deny your conclusion.

Do you know if there is a way for ask to Cisco the implementation for this method in the next firmware?

It seems you missed End-of-Sale and End-of-Life Announcement for the Cisco SPA112 2-Port Phone Adapter and SPA122 ATA with Router. Suggested replacement is ATA192-3PW-K9. I don't know if the current 3PW supports tel: URI scheme. It's up to you to test.

dwnf.fm76 · ‎02-12-2021

Hello Dan,

I substituted my SPA122 with the new ATA191, but the problem is the same.

I attach the ata191 log where is preset the caller id <tel:00393319476491> in the from and P-Asserted-Identity: <tel:3319476491>, but I don't see any warning error...

Do you think that with this new product is possible ask to Cisco to implement the capability for read the caller id in tel format even if it isn't formally correct?

Thank You

Dan Lukes · ‎02-12-2021

I suspect the log is incomplete. I see facility local1 severity debug messages only. But I expect messages with other severities and even other facilities (local0 and local2) as well. OK, I'm not familiar with ATA191 enough and I'm just guessing, but no info/warn/error message in log is suspicious. Either you turned on debug messages only (thus others are not send by ATA191) or you didn't captured others.

According the question ...

I'm not Cisco emplyee, I can't judge. I can just estimate. I has tried report firmware bugs - even some security critical - and I have no reason to thing your chances are better than almost zero. Even if you have support contract. You are asking the feature will be implemented against standard published. It's Tiscali misconfigured server that's behind. Ask Tiscali to correct the bug. Well, if you are large Cisco customer, your chances are better - but you may be asked to pay for implementation of your specific request ...