1 Nov
2005
1 Nov
'05
3:51 p.m.
On 01-11-2005 15:41, Evan Borgstrom wrote:
Daniel-Constantin Mierla wrote:
Right, if you can determine current time. This is not always the case,
you can have a phone that was rebooted and has neither internal clock
nor access to NTP.
Jan.
On 11/01/05 20:46, Evan Borgstrom wrote:
How would the UA having a RFC1918 IP address cause it fail? It's
still a valid address it's just not routable, besides it's the part before
@ip that's really important. md5(time() + my_mac_address) will give you a
"unique identifier over space and time" so there's no excuse for reusing
or not generating unique call-id's.
If a UA doesn't change it's call id on every new transaction or it
reuses call id's then drop support for the UA in your network and tell
the vendor to fix their broken implementation. I'm tired of seeing
little kludges to deal with one or two broken vendors.
Section 8.1.1.4 of RFC 3261:
In a new request created by a UAC outside of any dialog, the Call-ID
header field MUST be selected by the UAC as a globally unique
identifier over space and time unless overridden by method-specific
behavior. All SIP UAs must have a means to guarantee that the Call-
ID header fields they produce will not be inadvertently generated by
any other UA.
Here is where the problem usually occurs. Most of the UA I have
seen
relies on IP address to fulfill this requirement, but this fails in the
case of private addresses. Usually, the call id is in the form of
"some_hash@ip".