[Problem] Asterisk & Personal-VoIP - Probleme mit eingehenden Anrufen - No matching peer found

RcRaCk2k

Mitglied
Mitglied seit
4 Aug 2005
Beiträge
238
Punkte für Reaktionen
1
Punkte
16
Hi Leute!

Ausgangssituation:
Asterisk 1.6.2.7
Öffentliche IP-Adresse am Asterisk

Zum Problem::
Das "peer" registriert sich mit dem Host 193.106.16.101, eingehende Anrufe werden aber von 46.182.250.50 signalisiert.
Somit landen eingehende Anrufe in meinem Default-Context, statt im Context des Peers.

Fazit: chan_sip.c:20063 handle_request_invite: Call from '' to extension '673331' rejected because extension not found.

Code:
<--- SIP read from UDP:46.182.250.50:5060 --->
INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:46.182.250.50;lr;ftag=as4f6ad5f5;vsf=AAAAAAAAAAAAAAAAAAAAAABBXEFdXl5XQhxAQVhAGWRl>
Via: SIP/2.0/UDP 46.182.250.50;branch=z9hG4bKd26a.fa822423.0
Via: SIP/2.0/UDP 193.106.16.107:5060;received=193.106.16.107;branch=z9hG4bK20a08787;rport=5060
Max-Forwards: 69
From:  <sip:[email protected]>;tag=as4f6ad5f5
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: PBX-network SERVER
Date: Sat, 25 May 2013 10:36:54 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
P-Called-Party-ID: <sip:[email protected]:5060>;user=phone
X-ORIGINAL-DDI-URI: sip:[email protected]:5060;user=phone
Content-Type: application/sdp
Content-Length: 372

Code:
[personal-voip](!)
type=friend
canreinvite=no
host=sip.personal-voip.de
fromdomain=personal-voip.de
insecure=invite,port
context=inbound-personal-voip
session-timers=refuse
maxexpiry=3600
defaultexpiry=1800

Eigentlich sollten eingehende Anrufe in inbound-personal-voip terminiert werden.
Aufgrund des falschen Hosts, über den die Anrufe herein kommen, gehen die Anrufe in den Default-Context.

Ich würde ungern in meinem Default-Context einen Switch einbauen, der den FROM-Header nach @personal-voip.de auswertet und den Anruf dann in den inbound-personal-voip-Context umleitet.

PS: Anscheinend ändert sich in einigen Abständen immer die IP-Adresse, die hinter sip.personal-voip.de kommuniziert wird.
Code:
~ # dig sip.personal-voip.de

; <<>> DiG 9.9.1-P1 <<>> sip.personal-voip.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23922
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sip.personal-voip.de.          IN      A

;; ANSWER SECTION:
sip.personal-voip.de.   600     IN      CNAME   sip-proxy02.pbx-network.de.
sip-proxy02.pbx-network.de. 85363 IN    A       46.182.250.50

;; Query time: 9 msec
;; SERVER: 83.142.86.1#53(83.142.86.1)
;; WHEN: Sat May 25 12:57:23 2013
;; MSG SIZE  rcvd: 92
 
Wenn das ein SIP-Host von personal-voip ist, dann trage ihn doch einfach als peer in Deine sip-conf ein. Dann weist Du dem ein default-context zu und alles ist gut.
 
Mit diesem Gedanken habe ich auch schon gespielt.
Wenn aber Personal-VoIP mehrere Hosts betreibt, dann gehst du damit aber Baden, weil dann muss man für jeden Host einen eigenen Eintrag schaffen.
 
und genau so ist es auch... Bei 1und1 sind das irgendwas um die 50 Peers...


[EDIT]
Code:
tk01*CLI> sip show peers
Name/username              Host                                    Dyn Forcerport ACL Port     Status
1und1-1-1                  212.227.67.131                               N             5060     OK (86 ms)
1und1-1-2                  212.227.67.201                               N             5060     OK (87 ms)
1und1-1-3                  212.227.18.131                               N             5060     OK (86 ms)
1und1-1-4                  212.227.18.201                               N             5060     OK (85 ms)
1und1-2-1                  212.227.67.132                               N             5060     OK (86 ms)
1und1-2-2                  212.227.67.202                               N             5060     OK (86 ms)
1und1-2-3                  212.227.18.132                               N             5060     OK (86 ms)
1und1-2-4                  212.227.18.202                               N             5060     OK (85 ms)
1und1-3-1                  212.227.67.133                               N             5060     OK (86 ms)
1und1-3-2                  212.227.67.203                               N             5060     OK (86 ms)
1und1-3-3                  212.227.18.133                               N             5060     OK (86 ms)
1und1-3-4                  212.227.18.203                               N             5060     OK (85 ms)
1und1-4-1                  212.227.67.134                               N             5060     OK (80 ms)
1und1-4-2                  212.227.67.204                               N             5060     OK (66 ms)
1und1-4-3                  212.227.18.134                               N             5060     OK (73 ms)
1und1-4-4                  212.227.18.204                               N             5060     OK (57 ms)
1und1-5-1                  212.227.67.135                               N             5060     OK (50 ms)
1und1-5-2                  212.227.67.205                               N             5060     OK (44 ms)
1und1-5-3                  212.227.18.135                               N             5060     OK (42 ms)
1und1-5-4                  212.227.18.205                               N             5060     OK (86 ms)
1und1-6-1                  212.227.67.136                               N             5060     OK (86 ms)
1und1-6-2                  212.227.67.206                               N             5060     OK (86 ms)
1und1-6-3                  212.227.18.136                               N             5060     OK (86 ms)
1und1-6-4                  212.227.18.206                               N             5060     OK (86 ms)
1und1-7-1                  212.227.67.137                               N             5060     OK (86 ms)
1und1-7-2                  212.227.67.197                               N             5060     OK (86 ms)
1und1-7-3                  212.227.18.137                               N             5060     OK (86 ms)
1und1-7-4                  212.227.18.197                               N             5060     OK (85 ms)
1und1-8-1                  212.227.67.138                               N             5060     OK (86 ms)
1und1-8-2                  212.227.67.198                               N             5060     OK (86 ms)
1und1-8-3                  212.227.18.138                               N             5060     OK (86 ms)
1und1-8-4                  212.227.18.198                               N             5060     OK (85 ms)
1und1-9-1                  212.227.67.139                               N             5060     OK (85 ms)
1und1-9-2                  212.227.67.199                               N             5060     OK (85 ms)
1und1-9-3                  212.227.18.139                               N             5060     OK (86 ms)
1und1-9-4                  212.227.18.199                               N             5060     OK (86 ms)
201                        (Unspecified)                            D   N             0        UNKNOWN
202/202                    10.0.1.5                                 D   N             1025     OK (109 ms)
203                        (Unspecified)                            D   N             0        UNKNOWN
204/204                    (Unspecified)                            D   N             0        UNKNOWN
4930*******/4930*******    212.227.18.202                               N             5060     OK (86 ms)
4930*******/4930*******    212.227.18.135                               N             5060     OK (86 ms)
4930*******/4930*******    212.227.67.137                               N             5060     OK (87 ms)
telefonica-1               193.189.245.208                              N             5060     OK (45 ms)
telefonica-2               193.189.245.145                              N             5060     OK (84 ms)
telefonica-3               193.189.245.202                              N             5060     OK (88 ms)
telefonica-5               193.189.245.204                              N             5060     OK (89 ms)
telefonica-6               193.189.245.202                              N             5060     OK (88 ms)
telefonica-7               193.189.245.139                              N             5060     OK (88 ms)
telefonica-8               193.189.245.204                              N             5060     OK (89 ms)
50 sip peers [Monitored: 47 online, 3 offline Unmonitored: 0 online, 0 offline]
[/EDIT]


[EDIT2]
Alternative wäre: allowguest=yes in der sip.conf. Das solltest Du aber wirklich nur dann tun, wenn Dein default-context sehr gut abgesichert bzw. leer ist. Andernfalls würdest Du ein offenes Relay betreiben...
[/EDIT2]
 
Zuletzt bearbeitet:
Ich habe nun meine IP-Adresse als Domain in der SIP.CONF hinterlegt und an den Context inbound-ip geschickt.

Code:
[inbound-ip]
exten => _x.,1,Set(ORIGINAL_EXTENSION=${EXTEN})
exten => _x.,n,GoTo(findPeer,1)

exten => findPeer,1,NoOp(Inbound call from unauthenticated user: ${SIP_HEADER(From)} to direct IP)
exten => findPeer,n,Set(domain=${CUT(SIP_HEADER(FROM),@,2)})
exten => findPeer,n,Set(domain=${CUT(domain,>,1)})
exten => findPeer,n,GoTo(inbound-ip-redirect,${domain},1)

[inbound-ip-redirect]
exten => personal-voip.de,1,GoTo(inbound-personal-voip,${ORIGINAL_EXTENSION},1)
exten => sipgate.de,1,GoTo(inbound-sipgate,${ORIGINAL_EXTENSION},1)
exten => easybell.de,1,GoTo(inbound-easybell,${ORIGINAL_EXTENSION},1)
exten => dus.net,1,GoTo(inbound-dusnet,${ORIGINAL_EXTENSION},1)

Das Dumme dabei ist, dass DUS.NET bei anonymen Anrufen im FROM-Header "Anonymous" <sip:[email protected]> schickt. Nun kann ich das nicht mehr auswerten.
Das aberdumme ist, dass Personal-VoIP im TO-Header @IP-Adresse verwendet, anstatt @personal-voip.de

Das ist echt ärgerlich! Kein Provider macht irgendwie was richtig.
Bei FROM und bei TO sollte eigentlich immer @provider.tld stehen.. also From: [email protected] To: [email protected]

Man kann somit keinen korrekten Dialplan schaffen.
 
Konntest Du Dein Peer-Problem so lösen? eine Rückmeldung diesbezüglich wäre toll.
 
Leider nur Teils.
Das Problem mit Personal-VoIP ist damit behoben, dafür geht dann DUS.NET nicht mehr.

Das Problem ist ganz logisch:
Sobald ich domain => 80.255.xx.xx,inbound-ip in meine sip.conf einbaue, werden alle Anrufe von DUS.NET, easyBell, SIPGATE und Personal-VoIP über diesen Context geleitet, weil die Request-URI auf [email protected] lautet.

Das Dumme dabei ist, dass eigentlich ein entsprechendes Peer gefunden wurde (aufgrund der IP-Adresse des eingehenden Pakets). Asterisk schickt den Rufaufbau aber an inbound-ip, anstatt an inbound-dusnet bzw. inbound-sipgate usw.

Nun müsste man manuell ein Routing innerhalb von inbound-ip vornehmen, aber das geht nicht, weil in der FROM bzw. in der TO-Adresse nicht die richtigen Daten übergeben werden. Bei DUS.NET könnte ich höchstens die CALL-ID auswerten, aber das ist echt zu viel des Guten und echt fehleranfällig. Zudem hat man dann keine saubere Kontrolle mehr über die eingehenden Gespräche. Wenn jemand die Konfiguration des Servers kennt, könnte er einfach den FROM verfälschen und so Anrufe durchstellen.

Personal-VoIP sollte die Kommunikation immer nur über den Registration-Server leiten. Das ist echt pervers, dass man sich mit IP-A registriert und von IP-B einen INVITE bekommt! Das ist nicht korrekt.
 
Naja, ich kann nicht nachvollziehen warum es für Dich so wichtig ist, den Header auszuwerten. Weise doch DUS.net und co einfach mal drauf hin bzw. Frag ob das Problem nicht irgendwie zu lösen wäre.
 
