[Devel] Processing REGISTER requests
Dan Pascu
dan at ag-projects.com
Thu Oct 6 17:56:14 CEST 2005
On Thursday 06 October 2005 15:19, Klaus Darilion wrote:
> I still can't see how we may combine them. Just take your scenario 1.
> from above. Two different clients -> 2 different call-ids. Thus, your
> call-id algorithm does not match and you suggest the use the old
> algorithm. Thus, we again overwrite the contact.
I really don't understand what you say here.
First registration.
Phone 1:
callid = somecallid
cseq = 101
ip = 10.0.0.1
port = 5060
Phone 2:
callid = anothercallid
cseq = 101
ip = 10.0.0.1
port = 5060
Second registration if phones support the RFC recommandation to reuse
callid and increment CSeq:
Phone 1:
callid = somecallid
cseq = 103
ip = 10.0.0.1
port = 5060
Phone 2:
callid = anothercallid
cseq = 103
ip = 10.0.0.1
port = 5060
using callid and cseq each phone will match its previous registration.
Second registration if phones do not support the RFC recommandation to
reuse callid and increment CSeq:
Phone 1:
callid = thirdcallid
cseq = 101
ip = 10.0.0.1
port = 5060
Phone 2:
callid = fourthcallid
cseq = 101
ip = 10.0.0.1
port = 5060
using callid and cseq each phone will not match its previous registration
and the contacts will be overwriten. However note that this happens right
now with the current algorithm, so nothing changed. It behaves exactly
the same.
As I said, I've found that 98% of the phones follow the RFC recommendation
about using the same callid and incrementing cseq with each register
request, so this concludes that using callid will improve contact lookup
for 98% of the phones while for the rest will continue to behave like now
(not any bit worse).
Now there are claims that different phones use the same callid which
should interfere with this. Until some provides some data about this, in
my book is just an hypothesys. Even if true, how many of the 98% do you
think a random callid overlapping will affect? I'd say it's still an
improvement, even if the critics provide to be true.
--
Dan
More information about the Devel
mailing list