[Gelöst] Funktionierende Konfiguration für Swisscom SIP

killbyt

Neuer User
Mitglied seit
18 Apr 2015
Beiträge
13
Punkte für Reaktionen
0
Punkte
1
Das Problem ist Gelöst, siehe Post #9

Hallo Zusammen Ich versuche schon seit längerem einen Swisscom SIP Anschluss auf meiner FreePBX zum laufen zu bringen. (SIP Zugangsdaten wurden mit bisschen Aufwand aus dem Modem "extrahiert" ). Nun momentan ist der Stand der Dinge folgender:
- Eingehende Anrufe funktionieren
- Ausgehende Anrufe funktionieren leider nicht
- Ich habe testweise die SIP-Zugangsdaten in mein Android eingegeben => funktioniert (eingehend und ausgehend)
- NAT Probleme kann ich ausschliessen, interne Telefonie funktioniert sogar via Mobilfunknetz (NAT44)

Ich habe schon vieles versucht, aber bis jetzt hat noch nichts zum gewünschten Ergebnis geführt. Nun zu meiner momentanen Konfiguration:
Code:
#OUT

username=+4131xxxxxxx
type=peer
secret=mein_passwort
qualify=yes
nat=yes
insecure=invite,port
host=bc1.ims.swisscom.ch
[email protected]
fromuser=+4131xxxxxxx
fromdomain=swisscom.ch
disallow=all
canreinvite=no
allow=ulaw&alaw
context=from-trunk


#IN
type=peer
port=5060
host=bc1.ims.swisscom.ch
fromdomain=swisscom.ch
disallow=all
allow=ulaw&alaw


#REGISTER STRING
[email protected]:mein_passwort:[email protected]/+4131xxxxxxx

In Console steht bei Anrufversuch folgendes:
Code:
[2015-05-09 17:10:16] WARNING[3272][C-0000000d]: chan_sip.c:23159 handle_response_invite: Received response: "Forbidden" from '<sip:[email protected]:5059>;tag=as51f91bed'

Und hier der Output von"sip set debug peer Swisscom":
Code:
raspbx*CLI> sip set debug peer Swisscom
SIP Debugging Enabled for IP: 195.186.128.16
[2015-05-09 17:13:26] NOTICE[3272]: chan_sip.c:15094 sip_reregister:    -- Re-registration for  [email protected]
REGISTER 11 headers, 0 lines
Reliably Transmitting (NAT) to 195.186.128.16:5060:
REGISTER sip:swisscom.ch SIP/2.0
Via: SIP/2.0/UDP 83.78.103.73:5059;branch=z9hG4bK613ced4e;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=as1c536511
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 105 REGISTER
User-Agent: Centro grande/6.14.00
Authorization: Digest username="NCxxauth_name", realm="swisscom.ch", algorithm=MD5, uri="sip:swisscom.ch", nonce="932035xxxxxxxxxxx04F25806A", response="e52531xxxxxxxxxxx9ee6998", qop=auth, cnonce="5exx076", nc=00000003
Expires: 120
Contact: <sip:[email protected]:5059>
Content-Length: 0


---

<--- SIP read from UDP:195.186.128.16:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 83.78.103.73:5059;received=83.78.103.73;rport=49155;branch=z9hG4bK613ced4e
To: <sip:[email protected]>;tag=b2j9c8nqpjucx9v7l99zltgcky92kdvp
From: <sip:[email protected]>;tag=as1c536511
Call-ID: [email protected]
CSeq: 105 REGISTER
Contact: <sip:[email protected]:5059>;expires=120
P-Associated-Uri: <sip:[email protected]>
User-Agent: Centro grande/6.14.00
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
[2015-05-09 17:13:26] NOTICE[3272]: chan_sip.c:23656 handle_response_register: Outbound Registration: Expiry for bc1.ims.swisscom.ch is 120 sec (Scheduling reregistration in 105 s)
Really destroying SIP dialog '[email protected]' Method: REGISTER
[2015-05-09 17:13:26] NOTICE[3272]: chan_sip.c:15094 sip_reregister:    -- Re-registration for  [email protected]
[2015-05-09 17:13:26] NOTICE[3272]: chan_sip.c:23656 handle_response_register: Outbound Registration: Expiry for free4.voipgateway.org is 120 sec (Scheduling reregistration in 105 s)
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
Audio is at 10048
Adding codec 100003 (ulaw) to SDP
Adding codec 100004 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 195.186.128.16:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 83.78.103.73:5059;branch=z9hG4bK6ee9d7f8;rport
Max-Forwards: 70
From: <sip:[email protected]:5059>;tag=as4b15885a
To: <sip:[email protected]>
Contact: <sip:[email protected]:5059>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Centro grande/6.14.00
Date: Sat, 09 May 2015 15:13:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 260

