SPA, eigenes Reg-Intervall und Vorgabe durch Provider

exim · 8 Jul 2004

- 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:

Sipura-Support schrieb:
If you configure 900 but Proxy replies 3600 or 3780, the SPA
will take the smaller value; this is the recommended practice
per RF3261. Try to have the proxy reply something less than 900,
then the SPA will follow.

Im RFC steht
unter Punkt 10.2.2.1 u.a.:

When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like
the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.)

unter Punkt 10.2.4 u.a.:

The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each
contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration
time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each
of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.

unter Punkt 10.3 u.a.:

The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration
interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY
reject the registration with a response of 423 (Interval Too Brief). This response MUST contain a Min-Expires header field
that states the minimum expiration interval the registrar is willing to honor.

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:

koehler · 8 Jul 2004

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:

5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)

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

koehler · 8 Jul 2004

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

betateilchen · 9 Jul 2004

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:[email protected]>
Expires: 90
From: "Coffee Shop" <sip:[email protected]>
Call-ID: [email protected]
Content-Length: 0
User-Agent: kphone/4.0.3
Event: registration
Allow-Events: presence
Contact: "Coffee Shop" <sip:[email protected];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:[email protected]>
To: "Coffee Shop" <sip:[email protected]>
CSeq: 2672 REGISTER
Call-ID: [email protected]
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:[email protected]>
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:[email protected]>
Call-ID: [email protected]
Content-Length: 0
User-Agent: kphone/4.0.3
Event: registration
Allow-Events: presence
Contact: "Coffee Shop" <sip:[email protected];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:[email protected]>
To: "Coffee Shop" <sip:[email protected]>
CSeq: 2673 REGISTER
Call-ID: [email protected]
Expires: 3780
Content-Length: 0
Contact: <sip:[email protected]: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:[email protected]>
Expires: 5000
From: "Coffee Shop" <sip:[email protected]>
Call-ID: [email protected]
Content-Length: 0
User-Agent: kphone/4.0.3
Event: registration
Allow-Events: presence
Contact: "Coffee Shop" <sip:[email protected];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:[email protected]>
To: "Coffee Shop" <sip:[email protected]>
CSeq: 1132 REGISTER
Call-ID: [email protected]
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:[email protected]>
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:[email protected]>
Call-ID: [email protected]
Content-Length: 0
User-Agent: kphone/4.0.3
Event: registration
Allow-Events: presence
Contact: "Coffee Shop" <sip:[email protected];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:[email protected]>
To: "Coffee Shop" <sip:[email protected]>
CSeq: 1133 REGISTER
Call-ID: [email protected]
Expires: 3780
Content-Length: 0
Contact: <sip:[email protected]:5060>


SipCall: Incoming response
SipCall: Checking for Contact and Record-Route
SipCall: Setting Contact for this Call Member
SipTransaction: Incoming Response
ReRegistrationTimer (ms): 3402000

koehler · 9 Jul 2004

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

Languages

Suche

Languages

Suche

SPA, eigenes Reg-Intervall und Vorgabe durch Provider

exim

Admin a.D.

koehler

Forumsbundespräsident

koehler

Forumsbundespräsident

betateilchen

Grandstream-Guru

koehler

Forumsbundespräsident

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums