Asterisk hinter fbf: Nach reload kommt "403 forbidden" bei 1und1

[meimi039]

Hallo Leute!

Nach langen Tests mit SIPGATE habe ich einige Accounts auf 1und1 umstellen wollen. Dabei stoße ich nun auf ein neues Verhalten und brauche da mal eure Unterstützung.
Wenn ich Asterisk starte und die Nummer 333333 (so nenne ich sie mal hier) von extern anrufe, kann ich mir ein Wavefile zum testen anhören.
Wenn ich dann ein "module reload" absetze, erhalte ich bei erneutem Anruf ein "SIP/2.0 403 Forbidden.". Das will einfach nicht in meinen Kopf.
Kann da mal jemand drüber schauen:

Das ist der Anruf nach dem start von Asterisk:

U 212.227.19.130:5060 -> 192.168.110.1:5061
[COLOR="Red"]INVITE[/COLOR] sip:[email protected]:5061 SIP/2.0.
Record-Route: <sip:212.227.19.130;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.141;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.131;lr=on;ftag=69655858>.
Record-Route: <sip:217.188.58.181;lr=on;ftag=69655858>.
Via: SIP/2.0/UDP 212.227.19.130;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.1.
Via: SIP/2.0/UDP 212.227.19.141;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.1.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK6511.b5990015.0.
Via: SIP/2.0/UDP 217.188.58.181;branch=z9hG4bK6511.b5990015.0.
Via: SIP/2.0/UDP 1und1-3.sip.mgc.voip.telefonica.de:5060;received=193.189.245.202;branch=z9hG4bKterm-afd85b-+49XXXX333333-+499999999-52832.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=69655858.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>.
Call-ID: 6941a789-e80d144-569dc033-212a@1und1-3.sip.mgc.voip.telefonica.de.
CSeq: 1 [COLOR="#ff0000"]INVITE[/COLOR].
Max-Forwards: 12.
Supported: timer.
Session-Expires: 1800.
Min-SE: 1800.
Contact: +499999999 <sip:[email protected]:5060;transport=udp>.
Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE.
P-Asserted-Identity: +4999999999 <sip:[email protected];user=phone>.
Content-Type: application/sdp.
Content-Length: 677.
.
v=0.
o=- 1825333 0 IN IP4 62.53.226.61.
s=Cisco SDP 0.
c=IN IP4 62.53.226.61.
t=0 0.
m
#
U 192.168.110.1:5061 -> 212.227.19.130:5060
[COLOR="#ff0000"]SIP/2.0 100 Trying[/COLOR].
Via: SIP/2.0/UDP 212.227.19.130;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.1;received=212.227.19.130.
Via: SIP/2.0/UDP 212.227.19.141;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.1.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK6511.b5990015.0.
Via: SIP/2.0/UDP 217.188.58.181;branch=z9hG4bK6511.b5990015.0.
Via: SIP/2.0/UDP 1und1-3.sip.mgc.voip.telefonica.de:5060;received=193.189.245.202;branch=z9hG4bKterm-afd85b-+49XXXX333333-+499999999-52832.
Record-Route: <sip:212.227.19.130;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.141;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.131;lr=on;ftag=69655858>.
Record-Route: <sip:217.188.58.181;lr=on;ftag=69655858>.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=69655858.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>.
Call-ID: 6941a789-e80d144-569dc033-212a@1und1-3.sip.mgc.voip.telefonica.de.
CSeq: 1 [COLOR="#ff0000"]INVITE[/COLOR].
User-Agent: AVM FRITZ!Box WLAN 7990 77.04.96 (Jan 27 2011).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:[email protected]:5061>.
Content-Length: 0.
.