v=0
o=root 1612192638 1612192638 IN IP4 83.78.103.73
s=Asterisk PBX 11.17.0
c=IN IP4 83.78.103.73
t=0 0
m=audio 10048 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

---

<--- SIP read from UDP:195.186.128.16:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 83.78.103.73:5059;received=83.78.103.73;rport=49155;branch=z9hG4bK6ee9d7f8
To: <sip:[email protected]>;tag=h7g4Esbg_uqgrhzp4y1wguchzlx3tmkiyh75j4nct
From: <sip:[email protected]:5059>;tag=as4b15885a
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 0

<------------->
--- (7 headers 0 lines) ---
Transmitting (NAT) to 195.186.128.16:5060:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 83.78.103.73:5059;branch=z9hG4bK6ee9d7f8;rport
Max-Forwards: 70
From: <sip:[email protected]:5059>;tag=as4b15885a
To: <sip:[email protected]>;tag=h7g4Esbg_uqgrhzp4y1wguchzlx3tmkiyh75j4nct
Contact: <sip:[email protected]:5059>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: Centro grande/6.14.00
Content-Length: 0


---
[2015-05-09 17:13:27] WARNING[3272][C-0000000e]: chan_sip.c:23159 handle_response_invite: Received response: "Forbidden" from '<sip:[email protected]:5059>;tag=as4b15885a'
Scheduling destruction of SIP dialog '[email protected]' in 6400 ms (Method: INVITE)
  == Everyone is busy/congested at this time (1:0/0/1)
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
  == Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'SIP/701-0000001d' in macro 'dialout-trunk'
  == Spawn extension (from-internal, 078xxxxxxx, 6) exited non-zero on 'SIP/701-0000001d'
  == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/701-0000001d'
Really destroying SIP dialog '[email protected]' Method: INVITE
raspbx*CLI> sip set debug off
SIP Debugging Disabled
raspbx*CLI>

Nun, hat vieleicht jemand eine funktionierende Konfiguration oder weiss was hier schief läuft?

Vielen Dank für eine Antwort

Gruss

Killbyt
 
Zuletzt bearbeitet:
Moins

NAT Probleme kann ich ausschliessen, interne Telefonie funktioniert sogar via Mobilfunknetz (NAT44)

Sicher?
Denn es hört sich nach einen NAT Problem an.
Wenn der Server sich im LAN befindet dann übergeben lokale Telefone ihre lokale IP als "Rücksendeadresse".
So bekomme ich aus dem LAN nur eine funktionierende Internetverbindung wenn ich auch STUN verwende.
Also, meine Empfehlung: Verwende STUN, dabei geht jeder STUN Server den du habhaft werden kannst.
Ich nutze: STUN: stun.1und1.de auf Standardport (muss nicht angegeben werden)

Beispiel mit PhonerLite ohne Registrierung im LAN...
Erfolglos ohne STUN-Server...
Code:
13:28:30,944: T: [::FFFF:212.42.244.116]:5060 (UDP)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.178.5:5060;branch=z9hG4bK00038a843ef6e4119a72d5dddad1256e;rport
From: <sip:[email protected]>;tag=2740018483
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
Max-Forwards: 70
Supported: 100rel, replaces, from-change
P-Early-Media: supported
User-Agent: SIPPER for PhonerLite
P-Preferred-Identity: <sip:[email protected]>
Content-Length:   257

