endPoint.play does not return if call end by RemoteParty

[haeferer]

we have a sample conneting to a local PhonerLite.

AsyncMain(process.mainModule == module, async () => {
    const srf = new Srf();
    srf.connect({host: '172.22.17.11', port: 9022, secret: 'cymru'});
    let hostport = await waitForEvent<string>(srf, 'connect');
    console.log('Connected ', hostport);
    const mrf = new Mrf(srf);
    let mediaserver = await mrf.connect({listenAddress: '172.22.17.9', address: '172.22.17.11', port: 8021, secret: 'ClueCon'});
    console.log('MediaServer Available');
    let endPoint = await mediaserver.createEndpoint();
    console.log('Endpoint created',endPoint.local.sdp);
    let dialog = await srf.createUAC('sip:[email protected]:5070', {
        localSdp: endPoint.local.sdp,
    }, {
        cbRequest: (err,req, res) => {
            console.log('CbReq...', err, );
        },
        cbProvisional: (res) => {
            console.log('ProvisionalResp...',res.status+' '+res.reason)
        }
    });
    await endPoint.dialog.modify(dialog.remote.sdp);
    dialog.on('destroy', (msg, reason) => {
        endPoint.destroy();
        console.log('got bye', reason);
    })
    console.log('Established');
    await waitFor(1000);
    await endPoint.play(['silence_stream://1000', 'voicemail/8000/vm-record_message.wav']);
    console.log('Done Playing')
    await endPoint.execute('send_dtmf', '1234@100');
    // console.log('done Play file');
    let answer = await endPoint.playCollect({file: 'silence_stream://200', min: 1, max: 4});
    console.log(answer);
    await waitFor(5*1000);
    console.log('Dest. Dialog');
    await dialog.destroy();
    console.log('Done');

});

The Playback works, but if the remoteparty (Phonerlite) hangs up during playback the Promise

await endPoint.play(['silence_stream://1000', 'voicemail/8000/vm-record_message.wav']);

never ends...

The destroy event from Dialog is fired

console.log('got bye', reason);

[haeferer]

The Result is the same with or without

await endPoint.dialog.modify(dialog.remote.sdp);

It is realy needed to Populate the remote.sdp (i think so?)

[davehorton]

Yes, this is how it currently works. If you destroy the Endpoint (as you do in the 'destroy' handler for the sip dialog) then any operations are terminated by freeswitch and those promises won't resolve .

I suppose it would be more correct to have those promises be rejected (or callbacks invoked with an error) that indicate the call / session was terminated? In practice, I have never had the need to want to receive those since once the call is over I implicitly know all operations have ceased and I mostly proceed to doing my cleanup code. I can take a deeper look at this, but would be good to know what you expect....a Promise rejection, as I suggest above?

[haeferer]

A Promise rejection wood be perfect. Even if I know the Endpoint is destroyed i‘m not able to reject a Promis, even if I have the promise (and normally only the creator of the promise should resolve or reject). Best solution would be promises „owned“ by Endpoint so all promises can be rejected if the endpoint is destroyed/ crashed whatever. Von meinem iPhone gesendet Am 23.11.2018 um 19:00 schrieb Dave Horton <[email protected]<mailto:[email protected]>>: Yes, this is how it currently works. If you destroy the Endpoint (as you do in the 'destroy' handler for the sip dialog) then any operations are terminated by freeswitch and those promises won't resolve . I suppose it would be more correct to have those promises be rejected (or callbacks invoked with an error) that indicate the call / session was terminated? In practice, I have never had the need to want to receive those since once the call is over I implicitly know all operations have ceased and I mostly proceed to doing my cleanup code. I can take a deeper look at this, but would be good to know what you expect....a Promise rejection, as I suggest above? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#9 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYvpiO1F36TBfmT2O1te7Nc-y665pZdWks5uyDezgaJpZM4YwlgY>.

[haeferer]

How do you end a Promise if your Code waits on the Promise. Maybe this is only needed for persons like me, working with async functions. Von meinem iPhone gesendet Am 23.11.2018 um 19:00 schrieb Dave Horton <[email protected]<mailto:[email protected]>>: Yes, this is how it currently works. If you destroy the Endpoint (as you do in the 'destroy' handler for the sip dialog) then any operations are terminated by freeswitch and those promises won't resolve . I suppose it would be more correct to have those promises be rejected (or callbacks invoked with an error) that indicate the call / session was terminated? In practice, I have never had the need to want to receive those since once the call is over I implicitly know all operations have ceased and I mostly proceed to doing my cleanup code. I can take a deeper look at this, but would be good to know what you expect....a Promise rejection, as I suggest above? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#9 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYvpiO1F36TBfmT2O1te7Nc-y665pZdWks5uyDezgaJpZM4YwlgY>.

[haeferer]

At the end I think a Promise should always end by the component which created the Promise (even by timeout). Only this way it’s possible for booth sites to continue correctly (means „at a trusted state“). Second problem would be a possible memory leak by unresolved promises / or never called callbacks! Von meinem iPhone gesendet Am 23.11.2018 um 20:47 schrieb Häferer, Andreas <[email protected]<mailto:[email protected]>>: How do you end a Promise if your Code waits on the Promise. Maybe this is only needed for persons like me, working with async functions. Von meinem iPhone gesendet Am 23.11.2018 um 19:00 schrieb Dave Horton <[email protected]<mailto:[email protected]>>: Yes, this is how it currently works. If you destroy the Endpoint (as you do in the 'destroy' handler for the sip dialog) then any operations are terminated by freeswitch and those promises won't resolve . I suppose it would be more correct to have those promises be rejected (or callbacks invoked with an error) that indicate the call / session was terminated? In practice, I have never had the need to want to receive those since once the call is over I implicitly know all operations have ceased and I mostly proceed to doing my cleanup code. I can take a deeper look at this, but would be good to know what you expect....a Promise rejection, as I suggest above? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#9 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYvpiO1F36TBfmT2O1te7Nc-y665pZdWks5uyDezgaJpZM4YwlgY>.

[haeferer]

we had solved the problem by implementing a BreakablePromise. This class implements a Set of Promises. If an event (like destroy) occurs, all promises in unresolved( like on .play or .playCollect) will be broken (resolved) with a special error.

[davehorton]

ok. I'm still going to look into properly resolving/rejecting those promises. let's leave this issue open until I do so.

[haeferer]

So far i‘ve build a BreakablePromise Wrapper, to break alle unresolved Promises for an endpoint in case of an destroy event. Von meinem iPhone gesendet Am 30.11.2018 um 16:23 schrieb Dave Horton <[email protected]<mailto:[email protected]>>: ok. I'm still going to look into properly resolving/rejecting those promises. let's leave this issue open until I do so. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#9 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYvpiJ-QoYgcPVR5fzHDHCspmHjYO2R3ks5u0U1_gaJpZM4YwlgY>.