Interestingly I made a measurement which supports your argument.
In short, a vast majority of SIP traffic going through iptel.org
has IP address in it. Details of the measurement follow bellow
for those interested in details (including links to colorful
non-ASCII graphs ;-)). Key characteristics of the iptel.org
SIP service is high variance in type of UAs using it.
As for the backwards-compatibility argument, I guess that it will
take same long time to get UAs do session-id, so IMO an improvement
is only possible under an assumption that network-asserted session-id
is easier to introduce than UA-asserted, right? That appears
meaningful to me.
-jiri (hoping for better life for unfortunate ones, who have chosen
to operate callid-mangling B2BUAs and RFC-2543 clients without upgrade
strategy ;-))
Measurement Details
--------------------
a) types of UA
for a pie-chart see: http://www.iptel.org/~jiri/etc/ua-breakdown.png
(picture to big to be attached, sorry)
It is saying that there are 162 diffent types of User Agents for
1131 users. Apart from the most popular UA types seen in the graph,
the greatest variety occurs in the "other devices" chunk representing
150+ User Agent Types.
In summary I think the selection of UAs is quite representative.
b) callid stats
I pulled about 18 minutes of SIP traffic at about 0.5 Mbps (including
layer-2 headers; resulting in about 65e3 packets totaling to 35e6
bytes of SIP data, avg SIP packet size 540 bytes) and postprocessed
it as follows:
# IP addres in grep -v is an availabaility checker -- to be excluded
ngrep -d any -W byline port 5060| grep -i Call-ID|grep -v
"213.192.59.93"|sort -u >/tmp/callid2
# number of callids captured in the sample: 4345
tlb1:~# wc /tmp/callid2
4345 8733 184947 /tmp/callid2
# number of @IP callids: 3695 (85%)
tlb1:~# egrep "@[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"
/tmp/callid2|wc
3695 7433 152577
# number of callids w/o @: 470 (11%)
tlb1:~# egrep -v "@" /tmp/callid2|wc
470 940 23053
# numver of callids with @ and some non-nummerical stuff after it
(domain name typically)
tlb1:~# egrep "@[^0-9]" /tmp/callid2|wc
149 298 8220
# number of "natted callids"
tlb1:~# egrep "@(10|192\.168|172\.(16|17|18|19|2[0-9]|30|31))\."
/tmp/callid2|wc
1092 2184 47063
c) measurement mistakes: a and b have been measured independently, it
is possible but unlikely that the statements in b related to a different
set of UAs featuring a different variance. This likelihood of such
circumstances to occur doesn't seem very high to me. b) has been measured
on an off-the shelf PC attached to the same Ethernet swtich at iptel.org's
load-balancer --it is possible that such a PC could have missed some
IP packets. If so, I assume it has done so on a fair basis which does not
impact the CallId assertion.
[email protected] wrote:
Jiri,
I agree with you on the im portance of the problem, but I don't agree
with you that we can solve the problem by changing one of the protocol
basics at this time, with millions of existing boxes, network boxes as
well as end devices. Especially the end devices are critical. Most of
them send today the IP-address in the call-ID. Customers often do not
accept the upgrades. Some customers also have their own boxes. It will
take at least 10 years until we can can rely on the secure call-id for
dialog correlation. This is far too late. We also do not realy know
which problems may occur if we change the protocol basics.
I support the session-ID troubleshooting. It works fine and it works
now. For dialog matching we should work on a more general framework,
e.g. context-id or something else.
We can try secure call-id as a long term improvement of the protocol.
But we have to make sure that we do not cause problems for the existing
boxes and services which are up and running.
Laura
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Jiri Kuthan
Sent: Thursday, March 26, 2009 11:34 PM
To: Hadriel Kaplan
Cc: IETF SIP List
Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00
First of all I think it is definitely worth trying.
Not being able to correlate dialogs through B2BUA is a big
operational problem. I'm not sure that this will get really
adopted (who knows what today's obfuscators choose to obfuscate
tomorrow...). However in hope for solving this problem, presence of
incentives for adoption and absence of any known harm it is
definitely worth doing.
Another idea how to accommodate receivers that are silly not
to be liberal is using a fake IP address (popular 0.0.0.0).
While not aesthetic at all, it could accommodate such receivers
(under assumption they assign no syntactical meaning to it)
and signal to B2BUA there is no disclosure of IP addresses.
OTOH it could be time too to abandon 2543 legacy. Supporting
strict routing and other ancient stuff like IP in callid does
not seem worth the trouble to me.
-jiri
Hadriel Kaplan wrote:
Ooh, good point. Fair enough, I'll change that.
-hadriel
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of
Jonathan Rosenberg
Sent: Wednesday, March 25, 2009 4:51 PM
To: IETF SIP List
Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00
I didnt get a chance to say this at the mike.
You *cannot* change the BNF for the call-id. If you did,
you might end
up with the following problem:
A new UA gets built, compliant to this update. It is one of these
'aggressive parsing' UAs. It rejects any message which is
not compliant
to the BNF. An older, normal RFC-3261 compliant UA sends a
call-id which
includes the @-sign.
According to the BNF of this updated 3261, and based on
the strictness
of this aggressive-parsing UAs, it rejects that request as
non-compliant.
As such, you need to keep the BNF, but change the
normative language
such that an endpoint MUST NOT include the [@ host] but
MUST be prepared
to receive it.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 111 Wood
Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
[email protected]
http://www.jdrosen.net PHONE:
(408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
