none
OpenAsync on 2nd session causes 1st to disconnect RRS feed

  • Question

  • Hello - I have a problem with supervised transfer.

    My application worked fine with the TAP version of teh software, but when this expired at the end of december we had to install the developer edition.

    The code has not changed, but supervised transfer now fails.

     

    The original session is placed on hold and a new consultation session is created - appears to work fine and no errors are thrown - however the original session actually gets disconnected as soon as the consultation session is connected and so when the two sessions are joined it fails.

    The code works fine in debug mode, but failes when its connected to a real SIP peer.

     

    Seems to be that something could be causing only one session to be allowed, therefore forcing the other to disonnect.

     

    Has anyone any ideas what might be going on and how to fix it?

     

    _telephonySession.HoldCompleted += TelephonySession_HoldCompleted;

    _telephonySession.HoldAsync();

     this code executes and the state of _telephonySession is "connected"

     

    it remains in the connected state until this code is executed

    _consultationSession.OpenCompleted += ConsultationSession_OpenCompleted;

    _consultationSession.OpenAsync(CalledParty, CallingParty);

     

    as soon as the _consultationSession.OpenAsync executes, the original _telephonySession is disconnected.

    We haven't changed anything code-wise, but have installed the developer edition of MSS.

     

    Can anyone help?

     

    Thanks

     

    Christine

    Tuesday, January 15, 2008 4:55 PM

All replies

  • There is a SupervisedTransfer sample application.  Try this - does it work?  If so, compare it to your code to see what the differences are. 

     

    Wednesday, January 16, 2008 11:56 AM
  • Actually, I know whats up now - the system works fine on our TAP version of MSS.  We have been developing it for over a year as MSS TAP partners of Microsoft , so I know its not a matter of code.

    However, when the TAP licences ran out we had to install the developer edition on W2K3 R2 - and this was when we saw the problem.

     

    If I go back to the TAP enterprise edition s/w it works fine, so its not the VoIP gw, its not the PBX and its not our code - if I install the dev edition then as I said before, the originaly session gets disconnected as soon as the consultation session gets opened.

     

    There is a limitation on the number of concurrent connection on the dev edition when its running on XP and vista, but this should not be the case when its running on W2K3 R2 - but nonetheless it appears to be so...

     

    My work around for the time being is to use the TAP s/w until after our next round of demos, but its odd behavoiur nonthe less.

     

    Wednesday, January 16, 2008 2:03 PM
  • "There is a limitation on the number of concurrent connection on the dev edition when its running on XP and vista, but this should not be the case when its running on W2K3 R2 - but nonetheless it appears to be so..."

     

    As you say, this limit only applies on XP / Vista.  If you were hitting it, the OpenAsync on the consultation session would fail, it wouldn't disconnect the original session.

     

     

    "If I go back to the TAP enterprise edition s/w it works fine, so its not the VoIP gw, its not the PBX and its not our code "

     

    When you say "TAP edition" do you mean TAP or Beta?  I hope you mean the latest Beta.  Changes were made between each pre-RTM version, and I don't recall whether there were any that affected SupervisedTransfer between Beta and RTM.  My suggestion to try out & compare to the SupervisedTransfer sample app was as a quick way to test whether there were any such changes, either to Speech Server API or behaviour (which might require a change to the app) or Speech Server SIP implementation (which would change how it talks to your GW). 

    Wednesday, January 16, 2008 2:24 PM