#
U 192.168.110.1:5061 -> 212.227.19.130:5060
[COLOR="#ff0000"]SIP/2.0 200 OK.[/COLOR]
Via: SIP/2.0/UDP 212.227.19.130;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.1;received=212.227.19.130.
Via: SIP/2.0/UDP 212.227.19.141;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.1.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK6511.b5990015.0.
Via: SIP/2.0/UDP 217.188.58.181;branch=z9hG4bK6511.b5990015.0.
Via: SIP/2.0/UDP 1und1-3.sip.mgc.voip.telefonica.de:5060;received=193.189.245.202;branch=z9hG4bKterm-afd85b-+49XXXX333333-+499999999-52832.
Record-Route: <sip:212.227.19.130;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.141;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.131;lr=on;ftag=69655858>.
Record-Route: <sip:217.188.58.181;lr=on;ftag=69655858>.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=69655858.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>;tag=as2ce63b51.
Call-ID: 6941a789-e80d144-569dc033-212a@1und1-3.sip.mgc.voip.telefonica.de.
CSeq: 1 [COLOR="#ff0000"]INVITE[/COLOR].
User-Agent: AVM FRITZ!Box WLAN 7990 77.04.96 (Jan 27 2011).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:[email protected]:5061>.
Content-Type: application/sdp.
Content-Length: 284.
.
v=0.
o=root 11892 11892 IN IP4 89.14.197.95.
s=session.
c=IN IP4 89.14.197.95.
t=0 0.
m=audio 16588 RTP/AVP 8 0 3 99.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:99 telephone-event/8000.
a=fmtp:99 0-16.
a=s
#
U 212.227.19.130:5060 -> 192.168.110.1:5061
[COLOR="#ff0000"]ACK [/COLOR]sip:[email protected]:5061 SIP/2.0.
Record-Route: <sip:212.227.19.130;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.141;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.131;lr=on;ftag=69655858>.
Record-Route: <sip:217.188.58.181;lr=on;ftag=69655858>.
Via: SIP/2.0/UDP 212.227.19.130;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.3.
Via: SIP/2.0/UDP 212.227.19.141;branch=z9hG4bK6511.f8be6c8546017afb0a74b34167d436ed.3.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK6511.b5990015.2.
Via: SIP/2.0/UDP 217.188.58.181;branch=z9hG4bK6511.b5990015.2.
Via: SIP/2.0/UDP 1und1-3.sip.mgc.voip.telefonica.de:5060;received=193.189.245.202;branch=z9hG4bKterm-afd85b-+49XXXX333333-+499999999-8084.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=69655858.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>;tag=as2ce63b51.
Call-ID: 6941a789-e80d144-569dc033-212a@1und1-3.sip.mgc.voip.telefonica.de.
CSeq: 1 [COLOR="#ff0000"]ACK[/COLOR].
Max-Forwards: 12.
Content-Length: 0.
P-hint: rr-enforced.
.

#
U 212.227.19.130:5060 -> 192.168.110.1:5061
[COLOR="#ff0000"]BYE[/COLOR] sip:[email protected]:5061 SIP/2.0.
Record-Route: <sip:212.227.19.130;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.141;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.131;lr=on;ftag=69655858>.
Record-Route: <sip:217.188.58.181;lr=on;ftag=69655858>.
Via: SIP/2.0/UDP 212.227.19.130;branch=z9hG4bK3511.64417f7065461695c195bfea00d73b54.0.
Via: SIP/2.0/UDP 212.227.19.141;branch=z9hG4bK3511.64417f7065461695c195bfea00d73b54.0.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK3511.410ef666.0.
Via: SIP/2.0/UDP 217.188.58.181;branch=z9hG4bK3511.410ef666.0.
Via: SIP/2.0/UDP 1und1-3.sip.mgc.voip.telefonica.de:5060;received=193.189.245.202;branch=z9hG4bKterm-afd85b-+49XXXX333333-+499999999-78794.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=69655858.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>;tag=as2ce63b51.
Call-ID: 6941a789-e80d144-569dc033-212a@1und1-3.sip.mgc.voip.telefonica.de.
CSeq: 2 [COLOR="#ff0000"]BYE[/COLOR].
Max-Forwards: 66.
Supported: timer.
Content-Length: 0.
P-hint: rr-enforced.
.

#
U 192.168.110.1:5061 -> 212.227.19.130:5060
[COLOR="#ff0000"]SIP/2.0 200 OK[/COLOR].
Via: SIP/2.0/UDP 212.227.19.130;branch=z9hG4bK3511.64417f7065461695c195bfea00d73b54.0;received=212.227.19.130.
Via: SIP/2.0/UDP 212.227.19.141;branch=z9hG4bK3511.64417f7065461695c195bfea00d73b54.0.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK3511.410ef666.0.
Via: SIP/2.0/UDP 217.188.58.181;branch=z9hG4bK3511.410ef666.0.
Via: SIP/2.0/UDP 1und1-3.sip.mgc.voip.telefonica.de:5060;received=193.189.245.202;branch=z9hG4bKterm-afd85b-+49XXXX333333-+499999999-78794.
Record-Route: <sip:212.227.19.130;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.141;lr=on;ftag=69655858>.
Record-Route: <sip:212.227.19.131;lr=on;ftag=69655858>.
Record-Route: <sip:217.188.58.181;lr=on;ftag=69655858>.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=69655858.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>;tag=as2ce63b51.
Call-ID: 6941a789-e80d144-569dc033-212a@1und1-3.sip.mgc.voip.telefonica.de.
CSeq: 2 [COLOR="#ff0000"]BYE[/COLOR].
User-Agent: AVM FRITZ!Box WLAN 7990 77.04.96 (Jan 27 2011).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:[email protected]:5061>.
Content-Length: 0.
.

Das sieht für mich erstmal Bilderbuchmäßig aus.

Jetzt:

Connected to Asterisk 1.4.21.2~dfsg-3ubuntu2.1 currently running on homeserver (pid = 11892)
homeserver*CLI> [COLOR="#ff0000"]module reload[/COLOR]