v=0
o=- 1655194355 1 IN IP4 192.168.178.5
s=SIPPER for PhonerLite
c=IN IP4 192.168.178.5
t=0 0
m=audio 5062 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:1816477718
a=sendrecv

Erfolgreich mit STUN: stun.1und1.de
Code:
13:31:33,076: T: [::FFFF:212.42.244.116]:5060 (UDP)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 217.250.217.216:61012;branch=z9hG4bK000205f13ef6e4119e1c55fe7d0c0a88;rport
From: <sip:[email protected]:61012>;tag=18261622
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:61012>
Content-Type: application/sdp
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
Max-Forwards: 70
Supported: 100rel, replaces, from-change
P-Early-Media: supported
User-Agent: SIPPER for PhonerLite
P-Preferred-Identity: <sip:[email protected]>
Content-Length:   261

v=0
o=- 2198395541 1 IN IP4 217.250.217.216
s=SIPPER for PhonerLite
c=IN IP4 217.250.217.216
t=0 0
m=audio 5062 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:4206359432
a=sendrecv
...in HD. ;)

Es kommt also darauf an, was im SIP Header hinter Via:, From:, Contact: und c=IN IP4 steht.
...und dafür ist der STUN verantwortlich.

Die IP mach ich mal nicht unkenntlich, da schon eine Neue bestellt. :mrgreen:
 
Zuletzt bearbeitet:
Danke für die Antwort, aber ich kann NAT Probleme wirklich ausschliessen:
Code:
 Via: SIP/2.0/UDP 83.78.103.73:5059;branch=z9hG4bK6ee9d7f8;rport Contact:  c=IN IP4 83.78.103.73
Und zumdem funktioniert ein anderer Anbieter (Sipcall) ohne Probleme. Gruss Killbyt
 
Es kann ja nur am From (fromdomain / Formatierung fromuser) oder To (Formatierung Zielnummer) liegen, alles andere käme erst im authentifizierten Invite. Wende Dich doch an den Support und gib denen das Invite durch, die können bestimmt sagen, was da nicht passt. Wenn Du eine Rückmeldung hast, was wie aussehen muss, können wir hier bestimmen, wie das auf Asterisk-Seite umzusetzen ist.
 
Da hast Du wohl recht :) Nur das Problem ist, ich hab ja Anfangs geschrieben, die Zugangsdaten wurden aus dem Modem "extrahiert", was ich damit sagen will, die Zugangsdaten habe ich inoffiziell - also kein Support:rolleyes:

Nun bin ich aber deiner Idee ein bisschen nachgegangen, ich habe nämlich schon länger ein Avaya IP 1140E in Betrieb mit den selben Zugangsdaten. Hier ein Debug log eines ausgehenden Anrufs:
Code:
Rec #120 ===============
Up time: 04:16:37 (274597790 msec) Type: Out
Real time: 05/12/2015 17:21:07 UTC
INVITE sip:[email protected];user=phone SIP/2.0
Accept: application/sdp
Via: SIP/2.0/UDP 192.168.1.114:5060;branch=z9hG4bK875385a18bf3d6045
Max-Forwards: 70
From: <sip:[email protected]>;tag=43017e2dec
To: <sip:[email protected];user=phone>
Call-ID: f4aaaa579520d79c
CSeq: 11559 INVITE
Allow-Events: talk,hold
Contact: <sip:[email protected]>
Min-SE: 1800
Session-Expires: 1800
Supported: timer, replaces
User-Agent: Avaya IP Phone 1140E (SIP1140e.04.04.10.00)
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, REFER, INFO, MESSAGE, NOTIFY, UPDATE
Remote-Party-ID: <sip:[email protected]>;screen=yes;party=calling;privacy=off
Expires: 180
x-nt-GUID: CCF95495836B
Content-Type: application/sdp
Content-Length: 391

v=0
o=+4131xxxxxxxx 0 1431451270 IN IP4 192.168.1.114
s=-
c=IN IP4 192.168.1.114
t=0 0
m=audio 16396 RTP/AVP 0 8 18 9 4 101 111
c=IN IP4 192.168.1.114
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:9 G722/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:111 X-nt-inforeq/8000
a=fmtp:18 annexb=no
a=fmtp:4 annexa=no
a=maxptime:60


Rec #121 ===============
Up time: 04:16:37 (274597820 msec) Type: In
Real time: 05/12/2015 17:21:07 UTC
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.114:5060;received=83.78.103.73;branch=z9hG4bK875385a18bf3d6045
To: <sip:[email protected];user=phone>;tag=h7g4Esbg_fc1286030507a1ab0ba5520008ec994
From: <sip:[email protected]>;tag=43017e2dec
Call-ID: f4aaaa579520d79c
CSeq: 11559 INVITE
Content-Length: 0
Proxy-Authenticate: Digest nonce="DCF5A45C6D1A52550000000023851E51",realm="swisscom.ch",algorithm=MD5,qop="auth"



Rec #122 ===============
Up time: 04:16:37 (274597830 msec) Type: Out
Real time: 05/12/2015 17:21:07 UTC
ACK sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.1.114:5060;branch=z9hG4bK875385a18bf3d6045
Max-Forwards: 70
From: <sip:[email protected]>;tag=43017e2dec
To: <sip:[email protected];user=phone>;tag=h7g4Esbg_fc1286030507a1ab0ba5520008ec994
Call-ID: f4aaaa579520d79c
CSeq: 11559 ACK
User-Agent: Avaya IP Phone 1140E (SIP1140e.04.04.10.00)
Content-Length: 0



Rec #123 ===============
Up time: 04:16:37 (274597830 msec) Type: Out
Real time: 05/12/2015 17:21:07 UTC
INVITE sip:[email protected];user=phone SIP/2.0
Accept: application/sdp
Via: SIP/2.0/UDP 192.168.1.114:5060;branch=z9hG4bK7a448da1c46cbd9eb
Proxy-Authorization: Digest username="NCxx_auth_name",realm="swisscom.ch",nonce="DCF5A45C6D1A52550000000023851E51",uri="sip:[email protected];user=phone",response="2896568f9c74278e02e3bab264b764a6",algorithm=MD5,qop=auth,cnonce="57c0d954",nc=00000001
Max-Forwards: 70
From: <sip:[email protected]>;tag=43017e2dec
To: <sip:[email protected];user=phone>
Call-ID: f4aaaa579520d79c
CSeq: 11560 INVITE
Allow-Events: talk,hold
Contact: <sip:[email protected]>
Min-SE: 1800
Session-Expires: 1800
Supported: timer, replaces
User-Agent: Avaya IP Phone 1140E (SIP1140e.04.04.10.00)
Remote-Party-ID: <sip:[email protected]>;screen=yes;party=calling;privacy=off
Expires: 180
x-nt-GUID: CCF95495836B
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, REFER, INFO, MESSAGE, NOTIFY, UPDATE
Content-Type: application/sdp
Content-Length: 391

v=0
o=+4131xxxxxxxx 0 1431451270 IN IP4 192.168.1.114
s=-
c=IN IP4 192.168.1.114
t=0 0
m=audio 16396 RTP/AVP 0 8 18 9 4 101 111
c=IN IP4 192.168.1.114
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:9 G722/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:111 X-nt-inforeq/8000
a=fmtp:18 annexb=no
a=fmtp:4 annexa=no
a=maxptime:60


Rec #124 ===============
Up time: 04:16:38 (274598040 msec) Type: In
Real time: 05/12/2015 17:21:07 UTC
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.114:5060;received=83.78.103.73;branch=z9hG4bK7a448da1c46cbd9eb
To: <sip:[email protected];user=phone>
From: <sip:[email protected]>;tag=43017e2dec
Call-ID: f4aaaa579520d79c
CSeq: 11560 INVITE
Content-Length: 0



