30 Sep
2007
30 Sep
'07
2:33 a.m.
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(a)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?