Dale,
On Thu, 2005-11-17 at 22:19 +0100, Jeroen van Bemmel wrote:
> The reason that the Call-Id's on successive registrations are the same
> is so that the registrar can update the previous registration's record
> rather than creating a new one. I have seen some instances where UAs
> generated new Call-Id's for each registration, and the registrar's
> database did get cluttered with old registrations (which it kept around
> for an hour or so after they expired).
I am not sure if I understand this. AFAIU creation of a new record versus
updating an existing one depends solely on the Contact URI: registration
record equality is defined in terms of URI equality. So a previous record
is
updated if-and-only-if the Contact URI is the same
Hmmm, yes. Looking at section 10.2.2, I have to say you're right. It
turns out our registrar segregates registrations based on what Call-Id
they were made with, and a registration with one Call-Id will not update
a registration made with another, it will create a new registration.
Though in the case we ran into, this doesn't make any difference. The
UA's were sending frequent registrations with different Call-Id's and
the registrar was having to keep track of all of them so it could
compare CSeq's.
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
( for example in Java, you could use "Map<SipURI,Map<SipURI,Binding>>
bindings;", for implementation ConcurrentHashMap is a good choice for the
first Map)
Regards,
jeroen
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