Rec #125 ===============
Up time: 04:16:38 (274598730 msec) Type: In
Real time: 05/12/2015 17:21:08 UTC
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.114:5060;received=83.78.103.73;branch=z9hG4bK7a448da1c46cbd9eb
To: <sip:[email protected];user=phone>;tag=h7g4Esbg_1609717534-1431444069619
From: <sip:[email protected]>;tag=43017e2dec
Call-ID: f4aaaa579520d79c
CSeq: 11560 INVITE
Contact: <sip:[email protected];transport=udp>
Record-Route: <sip:195.186.128.16;transport=udp;lr>
Supported: timer
Content-Type: application/sdp
Content-Length: 235
Session: Media
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE

v=0
o=BroadWorks 575383035 1 IN IP4 195.186.128.16
s=-
c=IN IP4 195.186.129.36
t=0 0
m=audio 12426 RTP/AVP 8 101 18
a=rtpmap:101 telephone-event/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=sendrecv


Rec #126 ===============
Up time: 04:16:42 (274602390 msec) Type: In
Real time: 05/12/2015 17:21:11 UTC
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.114:5060;received=83.78.103.73;branch=z9hG4bK7a448da1c46cbd9eb
To: <sip:[email protected];user=phone>;tag=h7g4Esbg_1609717534-1431444069619
From: <sip:[email protected]>;tag=43017e2dec
Call-ID: f4aaaa579520d79c
CSeq: 11560 INVITE
Contact: <sip:[email protected];transport=udp>
Record-Route: <sip:195.186.128.16;transport=udp;lr>
Supported: timer
Content-Type: application/sdp
Content-Length: 235
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE

v=0
o=BroadWorks 575383035 1 IN IP4 195.186.128.16
s=-
c=IN IP4 195.186.129.36
t=0 0
m=audio 12426 RTP/AVP 8 101 18
a=rtpmap:101 telephone-event/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=sendrecv

Bis jetzt konnte ich folgendes feststellen:
- der Origin (o) header ist bei astersik "root" und beim Avaya meine Nummer
- der Subject (s) header ist bei asterisk "Asterisk PBX xx.xx.x" und beim Avaya leer ("-")
- Beim Avaya wird immer die lokale IP "announced" und bei Astersik die externe
- Das "Remote Party-ID" konnte ich inzwischen auch bei Astersik hinkriegen (sendrpid=yes)

Gruss

Killbyt
 
Zuletzt bearbeitet:
Ich kann mir nicht vorstellen, dass es an der Adresse im Contact hängt. Zumal der Avaya das ja eigentlich falsch macht.

Was auffällt ist der unterschiedliche To Header, versuch mal als Host nur swisscom.ch einzustellen und bc1.ims.swisscom.ch falls notwendig als Proxy. Mag sein, dass Du die Register Anweisung auch anpassen musst, manche Provider erlauben abgehende Gespräche nur nach Registrierung von derselben Quell-Adresse.
 
So also, ich habe es jetzt hingekriegt das der Invite-Header nahezu identisch mit dem Avaya ist:
Code:
Reliably Transmitting (NAT) to 193.222.73.227:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 83.78.103.73:5059;branch=z9hG4bK19c35e50;rport
Max-Forwards: 70
From: <sip:[email protected]:5059>;tag=as02253025
To: <sip:[email protected]>
Contact: <sip:[email protected]:5059>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Wed, 13 May 2015 15:46:14 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "+4131xxxxxxx" <sip:[email protected]>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 260

v=0
o=root 2006623869 2006623869 IN IP4 83.78.103.73
s=Asterisk PBX 11.17.0
c=IN IP4 83.78.103.73
t=0 0
m=audio 10026 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

Doch leider ist die Antwort immernoch:
Code:
<--- SIP read from UDP:195.186.128.16:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 83.78.103.73:5059;received=83.78.103.73;rport=49155;branch=z9hG4bK19c35e50
To: <sip:[email protected]>;tag=h7g4Esbg_9czmel6rbe5flpckxwekeg5tzh46drgn
From: <sip:[email protected]:5059>;tag=as02253025
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 0

