On 11/17/05 17:14, Dale R. Worley wrote:
On Thu, 2005-11-17 at 09:37 -0500, Paul Kyzivat wrote:
I guess people can implement as they wish, but that sounds like a bad
implementation to me. There is nothing illegal, according to 3261, if
two UAs (using different callids of course) keep doing registrations
that overwrite the same contact address. In that case there is no reason
to retain a record of the older registration.
Yes, it was a weakness of the implementation, enhanced by a strange
operating environment that made the situation much worse. And in the
interval after the re-registration had been made, but before the first
one expired, there were two registrations for the same AOR (and both
gave the same contact). Which isn't too troublesome, but is messy.
The whole point of the Call-Id for registrations is so that the
registrar can tell if a REGISTER is entirely new or just updating a
previous registration, and things work better if it can tell that.
There is another registration situation that gets troubles: when the
UACs are behind NAT and have same private IP address, in the case when
the UACs serve same AoR. The Contact headers might have the same
addresses (private_ip:5060) and each registration/refresh will overwrite
the other bindings.
From the RFC, sec. 10.3, step 7 of REGISTER processing:
For each address, the registrar then searches the list of
current bindings using the URI comparison rules. If the
binding does not exist, it is tentatively added. If the
binding does exist, the registrar checks the Call-ID value. If
the Call-ID value in the existing binding differs from the
Call-ID value in the request, the binding MUST be removed if
the expiration time is zero and updated otherwise. If they are
the same, the registrar compares the CSeq value. If the value
is higher than that of the existing binding, it MUST update or
remove the binding as above. If not, the update MUST be
aborted and the request fails.
All these troubles occur when server-side solutions are used for NAT
traversal. Different contacts are indexed by same key (aor,
private_ip:port) and processing according to RFC is troublesome. In my
opinion, in this case the source ip should be taken in consideration,
too, to avoid contact overlapping. But the problem persists when the
UACs are behind multiple levels of NAT, here you cannot rely on source
IP, maybe Call-ID would help to distinguish between different contacts.
SIP Instance extension should solve the problem, but is still a draft
and not many UA implements it (as far as I know, snom does it).
Daniel
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
