[Problem] Got SIP response 603 "Decline" from 192.168.1.1:5060

[Tiieto]

Hallo zusammen...

Hab gerade mal versucht ne "Sonderrufnummer" anzurufen..
Bekomme dabei im CLI die Meldung:

Got SIP response 603 "Decline" from 192.168.1.1:5060

Die Rufsperre für Sonderrufnummern wurde bereits aus der Fritzbox entfernt... Trotzdem kommt immer wieder diese Meldung...
Gibts da ne Lösung für?

Der gesamte Ablauf aus der CLI:

[May 18 11:52:43] SECURITY[627]: res_security_log.c:114 security_event_stasis_cb: SecurityEvent="ChallengeSent",EventTV="2021-05-18T11:52:43.211+0200",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:[email protected]:5061",SessionID="0x7413a2d8",LocalAddress="IPV4/TLS/192.168.1.240/5061",RemoteAddress="IPV4/TLS/192.168.1.246/12662",Challenge="79c4b546"
  == Using SIP RTP CoS mark 5
       > 0x7412fc20 -- Strict RTP learning after remote address set to: 192.168.1.246:12350
  == Extension Changed 1002[intern-device-hints] new state InUse for Notify User 1000
[May 18 11:52:43] SECURITY[627]: res_security_log.c:114 security_event_stasis_cb: SecurityEvent="SuccessfulAuth",EventTV="2021-05-18T11:52:43.227+0200",Severity="Informational",Service="SIP",EventVersion="1",AccountID="01806xxxxxxx",SessionID="0x7413a2d8",LocalAddress="IPV4/TLS/192.168.1.240/5061",RemoteAddress="IPV4/TLS/192.168.1.246/12662",UsingPassword="1"
    -- Executing [01806xxxxxxx@from-my-phones:1] NoOp("SIP/1002-0000002e", "1002 is calling 01806xxxxxxx") in new stack
    -- Executing [01806xxxxxxx@from-my-phones:2] Dial("SIP/1002-0000002e", "SIP/01806xxxxxxx@4711,,tT") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/01806xxxxxxx@4711
       > 0x74007618 -- Strict RTP learning after remote address set to: 192.168.1.1:7078
    -- SIP/1501174-0000002f is making progress passing it to SIP/1002-0000002e
    -- Got SIP response 603 "Decline" back from 192.168.1.1:5060
    -- SIP/1501174-0000002f is busy
  == Everyone is busy/congested at this time (1:1/0/0)
    -- Auto fallthrough, channel 'SIP/1002-0000002e' status is 'BUSY'
  == Extension Changed 1002[intern-device-hints] new state Idle for Notify User 1000
VoiP-Pi*CLI>

LG

 

[koyaanisqatsi]

Moinsen


Ist die Meldung auch im Ereignislog der FRITZ!Box?
...und kommt eventuell vom Anbieter?
...was sagt das "SIP log" der FRITZ!Box?
Dafür solltest du die erweiterten Supportdaten laden und ab "SIP log" und/oder "SIP invite log" analysieren.

 

[Tiieto]

Nachdem ich ein anderes Mobilteil direkt am DECT der Fritzbox angemeldet habe, konnte ich diese Nummer anrufen…
Vom Anbieter kommt’s also schonmal nicht..
Die SIP.log der Fritte muss ich erstmal schuldig bleiben, bin gerade auf Maloche…

Hie mal der kram aus der Fritte (ich seh da nix..)
In der Anrufliste der FritzBox tauchte da übrigens kein Eintrag für diesen Anruf auf...

2021-05-18 12:05:00.018 - IN: my=192.168.1.1%14:5060 peer=192.168.1.240 port=5060 UDP, sipiface=none:
INVITE sip:[email protected] 2.0
Via: SIP/2.0/UDP 192.168.1.240:5060;branch=z9hG4bK74e764a2
From: "Mobilteil 2" <sip:[email protected]>;tag=as7297d695
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 103 INVITE
Contact: <sip:[email protected]:5060>
Authorization: Digest username="MSN4711", realm="fritz.box", nonce="A5D167C2D674E304", uri="sip:[email protected]", response="e1320ece968374feda67d436c48497ff", algorithm=MD5
Max-Forwards: 70
User-Agent: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Date: Tue, 18 May 2021 10:05:00 GMT
Supported: replaces
Supported: timer
Allow: INVITE,  ACK,  CANCEL,  OPTIONS,  BYE,  REFER,  SUBSCRIBE,  NOTIFY,  INFO,  PUBLISH,  MESSAGE
Content-Type: application/sdp
Content-Length:  1232