Folgendes habe ich auch noch versucht:
- Useragent wieder auf "Asterisk PBX" geändert ( War vorhin auf das Modem eingestellt, da ich erst gedacht hatte die Filtern nach Useragent)
- Die Konfiguration von Astersik auf "public-ip" gestellt und die lokale IP angegeben
- bc1.ims.swisscom.ch als outboundproxy konfiguriert (ist momentane Situation)

Gruss Killbyt

P.s ich danke schon jetzt für eure Hilfe!:cool:

##EDIT: Im Anhang findet sich noch der Invite mit lokaler IP, unterscheidet sich aber so weit ich gesehen habe bis eben auf die IP nicht....
 

Anhänge

  • local.txt.txt
    1.3 KB · Aufrufe: 2
Zuletzt bearbeitet:
So nach einer kleinen Pause habe ich mich wieder einmal ein bisschen dran gesetzt und das Problem gefunden! Der Swisscom-Server kann es nicht ausstehen, wenn der invite Request nicht von einem Standart Port kommt genau gesagt das:
Code:
From: <sip:[email protected]:5059>;tag=as7720c520
geht nicht.

Wenn ich den Port nun auf standart (5060) ändere, Antwortetet er mit: "Proxy auth required", sprich so gehts.

Nun das Problem ist, ich kann meine PBX nicht auf standart-Port laufen lassen, den dieser lässt sich auf unserem Router nicht Forwarden. Gibt es nun eine Möglichkeit den Port aus dem "From:" - Header zu kriegen?

Gruss

Killbyt
 
Problem Gelöst!

So, da ich jetzt endlich die Möglichkeit hatte die PBX auf Standartport laufen zu lassen, habe ich es auch zu 100% hingekriegt. Nun für alle die sich auch einmal die Zähne dran ausbeissen:

Ein paar Hinweise vorweg:
- Die Sip zugangsdaten lassen sich nur auf dem Standartport benutzen (ansonsten bei ausgehenden Anrufen "Forbidden").
- Offensichtlich hat Asterisk Probleme, die Domain "Swisscom.ch" richtig aufzulösen, dies muss mit einem Workaround umgangen werden (Hosts-Datei: Swisscom.ch 195.186.128.16 => entspricht bc1.ims.swisscom.ch)
- Die CallerID kann natürlich nicht beliebig gesetzt werden;)

Nun zu den Einstellungen:
PEER
Code:
user=+4131xxxxxxx
type=peer
srvlookup=yes
secret=passwort
outboundproxy=bc1.ims.swisscom.ch
nat=yes
insecure=invite,port
host=swisscom.ch
fromuser=+4131xxxxxxx
fromdomain=swisscom.ch
dtmfmode=auto
defaultuser=authusername!!!!
canreinvite=no
disallow=all
allow=alaw&ulaw&g729&gsm&slinear&ulaw

USER (Context: +4131xxxxxxx)
Code:
type=peer
host=bc1.ims.swisscom.ch
fromdomain=swisscom.ch
disallow=all
allow=alaw&ulaw&g729&gsm&slinear&ulaw

REGISTER
Code:
[email protected]:passwort:[email protected]/+4131xxxxxxx

So ich hoffe ich konnte hiermit dem einen oder andern weiterhelfen.

=>> Im Anhang ist noch die Ausgabe von "sip set debug peer XX", bei einem erfolgreichen ausgehenden Anruf.

Gruss Killbyt
 

Anhänge

  • INVITE_Swisscom.txt
    6.5 KB · Aufrufe: 16
Hallo Killbyt

Bereits seit einigen Tagen versuche ich, meine FreePBX einzurichten. Dank Deiner detailierten Anleitung ist mir endlich die Registrierung am Swisscom Server gelungen. Ebenfalls angemeldet ist auch ein IP Gigaset C470 Telefon. Leider gelingt es mir aber auch nach mehreren Versuchen nicht, ein Anruf zu tätigen oder zu empfangen. Beim Hinaustelefonieren erhalte ich nur ein Besetztzeichen und bei einem Anruf geht die FreePBX nicht ran. Hättest Du mir vielleicht noch einen Tipp wie Du alles weitere konfiguriert hast? Ich weiss nämlich echt nicht mehr, was ich noch versuchen könnte.

Mein Thread dazu:
http://www.ip-phone-forum.de/showthread.php?t=294433
 
Zuletzt bearbeitet von einem Moderator:
Hi Koretabs

Das keine Anrufe rein kommen, könnte ev. an einem NAT liegen. Hierzu sind folgende Punkte zu beachten:
-Lauft FreePBX im NAT Modus?
-Sind entsprechende Ports weitergeleitet, auch RTP Ports?
-Hast Du ev. eine Dynamische IP? So kann ein Dynamischer Hostname hinterlegt werden?

An deiner Stelle würde ich auch einmal den Console Output prüfen beim Reintelefonieren:
Code:
Per SSH auf die Maschine verbinden und anschliessend asterisk -rvvv
Jetzt einmal Anrufen und schauen ob überhaupt etwas passiert. Wenn ja liegt der Fehler zu irgendwo an deiner lokalen Konfiguration (z.B Unmöglicher Kontext, eine ungültige Destination...)

Für die Ausgehenden Anrufe einmal folgendes in die Console eingeben:
Code:
sip set debug peer XXXTRUNK-NAMEXXXX
Der spezifischische Output dieser Debug-Funktion kommt in dem Format daher:
Code:
<--- Transmitting (NAT) to 212.101.4.3:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.101.4.3;branch=z9hG4bKbb68.6474e3c4.0;received=212.101.4.3;rport=5060
From: <sip:[email protected]>;tag=25329583
To: <sip:[email protected]>;tag=as7ff6047d
Call-ID: 1494357194-24441426@MMI
CSeq: 1 CANCEL
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
(Ev. die Console ohne "v" Argument starten, ist ein bisschen übersichtlicher)

in diesem Output findest Du auch eventuelle Fehlermeldungen seitens Swisscom Server.

Ich hoffe das bringt dich zumindest ein bisschen weiter.

Gruss Killbyt
 
Zuletzt bearbeitet von einem Moderator:
Hallo killbyt

Danke für Deine Antwort. Bei mir funktioniert nun alles, mit einer einzigen Ausnahme. Ich habe 3 Rufnummern welche ich in freePBX erfolgreich registriert habe. Eingehende Anrufe funktionieren problemlos. Möchte ich jedoch einen Anruf tätigen, gehen sämtliche Anrufe auf der selben Rufnummer raus. Ich suche nun schon seit Tagen nach diesem Fehler, kann ihn aber nicht finden. Hast Du mir da noch einen Tipp?
 
Hi Koreatabs

Dies ist vermutlich kein Fehler. Das Verhalten bei ausgehenden Anrufen kannst Du unter "Outbound Routes" definieren(z.B mit einem Deal-Prefix).

Gruss

Killbyt
 
Hmmm. Und was müsste ich dort dann eintragen? Aktuell habe ich nur das Feld "match pattern" mit X. gefüllt.

- - - Aktualisiert - - -

