Problem with our custom reinvite management

[Lorenzo Miniero]

Hi you all,
always Lorenzo from the Confiance Project here: I write you to ask you 
some indication about a problem I've met.

We're working on the new version of the project, and one of the features 
is enabling the transport of BFCP information in custom SDP lines, which 
is to be done through a reinvite from the server.
Since I know Minisip doesn't support reinvites yet, we tried to add some 
rough reinvite management on our own, and we did it by adding a new 
transaction to SipDialogVoip, "transition_incall_incall_INVITE", which 
briefly does the following:

    * we get the info on BFCP from the reinvite's SDP, if present (we
      added some custom get methods in SdpPacket for this), and if so we
      dispatch it to the gui where CallWidget intercepts and manages it;
    * then we reply with an OK to which we add our reply info on BFCP in
      SDP too, else the server would retransmit the reinvite indefinitely.

To send the OK to the reinvite we took sendInviteOk from 
SipDialogVoipServer as inspiration, changing what had to be changed to 
make it work: for example making the method use the SdpOffer and not the 
SdpAnswer, and using a casting of command.getCommandPacket instead of 
getLastInvite. The management of the reinvite is indeed very rough, 
since we assume that all the media lines are unchanged, and we only get 
the m-line and a-lines regarding BFCP.

To make it brief, everything works, the BFCP info is correctly parsed 
and passed to the gui, which then uses it as it should; the OK to the 
reinvite is correctly completed with BFCP info in its SDP and sent, and 
then the ACK from the server is correctly received (I checked all this 
with Ethereal too). The problem is that after this, I don't seem to be 
able to hang up the active call anymore, neither by hanging up from 
Minisip, nor by receiving a BYE from the server: both the signals are 
ignored or discarded by Minisip. As far as I've understood, the problem 
could be that Minisip, after or while sending the OK to the reinvite, 
creates a new callid for the call different from the callid of the 
original call: in fact by debugging I noticed that Asterisk's BYEs are 
discarded because the callid check fails (if I print the local callid 
and the one from the message, they're different). However, why then 
would the BYE be discarded, while the ACK to the reinvite's OK be 
accepted? Both the ACK and the BYE have the same callid...

Do you know what could be the cause of the problem? I don't know if you 
already tried to make some work on reinvites on your own too, but I 
really could use even only some indication on where to look for this in 
the code. Of course if you think our modifications can be of any use for 
you just tell me and I'll mail it to you.

Thanks in advance for every help you'll be able to give us, I hope to 
hear you soon.

Lorenzo

--
http://confiance.sourceforge.net/