- Mitglied seit
- 6 Mai 2004
- Beiträge
- 1,864
- Punkte für Reaktionen
- 0
- Punkte
- 0
Hallo,
ich habe eine FBF 5050 FW 12.03.62, die sich an meinen Asterisk (der auf einem dedicated server im Internet läuft) mit 2 VoIP accounts anmeldet.
Nun sehe ich im Log von Asterisk (CVS Head 10/29/04), ständig diese Meldung 2xmal hintereinander (genau alle 27min.):
NOTICE[6150]: Chan_sip.c:4370 parse_contact: ' ' is not a valid SIP contact (missing sip
trying to use anyway
Auf der FBF sehe ich, dass zu dieser Zeit diverse connects zum Asterisk versucht werden:
Mich wundert an obigem output gleich mehreres:
1. Wieso versucht die FBF hier erst ein register durchzuführen =ohne= die Rufnummer (z.B. 4317978) im string?
May 19 14:49:10 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
Müßte doch wohl eher >>> Request: REGISTER sip:[email protected]
lauten, oder ?
2. Wieso funktioniert das jeweils erste SUBSCRIBE danach sieht man aber gleich einen weiteren Versuch der fehlschlägt?
Mein sip.conf Eintrag einer der beiden VoIP accounts der FBF:
Nun scheint die ganze Geschichte keine negativen Auswirkungen zu haben, die Registrierung klappt ja trotz allem und ich kann raustelefonieren und auch Anrufe erhalten auf beiden VoIP accounts. Mich interessiert nur, ob der Fehler hier bei der FBF liegt oder ob Asterisk hier "überreagiert".
Tritt diese Erscheinung mit einem neueren CVS Head vielleicht nicht auf? Wie sind Eure Erfahrungen? Kann das jemand bei sich nachvollziehen?
Danke,
Tin
ich habe eine FBF 5050 FW 12.03.62, die sich an meinen Asterisk (der auf einem dedicated server im Internet läuft) mit 2 VoIP accounts anmeldet.
Nun sehe ich im Log von Asterisk (CVS Head 10/29/04), ständig diese Meldung 2xmal hintereinander (genau alle 27min.):
NOTICE[6150]: Chan_sip.c:4370 parse_contact: ' ' is not a valid SIP contact (missing sip
Auf der FBF sehe ich, dass zu dieser Zeit diverse connects zum Asterisk versucht werden:
Code:
81.169.172.xxx = meine Asterisk IP
84.143.103.xxx = derzeitige FBF WAN IP
May 19 14:40:29 voipd[386]: <<< Request: NOTIFY sip:[email protected];uniq=329250866BC8C801432A9F8B275F
May 19 14:40:29 voipd[386]: ua_rcvnotify: application/simple-message-summary
May 19 14:40:29 voipd[386]: NOTIFY-Value = 0x0
May 19 14:40:29 voipd[386]: >>> Status: 200 OK
May 19 14:40:29 voipd[386]: <<< Request: NOTIFY sip:[email protected];uniq=329250866BC8C801432A9F8B275F
May 19 14:40:29 voipd[386]: ua_rcvnotify: application/simple-message-summary
May 19 14:40:29 voipd[386]: NOTIFY-Value = 0x0
May 19 14:40:29 voipd[386]: >>> Status: 200 OK
May 19 14:46:17 dsld[365]: 34 Packets
May 19 14:49:09 voipd[386]: query_local_ipaddress: 84.143.103.xxx
May 19 14:49:09 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:09 voipd[386]: query_local_ipaddress: 84.143.103.xxx
May 19 14:49:09 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:09 voipd[386]: <<< Status: 100 Trying
May 19 14:49:09 voipd[386]: <<< Status: 401 Unauthorized
May 19 14:49:09 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:10 voipd[386]: <<< Status: 100 Trying
May 19 14:49:10 voipd[386]: <<< Status: 401 Unauthorized
May 19 14:49:10 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:10 voipd[386]: <<< Status: 100 Trying
May 19 14:49:10 voipd[386]: illegal sip message corrected
May 19 14:49:10 voipd[386]: <<< Status: 200 OK
May 19 14:49:10 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:10 voipd[386]: <<< Status: 100 Trying
May 19 14:49:10 voipd[386]: illegal sip message corrected
May 19 14:49:10 voipd[386]: <<< Status: 200 OK
May 19 14:49:10 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:10 voipd[386]: <<< Status: 100 Trying
May 19 14:49:10 voipd[386]: <<< Status: 401 Unauthorized
May 19 14:49:10 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:10 voipd[386]: <<< Status: 100 Trying
May 19 14:49:10 voipd[386]: <<< Status: 401 Unauthorized
May 19 14:49:10 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
May 19 14:49:10 voipd[386]: <<< Status: 100 Trying
May 19 14:49:10 voipd[386]: <<< Status: 200 OK
May 19 14:49:10 voipd[386]: sip:[email protected];uniq=329250866BC8C801432A9F8B275F: REGISTER complete (next in 1620 seconds)
May 19 14:49:10 voipd[386]: >>> Request: SUBSCRIBE sip:[email protected]
May 19 14:49:10 voipd[386]: <<< Status: 100 Trying
May 19 14:49:10 voipd[386]: <<< Status: 200 OK
May 19 14:49:10 voipd[386]: sip:[email protected];uniq=329250866BC8C801432A9F8B275F: REGISTER complete (next in 1620 seconds) May 19 14:49:10 voipd[386]: >>> Request: SUBSCRIBE sip:[email protected]
May 19 14:49:10 voipd[386]: <<< Status: 407 Proxy Authentication Required
May 19 14:49:10 voipd[386]: >>> Request: SUBSCRIBE sip:[email protected]
May 19 14:49:10 voipd[386]: <<< Status: 407 Proxy Authentication Required
May 19 14:49:10 voipd[386]: >>> Request: SUBSCRIBE sip:[email protected]
May 19 14:49:10 voipd[386]: <<< Status: 403 Forbidden
May 19 14:49:10 voipd[386]: <<< Status: 403 Forbidden
May 19 14:49:20 voipd[386]: <<< Request: NOTIFY sip:[email protected];uniq=329250866BC8C801432A9F8B275F
May 19 14:49:20 voipd[386]: ua_rcvnotify: application/simple-message-summary
May 19 14:49:20 voipd[386]: NOTIFY-Value = 0x0
May 19 14:49:20 voipd[386]: >>> Status: 200 OK
May 19 14:49:20 voipd[386]: <<< Request: NOTIFY sip:[email protected];uniq=329250866BC8C801432A9F8B275F
May 19 14:49:20 voipd[386]: ua_rcvnotify: application/simple-message-summary
May 19 14:49:20 voipd[386]: NOTIFY-Value = 0x0
May 19 14:49:20 voipd[386]: >>> Status: 200 OK
Mich wundert an obigem output gleich mehreres:
1. Wieso versucht die FBF hier erst ein register durchzuführen =ohne= die Rufnummer (z.B. 4317978) im string?
May 19 14:49:10 voipd[386]: >>> Request: REGISTER sip:81.169.172.xxx
Müßte doch wohl eher >>> Request: REGISTER sip:[email protected]
lauten, oder ?
2. Wieso funktioniert das jeweils erste SUBSCRIBE danach sieht man aber gleich einen weiteren Versuch der fehlschlägt?
Mein sip.conf Eintrag einer der beiden VoIP accounts der FBF:
Code:
[4317978]
type=friend
username=4317978
secret=xxxxx
host=dynamic
context=default_out
nat=yes
disallow=all
allow=ulaw
allow=alaw
allow=g729
allow=gsm
allow=ilbc
canreinvite=no
qualify=no
Nun scheint die ganze Geschichte keine negativen Auswirkungen zu haben, die Registrierung klappt ja trotz allem und ich kann raustelefonieren und auch Anrufe erhalten auf beiden VoIP accounts. Mich interessiert nur, ob der Fehler hier bei der FBF liegt oder ob Asterisk hier "überreagiert".
Tritt diese Erscheinung mit einem neueren CVS Head vielleicht nicht auf? Wie sind Eure Erfahrungen? Kann das jemand bei sich nachvollziehen?
Danke,
Tin