Stopping call execution deep in a promise chain

[WhiteyDude]

Hi Dave,

This may be a dumb question as I'm not a node/modern JS guy, but how do you stop execution of a call on an error condition within chained promises?

https://gist.github.com/WhiteyDude/8dfe7c612cafa7dbf6f3970d5f8d946e

In the commented spot where I wish to stop execution, I've tried using a next() I've seen in examples, and I've tried returning a res.send(). However execution continues and the console.log is triggered. This works perfectly if I return it from within the main invite handler:

https://gist.github.com/WhiteyDude/98f21cc61e306ae340dcce7e691f67b1

I figure because it's within a promise (which I'm also new to), it doesn't return before execution continues. Is there a function I can call to do this, or a clean way to make this blocking?

Thanks!

[davehorton]

Hi there!

Since you aren't that familiar with Promises, I'd just suggest you go straight to using the "async / await " syntax for dealing with Promise-returning functions, since that is a bit easier.

using that, here is my version of your function, that does what you need:

https://gist.github.com/davehorton/c4d99329c43f8530c4e3f0ed95fe3189

A few points:

• you were using req.msg.headers.to to get the value of the To header -- be advised you can do that simply by req.getHeader('To'). And if you wanted instead of the raw To header a JSON object containing its components (ie 'user', 'host', etc), you could do req.getParsedHeader('To').
• you supply your own parsing function to parse the To header (calls.parseUri), but be advised you can also use this one from the library: const parseUri = require('drachtio-srf').parseUri
• you are using a lot of global variables in your code, which you should not do. See my gist for comparison.
• Your calls.check_is_valid function returns a Promise, which is fine if it needs to do something asynchronous like go hit a database....if its not doing anything async then just return the value directly. However, if you are going to use return a Promise, then the typical way to signal failure is to reject the Promise in calls.check_is_valid rather than returning a null value. This is kind of up to you though.

[davehorton]

I made a slight update to my example -- I'd forgotten to reject the incoming INVITE if we fail to connect to the media server in some way.

[WhiteyDude]

Wow, thanks so much Dave! I just wanted a little direction, you’ve completely refactored the code for the better!

I’ve removed my custom parsing function - I’m not amazing at regex either so it wasn’t great!

I can’t find in any of the docs or API reference where req.calledNumber or parseUri() are mentioned. Can you point me to these so I can see if I’m writing more duplicate functions?

Also thanks so much for for writing and releasing drachtio! It’s completely changing how I do voice, and it’s an absolutely pleasure. Looking forward to seeing your talk at CommCon next month!

[WhiteyDude]

Also just to confirm, in the scenario where the check_is_valid returns true, I'd put that further execution into the else?

https://gist.github.com/WhiteyDude/e1a9d19f09e098dd6d72865c301e440c#file-sample-js-L20

Thanks!

[davehorton]

yes, that looks good.

[WhiteyDude]

Thanks so much for your help!

[davehorton]

I forgot to point you to the docs you requested

req.calledNumber is described here:

https://drachtio.org/api#message-prop-called-number

Note that SipRequest inherits from SipMessage so it has access to all those properties

Srf.parseUri described here:

https://drachtio.org/api#Srf-properties

[WhiteyDude]

Thanks so much Dave!

I've come across one more thing I need to ask.

When I'm calling the media server's ep.bridge() I can await this, however this returns upon the bridge connecting. Is there a way to wait for the bridges disconnection (e.g. one party hanging up)? Or would this be best handled with the on('destroy') event? I've been await chaining to force sync operations for now, but I suppose I'll have to encapsulate this one within an if/then/else scenario if I need to catch it in the on('destroy').

Thanks!

Also, is there a better way to ask for help than github issues? I'm conscious people generally like to reserve this area for bug reports/feature requests etc.

[davehorton]

Sorry for the late response.

I think if you want to wait for one party hanging up, the dlg.on('destroy',.. is the way to do it. I usually have a handler for that and then explicitly destroy any related endpoints (you can also explicity call unbridge on an endpoint, but that is unnecessary if you are destroying either or both of them).

github issues are fine, and preferred in fact since hopefully other people may learn from them