E65 & Spa9000

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
S

ssteiner

Mitglied
Mitglied seit
27 Mai 2006
Beiträge
360
Punkte für Reaktionen
0
Punkte
0
Und wieder das leidige Thema.. das E65 gesellt sich zum SL75 und F3000 und versteht das OK auf sein REGISTER nicht :(

So siehts aus
Code: 
[pxy]<<192.168.1.124:5060(482)
[pxy]<<192.168.1.124:5060(482)
REGISTER sip:192.168.1.4:6060;transport=UDP SIP/2.0
Route: <sip:192.168.1.4:6060;lr;transport=UDP>
Via: SIP/2.0/UDP 192.168.1.124:5060;branch=z9hG4bKu43hooi1d9hc6ca74fs0t0b;rport
From: <sip:[email protected]>;tag=nvohoonl3hhc7hul4fs0
To: <sip:[email protected]>
Contact: <sip:[email protected];transport=UDP>;expires=3600
CSeq: 875 REGISTER
Call-ID: nqUsoFTNoIffFOfU3L2NZS9vlyUUzW
Supported: sec-agree
User-Agent: Nokia RM-208 1.0633.18.01
Max-Forwards: 70
Content-Length: 0

[pxy]->192.168.1.124:5060(419)
[pxy]->192.168.1.124:5060(419)
SIP/2.0 200 OK
To: <sip:[email protected]>;tag=60b7acd9-0
From: <sip:[email protected]>;tag=nvohoonl3hhc7hul4fs0
Call-ID: nqUsoFTNoIffFOfU3L2NZS9vlyUUzW
CSeq: 875 REGISTER
Via: SIP/2.0/UDP 192.168.1.124:5060;branch=z9hG4bKu43hooi1d9hc6ca74fs0t0b
Contact: sip:[email protected]:5060;expires=360
Server: Linksys/SPA9000-5.1.7
Allow-Events: talk, hold, conference
Content-Length: 0
Date: Mon, 13 Apr 2007 22:56:36 PST

Abgehend wählen geht somit nicht da das Telefon keine Wahl ohne Registration zulässt. Der SPA9000 erachtet das Gerät aber als registriert und routet Anrufe drauf.. das sieht dann so aus (und zeigt dass die beiden Geräte sich durchaus verstehen):
Code: 
[pxy]<<192.168.1.102:5060(1073)
[pxy]<<192.168.1.102:5060(1073)
INVITE sip:[email protected]:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK-c34d08ef
From: "Stephan" <sip:[email protected]:6060>;tag=addd907f4ee8a5c6o0
To: <sip:[email protected]:6060>
Remote-Party-ID: "Stephan" <sip:[email protected]:6060>;screen=yes;party=calling
Call-ID: [email protected]
CSeq: 101 INVITE
Max-Forwards: 70
Contact: "Stephan" <sip:[email protected]:5060>;+sip.instance="<00000000-0000-0000-0000-000E08DD6BFA>"
Expires: 240
User-Agent: Linksys/SPA962-5.1.7
Content-Length: 397
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE
Allow-Events: dialog
Supported: replaces
Content-Type: application/sdp


v=0
o=- 221626 221626 IN IP4 192.168.1.102
s=-
c=IN IP4 192.168.1.102
t=0 0
m=audio 16434 RTP/AVP 8 0 2 4 18 96 97 98 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv

[pxy]<<192.168.1.124:5060(304)
[pxy]<<192.168.1.124:5060(304)
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.4:6060;branch=z9hG4bK-c34d08ef__0,SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK-c34d08ef
To: <sip:[email protected]>
From: "Stephan" <sip:[email protected]>;tag=addd907f4ee8a5c6o0
Call-ID: [email protected]
CSeq: 101 INVITE
Content-Length: 0


[pxy]<<192.168.1.102:5060(1073)
[pxy]<<192.168.1.102:5060(1073)
INVITE sip:[email protected]:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK-c34d08ef
From: "Stephan" <sip:[email protected]:6060>;tag=addd907f4ee8a5c6o0
To: <sip:[email protected]:6060>
Remote-Party-ID: "Stephan" <sip:[email protected]:6060>;screen=yes;party=calling
Call-ID: [email protected]
CSeq: 101 INVITE
Max-Forwards: 70

Contact: "Stephan" <sip:[email protected]:5060>;+sip.instance="<00000000-0000-0000-0000-000E08DD6BFA>"
Expires: 240
User-Agent: Linksys/SPA962-5.1.7
Content-Length: 397
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE
Allow-Events: dialog
Supported: replaces
Content-Type: application/sdp

v=0
o=- 221626 221626 IN IP4 192.168.1.102
s=-
c=IN IP4 192.168.1.102
t=0 0
m=audio 16434 RTP/AVP 8 0 2 4 18 96 97 98 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv


[pxy]<<192.168.1.124:5060(332)
[pxy]<<192.168.1.124:5060(332)
SIP/2.0 486 Busy Here

Via: SIP/2.0/UDP 192.168.1.4:6060;branch=z9hG4bK-c34d08ef__0,SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK-c34d08ef
To: <sip:[email protected]>;tag=utd1ooh5uhhc681r6kcu
From: "Stephan" <sip:[email protected]>;tag=addd907f4ee8a5c6o0
Call-ID: [email protected]
CSeq: 101 INVITE
Content-Length: 0

Und damit alle Unklarheiten bei den Traces beseitigt sind: 192.165.1.4 ist der Proxy, 192.168.1.124 das E65 mit Rufnummer 53, 192.168.1.102 ein SPA962 IP Phone mit der Rufnummer 55
 
Nachdem ich Nokia mühsam dazu bringen musste, das Ganze überhaupt anzuschauen, gabs nach 2 Wochen die Antwort dass der Fehler bei Linksys liege und man Linksys entsprechend informiert hätte - wo genau das Problem liegt wollte man auch nach diversem Nachstochern nicht angeben, es handle sich dabei um "technisch spezifische Firmeninternas", was kompletter Schwachsinn ist. Da ich Firmen die mit frei erfundenen Gründen versuchen mich loszuwerden eh nicht traue, habe ich daraufhin selbst eine Detailanalyse zu den beiden Paketen gemacht.

Falls es jemand interessiert, hier die Angaben zu 2 Fehlern in der RFC Implementation bei Linksys:

Die Zeile

Date: Mon, 13 Apr 2007 22:56:36 PST

verstösst gegen die in 20.17 gestellte Anforderung dass die Zeit in der GMT
Zeitzone angegeben wird. Es obliegt dem Endgerät diese in das lokale
Zeitformat umzusetzen.

Contact: sip:[email protected]:5060;expires=360

Wird vermutlich vom UA nicht erkannt. Gemäss der Logik für die Registration
(10.4) sucht der UA nach dem entsprechenden Binding im Contact Feld der
Registrationsantwort. Dabei wird URI matching wie in 19.1.4 definiert
verwendet. 19.1.4 definiert die URI Felder welche zwingend übereinstimmen
müssen. Gemäss der aktuellsten SIP RFC, entspricht user@proxy nicht mehr
user@proxy:5060 (bei UDP) - ausserdem wird ein match der ttl, user, method
und transport parameter verlangt.

Aufgrund der REGISTER Nachricht

Contact: <sip:[email protected];transport=UDP>;expires=3600

Dürfte die Antwort also den Port 5060 nicht enthalten - dafür müsste aber
"transport=UDP" enthalten sein. Dadurch haben wir eine Contact URI mit einem
Semikolon, welche gemäss 20.10 durch <> Klammern eingeklammert sein muss.

Dadurch ergibt sich:

Contact: <sip:[email protected];transport=UDP>;expires=360

Als korrekte Antwort auf die Registration. Stellt man den Transport auf
Auto, wäre zwar die <> Umklammerung nicht mehr nötig (im Contact URI in der
REGISTER Nachricht gibts dann kein Transport mehr), aber der Port müsste
trotzdem aus der Antwort entfernt werden. Die Anforderung mit dem Port 5060
auslassen besteht erst seit dem RFC 3261 und es gibt viele UAs, welche eine
Antwort wie vom SPA9000 trotzdem aktzeptieren.
Zum Vergrößern anklicken....
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 558 (Mitglieder: 2, Gäste: 556)

Neueste Beiträge

Statistik des Forums

Themen
246,626
Beiträge
2,255,010
Mitglieder
374,548
Neuestes Mitglied
olivierogabriel
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück