Benny,
>> funny and desperate at the same time
lol
Thoughts on your algorithm:
1. If there is no matched Contact but there is an Expires header, that should take precedence over picking an 'arbitrary' value by whatever means otherwise you break compliance. RFC3261 10.2.4: "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 capital E says to me this is talking about the Expires header, the word 'field' in this context is spurious and can have no other meaning, yes?).
2. The value of the expires parameter in Contact headers for any other UACs returned by the registrar is not that originally registered, it's the remaining time until that registration expires (at least from SER anyway). If you have two UACs each picking the lowest from the returned Contact headers at each re-registration you'll induce a 'race' condition where they both speed up and eventually get a 423 error (especially if they initially registered different values). I tried that approach till I saw what was happening.
3. Using the value from the request as a last resort to simplify things will be OK most of the time. The response latency bit may seem daft but we have customers on the other side of the planet, the latency is often in excess of 500mS. Over satellite links and some cellular infrastructures its > 800mS. A heavy download going on at the client end can jack it up further. Adding this twist is a tad safer and there's little overhead in doing it.
RFC3261 says very little about how the server is supposed to construct a reply to a REGISTER command. Section 10.3 says nothing about the value to be returned in the expires parameter of Contact headers or requirement for and value in an Expires header. There is nothing at 20.10. 20.19 tells us the value in Expires header (if any) is the time until the response itself expires measured from when the request was received by the server but what does that mean in this context? The largest of the expires parameters in the contained Contact headers perhaps or the one specific to the request? Rather-Fuzzy-Concept again.
There is nothing about tolerance to be applied by a registrar when flushing stale registrations, hence IMHO the need to compensate for request/response latency.
There is this at 10.3 point 7 on page 65 "The registrar MAY choose an expiration less than the requested expiration interval." This makes using the requested time as a last resort open to failure but:
1. We are in non-compliant lala land anyway.
2. As I already said to Electrocut, that's easily sorted by changing the client configuration to be within the servers configured maximum.
So... IMHO the algorithm should be:
if we're registering:
if the answer is 200/OK:
if matched Contact is found:
get expiration from Contact
else if Expires is found:
get expiration from Expires header
else
get expiration from the request (adjusted for response latency)
else if the answer is 3xx-6xx:
the registration has failed
if we're unregistering:
if the answer is 200/OK:
the unregistration has been successful
else
it doesn't matter, we're unregistering no matter
Thoughts back?
Alan.
-----Original Message-----
From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Benny Prijono
Sent: 07 May 2008 16:48
To: pjsip list
Subject: Re: Parsing expires from REGISTER reply
Gents,
sorry for not responding sooner. So bottom line is, if server doesn't
follow the protocol, then there's no exact way to make registration
right. I wonder again if it's really hopeless to ask them to fix it (I
kind of know the answer though :) ).
Alan, as you said your patch looks a bit rough (I tend to see it as
both funny and desperate at the same time). Can we not do like this,
which is simpler (this would only happen if the strict checking is
disabled):
if we're registering:
if the answer is 200/OK:
if matched Contact is found:
get expiration from Contact
else if there is at least one Contact
get the lowest expires from all Contacts
else if Expires is found:
get expiration from Expires header
else
get expiration from the request
else if the answer is 3xx-6xx:
the registration has failed
if we're unregistering:
if the answer is 200/OK:
the unregistration has been successful
else
it doesn't matter, we're unregistering no matter
What do you think?
Cheers
Benny