Nun, ich muss wissen, wer der Downstream-Provider ist. Ich habe hier über 10 SIP-Anbieter in meiner Konfiguration laufen.

Der eine schickt Informationen zum Anrufer über den FROM-Header, der andere über P-Called-Party-ID, der Andere über ganz andere Attribute.
Damit ich darüber Herr der Dinge werde, habe ich für jeden Provider einen eigenen Context, wo die entsprechenden Dinge berücksichtigt werden.

Dummerweise unterstützt Personal-VoIP ebenso nicht, dass man beim Register einen eigenen Extension-Name angibt. Das ist immer die SIP-ID. Somit müsste ich im Context die SIP-ID weiterleiten, was ja auch kein Problem wäre, aber vielleicht kommt einer der Tage, wo einer meiner anderen 9 SIP-Anbieter genau die selbe SIP-ID vergibt, wie auch Personal-VoIP, dann kann ich nicht mehr auseinanderkennen, von wem der Anruf kam und für wen er eigentlich ist.

Dumme Sache das Alles.

Das Beste wäre einfach, Personal-VoIP würde die Invites von dem Server aus zu meinem Server senden, bei dem ich mich registriert habe.
Alles Andere ist Blödsinn und die Sicherheit kann nicht gewährleistet werden.
 
Aktuell sieht es so aus:

Code:
<--- Transmitting (NAT) to 46.182.250.50:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 46.182.250.50;branch=z9hG4bK9333.9af86df4.0;received=46.182.250.50;rport=5060
Via: SIP/2.0/UDP 193.106.16.107:5060;received=193.106.16.107;branch=z9hG4bK73ac01f3;rport=5060
Record-Route: <sip:46.182.250.50;lr;ftag=as3e155184;vsf=AAAAAAAAAAAAAAAAAAAAAEFcQV1eXldCHEBBWEAZZGU->
From: <sip:[email protected]>;tag=as3e155184
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 INVITE

Bin registriert bei 46.182.... sip.personal-voip.de bzw. sip-proxy02.pbx-network.de. Funktioniert das nun bei mir problemlos weil der erste Via Eintrag auf 46... lautet? Wozu eigentlich die zweite Via Zeile? Falls die 46... ausfällt, ändert pbx dann auch die Zeilen ab so das die 193.. zuerst steht oder hat man das Problem wie oben im Thread das es dann nicht funktioniert wenn man nicht beide Peers definiert hat?
Man beachte auch das die domain im TO immer noch falsch ist.

Zufällig hab ich das gefunden:
http://www.personal-voip.de/index.php?page=wiki&wikiid=support:konfigurationen:asterisk
"Da Anrufe nicht immer vom Register-Server kommen, muss insecure entsprechend gesetzt werden. "
Leider auch nicht korrekt, denn insecure heisst ja nur das sich der remote server bei uns nicht anmelden muss.
Dann ist mir noch was aufgefallen:

Code:
<--- SIP read from UDP:46.182.250.50:5060 --->
OPTIONS sip:88.64.209.163:5060 SIP/2.0
Via: SIP/2.0/UDP 46.182.250.50:5060;branch=0
From: sip:[email protected];tag=02070306
To: sip:88.64.209.163:5060
Call-ID: [email protected]
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
Sending to 46.182.250.50:5060 (NAT)
Looking for s in default (domain 88.64.209.163)

<--- Transmitting (NAT) to 46.182.250.50:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 46.182.250.50:5060;branch=0;received=46.182.250.50;rport=5060
From: sip:[email protected];tag=02070306
To: sip:88.64.209.163:5060;tag=as142f1f08
Call-ID: [email protected]
CSeq: 1 OPTIONS
Server: DSL-EasyBox/DSL-EasyBox-10.02.012
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

Es wird dabei versucht bei meinem Host die Fähigkeiten zu lesen (Options). Weil keine exten angegeben ist, schaut Asterisk in der s exten unter default context. Um den Fehler zu beheben einfach s,1,Hangup in default einfügen.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.