Subject: draft-ietf-mmusic-sip-12.txt Call-ID: port number?

From: "Rick Dean" <[email-masked]>
Date: Wed, 24 Feb 1999 11:16:15 -0600

In draft-ietf-mmusic-sip-12.txt, the Call-ID
is not permitted to have a port number
after the host.  With network address translation (NAT),
multiple hosts may share one IP address, but be unable to
confer on a locally unique local-id.  I propose we allow
an optional ':' with a port number after the hostname.

--
Rick Dean
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Feb 1999 14:16:10 -0500

> an optional ':' with a port number after the hostname.

Besides the procedural point that this is a bit late to change it for
this round, I'm also not sure that this is needed. A good implementation
will use a cryptographically-strong random number generator for the
localid, which would prevent collision with any other locally running
implementation, as recommended by the spec.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 25 Feb 1999 11:45:06 -0600

> implementation, as recommended by the spec.

As I read it, random generation of the localID only makes an ID
collision "improbable", not "impossible" -- and given more hosts behind
the NAT, that probability does increase. Although I suspect that one
would need more than a couple of hundred monkeys with typwriters to have
any useful probability of creating great literature . . .

So, let's examine the probability of collision in randomly generated
localIDs.

If we assume a local-component of Call-ID with a useful length of 32
characters, selected from the 64 or so reasonably useful ASCII
characters, we have an expression range of  app. 32**64, or
approximately 2ee96 useful ID strings.

Tack on a date respresentation so we don't have to worry about
uniqueness except within a 24-hour period (the same random number a day
later would generate a different Call_ID because of the difference in
date components)

What is the probability that a such a local-ID will collide with another
generated in the same 24 hour period? If there are N calls made in the
period, the probability would be app. N*(1/2ee96), which is well below
the acceptable rate of PSTN call failure for any reasonable number of
N -- I estimate hitting "five nines" at N=2ee90, which is a lot of calls
in any reasonable period of time.

If we further assume that calls are generated from a number of hosts
(H), and that each host is capable of detecting and preventing
collisions within its own namespace (a log file?), we would further
reduce the probability by a constant of only 1/H, which seems hardly
worthwile for H>1.

On the other hand, the reality of random number generators may be a bit
lacking, and is outside of my scope in any case. Any real mathemeticians
care to expound? Given current generators, how large does the generated
ID need to be to reduce the probability of per-call collision below
1ee-6?

The real problem here is network address translation. Face it, NAT is
evil and we should repent before the end comes.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Feb 1999 15:10:40 -0500

> later would generate a different Call_ID because of the difference in

See
http://www.ietf.org/internet-drafts/draft-ietf-usefor-message-id-01.txt
for some detail.

Generally, the collision probability for random numbers is given by the
solution to the birthday problem. Details are  in my Network Security
slides, or many statistics textbooks or the RTP spec. The probability
that there is no collision is approximately

p = 1 - n(n-1)/(2k),

where n = number of calls, k = number of choices (random numbers). For
1e9 (a billion) calls a day and 1e23 different call-ids, we get a
probability of no collision of 0.999995.

Thus, 23 digits or roughly 13 letters (base-64) of randomness is good
enough. Since generating that much randomness takes a two-year old left
alone in his room for a few hours, a date-based mechanism with a second
resolution makes the problem much more tractable.

We only have to worry about IDs within the same day, since calls rarely
last beyond that, whether we use date identifiers or not (which is a
good idea, see the above I-D).