[Gelöst] Vodafone IP-Anlagenanschluss über Chan_SIP einbinden

[Philipp971]

Hallo Zusammen!

Der Einsatz eines Sipgate-Testtrunks hatte damals mit dem regulären Chan_SIP peer problemlos funktioniert - erreichbar sowohl Inbound als auch Outbound.
Zur Zeit teste ich einen Vodafone IP-Anlagenanschluss über Chan_SIP und würde gerne eure Meinung anhand der gegebenen Daten von VF und meiner Umsetzung des Trunks wissen:

Das habe ich von VF bekommen:
Benutzer: 0361XXXXXXX
Passwot: keins - hier bei der Registrierung nicht notwendig
Testrufnummern von 0361XXXXXXX: 0..9
SBC-IP: IPv4 und Port 5060
SIP Domain: XXX.ngn.vodafone.de

Das ist mein aktueller Chan_SIP-Peer:

[PEER Details (Outgoing)]
outboundproxy=IP des Registrar
host=IP des Registrar
port=5060
username=0361XXXXXXX
fromuser=0361XXXXXXX
fromdomain=XXX.ngn.vodafone.de
type=peer
qualify=no
dtmfmode=rfc2833
disallow=all
allow=alaw
insecure=invite,port

[PEER Details (Incoming)]
type=user
context=from-trunk

[Benutzer Context]
0361XXXXXXX

[Register String]
leer


Die Einrichtung unter PJSIP hatte bereits funktioniert, allerdings nur für ausgehende Anrufe, eingehend konnte ich nicht telefonieren. Daher möchte ich es jetzt als vergleich per Chan_SIP probieren.
Erkennt ihr Unstimmigkeiten im peer? Ich bin mir nicht ganz sicher was die Parameter "fromuser" und "username" angeht. Ob hier bei beiden die +49 oder nur die 0 vorgestellt wird, oder beim Benutzercontext nur die +49 oder nur die 0.

Die öffentliche Adresse ist korrekt in der FreePBX hinterlegt, der Vodafone-SBC wird auch erreicht (sah ich ja beim PJSIP-Trunk) und Port 5060 ist natürlich für Chan_SIP aktiv.
In den Protokolldateien habe sobald ich rauswärts telefonieren möchte folgende Meldung:

chan_sip.c: Retransmission timeout reached on transmission [email protected] for seqno 102 (Critical Request)

Der Befehl "sip show peers" zeigt mir die aktiven Nebenstellen an und eine "Unmonitored" Verbindung die aber dennoch online zu sein scheint.
Interessant ist, dass sobald ich den [Register String] ausfülle, erhalte ich einen Timeout:

