There are two types of CANCEL, one is in-dialog (and will be loose routed) while the other is CANCELing before the dialog is set up. The correct way to handle such CANCELs is to run the same routing logic on the CANCEL as for the INVITE. If you send all CANCELs directly to PSTN, you will get a problem with cancelling of local calls. g-)

x-ser@sidell.org wrote:

I'm working with the gw-pstn.cfg example, and am having a problem with canceling outbound pstn calls.

The invite step seems to work fine. Function route[3] checks for a pstn in the uri, and uses route[5] to route outbound calls to the pstn gateway.

But, if the originating client cancels the call before it gets connected, the cancel sip message doesn't go through the same route[3] -> route[5] processing. Instead, the processing ends up falling through to the end of the main route() function, where lookup("location") fails, because the pstn in the LHS of the uri doesn't match any known registered local devices. So, the client gets a "404" error, and the target pstn keeps ringing.

It seems to me that all messages, not just the invites, need to be rerouted as they are in route[5], so that they are sent to the pstn gateway, and aren't processed as if for a local device.

Am I missing something here? Have I not configured everything correctly?