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 [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
