Problem with our custom reinvite management

[Lorenzo Miniero]

Hi Erik,
thanks a lot for the very quick answer!

>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?
>  
>

Yes, the call-ids surely match until then: the reinvite is handled fine, 
I suppose something goes wrong in a second moment, when the OK is 
compiled and sent back in reply to the reinvite.

>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")
>  
>

So this is the way to make mdbg lines appear! I redifined them as merr 
in libmutil, since I never saw them during debug, and this is how I 
monitored what was happening.

>Maybe you could provide some more information?
>
>Regards,
>Erik
>  
>

I saved the full debug of all that is happening in three different text 
files, every part preceeded by the internal state of Minisip at that moment:

    * _debug1.txt_ shows the first part:
         1. Minisip invites Asterisk;
         2. Asterisk replies (Trying and then OK);
         3. Minisip ACKs;
         4. Asterisk sends the reinvite (SDP+BFCP);
         5. Minisip replies with an OK (SDP+BFCP);
         6. Asterisk ACKs.
      The call-id so far is 162664392, but some weird things already
      appear, as the "stop_ringing" command sent to the MessageRouter
      after the invite_ok handling (which is probably caused by the fact
      an OK usually follows an INVITE after the user has physically
      accepted a remote call, while in this case this is a reinvite and
      Minisip is actually the client of the call, not the receiver),
      followed by a "call_terminated" shortly after...
    * _debug2.txt_ shows Asterisk trying to hang up the call by sending
      a BYE: the debug is mostly the same BYE retransmitted many times,
      since Minisip doesn't answer. I added a custom debug line that
      shows why the call-id check fails:

          SipDialog: 1869851581 at 192.168.1.100 != 162664392 at 192.168.1.100

      The correct call-id, as showed before, should be 162664392, but
      the check in SipDialog::handleCommand fails, since
      dialogState.callId returns 1869851581 instead.
    * _debug3.txt_ shows Minisip hanging the call from the gui (since
      apparently the call is still on), the same error happens if
      hanging up the call before the server does it: the BYE is never
      sent. The cause is probably the same, since the destination_id is
      set to 162664392 at 192.168.1.100 (and as we have seen before, the
      callid seems to have changed), but here the request is discarded
      in DefaultDialogHandler.

I attached to the txt debugs an Ethereal dump too: only the SIP & 
SIP/SDP packets are reported, so that you can see for yourself how 
exactly all the messages are. The files are all in the attached package.

Hope this is enough to have an overview of the possible problems: every 
opinion will be more than welcome!

Best regards,
Lorenzo

--
http://confiance.sourceforge.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdp_bfcp_minisip-devel.tar.gz
Type: application/x-gzip
Size: 6349 bytes
Desc: not available
Url : http://lists.minisip.org/pipermail/minisip-devel/attachments/20060815/befb7d04/sdp_bfcp_minisip-devel.tar.bin