Registration for '[email protected]' timed out, trying again (Attempt #2)

Habt ihr Ideen? Wo sollte ich mit dem Debug beginnen, um euch weitere Infos zu geben? Ich bin für jede Idee und Hilfe dankbar!

EDIT: Ah, Moment - Ouboundproxy ist dem Fall ja natürlich die SBC-IP von Vodafone, und nicht die SIP-Domain. Fällr mir jetzt erst auf, ich probiere das mal fix...Theoretisch ja auch der Host.

Grüße

 

[Philipp971]

Okay - ich mache ungern Doppelposts (sofern nötig kann es der Moderator ja zusammenfügen).

Der Trunk scheint unter Chan_SIP zwar registriert zu sein, sprich Outbound-Calls sind möglich, Inbound funktioniert noch allerdings nicht. Ich bekomme beim Rufaufbau die Meldung dass die Nummer nicht in Gebrauch sei.
ABER, ich bekomme beim Rufaufbau im Log folgenden Mitschnitt:

[2020-01-17 14:38:07] VERBOSE[11164][C-0000000f] netsock2.c: Using SIP RTP TOS bits 184
[2020-01-17 14:38:07] VERBOSE[11164][C-0000000f] netsock2.c: Using SIP RTP CoS mark 5
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [+4936143056850@from-sip-external:1] NoOp("SIP/ims.vodafone.de-00000016", "Received incoming SIP connection from unknown peer to +4936143056850") in new stack
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [+4936143056850@from-sip-external:2] Set("SIP/ims.vodafone.de-00000016", "DID=+4936143056850") in new stack
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [+4936143056850@from-sip-external:3] Goto("SIP/ims.vodafone.de-00000016", "s,1") in new stack
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx_builtins.c: Goto (from-sip-external,s,1)
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:1] GotoIf("SIP/ims.vodafone.de-00000016", "1?setlanguage:checkanon") in new stack
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx_builtins.c: Goto (from-sip-external,s,2)
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:2] Set("SIP/ims.vodafone.de-00000016", "CHANNEL(language)=de_DE") in new stack
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:3] GotoIf("SIP/ims.vodafone.de-00000016", "1?noanonymous") in new stack
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx_builtins.c: Goto (from-sip-external,s,5)
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:5] Set("SIP/ims.vodafone.de-00000016", "TIMEOUT(absolute)=15") in new stack
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] func_timeout.c: Channel will hangup at 2020-01-17 14:38:22.684 CET.
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:6] Log("SIP/ims.vodafone.de-00000016", "WARNING,"Rejecting unknown SIP connection from 192.168.16.222"") in new stack
[2020-01-17 14:38:07] WARNING[29196][C-0000000f] Ext. s: "Rejecting unknown SIP connection from 192.168.16.222"
[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:7] Answer("SIP/ims.vodafone.de-00000016", "") in new stack
[2020-01-17 14:38:08] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:8] Wait("SIP/ims.vodafone.de-00000016", "2") in new stack
[2020-01-17 14:38:10] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:9] Playback("SIP/ims.vodafone.de-00000016", "ss-noservice") in new stack
[2020-01-17 14:38:10] VERBOSE[29196][C-0000000f] file.c: <SIP/ims.vodafone.de-00000016> Playing 'ss-noservice.g722' (language 'de_DE')
[2020-01-17 14:38:16] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:10] PlayTones("SIP/ims.vodafone.de-00000016", "congestion") in new stack
[2020-01-17 14:38:16] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:11] Congestion("SIP/ims.vodafone.de-00000016", "5") in new stack
[2020-01-17 14:38:17] VERBOSE[29196][C-0000000f] pbx.c: Spawn extension (from-sip-external, s, 11) exited non-zero on 'SIP/ims.vodafone.de-00000016'
[2020-01-17 14:38:17] VERBOSE[29196][C-0000000f] pbx.c: Executing [h@from-sip-external:1] Hangup("SIP/ims.vodafone.de-00000016", "") in new stack
[2020-01-17 14:38:17] VERBOSE[29196][C-0000000f] pbx.c: Spawn extension (from-sip-external, h, 1) exited non-zero on 'SIP/ims.vodafone.de-00000016'

Besonders interessant finde ich den Part:

[2020-01-17 14:38:07] VERBOSE[29196][C-0000000f] pbx.c: Executing [s@from-sip-external:6] Log("SIP/ims.vodafone.de-00000016", "WARNING,"Rejecting unknown SIP connection from 192.168.16.222"") in new stack
[2020-01-17 14:38:07] WARNING[29196][C-0000000f] Ext. s: "Rejecting unknown SIP connection from 192.168.16.222"

Scheint wohl noch ein Konfigurationsproblem unsererseits zu sein... Auf jeden Fall merkt die Asterisk hier dass ein Anruf eingeht, kann mit der "unknown" SIP-Connection aber scheinbar nichts anfangen bzw. lehnt diese von der IP wieder ab. Die genannte IP ist in dem Fall das GW, hier scheint es wohl noch Probleme mit der öffentlichen Adresse von PBX zu VF bzw. umgekehrt zu geben...

Gruselig. Das Problem scheint vollkommen wo anders zu liegen ... Drehe ich die Option in der FreePBX auf YES welche Anonyme Anrufe durchlässt, funktionieren auch eingehende Gespräche. Ich werde also nach diesem Zusammenhang suchen,, das Thema schließe ich somit.

 