v=0
o=root 1952365006 1952365007 IN IP4 192.168.1.240
s=Asterisk PBX 16.2.1~dfsg-1+deb10u2
c=IN IP4 192.168.1.240
t=0 0
m=audio 19088 RTP/AVP 107 0 8 3 108 109 4 111 112 5 10 122 118 123 124 125 126 127 96 7 18 110 117 119 97 9 102 115 116 101
a=rtpmap:107 opus/48000/2
a=fmtp:107 sprop-maxcapturerate=16000;maxaveragebitrate=20000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:108 AMR/8000
a=rtpmap:109 AMR-WB/16000
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:111 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:10 L16/8000
a=rtpmap:122 L16/12000
a=rtpmap:118 L16/16000
a=rtpmap:123 L16/24000
a=rtpmap:124 L16/32000
a=rtpmap:125 L16/44000
a=rtpmap:126 L16/48000
a=rtpmap:127 L16/96000
a=rtpmap:96 L16/192000
a=rtpmap:7 LPC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:110 speex/8000
a=rtpmap:117 speex/16000
a=rtpmap:119 speex/32000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/8000
a=rtpmap:102 G7221/16000
a=fmtp:102 bitrate=32000
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:116 G719/48000
a=fmtp:116 bitrate=64000
a=rtpmap:101 telep
2021-05-18 12:16:33.148 - OUT: my=192.168.1.1%18:5060 peer=217.0.27.33 port=5060 UDP, sipiface=internet tcclass=sip_toi, netmark=0:
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 91.2.68.43:5060;rport;branch=z9hG4bK5AECFB189733BBCC
Route: <sip:217.0.27.33:5060;transport=udp;lr>
From: <sip:[email protected];user=phone>;tag=5A13F220D37FD211
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 15 INVITE
Contact: <sip:[email protected];uniq=0CC539C9EEEEE8BCBC9C4E906E231;user=phone>
Proxy-Authorization: Digest username="[email protected]", realm="tel.t-online.de", nonce="BE9270014F93A3600000000034C5EE57", uri="sip:[email protected];user=phone", response="1b4dc5dd748c0441eada59091870499c", algorithm=MD5, cnonce="2066A3A16883D06C", qop=auth, nc=00000012
P-Preferred-Identity: <sip:[email protected];user=phone>
Max-Forwards: 70
Expires: 120
User-Agent: AVM FRITZ!Box 7490 113.07.21 (Sep  3 2020)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length:   427

v=0
o=user 10956937 10956937 IN IP4 91.2.68.43
s=call
c=IN IP4 91.2.68.43
t=0 0
m=audio 7078 RTP/AVP 9 8 0 2 102 100 99 101 97 120 121
a=sendrecv
a=rtpmap:2 G726-32/8000
a=rtpmap:102 G726-32/8000
a=rtpmap:100 G726-40/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:120 PCMA/16000
a=rtpmap:121 PCMU/16000
a=rtcp:7079
a=ptime:20

 

[koyaanisqatsi]

Moinsen


Ich könnte mir vorstellen, dass die Codecliste über Asterisk ein wenig zu lang ist und deswegen der Anruf abgelehnt wird.
Versuchs mal mit den Notwendigsten: allow=!all,alaw,ulaw
Und wenn das dann klappt noch den HD Codec dazu: allow=!all,g722,alaw,ulaw
( alaw ist europäischer quasi Standard und ulaw eher für das "Ausland" gedacht )

 

[Tiieto]

Hmm...

Sehen Sie selbst...
(aus der sip.conf)

[main_phone_config](!)              ; Template Telefone
type            = friend
context            = from-my-phones                ; group in extentions.conf
host            = dynamic                    ; somewhere in the network
subscribecontext    = from-my-phones
call-limit        = 10
callgroup        = 1
pickupgroup        = 1
dtmfmode        = rfc2833                    ;
allow            = !all,opus,speex,g722,alaw,ulaw,gsm        ; only allow codec (auch mehrere)
;encription        = yes
transport        = udp,tls                    ; udp,tls

 

[koyaanisqatsi]

Opus und Speex erweitern deine Liste auf über 30 Codecs.
( Bei 30x a hab ich aufgehört zu zählen )
Hast du die jemals mit irgendeinen Gerät ausgehandelt gesehen?
...und gsm halte ich einfach mal für komplett überflüssig.
Was kostet es dich, dass mal auszuprobieren?

 

[Tiieto]

Kosten? Nix...

Opus ist halt für die interne Telefonie mit meinen Yealink's...
Speex, eher weniger, den nehm ich dann mal raus... Genauso gsm...

