Multiple Incoming SIP calls with identical Call-ID.
mungewell
I am attempting to figure out the solution to the problem where a
multi-pressence UA can have multiple incoming calls with the same
Call-ID (along with To and From). This situation can arise when a call
is forwarded between accounts and happens to arrive at the UA via
different accounts/routes.
http://www.ietf.org/rfc/rfc3261.txt says
--- page 12
Call-ID contains a globally unique identifier for this call,
generated by the combination of a random string and the softphone's
host name or IP address. The combination of the To tag, From tag,
and Call-ID completely defines a peer-to-peer SIP relationship
between Alice and Bob and is referred to as a dialog.
---
For example with FreeWorldDialup, a user can place a 'perminant
forward' on an account. This causes an incoming call that account to
ring both the account's UA and that of the forward destination.
If a UA is registered to both accounts it will receive 2 INVITEs with
identical call tags (Call-ID, To & From), hence the 'dialogues' are not
unique.
This example uses the 'Call Me' service from the FWD webpages to
initiate call.
---
INVITE sip:aaa...@xx.xxx.xx.x:5063;transport=udp SIP/2.0
CSeq: 2 INVITE
Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bKca7f.beaf88d4.3
Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bKca7f.aeaf88d4.0
Via: SIP/2.0/UDP 69.90.168.5:5060
User-Agent: eDial Server
From: "fwdu...@pulver.com"
<sip:5...@fwd.pulver.com>;tag=94919237611626883
Call-ID: 6489...@conf1.conference.libretel.com
To: sip:bbb...@fwd.pulver.com
Contact: sip:69.90.168.5:5060
---
INVITE sip:bbb...@xx.xxx.xx.x:5064;transport=udp SIP/2.0
CSeq: 2 INVITE
Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bKca7f.aeaf88d4.4
Via: SIP/2.0/UDP 69.90.168.5:5060
User-Agent: eDial Server
From: "fwdu...@pulver.com"
<sip:5...@fwd.pulver.com>;tag=94919237611626883
Call-ID: 6489...@conf1.conference.libretel.com
To: sip:bbb...@fwd.pulver.com
Contact: sip:69.90.168.5:5060
---
Although this example is deliberately caused, this situation could
exist in real world situations presumably un-intentionally.
This situation will not be detected by the proxies as a call loop, as
it is not a loop - they only see two unique requests as they look at
the 'via' information.
At present the UA solely uses the Call-ID to identify call channels,
this 'feature' is causing it to get confussed - treating the two
channels as a single enitity and therefore be unable to converse
correctly to the two SIP INVITEs.
Any suggestions on how to guard against this (ie, detect it), or to
harden the UA so that it can distinguish between these type of multiple
incoming calls?
Yours,
Simon.