On Thu, 2005-11-17 at 23:47 +0100, Jeroen van Bemmel wrote:
Well, it makes a difference in the sense that the element at fault here
is
the registrar, not the UAs. The registrar should not be implemented based
on
the assumption that UAs use the same Call-ID (i.e. what you're doing when
you segregate based on Call-ID), else you get precisely the kind of
cluttered database that you talked about (for UAs that don't honor the
SHOULD).
The registration database structure should look something like this:
AoR --> Contact URI --> BindingInfo (call-id, cseq, expire time, more)
1 : N 1 : 1
Actually, it's
AoR (1:N) Contact URI (1:1) (expire time)
Yes, that's what I intended above (except that per Contact URI more than
just the expire time can be maintained). In my example the last Call-ID and
CSeq seen for that Contact URI are also maintained.
But you need an additional table to track the last-seen CSeq for each
Call-Id -- If I register a contact using one Call-Id, then refresh it
using another Call-Id, and then I send a third refresh, which CSeq it
can use is determined by which Call-Id it uses.
The CSeq check only works if the UAC sends the same Call-ID each time. If
the second one it sends is different, there's a good chance that the third
will again be different. So I don't see the point of keeping more than 1
CSeq/Call-ID per UAC Contact (i.e. only the latest pair it sent).
Jeroen
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