Komisch ist aber, dass die anderen Teilnehmer nicht ihre eigene Wählregel verwenden, sondern die des einen Teilnehmers, wessen Nummer auf allen Geräten erscheint. Lösche ich nämlich die Wählregel eines dieser Teilnehmer, kann ich nach wie vor nach draussen telefonieren. :(
 
Und was müsste ich dort dann eintragen? Aktuell habe ich nur das Feld "match pattern" mit X. gefüllt.

Ganz hinten im letzten Feld nach dem / kommt die Nummer bzw. CID der Nebenstelle rein, für die die Wahlregel gelten soll.
 
Hallo rentier-s

Ich denke das Problem liegt woanders. Denn wie zuvor beschrieben, scheinen sämtliche Teilnehmer die outbound Routes desjenigen Teilnehmers zu verwenden, bei welchem die ausgehende Rufnummer angezeigt wird. Das bestätigt sich, wenn ich wie von Dir beschrieben, die Rufnummer im CID eintrage. Dann kann ich nämlich nur noch mit denjenigen Teilnehmern nach draussen telefonieren, welche diesem Trunk zugewiesen sind. Die anderen hören dann "your call cannot be completed as dialed". Selbst wenn ich die Outbound Routes der anderen Teilnehmer lösche, können diese weiterin über die entsprechenden Outbound Routes nach draussen telefonieren. Deshalb habe ich angenommen, dass der Fehler bereits in den Einstellungen des Trunks besteht.

Aktuell bin ich völlig ratlos.
 
wenn ich wie von Dir beschrieben, die Rufnummer im CID eintrage. Dann kann ich nämlich nur noch mit denjenigen Teilnehmern nach draussen telefonieren, welche diesem Trunk zugewiesen sind.

Ja, aber das soll doch auch so sein :gruebel:

Du hast für jede Deiner Rufnummern einen Trunk angelegt. Dort kannst Du auch die jeweilige outbound CID einstellen. Die Nebenstellen bekommen dann entsprechende outbound routes über das CID Feld (wenn es so heißt) zugewiesen, so dass für jede Nebenstelle nur die outbound route greift, die auf den Trunk mit der der jeweiligen Nebenstelle zugehörigen Rufnummer zeigt.
 
Macht alles Sinn was Du schreibst. Meiner Meinung nach habe ich das auch genauso umgesetzt. Trotzdem funktioniert es nicht. Aktuell höre ich nur noch das Besetzzeichen. Ich habe übrigens für jede Rufnummer einen eigenen Trunk eingerichtet.

Ich publiziere deshalb hier mal meine gesammten Einstellungen. Vielleicht siehst Du was ich falsch mache?

General

- Trunk Name: Frei gewählt

- Hide Caller ID: NO
- Outbound CallerID: xxxxx69

- CID Options: Allow Any CID
- Maximum Channels: leer

- Asterisk Trunk Dial Options: System
- Continue if Busy: No
- Disable Trunk: No

Dial Number Manipulation Rules
Habe ich nichts verändert

sip Settings
Trunk Name: Habe ich Swisscom
PEER Details:

user=+4144xxxxxxx
type=peer
srvlookup=yes
secret=DeinPasswort
outboundproxy=bc1.ims.swisscom.ch
nat=yes
insecure=invite,port
host=swisscom.ch
fromuser=+4144xxxxxxx
fromdomain=swisscom.ch
dtmfmode=auto
[email protected]
canreinvite=no
disallow=all
allow=alaw&ulaw&g729&gsm&slinear&ulaw

User Context: +4144xxxxxxx
USER Details:
type=peer
host=bc1.ims.swisscom.ch
fromdomain=swisscom.ch
disallow=all
allow=alaw&ulaw&g729&gsm&slinear&ulaw

Register String:
[email protected]: DeinPasswort: [email protected]/+4144xxxxxxx

Extensions

Display Name: xxxxx69

CID: xxxxx69
Secret: xxxxx69

Hier verbinde ich zur telpho


Inbound Routes


General
Description: Swisscom
DID Number: +4144xxxxxxx
CallerID Number: habe ich leer gelassen
CID Priority Route: No
Alert Info: None
Ringer Volume Override: None
CID name prefix: leer
Music On Hold: Default
Set Destination: Extensions xxxxx69


Advanced
Keine Änderungen vorgenommen

Privacy
Keine Änderungen vorgenommen

Other
Call Recording
Könnt Ihr wählen falls ihr das wünscht

Nun gehts an die Outbound Routes

Route Name: Bei mir "Swisscom"
Route CID: xxxxx69

Override Extension: No
Route Password: leer

Route Type: Nichts ausgewählt
Music On Hold? Default
Route Position: No change
Trunk Sequence for Matched Routes: xxxxx69

Optional Destination on Congestion: Normal Congestion

Register -> Dial Patterns
( ) | [X./xxxxx69]

Import / Export Patterns: Keine Änderungen
Additional Settings: Keine Änderungen

Dabei sollte ich noch erwähnen, dass es mit identischen Einstellungen beim ersten Trunk funktioniert.
 
Zuletzt bearbeitet:
Keiner eine Idee wo ich ansetzen könnte'
 
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.