Neuer Anruf:

root@homeserver:~ #  ngrep -W byline port 5061
interface: eth0
filter: (ip or ip6) and ( port 5061 )

U 212.227.19.136:5060 -> 192.168.110.1:5061
[COLOR="#ff0000"]INVITE[/COLOR] sip:[email protected]:5061 SIP/2.0.
Record-Route: <sip:212.227.19.136;lr=on;ftag=986443090>.
Record-Route: <sip:212.227.19.143;lr=on;ftag=986443090>.
Record-Route: <sip:212.227.19.131;lr=on;ftag=986443090>.
Record-Route: <sip:195.71.47.146;lr=on;ftag=986443090>.
Via: SIP/2.0/UDP 212.227.19.136;branch=z9hG4bK1e96.d5245e7848fa4530588c8c00aae68f32.1.
Via: SIP/2.0/UDP 212.227.19.143;branch=z9hG4bK1e96.d5245e7848fa4530588c8c00aae68f32.1.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK1e96.4f7a7fd.0.
Via: SIP/2.0/UDP 195.71.47.146;branch=z9hG4bK1e96.4f7a7fd.0.
Via: SIP/2.0/UDP 1und1-8.sip.mgc.voip.telefonica.de:5060;received=193.189.245.204;branch=z9hG4bKterm-b5b394-+49XXXX333333-+499999999-60885.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=986443090.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>.
Call-ID: 5b8bcb1d-615daebe-7d6f6877-40d5@1und1-8.sip.mgc.voip.telefonica.de.
CSeq: 1 [COLOR="Red"]INVITE[/COLOR].
Max-Forwards: 12.
Supported: timer.
Session-Expires: 1800.
Min-SE: 1800.
Contact: +499999999 <sip:[email protected]:5060;transport=udp>.
Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE.
P-Asserted-Identity: +4999999999 <sip:[email protected];user=phone>.
Content-Type: application/sdp.
Content-Length: 677.
.
v=0.
o=- 1825489 0 IN IP4 62.53.226.61.
s=Cisco SDP 0.
c=IN IP4 62.53.226.61.
t=0 0.

#
U 192.168.110.1:5061 -> 212.227.19.136:5060
[COLOR="#ff0000"][B]SIP/2.0 403 Forbidden[/B][/COLOR].
Via: SIP/2.0/UDP 212.227.19.136;branch=z9hG4bK1e96.d5245e7848fa4530588c8c00aae68f32.1;received=212.227.19.136.
Via: SIP/2.0/UDP 212.227.19.143;branch=z9hG4bK1e96.d5245e7848fa4530588c8c00aae68f32.1.
Via: SIP/2.0/UDP 212.227.19.131;branch=z9hG4bK1e96.4f7a7fd.0.
Via: SIP/2.0/UDP 195.71.47.146;branch=z9hG4bK1e96.4f7a7fd.0.
Via: SIP/2.0/UDP 1und1-8.sip.mgc.voip.telefonica.de:5060;received=193.189.245.204;branch=z9hG4bKterm-b5b394-+49XXXX333333-+499999999-60885.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=986443090.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>;tag=as7473f2f8.
Call-ID: 5b8bcb1d-615daebe-7d6f6877-40d5@1und1-8.sip.mgc.voip.telefonica.de.
CSeq: 1 INVITE.
User-Agent: AVM FRITZ!Box WLAN 7990 77.04.96 (Jan 27 2011).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Length: 0.
.

#
U 212.227.19.136:5060 -> 192.168.110.1:5061
[COLOR="#ff0000"]ACK[/COLOR] sip:[email protected]:5061 SIP/2.0.
Record-Route: <sip:212.227.19.136;lr=on;ftag=986443090>.
Via: SIP/2.0/UDP 212.227.19.136;branch=z9hG4bK1e96.d5245e7848fa4530588c8c00aae68f32.1.
Via: SIP/2.0/UDP 212.227.19.143;branch=z9hG4bK1e96.d5245e7848fa4530588c8c00aae68f32.1.
From: +499999999 <sip:[email protected]:5060;user=phone>;tag=986443090.
Call-ID: 5b8bcb1d-615daebe-7d6f6877-40d5@1und1-8.sip.mgc.voip.telefonica.de.
To: +49XXXX333333 <sip:[email protected]:5060;user=phone>;tag=as7473f2f8.
CSeq: 1 ACK.
Max-Forwards: 69.

User-Agent: OpenSER (1.3.4-tls (i386/linux)).
Content-Length: 0.
.

root@homeserver:~ #

Hier meine sip.conf:

