SIP/2.0 407 Proxy Authentication Required SIP/33XXXXXX-00000094 is circuit-busy

[Tigger1975]

Hallo,
nachdem ich nun schon so einiges zu diesem problem gewelst habe möchte ich mal hier fragen.

Eingehend Funktioniert nach dem ich Sip Guast Allow = Yes und Anonymous callers auf Yes gesetzt habe.
Aber ausgehend bekomme ich immer nur ein Besetzt zeichen.
Was habe ich denn hier falsch eingestellt?

Danke euch für die Muhe.

In meinem Log finde ich folgendes:

   -- Called SIP/3373580/92068
    -- SIP/3373580-00000094 is circuit-busy
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Executing [s@macro-dialout-trunk:23] NoOp("SIP/105-00000093", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 21") in new stack
    -- Executing [s@macro-dialout-trunk:24] Goto("SIP/105-00000093", "s-CONGESTION,1") in new stack

Und im Sip debug folgendes:

<--- SIP read from UDP:212.227.18.134:5060 --->
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 84.174.27.143:5061;branch=z9hG4bK1d2fa897;rport=5061
From: "49XXXXXX3373580" <sip:[email protected]>;tag=as3ec552b0
To: <sip:[email protected]>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.8829
Call-ID: [email protected]
CSeq: 102 INVITE
Proxy-Authenticate: Digest realm="1und1.de", nonce="4f216a01fb14c3817c7de1e5b218de8e0aa9474e"
Server: UI Kamailio
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---
Transmitting (NAT) to 212.227.18.134:5060:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 84.174.27.143:5061;branch=z9hG4bK1d2fa897;rport
Max-Forwards: 70
From: "49XXXXXX3373580" <sip:[email protected]>;tag=as3ec552b0
To: <sip:[email protected]>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.8829
Contact: <sip:[email protected]:5061>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: FPBX-2.10.0rc1(1.8.8.2)
Content-Length: 0


---
Audio is at 5061
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 212.227.18.134:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 84.174.27.143:5061;branch=z9hG4bK14fd2162;rport
Max-Forwards: 70
From: "49XXXXXX3373580" <sip:[email protected]>;tag=as3ec552b0
To: <sip:[email protected]>
Contact: <sip:[email protected]:5061>
Call-ID: [email protected]
CSeq: 103 INVITE
User-Agent: FPBX-2.10.0rc1(1.8.8.2)
Proxy-Authorization: Digest username="49XXXXXX3373580", realm="1und1.de", algorithm=MD5, uri="sip:[email protected]", nonce="4f216a01fb14c3817c7de1e5b218de8e0aa9474e", response="f3f736441d8ad632b25de53e2281223d"
Date: Thu, 26 Jan 2012 14:57:45 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 260

v=0
o=root 784479038 784479039 IN IP4 84.174.27.143
s=Asterisk PBX 1.8.8.2
c=IN IP4 84.174.27.143
t=0 0
m=audio 11058 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

---

<--- SIP read from UDP:212.227.18.134:5060 --->
SIP/2.0 403 User und Anrufernummer verschieden
Via: SIP/2.0/UDP 84.174.27.143:5061;branch=z9hG4bK14fd2162;rport=5061
From: "49XXXXXX3373580" <sip:[email protected]>;tag=as3ec552b0
To: <sip:[email protected]>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.fd2a
Call-ID: [email protected]
CSeq: 103 INVITE
Server: UI Kamailio
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
Transmitting (NAT) to 212.227.18.134:5060:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 84.174.27.143:5061;branch=z9hG4bK14fd2162;rport
Max-Forwards: 70
From: "49XXXXXX3373580" <sip:[email protected]>;tag=as3ec552b0
To: <sip:[email protected]>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.fd2a
Contact: <sip:[email protected]:5061>
Call-ID: [email protected]
CSeq: 103 ACK
User-Agent: FPBX-2.10.0rc1(1.8.8.2)
Content-Length: 0

[3373580]   
disallow=all
type=peer
username=49XXXXXX3373580
fromuser=4906423373580
secret=OAogZRYYkAA3ve29ys6j
host=sip.1und1.de  
fromdomain=1und1.de 
insecure=port,invite
allow=alaw
allow=ulaw
context=from-trunk-sip-3373580

in meiner sip_general_additional.conf

vmexten=*97
context=from-sip-external
callerid=Unknown 
notifyringing=yes
notifyhold=yes
tos_sip=cs3   
tos_audio=ef  
tos_video=af41
alwaysauthreject=yes
useragent=FPBX-2.10.0rc1(1.8.8.2)
disallow=all
allow=alaw 
allow=ulaw 
....
tos_sip=cs3
tos_audio=ef
transport=udp
callevents=yes
language=de   
bindport=5061 
bindaddr=0.0.0.0
jbenable=no
registertimeout=20
srvlookup=yes
registerattempts=10
maxexpiry=2000
minexpiry=1900
defaultexpiry=1600
allowguest=yes
notifyhold=yes
notifyringing=yes
maxcallbitrate=384
g726nonstandard=no
t38pt_udptl=yes   
videosupport=no   
canreinvite=yes   
rtptimeout=30     
rtpholdtimeout=300
rtpkeepalive=0
checkmwi=10   
nat=yes
externhost=al....ndns.org
externrefresh=60
localnet=192.168.178.0/255.255.255.0
localnet=192.168.10.0/255.255.255.0 
localnet=192.168.11.0/255.255.255.0 
localnet=192.168.20.0/255.255.255.0

 

[rentier-s]

SIP/2.0 403 User und Anrufernummer verschieden

Probier mal vor dem Dial ein Set(CALLERID(num)=49XXXXXX3373580)

username und fromuser sind vermutlich gleich, nur hier unterschiedlich anonymisiert, oder?

 

[Tigger1975]

username und fromuser sind vermutlich gleich, nur hier unterschiedlich anonymisiert, oder?

nein genau dabei hatte ich einen Fehler, der ist mir Heute Morgen aufgefallen als ich nochmals hier im Forum nachgeschaut habe und meinen Beitrag augeschaut habe.
Dabei ist mir aufgefallen das die Vorwahl nicht sauber entfernt wurde. bei genauerer Betrachtung habe ich gesehen das die Vorwahl falsch ist.

Jetzt geht wieder alles.

Eins noch gibt eine bessere Möglichkeit mit 1und1 zusammen zu arbeiten, als Anonyme call zuzulassen?
1und1 Arbeitet scheinbar mit mindestens 20 Server für ein Outbound load-balancing. Es kann doch nicht sein das man ständig prüfen muss ob mal alle Server im System hat.

 

[rentier-s]

Einen Tod musst Du sterben, entweder die Serverfarm pflegen oder die Sicherheitslücke in Kauf nehmen.

 

[Tigger1975]

Und was wäre mit einem Mittelweg wie Z.B. die IP Auflösen und wenn sie der Domain von z.B. 1und1.de gehört (FromDomain) könnte man den Call duch zulassen und in den Richtigen Kontext packen.

 

[rentier-s]

Wenn Du die entsprechende Stelle in der chan_sip.c findest :noidea:

Es würde ja schon reichen, die Subdomain(s) zu ignorieren und nur nach Domain zu matchen.