Problem with our custom reinvite management

[Erik Eliasson]

If the transition in SipDialogVoip gets the packet, then the CallId
should match?! If the CallId did not match the dialog, then it would not
be a re-invite, right?

I can't add much else to your analysis without some additional
information.

If you have enabled debugging, then you can press "+" and then enter in
the console to show the current internal state of the sip stack. If you
press "p" and then enter you will see all the packets. "d" will make the
debug output more verbose. (if you use the textui then the commands are
"+", "show packets" and "show debug")

Maybe you could provide some more information?

Regards,
Erik


On Tue, 2006-08-15 at 15:02 +0200, Lorenzo Miniero wrote:
> 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/
> _______________________________________________
> Minisip-devel mailing list
> Minisip-devel at minisip.org
> http://lists.minisip.org/mailman/listinfo/minisip-devel
-- 
Erik Eliasson <eliasson at it.kth.se>