Called Number Changed On SNOM 821
Dear list,
I have a very strange problem and no idea where the problem can be…
I have a Debian Server with Asterisk 16.2.1 from Debian repos and some SNOM phones (SNOM 821, last firmware snom821-SIP 8.7.5.35). If I call a number I can see in the display the called number, after a few seconds the number changes to the own numer. After hangup I just see my own number in the call log. The same if I receive a call.
On the old Server (with Asterisk 11.7.0) with the same phones there was no problem.
Do someone have any idea what can be the problem?
Thanks a lot Luca Bertoncello
(lucabert@lucabert.de)
—
23 thoughts on - Called Number Changed On SNOM 821
Am 28.12.2021 14:30, schrieb Luca Bertoncello:
Hi again,
Very very strange… The problem happens only on some numbers, but not on some other…
Any idea?
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
Sounds like something strange is happening with Remote-Party-ID.
Do a packet capture and see whether the 180 response from the callee’s phone contains an RPID header with silly content.
Antony.
—
“Remember: the S in IoT stands for Security.”
– Jan-Piet Mens
Please reply to the list;
please *don’t* CC me.
—
Am 28.12.2021 um 15:42 schrieb Antony Stone:
Hi Antony,
I captured the packet but I don’t see anything strange… Btw, what do you mean with “180 response”?
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
I mean the response from the called telephone in reply to the INVITE, which contains the SIP code “180 Ringing” and may optionally have an RPID header.
Antony.
—
“Measuring average network latency is about as useful as measuring the mean temperature of patients in a hospital.”
– Stéphane Bortzmeyer
Please reply to the list;
please *don’t* CC me.
—
Am 28.12.2021 um 17:22 schrieb Antony Stone:
Hi Antony
OK, I see something strange…
Here what I see if I call my mobile phone (then the number “changes”):
Via: SIP/2.0/UDP;tag=8o3bow73en To: ;tag=as234ad778
192.168.60.53:3072;branch=z9hG4bK-tzms3vciubaj;received=192.168.60.53;rport=3072
From: “Sekretariat”
Call-ID: 313634303730333537323534383539-zw0qs5wmmpd2
CSeq: 2 INVITE
Server: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces Contact:
P-Asserted-Identity: “03529529874”
Content-Length: 0
and here what I see if I call another mobile phone (then the number does NOT change):
Via: SIP/2.0/UDP;tag=fararstgh4;tag=as7da4425c Call-ID: 313634303730333630353537373731-7x9ey0nf5gm2
192.168.60.53:3072;branch=z9hG4bK-qjbxwwkv3n3p;received=192.168.60.53;rport=3072
From: “Sekretariat”
To:
CSeq: 2 INVITE
Server: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces Contact:
Content-Length: 0
So, I see, there is a “P-Asserted-Identity”… But I can’t understand why…
Any idea?
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
…..
…..
Where exactly were those packets captured?
On the connection from the called telephone sending the reponse in to Asterisk?
Or on the connection from Asterisk sending the response out to the calling telephone?
(It looks like the latter to me.)
It may well be a good idea to do both and compare, to see whether Asterisk is actually adding the header.
Antony.
—
3 logicians walk into a bar. The bartender asks “Do you all want a drink?”
The first logician says “I don’t know.”
The second logician says “I don’t know.”
The third logician says “Yes!”
Please reply to the list;
please *don’t* CC me.
—
Am 28.12.2021 um 17:35 schrieb Antony Stone:
tcpdump on the Asterisk-Server on the interface of the VLAN for the phones. All traffic captured.
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
Okay, so, returning to my question, do yu see any difference between the packet inbound to Asterisk from the called telephone, and the packet outbound from Asterisk to the calling telephone?
Antony.
—
I have an excellent memory. I can’t think of a single thing I’ve forgotten.
Please reply to the list;
please *don’t* CC me.
—
Am 28.12.2021 um 19:41 schrieb Antony Stone:
Hi Antony,
I’m trying to understand what you mean…
You mean that I should compare what the “180 ringing” in the internal network (phone to asterisk) and the external one (asterisk to Telekom)?
If so, then I have to check again, since I only sniffed the internal traffic…
If not, I didn’t understand what you mean… 🙁
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
Which way round are you making the telephone call?
From your earlier packet capture, it looked to me like you were dialling an external number from an internal telephone.
If that is true, then you should be looking for a packet *from Telekom* coming in to Asterisk, and a packet *from Asterisk* to the internal telephone –
remember that these packets are the _reply_ to the INVITE.
INVITE goes from callING telephone to callED telephone.
Response “180 Ringing” goes from the callED telephone to the callING
telephone.
I think it’s important to find out what Asterisk is receiving from your upstream provider, and whether it is then changing this in what it sends on to the calling telephone (the one on which you see the unexpected display).
Antony.
—
“It would appear we have reached the limits of what it is possible to achieve with computer technology, although one should be careful with such statements;
they tend to sound pretty silly in five years.”
– John von Neumann (1949)
Please reply to the list;
please *don’t* CC me.
—
Am 28.12.2021 um 20:00 schrieb Antony Stone:
This is correct!
I called my mobile phone using a VoIP phone connected to an Asterisk.
So do I have to compare the INVITE with the Ringing?
OK, so I have to sniff the data to Deutsche Telekom and not the internal network… Since the Asterisk is not my own, but of a company, I have to ask someone to call me from the phone when I sniff the traffic… I hope, I find someone tomorrow.
Regards Luca Bertoncello
(lucabert@lucabert.de)
—
No, you want to look at the “180 Ringing” response in both cases – what goes in to Asterisk, and what comes out of it.
The INVITE does not contain the data which gets displayed on the calling telephone.
No, data FROM Deutsche Telekom. They are the ones sending the “180 Ringing”
back to you once they think the external telephone is ringing.
I don’t quite follow that, but what I am saying is that the callEE’s number
(the number of the telephone you are calling) may be contained in an RPID
header of the “180 Ringing” packet which comes back from the telephone being called.
You want to find out whether this header, and the strange number you are not expecting, exists in the packets coming from your upstream provider IN to Asterisk, and also whether it exists in the packet coming FROM asterisk to your internal telephone which made the call, and is showing the strange data.
I hope that is clear.
Antony.
—
These clients are often infected by viruses or other malware and need to be fixed. If not, the user at that client needs to be fixed…
– Henrik Nordstrom, on Squid users’ mailing list
Please reply to the list;
please *don’t* CC me.
—
Am 28.12.2021 um 20:24 schrieb Antony Stone:
OK
OK. So I sniffed data from internal network and from DSL, then I started the call using the web management system of the SNOM.
I see Asterisk sends to the phone:
Via: SIP/2.0/UDP;tag=ts2ye4krhs To: ;tag=as32fe51ba Call-ID: 313634303731393637343630373636-ex7145moy1mt CSeq: 2 INVITE
192.168.60.53:3072;branch=z9hG4bK-igym6msxn88p;received=192.168.60.53;rport=3072
From: “Sekretariat”
Server: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces Contact:
Content-Length: 0
After about 6 seconds I get from the Telekom:
Via: SIP/2.0/UDP
;tag=h7g4Esbg_p65544t1640719676m169304c9321s1_3514393582-932943693
;tag=4781eb96-b155-421e-8206-593d44c9f7c4
87.191.224.158:5060;received=87.191.224.158;rport=5060;branch=z9hG4bKPj43be873a-cf55-4348-8867-5c2bb97bd76a To:
From:
Call-ID: 478ba582-946c-46ac-984d-6f1835e3391b CSeq: 15716 INVITE
Contact:
Record-Route:
P-Early-Media: sendrecv, gated Require: 100rel RSeq: 2
Content-Type: application/sdp Content-Length: 281
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PUBLISH, MESSAGE, UPDATE, PRACK, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE
Then I see Asterisk sends this to the phone:
Via: SIP/2.0/UDP;tag=ts2ye4krhs To: ;tag=as32fe51ba Call-ID: 313634303731393637343630373636-ex7145moy1mt CSeq: 2 INVITE
192.168.60.53:3072;branch=z9hG4bK-igym6msxn88p;received=192.168.60.53;rport=3072
From: “Sekretariat”
Server: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces Contact:
P-Asserted-Identity: “03529529874”
Content-Length: 0
So, it seems Asterisk receives from Deutsche Telekom _one_ “Ringing” and sends the phone _two_ “Ringing”, the second one with the P-Asserted-Identity…
Maybe help it to identify the problem?
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
So, no PAID header there, and no mention of “Sekretariat” either.
Indeed.
I would look at whatever part of the dial plan is responsible for inserting
“Sekretariat”, and also check whether you have “sendrpid=yes” in sip.conf.
However, at least you’ve got as far as ruling out Telekom as being the source of the problem, which I think is good.
Antony.
—
I bought a book about anti-gravity. The reviews say you can’t put it down.
Please reply to the list;
please *don’t* CC me.
—
Am 28.12.2021 um 21:21 schrieb Antony Stone:
I find “Sekretariat” in the Ringing sent from Asterisk:
Via: SIP/2.0/UDP;tag=ts2ye4krhs To: ;tag=as32fe51ba Call-ID: 313634303731393637343630373636-ex7145moy1mt CSeq: 2 INVITE
192.168.60.53:3072;branch=z9hG4bK-igym6msxn88p;received=192.168.60.53;rport=3072
From: “Sekretariat”
Server: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces Contact:
Content-Length: 0
In the users.d/74.conf (the configuration of the SIP client for
“Sekretariat”) I have:
…. sendrpid=pai
….
Well, this means, that the problem is in the Asterisk… Very huge part of the infrastructure… 🙁
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
[…]
Well, I can see a much more strange behavior here in Asterisk 18.x / pjsip. On outbound calls, the 180 and 200 Ok packages sent from asterisk to the internal caller contain a RPID or PAI header like this one:
Remote-Party-ID: “CID:+49..(own external number)”;party=called;privacy=off;screen=no
It contains a mix of both, the own external number and the number initially dialed by the caller. I consider this pretty odd.
The dialplan is generated by FreePBX.
My internal phone ignores the RPID completely and from the PAI, it presents the own external number (and the dialed number isn’t shown any more).
“Solution” is to disable rpid or pai completely.
Thanks Michael
—
Am 28.12.2021 um 21:21 schrieb Antony Stone:
Hi
So, I setted:
sendrpid=rpid
instead of:
sendrpid=pai
and now it seems to work. The called number does not change anymore.
Last very strange problem is, that the list of missed calls on the phone is always empty… But it can be a problem of the phone hisself… Maybe has someone an idea?
The phone is a Snom 821-SIP
Thanks and happy new year!
Luca Bertoncello
(lucabert@lucabert.de)
—
Glad you found a solution to this.
Check the SIP notifications which are being sent to the telephone for these calls, and whether any of them contain a “Reason” code for “Answered elsewhere”.
See https://datatracker.ietf.org/doc/html/rfc3326#section-2 – the first example at the top of page 3 shows the sort of thing I mean.
This “answered elsewhere” code is usually used when telephones are in a ring group or agents subscribed to a queue, and nobody wants to know about the calls which someone else answered, even if their telephone rang, so the phone sees this code and eliminates the call from its history.
Antony.
—
Pavlov is in the pub enjoying a pint. The barman rings for last orders, and Pavlov jumps up exclaiming “Damn! I
forgot to feed the dog!”
Please reply to the list;
please *don’t* CC me.
—
Am 31.12.2021 um 14:39 schrieb Antony Stone:
Hi Antony
Got it…
Via: SIP/2.0/UDP 192.168.60.1:5060;branch=z9hG4bK5d77ab07;rport Max-Forwards: 70;tag=as7a4dc11e To:
From:
Call-ID: 5372968b4a66dac5051ce91e29f8b283@192.168.60.1:5060
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Reason: SIP;cause=200;text=”Call completed elsewhere”
Content-Length: 0
Now the very question is how to remove this header… Can the problem be that I added a function to send an E-Mail if a call wasn’t answered?
[noanswer]
exten => s,1,NoOp(UID CALL: ${UNIQUEID} / DATE:
${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}))
exten => s,n,System(echo “Verpasster Anruf vom ${CALLERID(NUM)} um
${STRFTIME(${EPOCH},,%H:%M)}” | mail -s “Verpasster Anruf” info@xxx.de)
…. exten => h,1,GotoIf($[“${DIALSTATUS}” = “ANSWER”]?done)
exten => h,n,Goto(noanswer,s,1)
exten => h,n(done),NoOp()
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
Check the Dial() command which places the call to the phone. Does it contain the “c” option?
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Dial
Antony.
—
In science, one tries to tell people in such a way as to be understood by everyone something that no-one ever knew before.
In poetry, it is the exact opposite.
– Paul Dirac
Please reply to the list;
please *don’t* CC me.
—
Am 31.12.2021 um 16:04 schrieb Antony Stone:
Hi
Jup…
exten => _529874,1,Verbose(2,Call for Main – [${CALLERID(num)}])
exten => _529874,n,Set(CALLERID(num)=${IF($[ “${CALLERID(num):0:3}” =
“+49” ]?0${CALLERID(num):3}:${CALLERID(num)})})
exten => _529874,n,Set(CHANNEL(musicclass)=default)
exten => _529874,n,Dial(SIP/74,39,RcxX)
exten => _529874,n,Verbose(2,Voicemail for Main)
exten => _529874,n,Set(CALLERID(name)=)
; Damit in der E-Mail der AB nicht den Namen steht exten => _529874,n,VoiceMail(74,us)
exten => _529874,n,Hangup
I’ll try to remove it, but I can’t test it today…
I’ll let you know if it works.
Thanks Luca Bertoncello
(lucabert@lucabert.de)
—
Am 31.12.2021 um 16:07 schrieb Luca Bertoncello:
At least a call without anser does not contain the Header anymore…
I’ll ask if the number is shown in the missed calls.
Regards Luca Bertoncello
(lucabert@lucabert.de)
—
Am 31.12.2021 um 16:04 schrieb Antony Stone:
Hi Antony
So, I tested it right now and it works… Just removing the “c”…
Thanks a lot for your help and of course happy new year!
Luca Bertoncello
(lucabert@lucabert.de)
—