Hallo Matthias,

ich versuchs mal zusammen zu bekommen, ist ja schon eine Weile her. Leider nervt das Loadbalancing der Telekom extrem.

tel.t-online.de löst bei mir über die externen Rootserver auf 217.0.23.100 auf.

Wir haben auf jeder Anlage einen eigenen BIND in Standardkonfiguration laufen.

Als das Problem bestand, hatten wir einen Router mit einem DNSMASQ am laufen. Dieser hat die DNS Anfragen an die Telekom-DNS Server geFORWARDed.

Im Asterisk lief das dann folgendermaßen:

REGISTER/INVITE an den Server welcher unter "_sip._udp.tel.t-online.de" aufgelöst wurde

Asterisk löst danach neu auf, auf "tel.t-online.de"

"_sip._udp.tel.t-online.de" entsprach nicht "tel.t-online.de"

Das Gespräch kommt nicht zu stande, da dieser Server nichts von dem REGISTER weiß, daher meldet dieser FORBIDDEN.

bei der Auflösung über BIND/Rootserver löste "_sip._udp.tel.t-online.de" auf die selbe Adresse auf wie "tel.t-online.de".

Daher reichte die Installation vom BIND und das umlegen der resolv.conf auf 127.0.0.1

Man konnte das sehr schön im SIPLOG vom Asterisk sehen (sip set debug on).

Ich hoffe ich konnte helfen.

MFG Christian

Anbei noch die sip-conf für den telekom peer (verhindert auch andere BUGs):

[Telekom]
type=peer
insecure=invite
username=anonymous@t-online.de
secret=nopass
host=tel.t-online.de                                                                                                                 
fromdomain=tel.t-online.de                                                                                                           
canreinvite=no                                                                                                                       
realm=tel.t-online.de                                                                                                                
canreinvite=no                                                                                                                       
directmedia=no
nat=no                                                                                                                               
qualify=yes
context=default                                                                                                                      
insecure=port,invite
session-timers=refuse
dtmfmode=inband
videosupport=no
ignoresdpversion=yes

Hallo Christian,

danke für deine schnelle Antwort. Ich denke, ich habe es jetzt hinbekommen. Der Trunk steht jetzt seit seit mehr als 48h stabil ohne Abbrüche.

Am Ende hast du mich auf den richtigen Weg gebracht. Das Problem ist, dass wenn die 3cx den Service Locator Record "_sip._udp.tel.t-online.de" anfragt, gibt es 2 Namen zurück. Der erste wird zwar präfertiert aber es kommt dennoch ab und zu vor, dass der 2. Server gefragt wird. Dieser weiß dann offensichtlich nichts von der Sitzung und gibt "403 forbidden" zurück.

nslookup

> set type=srv

> _sip._udp.tel.t-online.de

Server: 172.19.xxx.xxx (mein Nameserver)

Address: 172.19.xxx.xxx#53

Abfrage des SRV Records ergibt 2 Hosts

Non-authoritative answer:

_sip._udp.tel.t-online.de service = 0 5 5060 ims001.voip.t-ipnet.de.

_sip._udp.tel.t-online.de service = 1 5 5060 ims002.voip.t-ipnet.de.

Kurz die IP checken

Non-authoritative answer:

ims001.voip.t-ipnet.de canonical name = b-epp-001.isp.t-ipnet.de.

Name: b-epp-001.isp.t-ipnet.de

Address: 217.0.23.100

> ims002.voip.t-ipnet.de

Server: 172.19.xxx.xxx

Address: 172.19.xxx.xxx#53

Non-authoritative answer:

ims002.voip.t-ipnet.de canonical name = h2-epp-801.isp.t-ipnet.de.

Name: h2-epp-801.isp.t-ipnet.de

Address: 217.0.128.132

> ims002.voip.t-ipnet.de

Server: 172.19.xxx.xxx

Address: 172.19.xxx.xxx#53

Ich habe mir jetzt so geholfen, dass ich 

ims001.voip.t-ipnet.de.

ims002.voip.t-ipnet.de.

in meine /etc/hosts (unter Windows einfach im "windows/system32/drivers/etc/hosts") die beiden Server eingetragen habe und auf die selbe IP verweise (217.0.23.100).

Man kann natürlich auch auf seinem DNS Server eine Zone voip.t-ipnet.de anlegen und dort die beiden A-records pflegen.

Ich hoffe, die T-kom ändert nicht demnächst die IP Adressen

Viele Grüße

Matthias