[general]
context=incomming
bindport=5061
bindaddr=0.0.0.0
localnet=192.168.0.0/255.255.0.0
tos_sip=cs3
tos_audio=ef
tos_video=af41
externip=dyndns
externrefresh=10
qualify=200
srvlookup=yes
language=de
;callerid=meimi039
useragent=AVM FRITZ!Box WLAN 7990 77.04.96 (Jan 27 2011) ; just kidding
nat=yes
allowguest=no
; type=peer
insecure=port,invite
;--------------------------------------------------------------------

register => 49XXXX111111:[email protected]/111111
register => 49XXXX222222:[email protected]/222222
register => 49XXXX333333:[email protected]/333333
register => 9444444:[email protected]/444444

;####################################################################
[111111]
; 1und1-main 0XXXX111111
context=incomming
type=peer
username=49XXXX111111
secret=passwort
host=sip.1und1.de
fromuser=49XXXX111111
fromdomain=sip.1und1.de
canreinvite=no
dtmfmode=auto
disallow=all
allow=alaw
allow=ulaw
allow=gsm
;allow=ilbc
;allow=g726
;allow=g729
nat=yes
insecure=port,invite
tos=0x18

[222222]
; 1und1-main 0XXXX222222
context=incomming
type=peer
username=49XXXX222222
secret=passwort
host=sip.1und1.de
fromuser=49XXXX222222
fromdomain=sip.1und1.de
canreinvite=no
dtmfmode=auto
disallow=all
allow=alaw
allow=ulaw
allow=gsm
;allow=ilbc
;allow=g726
;allow=g729
nat=yes
insecure=port,invite
tos=0x18

[333333]
; 1und1-main 0XXXX333333
context=incomming
type=peer
username=49XXXX333333
secret=passwort
host=sip.1und1.de
fromuser=49XXXX333333
fromdomain=sip.1und1.de
canreinvite=no
dtmfmode=auto
disallow=all
allow=alaw
allow=ulaw
allow=gsm
;allow=ilbc
;allow=g726
;allow=g729
nat=yes
insecure=port,invite
tos=0x18

[444444]
; 0XXXX444444 bei sipgate
context=incomming
type=peer
username=9444444
secret=passwort
host=sipgate.de
fromuser=9444444
fromdomain=sipgate.de
canreinvite=no
dtmfmode=rfc2833
disallow=all
allow=ulaw
nat=yes
insecure=port,invite
tos=0x18

Und die extensions.ael:

context incomming {
	333333 => {
		NoOp(TestMSN incomming);
		Answer();
		Wait(1);
		Playback(/tmp/weather);
		Wait(2);
		Hangup();
	}
}

Das Wetter erzeuge ich per cron (wen es interessiert):

wget -qO - 'http://www.tagesschau.de/mobil/index-mobilWetter.jsp?pic=0' | grep -vE '<|>|/|&' | nice -n 19 espeak --stdin -vde+m4 -p 30 -s 140 -w /tmp/w.wav ; nice -n 19 sox /tmp/w.wav -r 8000 /tmp/weather.wav dither ; chmod 777 /tmp/weather.wav ; rm /tmp/w.wav

Ich konnte dieses Verhalten durch Ändern der erlaubten Codecs provozieren. Nun gehts aber beim frisch gestarteten * aber nach einiger Zeit eben nicht mehr.
Was ändert sich hier über die Zeit?

 

[jacekw4101]

Hallo,

ich kann Dir leider nicht helfen. Jedoch möchte ich gerne wissen, wo Du SOX (auf der Fritz!Box) her hast? (selbstkompiliert?). Ich bekomme es nicht kompiliert...
[edit]
Ups, leider übersehen.

Gruß, Jacek

 

[meimi039]

Das ist kein Fritzbox-thread. Da ist der sox-part auch nicht nötig, da espeak alles in 8kHz ausgibt.

 

[meimi039]

Es gibt einen Sachstand:
Mir fällt auf, daß die FB immer nur mit 212.227.19.130 redet. Das ist die erste IP, die sie unter sip.1und1.de auflöst. Anrufe kommen dort auch immer von der .130 an.
Asterisk redet mit allen Loadbalancern von Telefonica. Erstaunlicherweise kommt der Anruf von 212.227.19.136 - der aber kein alias für sip.1und1.de ist! Asterisk hat trotzdem beim Registrieren mit ihm gesprochen.

Kann mal jemand prüfen, was eine FB macht, wenn sie die erste IP - also 212.227.19.130 - nicht mehr erreichen kann?

 

[Fonetiker]

Service-Lookup

Hi!

»Erstaunlicherweise kommt der Anruf von 212.227.19.136 - der aber kein alias für sip.1und1.de ist!«

Nein, kein Namens-Alias (im DNS-Sinn), aber eine Adresse (+PortNr) die sip.1und1.de fuer den Service _sip._udp (ist wohl selbsterklaerend) offeriert. (Unterstriche sind keine gültigen Bestandteile von Hostnamen, und wurden wohl deshalb als Prefixe zur Abtrennung gewählt.)