[FunkReich]

Der Befehl "sip show peers" zeigt mir die aktiven Nebenstellen an und eine "Unmonitored" Verbindung die aber dennoch online zu sein scheint.

das liegt denke ich am qualify=no
denn nur dann kann asterisk "monitoren" und zwar mit regelmäßigen OPTIONS paketen ob der trunk aktiv ist.

00000016", "WARNING,"Rejecting unknown SIP connection from 192.168.16.222"") in new stack
Auf jeden Fall merkt die Asterisk hier dass ein Anruf eingeht, kann mit der "unknown" SIP-Connection aber scheinbar nichts anfangen bzw. lehnt diese von der IP wieder ab. Die genannte IP ist in dem Fall das GW, hier scheint es wohl noch Probleme mit der öffentlichen Adresse von PBX zu VF bzw. umgekehrt zu geben...

versuche mal nachzuschauen, welche IP als Match im chansip peer steht. dort wird bei pjsip zumindest automatisch die IP adresse des sip registrar erlaubt.
bei freepbx:
admin/config.php?display=asteriskinfo&module=Peers
unter "Match: <criteria."

FreePBX auf YES welche Anonyme Anrufe durchlässt, funktionieren auch eingehende Gespräche.

ich hoffe du hast eine gute Firewall
Eine inbound route mit pattern match auf deine DID existiert aber?
In deinem eingehenden Trunk ist kein Server definiert? vielleicht tuts auch ein host=XXX.ngn.vodafone.de in der inbound peer

 

[Philipp971]

Danke für die Erklärung bezüglich des qualify=no. Ich werde das auf 'yes' setzen.

Den Punkt "Match" habe ich in dem Menüpunkt "asteriskinfo&module=Peers" leider nicht - mit dem qualify=yes wird der Trunk beim Befehl "sip show peers" als OK angezeigt. "sip show regestry" zeigt 0 registrations an. Auch in der Übersicht unter asteriskinfo&module=Peers wird scheinbar keine aktive SIP-Registrierung angezeigt:

##

Ich richte den Trunk jetzt nochmal über PJSIP ein und schaue ob die Asterisk an der Stelle eine aktive Registrierung merkt - hier wird ja der SIP Registrar UND die Fromdomain angegeben, und wie du schon sagst wird die Adresse des Registrar in dem Fall ja erlaubt.

Wir haben eine gute Firewall, ja.

Eine inbound route mit pattern match auf deine DID existiert aber?

Ja, das existiert. Wir haben eine Stammrufnummer und zusätzliche Testrufnummern. Bzw. habe ich die Inbound-Routen auf diese Test-DIDs festgelegt und die entsprechenden Nebenstellen auf welchen die Anrufe klingeln sollen, werden auch angesprochen, die DIDs funktionieren also problemlos.

In deinem eingehenden Trunk ist kein Server definiert? vielleicht tuts auch ein host=XXX.ngn.vodafone.de in der inbound peer

Ich habe oben meinen Peer aktualisiert, der Host ist bereits eingetragen, das hatte ich dann noch angepasst.

Wie gesagt, ich vermute dennoch dass die Firewall die Pakete irgendwie korrumpiert - ich weiß noch nicht genau wie und warum, aber es scheint so...
Denn ohne die Optuion "Anonyme Anrufe zulassen" verwirft die Asterisk die SIP-Pakete welchhe von der 16.222, unserer FW, eintreffen. Eigentlich muss es direkt ein 1zu1 Routing geben, dass die Firewall die öffentliche Adresse des Registrar durchschleift und die Asterisk demnach auch die Pakete eben dieser Adresse annimmt, aber hier meldet sich eben bei eintreffender Verbindung die Firewall mit ihrer Adresse und die Asterisk lässt die Pakete so wie ich das beurteilen kann dadurch nicht durch, schienbar eben nur, wenn auch Anonyme Anrufe zugelassen werden... Ich prüfe das weiterführend.