.titleBar { margin-bottom: 5px!important; }

SPA, eigenes Reg-Intervall und Vorgabe durch Provider

Dieses Thema im Forum "Linksys (VoIP)" wurde erstellt von exim, 8 Juli 2004.

  1. exim

    exim Admin a.D.

    Registriert seit:
    27 Apr. 2004
    Beiträge:
    1,013
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    - SPA registriert sich mit "expires=900"
    - Proxy antwortet mit "ok, expires=3780"
    - SPA sagt "ok", registriert sich jedoch nach 900 Sekunden neu

    Ich dachte immer, dass der Provider-Proxy grundsätzlich Vorrang hat, doch Sipura sieht das anders:

    Im RFC steht
    unter Punkt 10.2.2.1 u.a.:
    unter Punkt 10.2.4 u.a.:
    unter Punkt 10.3 u.a.:
    Könnte es sein dass Sipura Recht hat? Meine Interpretation:
    Der Satz "As described in Section 10.3, the registrar selects the actual time interval based on its local policy" ist eigentlich eindeutig. Doch der Fall "Registrar meldet einen größeren Intervall als den angefragten zurück" wird in 10.3 ja gar nicht erwähnt. Somit greift 10.2.4 und der SPA macht letzten Endes genau das, was da drinnensteht: "The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed." 900 Sekunden ist vor dem Ablauf der Intervalls von 3780 Sekunden. Ob er nun das Intervall abgleicht oder nicht - er erneuert die Registrierung vor Ablauf des Intervalls. Eine Meldung "423 - Interval Too Brief" mit einem "Min-Expires"-Anhang schickt der Proxy ja nicht.

    Und andersherum - wenn man dem SPA einen Intervall von z.B. 8000 vorsetzt geht er brav auf das Maximum vom Provider zurück.

    Wer hat nun Recht? :gruebel:
     
  2. koehler

    koehler Forumsbundespräsident

    Registriert seit:
    10 März 2004
    Beiträge:
    895
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Unterbezahlte Voodoopuppe
    Der jenige hat recht, der einerseits die Kompatibelitaet zum RFC 2543 aufrecht erhaelt und andererseits RFC 2119 kennt :)

    - 423 (too brief oder to frequent) ist nicht im Bestand von RFC 2543.
    - "MAY" heisst "Vielleicht" bzw. OPTIONAL

    Man beachte dass das Wort "MAY" gemaess RFC 2119 wie folgt definiert ist:

    Schluesselsatz fett.

    Die reduzierte Funktionalitaet ergibt in diesem Sinne, dass das Sipura sich immer neu registriert bzw. von sich aus registrieren muss. Die Grundfunktionalitaet seitens des Registrars, welcher kein 423 sendet sondert sofort eine feste Zeit in der finalen response liefert ist gegeben.

    n8,

    Michael
     
  3. koehler

    koehler Forumsbundespräsident

    Registriert seit:
    10 März 2004
    Beiträge:
    895
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Unterbezahlte Voodoopuppe
    Ich habe eben XLite und SIPPS auf diese optionale Erweiterung getestet. Fehlanzeige. Beide Soft-Clients arbeiten mit dieser Erweiterung nicht zusammen.

    Mit der Grandstream Software 1.0.5.0 funktioniert diese Erweiterung schon. Hat irgendjemand die Moeglichkeit das mit seinem Geraet zu testen ? Ich waere sehr interessiert ob dieses Feature von weiteren Clients/Phones beherrscht wird.

    UPDATE:
    ----------
    Auch SJPhone funktioniert nicht mit dieser Erweiterung.



    Gruss,

    Michael
     
  4. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Hallo Michael !

    kphone ist scheinbar auch völlig unbeeindruckt.

    Bei beiden Versuchen (mit 90 und 5000 Sekunden) kam immer die gleiche Re-Registration-Time raus.

    Code:
    
    
    $ kphone -u nikotel
    Found 2 interfaces.
    SipClient: Listening UDP on port: 5060
    SipClient: Our address: 192.168.11.201
    SipRegister: Auth is '(null)'
    SipRegister: Proxy Auth is '(null)'
    
    SipClient: Sending: 08:32:03.425
    --------------------------------
    REGISTER sip:calamar0.nikotel.com SIP/2.0
    Via: SIP/2.0/UDP 192.168.11.201
    CSeq: 2672 REGISTER
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Expires: 90
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Call-ID: 776416800@192.168.11.201
    Content-Length: 0
    User-Agent: kphone/4.0.3
    Event: registration
    Allow-Events: presence
    Contact: "Coffee Shop" <sip:coffeeshop@192.168.11.201;transport=udp>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER"
    
    
    res_search: NO result !
    res_search: NO result !
    SipClient: Sending to 'calamar0.nikotel.com:5060'
    SipClient: Receiving message...
    
    SipClient: Received: 08:32:03.804
    ---------------------------------
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP 192.168.11.201
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    CSeq: 2672 REGISTER
    Call-ID: 776416800@192.168.11.201
    Expires: 31
    WWW-Authenticate: Digest realm="nikotel.com", algorithm="MD5", nonce="xxx", qop="auth", opaque="xxx"
    Content-Length: 0
    
    
    SipCall: Incoming response
    SipTransaction: Incoming Response
    SipRegister: Authentication required
    getDigestResponse(): Remote endpoint supports Digest with qop=auth
    WL: SipProtocol: HA1=f58764607d79d643a1223ecf149ed089 (coffeeshop:nikotel.com)
    SipProtocol: Digest calculated.
    SipRegister: Auth is 'Digest username="coffeeshop", realm="nikotel.com", nonce="", uri="sip:calamar0.nikotel.com", qop=auth, cnonce="abcdefghi", nc=00000001, response="", opaque=""'
    SipRegister: Proxy Auth is '(null)'
    
    SipClient: Sending: 08:32:08.746
    --------------------------------
    REGISTER sip:calamar0.nikotel.com SIP/2.0
    Via: SIP/2.0/UDP 192.168.11.201
    CSeq: 2673 REGISTER
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Authorization: Digest username="coffeeshop", realm="nikotel.com", nonce="", uri="sip:calamar0.nikotel.com", qop=auth, cnonce="abcdefghi", nc=00000001, response="", opaque=""
    Expires: 90
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Call-ID: 776416800@192.168.11.201
    Content-Length: 0
    User-Agent: kphone/4.0.3
    Event: registration
    Allow-Events: presence
    Contact: "Coffee Shop" <sip:coffeeshop@192.168.11.201;transport=udp>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER"
    
    
    res_search: NO result !
    res_search: NO result !
    SipClient: Sending to 'calamar0.nikotel.com:5060'
    SipClient: Receiving message...
    
    SipClient: Received: 08:32:09.353
    ---------------------------------
    SIP/2.0 200 OK "Authenticated"
    Via: SIP/2.0/UDP 192.168.11.201
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    CSeq: 2673 REGISTER
    Call-ID: 776416800@192.168.11.201
    Expires: 3780
    Content-Length: 0
    Contact: <sip:coffeeshop@calamar0.nikotel.com:5060>
    
    
    SipCall: Incoming response
    SipCall: Checking for Contact and Record-Route
    SipCall: Setting Contact for this Call Member
    SipTransaction: Incoming Response
    ReRegistrationTimer (ms): 3402000
    
    *******************************************************************************
    
    
    $ kphone -u nikotel
    Found 2 interfaces.
    SipClient: Listening UDP on port: 5060
    SipClient: Our address: 192.168.11.201
    SipRegister: Auth is '(null)'
    SipRegister: Proxy Auth is '(null)'
    
    SipClient: Sending: 08:26:43.185
    --------------------------------
    REGISTER sip:calamar0.nikotel.com SIP/2.0
    Via: SIP/2.0/UDP 192.168.11.201
    CSeq: 1132 REGISTER
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Expires: 5000
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Call-ID: 556820261@192.168.11.201
    Content-Length: 0
    User-Agent: kphone/4.0.3
    Event: registration
    Allow-Events: presence
    Contact: "Coffee Shop" <sip:coffeeshop@192.168.11.201;transport=udp>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER"
    
    
    res_search: NO result !
    res_search: NO result !
    SipClient: Sending to 'calamar0.nikotel.com:5060'
    SipClient: Receiving message...
    
    SipClient: Received: 08:26:43.570
    ---------------------------------
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP 192.168.11.201
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    CSeq: 1132 REGISTER
    Call-ID: 556820261@192.168.11.201
    Expires: 31
    WWW-Authenticate: Digest realm="nikotel.com", algorithm="MD5", nonce="", qop="auth", opaque=""
    Content-Length: 0
    
    
    SipCall: Incoming response
    SipTransaction: Incoming Response
    SipRegister: Authentication required
    getDigestResponse(): Remote endpoint supports Digest with qop=auth
    WL: SipProtocol: HA1=f58764607d79d643a1223ecf149ed089 (coffeeshop:nikotel.com)
    SipProtocol: Digest calculated.
    SipRegister: Auth is 'Digest username="coffeeshop", realm="nikotel.com", nonce="", uri="sip:calamar0.nikotel.com", qop=auth, cnonce="abcdefghi", nc=00000001, response="", opaque=""'
    SipRegister: Proxy Auth is '(null)'
    
    SipClient: Sending: 08:26:48.001
    --------------------------------
    REGISTER sip:calamar0.nikotel.com SIP/2.0
    Via: SIP/2.0/UDP 192.168.11.201
    CSeq: 1133 REGISTER
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Authorization: Digest username="coffeeshop", realm="nikotel.com", nonce="", uri="sip:calamar0.nikotel.com", qop=auth, cnonce="abcdefghi", nc=00000001, response="", opaque=""
    Expires: 5000
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    Call-ID: 556820261@192.168.11.201
    Content-Length: 0
    User-Agent: kphone/4.0.3
    Event: registration
    Allow-Events: presence
    Contact: "Coffee Shop" <sip:coffeeshop@192.168.11.201;transport=udp>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER"
    
    
    res_search: NO result !
    res_search: NO result !
    SipClient: Sending to 'calamar0.nikotel.com:5060'
    SipClient: Receiving message...
    
    SipClient: Received: 08:26:48.634
    ---------------------------------
    SIP/2.0 200 OK "Authenticated"
    Via: SIP/2.0/UDP 192.168.11.201
    From: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    To: "Coffee Shop" <sip:coffeeshop@calamar0.nikotel.com>
    CSeq: 1133 REGISTER
    Call-ID: 556820261@192.168.11.201
    Expires: 3780
    Content-Length: 0
    Contact: <sip:coffeeshop@calamar0.nikotel.com:5060>
    
    
    SipCall: Incoming response
    SipCall: Checking for Contact and Record-Route
    SipCall: Setting Contact for this Call Member
    SipTransaction: Incoming Response
    ReRegistrationTimer (ms): 3402000
    
    
     
  5. koehler

    koehler Forumsbundespräsident

    Registriert seit:
    10 März 2004
    Beiträge:
    895
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Unterbezahlte Voodoopuppe
    beta: ich hatte das mit einem Testproxy gemacht. Das Problem war, dass SIPPS, XLite und SJPhone das 423 nicht interpretierten und somit keine Registrierung zustande kam.

    Ich habe dann versucht (gemaess "MAY") 'kompatibel' zu bleiben und habe nach dem 423 noch eine 200er Response hinterher geschossen, aber das 423 wurde allen Anschein nach von diesen Clients als allgemeine 4xx Fehler Response interpretiert oder, so meine zweite Vermutung, der Dialog des Clients wartet generell nur auf eine 200 oder 401 Response. Jedenfalls wurde das anschliessende 200 nicht mehr interpretiert. Hier sollte man auf unbedingt eine intelligentere Logik ansetzen um kompatibel zu sein :)

    Z. B.

    < REGISTER
    > 423 mit Min-Expires
    ...nuts.. client no further response or RE-REGISTER w/o creds.
    = client merken und fallback auf 200 mit zwangs-expire
    < REGISTER
    > 200 mit erhoehtem Expires


    Wirklich genau kann man jedenfalls nicht sagen was bei den einzelnen Clients intern passiert und wichtig ist eigentlich auch nur das Ergebnis und das war negativ. Bzgl. kPhone braucht man eigentlich nur einen grep auf die oSIP Lib. Sourcen zu machen ("grep -R 423 ./osip/src") um heraus zu finden ob das unterstuetzt werden koennte. Aber das ist natuerlich auch keine Garantie.

    Tja, dauert wohl noch.



    Gruss,

    Michael