Eine FB macht vielleicht keine SRV-Lookups (* srvlookup=yes).
____

Was ein normale DNS-Anfrage für ...136/sipbalance1-0.1und1.de liefert, weißt Du ja, also hier nur dieser:

# ein (DNS-)SRV-Lookup

PROMPT:> nslookup -type=SRV _sip._udp.sip.1und1.de
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
_sip._udp.sip.1und1.de service = 0 0 5060 sipbalance2-1.1und1.de.
_sip._udp.sip.1und1.de service = 0 0 5060 sipbalance2-2.1und1.de.
_sip._udp.sip.1und1.de service = 0 0 5060 sipbalance1-0.1und1.de.
_sip._udp.sip.1und1.de service = 0 0 5060 sipbalance1-1.1und1.de.
_sip._udp.sip.1und1.de service = 0 0 5060 sipbalance1-2.1und1.de.
_sip._udp.sip.1und1.de service = 0 0 5060 sipbalance2-0.1und1.de.

____
Soweit zu deiner DNS-Verwunderung, vielleicht hilft's
____

Mich erstaunt, warum sich nach einem module reload die IPA ändert:

To: +49XXXX333333 <sip:[email protected]:5060;user=phone>.

To: +49XXXX333333 <sip:[email protected]:5060;user=phone>.
____

Frage:

Bleibt denn das Forbidden bestehen (also *-Neustart nötig), oder klappt es wieder bei weiteren Anrufen? Du schreibst schreibst eingangs nur von »module reload«, zum Schluss aber auch:

»Ich konnte dieses Verhalten durch Ändern der erlaubten Codecs provozieren. Nun gehts aber beim frisch gestarteten * aber nach einiger Zeit eben nicht mehr.
Was ändert sich hier über die Zeit?«

Also nach längerer Zeit auch ohne »module reload«?

___

Sonstige Ideen:

Zum testen mal Gast-Anrufe in der sip.conf erlauben.

Mal die Registrierung in die [section] bringen, ein callbackextension=333333 ergänzen (siehe Beispiel-sip.conf) sollte reichen, und das
register => 49XXXX333333[email protected]/333333
weg lassen.

Gruß F.

 

[meimi039]

Super erster Beitrag hier im Forum. Erstmal herzlich willkommen hier und danke für die Aufklärung.
Ein module reload erlaubte immer mal wieder einen Anruf eingehend... dann aber wieder forbidden.
Ich habe inzwischen natürlich für jeden Balancer einen Account angelegt. Nun gehts.

Die Frage, die sich mir jetzt stellt ist: Wenn ich im default-context context=incomming definiert habe, dann müssten doch eingehende Anrufe, deren IP nicht bekannt sind, dort landen - also letztlich in incomming.
Das war wohl nicht so. Denn seit ich die ganzen Accounts angelegt habe gehts ja.
Da habe ich wohl noch was übersehen. Dabei könnte ich ENUM gleich mit erschlagen.

Also: Was muß ich machen, um mir die Account-Flut zu ersparen und ENUM gleich mit zu erledigen?

 

[Fonetiker]

Namensraeume

»Wenn ich im default-context context=incomming definiert habe, dann müssten doch eingehende Anrufe, deren IP nicht bekannt sind, dort landen - also letztlich in incomming.«

Ja, wenn es hier steht

[general]
context=incomming

hättest Du es bei den einzelnen Accounts auch nicht mehr schreiben müssen. Aber deinen * darf doch nicht einfach irgend wer anrufen, da steht ja auch

allowguest=no

____

Account-Flut: Du benutzt nun hoffentlich Templates(!), denn 3 mal 1und1 mal einige Balancer = ganz schön viel Schreibarbeit.

Könnte es sein, dass sich die übertragene Nummer
From: +499999999 <sip:[email protected]...
mit irgend was beißt? Hast Du z.B (intern) ein Telefon mit 8888 eingerichtet, und nun käme <sip: [email protected]...> herein, würde * den Ruf abweisen, in messages stände:
... NOTICE[20207] chan_sip.c: Failed to authenticate device "8888" <sip:8888@1und1...
Nun gleich mal die Frage, was steht bei dir in messages?

Vielleicht doch mal statt [333333] ein

[ext-account-1u1-03]
;; das erspart register => 49XXXX333333:.../333333
callbackextension = 333333
...
probieren?

So, ich habe mal bei mir geschaut, ich bin nicht von Balancern betroffen, zumindest bleiben sie wohl seit Monaten transparent hinter einer IPA versteckt. In meiner sip.conf steht aber [ext-account-ARC] und bei [ext-account-SG] kann ich im Moment auch nichts wechselhaftes entdecken. Bei eigenen undefinierten IPA steht
host = dynamic
aber wuerde das wirklich bei Balancern (also dauerndem Wechsel) helfen? Hmm, erstmal keine Idee mehr.
____

