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)

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.

Dale




_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to