Asterisk 13 - Magenta S - keine ausgehenden Anrufe trotz korrekter SIP-Signalisierung

ltrotzki

Neuer User
Mitglied seit
22 Okt 2015
Beiträge
25
Punkte für Reaktionen
0
Punkte
0
Hallo,
mein erster Beitrag und gleich ein großes Problem.
Folgendes Setup:
T-Com Speedport Hybrid DSL/LTE 8Tarif (Magenta S) <---> Asterisk 13 LTS Cert <----> Clients (phone 1, ...x - testweise mit softphone x-lite)
Ich kann die phones von außen anrufen, nur leider der umgekehrte Weg geht nicht. Von den phones kann ich keine Nummer "draußen" erreichen. Das Gespräch wird jedoch laut Asterisk korrekt signalisiert und durchgestellt, es kommt ein Rufzeichen(!) aber beim Teilnehmer "draußen" klingelt nichts.
sip.conf:
Code:
[general]
context=public                  ; Default context for incoming calls. Defaults to 'default'
allowoverlap=no                 ; Disable overlap dialing support. (Default is yes)
udpbindaddr=0.0.0.0             ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
tcpenable=no                    ; Enable server for incoming TCP connections (default is no)
tcpbindaddr=0.0.0.0             ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
transport=udp                   ; Set the default transports.  The order determines the primary default transport.
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls
qualify=yes
register=0123456789:654321:[email protected]@tel.t-online.de/0123456789~3600
nat=force_rport,auto_comedia

[authentication]
[basic-options](!)                ; a template
        dtmfmode=rfc2833
        context=from-office
        type=friend
[natted-phone](!,basic-options)   ; another template inheriting basic-options
        directmedia=no
        host=dynamic
[public-phone](!,basic-options)   ; another template inheriting basic-options
        directmedia=yes
[my-codecs](!)                    ; a template for my preferred codecs
        disallow=all
        allow=ilbc
        allow=g729
        allow=gsm
        allow=g723
        allow=ulaw
[ulaw-phone](!)                   ; and another one for ulaw-only
        disallow=all
        allow=ulaw

[seb]
        type=friend
        context=phones
        allow=ulaw,alaw
        secret=123456
        host=dynamic

[outside]
        type=peer
        context=incoming
        allow=ulaw,alaw,g722
        [email protected]
        [email protected]
        [email protected]
        [email protected]
        remotesecret=654321
        encryption = no
        sendrpid = no
        trustrpid = yes
        host=tel.t-online.de
        fromdomain=tel.t-online.de
        realm=tel.t-online.de
        qualify=yes
        directmedia=no
        dtmfmode=inband
        insecure=port,invite
        session-timers=refuse

extension.conf:
Code:
[outgoing]
exten => _0X.,1,NoOp(outgoing call via t-com)
same => n,Set(CALLERID(num-pres=0123456789)
same => n,Set(CALLERID(name)=0123456789)
same => n,Set(CALLERID(num)=0123456789)
same => n,SipAddHeader(P-Preferred-Identity: <sip:[email protected]>)
same => n,SipAddHeader(P-Asserted-Identity: <sip:[email protected]>)
same => n,Dial(SIP/outside/${EXTEN}@tel.t-online.de,180,rg)
same => n,HangUp

Debug-Ausgabe auf Konsole wenn Call rausgeht:
Code:
  == Using SIP RTP CoS mark 5
    -- Executing [015253987665@phones:1] NoOp("SIP/seb-0000000c", "015253987665") in new stack
    -- Executing [015253987665@phones:2] Goto("SIP/seb-0000000c", "outgoing,015253987665,1") in new stack
    -- Goto (outgoing,015253987665,1)
    -- Executing [015253987665@outgoing:1] NoOp("SIP/seb-0000000c", "ougoing call via t-com") in new stack
    -- Executing [015253987665@outgoing:2] Set("SIP/seb-0000000c", "CALLERID(num-pres=0123456789") in new stack
    -- Executing [015253987665@outgoing:3] Set("SIP/seb-0000000c", "CALLERID(name)=0123456789") in new stack
    -- Executing [015253987665@outgoing:4] Set("SIP/seb-0000000c", "CALLERID(num)=0123456789") in new stack
    -- Executing [015253987665@outgoing:5] SIPAddHeader("SIP/seb-0000000c", "P-Preferred-Identity: <sip:[email protected]>") in new stack
    -- Executing [015253987665@outgoing:6] SIPAddHeader("SIP/seb-0000000c", "P-Asserted-Identity: <sip:[email protected]>") in new stack
    -- Executing [015253987665@outgoing:7] Dial("SIP/seb-0000000c", "SIP/outside/[email protected],180,rg") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/outside/[email protected]

RTP Ports 30000 - 31000 in rtp.conf richtig gesetzt und am Speedport auf Asterisk Server weitergeleitet. Keine weiteren Firewalls etc.
Ich habe dazu alles abgegrasst was es im Forum so gibt. Keine Lösung. Was ist da los? Jemand eine Idee? Danke.

edit: nutze auch stun server (stun.t-online.de). stun show status gibt auch die richtige public adresse raus. somit dürfte das auch kein problem sein. ich glaube stand jetzt, der speedport "optimiert" die sip-verbindungen...
 
Zuletzt bearbeitet:
Hinter einem NAT brauchst Du im [general] noch externip oder externhost/externrefresh, und localnet. Asterisk nutzt STUN nur, um zu erkennen, dass sich die externe IP Adresse geändert hat, nutzt diese aber nicht in den SIP Paketen.

Wenn es dann immer noch nicht funktioniert, versuche einen anderen bindport. Man liest von Speedports hin und wieder, dass diese Probleme mit abgehenden Verbindungen von 5060 machen.
 
Danke rentier für deine Antwort,
ich habe genannte Direktiven eingesetzt und auch testweise wurde der Speedport "entfernt". Daran liegt es nicht. Fokussieren wir uns auf den Register-String. Ich habe jetzt mal ein Dump gemacht um mal zu schauen was da zwischen Provider und meinem Asterisk-Server an SIP-Paketen hin und herfliegt. Nach der Signalisierung ein "Bad Request":
491 5.366451 217.0.23.100 192.168.1.61 SIP 385 Status: 400 Bad request |

To: <sip:0123456789%[email protected]>;tag=huae4vbyvxx
From: "0123456789" <sip:my.mail%[email protected]>;tag=as5323771c

Man beachte die Kodierung des @-Zeichens in der Mail-Adresse. Das kommt dann vermutlich aus:

register=0123456789:654321:[email protected]@tel.t-online.de/0123456789~3600

my.mail wäre ja irgendwas wie [email protected]
Könnte das ein Kodierungs-Problem sein. Das wäre ärgerlich.

edit:
Hier der vollständige Header. Wie man sieht, ist die From Adresse "kaputt". Wieso schreibt Asterisk da 2x die Domain rein und dann beim ersten Mal sogar falsch kodiert (%40 anstatt @). Das ist doch komisch. Gibt es eine Möglichkeit den From-Header im Dialplan neuzuschreiben? Habe auf den ersten Blick keine Funktion gefunden.

INVITE sip:0123456789%[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.61:5060;branch=z9hG4bK2ea107bb
Max-Forwards: 70
From: "077654321" <sip:[email protected]>;tag=as064999e3
To: <sip:0123456789%[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.1-cert2
Date: Mon, 26 Oct 2015 21:59:41 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
P-Asserted-Identity: <sip:[email protected]>
P-Preferred-Identity: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 258

SIP/2.0 400 Bad request
Via: SIP/2.0/UDP 192.168.1.61:5060;branch=z9hG4bK2ea107bb
To: <sip:0123456789%[email protected]>;tag=hua1nh4pvhv
From: "0123456789" <sip:[email protected]>;tag=as064999e3
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 0

edit2:
hab das Dial folgend abgeändert, da ich in sip.conf auch fromdomain drin habe, so dass dies die Dopplung erklärt:

same => n,Dial(SIP/outside/${EXTEN},180,rg)

Jetzt bekomme ich ein Forbidden. Irgendwelche Ideen was ich noch anpassen muss?
 
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.