ENUM (Was hat es mit der Account-Flut zu tun?)

Wenn Du möchtest, dass dein * direkt erreichbar ist, müsstest Du ja Anrufe von jedermann in deiner sip.conf zulassen, d.h., ohne dass der Anrufer einen speziellen Account auf deinem * hat. FBs machen das in den meisten Konfigurationen (1u1), ein <sip:49OrtsnetzDeine1u1nummer@FBox-DynDNS-IP> ließe es also bei dir bimmeln. Ein * sagt aber ("normal konfiguriert") Forbidden.
Diese Jedermann-Anrufe wurde ich aber schon in einen speziellen Kontext einleiten, denn für die übertragene Nummer garantiert dann auch kein Provider mehr.

Nimm also einfach ein IP(Soft)-Telefon (ohne es am * zu registrieren!) und probiere, wenn das klappt, solltest Du dann also auch per ENUM erreichbar sein.

Wenn Du Anrufe von jedermann zulässt, dürften ja auch die Rufe deiner Provider nicht mehr verboten werden. Schön wäre es aber trotzdem, heraus zu bekommen, woran es nun lag, dass diese dich trotz Peer-Account nicht anrufen durften.

Gruß F.

 

[meimi039]

Hallo Fonetiker!

Seit Erstellung diese Freds ist natürlich einiges an Erkenntnis vergangen. Daher hat sich die sip.conf hübsch verändert.
Aber ich freue mich sehr, einen kompetenten Ansprechpartner zu haben!

Das mit der callbackextension scheint in 1.4 noch nicht vorhanden zu sein. Er meldet zwar keinen Fehler, ist aber auch nicht registriert (Oder habe ich was nicht verstanden?)

Ich habe folgendes in der sip.conf, um eingehende Gespräche zu erlauben:

[general]
type=friend
context=incomming
bindport=5061
bindaddr=0.0.0.0
localnet=192.168.0.0/255.255.0.0
nat=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
externip=dyndns
externrefresh=10
qualify=200
srvlookup=yes
language=de
callerid=meimi039
useragent=AVM FRITZ!Box WLAN 7990 77.04.96 (Jan 27 2011) ; just kidding
allowguest=yes
insecure=port,invite
;-------------------------------------------------------------------- 

[1und1](!)
type=friend
nat=yes
disallow=all
allow=alaw
allow=ulaw
;allow=g729
allow=g726
allow=gsm
host=sip.1und1.de
fromdomain=1und1.de
qualify=yes
insecure=port,invite
tos=0x18
;caninvite=no
canreinvite=no
dtmfmode=auto
language=de

[1und1-1-1](1und1)
host=sipbalance1-1.1und1.de 

[1und1-1-2](1und1)
host=sipbalance1-2.1und1.de 

[1und1-2-1](1und1)
host=sipbalance2-1.1und1.de 

[1und1-2-2](1und1)
host=sipbalance2-2.1und1.de 

[1und1-3-1](1und1)
host=sipbalance3-1.1und1.de 

[1und1-3-2](1und1)
host=sipbalance3-2.1und1.de 

[1und1-4-1](1und1)
host=sipbalance4-1.1und1.de 

[1und1-4-2](1und1)
host=sipbalance4-2.1und1.de 

[1und1-5-1](1und1)
host=sipbalance5-1.1und1.de 

[1und1-5-2](1und1)
host=sipbalance5-2.1und1.de 

[1und1-6-1](1und1)
host=sipbalance6-1.1und1.de 

[1und1-6-2](1und1)
host=sipbalance6-2.1und1.de 

[1und1-7-1](1und1)
host=sipbalance7-1.1und1.de 

[1und1-7-2](1und1)
host=sipbalance7-2.1und1.de 

[1und1-8-1](1und1)
host=sipbalance8-1.1und1.de 

[1und1-8-2](1und1)
host=sipbalance8-2.1und1.de

[949136](1und1)
;                            ___  _  _   ___  _ _____  __
;                           / _ \| || | / _ \/ |___ / / /_
;                          | (_) | || || (_) | | |_ \| '_ \
;                           \__, |__   _\__, | |___) | (_) |
;                             /_/   |_|   /_/|_|____/ \___/
context=incomming
username=491234949136
secret=meinz_is_gans_geheim!
fromuser=491234949136
host=sipbalance1-1.1und1.de

Damit scheint es zu gehen. Ich bekomme nun eine stabile Verbindung zu 1und1.

Mit diesem Template bleibt für die 1und1 Accounts nurnoch wenig zu tippen. Dennoch habe ich für jeden Balancer einen Kontext.
Ein "sip show peers" zeigt mir auch alle an.