Hab dann noch was im Amtsleitungstemplate gefunden... Da stand tatsächlich "all" drin..
Korrigiert auf:

[peers_FB_Main](!)              ; Template Amtsleitungen
type        = peer
context        = von-voip-provider
allow        = !all,g722,alaw,ulaw
host        = fritz.box
fromdomain    = fritz.box
insecure    = port,invite

Bin aber ehrlich gesagt davon ausgegangen, das die Gegenstellen sich auf einen Codec einigen & dann loslegen...

 

[koyaanisqatsi]

Das (sollten) sie auch machen, natürlich sollte das Telefon selber die selbe Codecliste führen wie Asterisk sein Template für dieses Telefon auch.
...sonst machen diese Feintuningeinstellungen wenig bis keinen Sinn.
Du hast also zweimal was zu Konfigurieren, 1x unter...
(sip.conf)

[general]
allow=!all,g722,alaw,ulaw

...und 1x für deine [User/Peer] Konfiguration die, die auch im Telefon eingestellt wurden.
Das dürfte dann die Aushandlungscodecliste erheblich verkürzen.
Welcher am End ausgehandelt wurde, siehst du bei einer laufenden Verbindung in der Konsole mit...

osmc*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer   
192.168.188.1    1005             180DA4120A03DB6  (g722)           No       Rx: ACK                    1005   
1 active SIP dialog

Welche Codecliste ein User/Peer führt...
( Beispielhaft für meinen User/Peer 1005 )

osmc*CLI> sip show peer 1005
...
Codecs       : (g722|alaw|ulaw)
...

( Gekürzt )

 

[Tiieto]

Also 3x…

im [general]
im Peer template &
im Telefontemplate?

Telefon & Peer sind ja schon durch… Müsste das nicht ausreichen?

muss nachher, nachm Dienst mal schauen ob der gerneral auch noch n allow drin stehen hat…
Meine nämlich das hat er nich…

mach Sch**ß drauf… Wozu jibbet VPN…
Also der general hat tatsächlich keinen allow mehr mit drin…

sollte / muss das?

LG

 

[koyaanisqatsi]

Bin ich mir nicht sicher, ob dann alle Codecs erlaubt sind.
Auf jeden Fall sollten immer die der User/Peer Konfiguration gültig sein, wenn angegeben.
...wenn dort nicht vorhanden, gelten die unter: [general]

Wenn also alle User/Peer Templates eine Codecliste führen kann unter [general] gefahrlos ein "allow=!all" stehen, was zu...
( sip show settings )

Global Signalling Settings:
---------------------------
  Codecs:                 (nothing)

...führt, aber keinen Einfluß auf die User/Peer Codec Konfiguration hat.

 

[Tiieto]

Ok, ist also als eine Art Rückfallebene zu betrachten…
Macht dann durchaus Sinn..
Bau ich mit ein…

thx..

ob das dann auch der Grund war, werden wir dann wohl erst später erfahren…
(Ich ruf ja nicht einfach nur zum Testen ne Kostenpflichtige Nummer an…)

rückmeldung erfolgt dann aber…

 

[koyaanisqatsi]

Überprüf auch in der FRITZ!Box...

...und hak die ab die das dürfen.
Das sperrt auch Sonderrufnummern und die AVM HD-Test SIP URI Calls aus dem FRITZ!Box Telefonbuch.
( **797, **798 und **799 ) Nur IP-Telefon Registrare, nicht DECT/ISDN/Analog direkt an der FRITZ!Box.
Wenn das der Grund war ist Asterisk (diesmal): Nicht schuldig

 

[Tiieto]

Ah ja…
Ok…
DAS wär auch noch ne Möglichkeit…
Muss ich dann mal schauen…

In meiner Fritte dürfen das alle SIP-Telefone... Also Alle in der Fritte eingerichteten Peers der Asterisk..

 

[koyaanisqatsi]

LOL - Nein!
Vergleiche mal ganz genau deinen Screenshot ( den du danach ruhig löschen kannst, wegen der unzensierten Nummer ) mit meinen.
...bei dir darf kein Registrar Ausland/Sonderrufnummern/SIP URI Calls, das passiert direkt beim Einrichten automatisch.
Bei AVM Firmware musst du hier also selbst abhaken, ohne beim Einrichten einen Hinweis* darauf erhalten zu haben.
Merk dir das also für die Zukunft.


* Extra Eins angelegt, kein Hinweis auf die Sperre gesehen

 

[Tiieto]

Danke für den Hinweis!!!

verdammt… Invertierte logic…