I have encountered a bug in my conference patch that is a
result of mess
in mixing callIDs and sessionCallIDs in existing code.
When we dial, we first create a call and associated
CpPeerCall. Since we
don't know SIP CallID we give it an ID with prefix
"c". Once we connect
the call, we fill sessionCallID in SIPX_CALL_DATA with SIP
CallID which
begins with "s". This is for outbound calls.
But for inbound calls, these 2 get mixed. Sometimes
CpPeerCall will have
ID with "c" prefix, sometimes with "s"
(s is SIP callID). SipConnection
always has ID with "s" prefix. The problem is, if
there is inbound call,
we are told only the SIP callID, not the CpPeerCall ID since
event gets
fired from sipxtacklib. So in sipxtapi we dont know the
correct ID of
CpPeerCall if its an inbound call (as it can be
"s" or "c").
These 2 were being mixed in conferencing code too, before my
patch
(which is not applied yet, it is not final). I changed it
and now they
are separate.
Since we can have a CpPeerCall with multiple media
connections (in
conferences), shouldn't we have always different IDs for
connection and
the CpPeerCall? That way we would be able to uniquely
identify just the
connection or the whole CpPeerCall. In the future, we would
be able to
clean up some mess that exists in sipxtapi & sipxcalllib
due to this ID
problem.
If we wanted to have different Ids, we would either have to
stop firing
events from sipxtacklib into sipxtapi directly, and do it
via
sipxcalllib (where we can locate the corresponding
CpPeerCall), or in
sipxtapi during NEWCALL event we would have to query
callmanager for the
ID of the corresponding CpPeerCall so we can update the
SIPX_CALL_DATA
structure properly with both IDs.
If you think IDs shouldnt be kept separate, then
conferencing code
cannot use existing call for conference shell. It will have
to create
new call with unique callID, and null sessionCallID. This is
to prevent
problems after conference join/split. This solution should
work, but we
will still have messy IDs.
Whats your opinion?
I need to fix this and would prefer to do it in a way which
can be
accepted in a patch.
Jaroslav Libak
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev list.sipfoundry.org
List Archive: http
://list.sipfoundry.org/archive/sipxtapi-dev/
|