Name/username              Host            Dyn Nat ACL Port     Status
49/49                      123.45.167.89    D   N      65401    OK (39 ms)
949136/491234949136        212.227.19.130       N      5060     OK (41 ms)
1und1-8-2                  212.227.19.156       N      5060     OK (39 ms)
1und1-8-1                  212.227.19.155       N      5060     OK (41 ms)
1und1-7-2                  212.227.19.172       N      5060     OK (37 ms)
1und1-7-1                  212.227.19.171       N      5060     OK (39 ms)
1und1-6-2                  212.227.19.160       N      5060     OK (38 ms)
1und1-6-1                  212.227.19.159       N      5060     OK (38 ms)
1und1-5-2                  212.227.19.139       N      5060     OK (39 ms)
1und1-5-1                  212.227.19.137       N      5060     OK (37 ms)
1und1-4-2                  212.227.19.138       N      5060     OK (37 ms)
1und1-4-1                  212.227.19.136       N      5060     OK (38 ms)
1und1-3-2                  212.227.19.135       N      5060     UNREACHABLE
1und1-3-1                  212.227.19.134       N      5060     OK (39 ms)
1und1-2-2                  212.227.19.133       N      5060     OK (40 ms)
1und1-2-1                  212.227.19.132       N      5060     OK (37 ms)
1und1-1-2                  212.227.19.131       N      5060     OK (37 ms)
1und1-1-1                  212.227.19.130       N      5060     OK (36 ms)
52 sip peers [Monitored: 49 online, 3 offline Unmonitored: 0 online, 0 offline]

Ich frage mich nun, ob ich mir das ersparen kann, wenn ich "allowguest=yes" setze? Welche Angaben müsste ich unter [general] noch machen - z.B. insecure=???, type=friend?

Wenn unter [general] "extension=incomming" eingetragen ist, landen doch sowieso alle unbekannten IPs im context incomming. Dort stehen nur meine von extern erreichbaren Nummern drin. Sehe ich das richtig, oder schaffe ich mir eine Sicherheitslücke und öffne Anderen kostenlose Telefonate?

Was ist also der geschickteste Weg, wenn man enum erlauben möchte, auch 1und1 stabil laufen zu haben?


----->

So Ich habe nun mal enum getestet:

Ich habe einen Anruf unregistriert an 949136@dyndnsIP:5061 abgesetzt und es geht. Es geht auch, wie erwartet, wenn ich die Balancer weglasse. Ich lande im context incomming.

    -- Executing [949136@incomming:1] NoOp("SIP/dyndnsIP.org-001caea8", "949136 für IVR Zeitunabhaengig") in new stack

Jetzt taucht ein neues Problem auf:

Ich habe ein Telefon <49> hinter einer Firewall (NAT) der Firma stehen. Wenn dieses am * registriert ist und ich den Anruf hinter der gleichen Firewall absetze (also mit gleicher IP), dann lande ich im gleichen Kontext wie das registrierte Telefon. * kann wohl die Endgeräte nicht auseinander halten.

    -- Executing [949136@privileged:1] NoOp("SIP/49-001caea8", "Ortsgespraech") in new stack
    -- Executing [949136@privileged:2] Dial("SIP/49-001caea8", "SIP/01234949136@949135|60|Ttr") in new stack
    -- Called 01234949136@949135
    -- Got SIP response 482 "Loop Detected" back from 212.227.19.130
    -- Now forwarding SIP/49-001caea8 to 'Local/01234949136@incomming' (thanks to SIP/949135-001b5988)
  == Everyone is busy/congested at this time (1:0/0/1)
  == Auto fallthrough, channel 'SIP/49-001caea8' status is 'CHANUNAVAIL'

Nach all meinen jetzigen Ergebnissen möchte ich meinen technophilen Kollegen keine privilegien auf meinem * freigeben. Da ich weiß, wer mich per enum anrufen will, werde ich deren IPs dediziert in der sip.conf eintragen.

 

[Fonetiker]

49, keine Trennung

Genau, das meinte ich, als ich schon mal etwas mit 8888 schrieb. Hast Du also für dein 49 einen richtigen Account (mit Passwort) angelegt, und ich käme als Gast (per ENUM) mit meiner zufällig auch 49 lautenden Kennung, würde * von mir die Authentifizierung wie für dein 49 fordern ..., letzlich Forbidden. Das gleiche, wenn dein _registrierter_ Provider einen Call mit der Kennung 49 bei dir absetzen wollte. Die Herkunft-IPA ist da wohl wurscht. Als normal denkender Programmierer und Admin würde Mann/Frau ja denken, das zumindest für die registrierten Accounts so eine Art Session/Kanal besteht und einfache „Anklingler“ dann wo anders landen ...


Bei den vielen Einträgen für die Balancer müsste es wohl bleiben, falls Du die Kontrolle über die zulässigen Anrufer haben wolltest.
Aus Beispiel sip.conf »... has multipe servers ... a peer for each server«:

; other way than described above. If you want to control where the call enters your
; dialplan, which context, you want to define a peer with the hostname of the provider's
; server. If the provider has multiple servers to place calls to your system, you need
; a peer for each server.

Es spricht natürlich wieder für 1&1, wenn sie zur Lastverteilung mehrere IPAs brauchen.

Mit Eingrenzung der IPAs tust Du sicherlich ein gutes Werk, selbst dyn. IPAs kommen ja immer aus einem Pool, aber es ändert sich auch mal.
Schon wegen der dann frei wählbaren Herkunftnummer wuerde ich dennoch einen [incomming-guest] benutzen (Templates kennst Du doch), übersichtlichere Protokollierung, anderer/extra Signalton ...

Du hattest bei SG nur ulaw erlaubt, g726 machen sie auch, aber

[Text-sip-account-SG](!)
...
;; die koennen wirklich nur g711a (SG-asterisk-Hinweise)?
;; (auf ihrer WebSite steht: G.729, G.711, iLBC, GSM, G.726)
;; mit Twinkle getestet, SG benutzt G.726 falsch, also als ATM AAL2
allow = g726
g726nonstandard = yes	; generell falsche Byte-Order, also falsche 
			; Kennzeichnung annehmen
...

Wenn Du mal forken musst, hilft der Pseudochannel LOCAL weiter:

Dial(LOCAL/extension@context&LOCAL/extension@other-context&...

eine andere einfache Möglichkeit der Parallelverarbeitung außer Dial( ...&...&... kenne ich nicht, ich habe aber aber auch nicht wirklich Ahnung von *, benutze es nur.

Gruß F.

 

[Fonetiker]

Enum?

Ich habe gerade nach der XXXX949136 geschaut, No Results.
Aber vielleicht erreicht dich die Feuerwehr?

Gruß F.

 

[Fonetiker]

Forbidden

112:
Fr 16:43:51

INVITE sip:[email protected]:5061 SIP/2.0

Leitung 1: Ruf erfolglos.
403 Forbidden

Hiermit kannst Du den Spaßfaktor für ungebetene Kontakte/Eindringlinge erhöhen:

alwaysauthreject = yes
; When an incoming INVITE or REGISTER is to be rejected,
; for any reason, always reject with an identical response
; equivalent to valid username and invalid password/hash
; instead of letting the requester know whether there was
; a matching user or peer for their request.  This reduces
; the ability of an attacker to scan for valid SIP usernames.

... und dich natürlich auch selbst verwirren, wenn Du Accounts einrichtest/testest, und nicht daran denkst.

In diesem Sinn (Accounts erraten) wäre es natürlich auch gut, in der sip.conf die Devices nicht einfach [49] zu benennen. Ich neige ja so wie so eher zu symbolischen Namen, ein Dial(SIP/112@ext-account01... ist für mich leserlicher als Dial(SIP/112@333333...

; Don't mix extensions with the names of the devices. Devices need a unique
; name. The device name is *not* used as phone numbers. Phone numbers are
; anything you declare as an extension in the dialplan (extensions.conf).

Ach so, die 112 wird ja normal gar nicht geloggt, ich nehme mal 49 und andere, dann kannst ja vielleicht in asterik/messages etwas lesen.

Gruß F.

 

[meimi039]

OK! IP 89.12.65.101 stimmt!

Hast Du alle 1und1-IPs gescannt und nach meinem User-Agent gesucht? Die 949136 ist meine Testnummer und somit auch nicht registriert.

Der erste Post von mir ist natürlich starkt anonymisiert... ich arbeite auch lieber mit Namen in der sip.conf.

Ich lasse auch nurnoch bekannte IPs zu... haste ja scheinbar auch schon bemerkt, oder?

PS:

[Apr 16 16:43:51] NOTICE[22321] chan_sip.c: Failed to authenticate user "Feuer Wer?" <sip:[email protected]>;tag=xjytb
[Apr 16 17:32:20] NOTICE[22321] chan_sip.c: Failed to authenticate user "oneANDone" <sip:[email protected]>;tag=bysji
[Apr 16 17:33:25] NOTICE[22321] chan_sip.c: Failed to authenticate user "oneANDone" <sip:[email protected]>;tag=hubny

Würde mich mal interessieren, wie Du vorgegangen bist...

 

[Fonetiker]

Phon-Zahlen

Ich schiebe dir morgen auf diesem Wege verwertbare Angaben ins Log. Weiß zwar jetzt nicht, was mein Zeitplan fürs WE sagt, kannst aber mal probieren.
(Ist das richtig, dass der Hubraum deines VW jetzt offen zu lesen ist?)

Gruß F.

 

[meimi039]

Nachdem Du mein Banner auf Port 5061 gefunden hast, hat mein IDS Dich noch ein paar mal beim Scannen beobachtet. Sieht mir nach nmap aus. Scheint einigermaßen aktuell zu sein.
Würde mal tippen, Du hast nmap selbst kompiliert.