You should do no more than what you have done.
The R-URI in CANCEL should be the same as in INVITE. If you can determine
the call is for PSTN with INVITE, the same logic applies to CANCEL.
If the R-URI received from CANCEL is different to the one from INVITE, there
is a problem with that implementation.
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx
Sent: Friday, 11 March 2005 1:24 PM
To: serusers(a)lists.iptel.org
Subject: [Serusers] Routing Logic Question
Hi All.
I'm a confused when handling CANCEL messages when the call is
between my SER proxy and a PSTN gateway.
I've had a few discussions with Jan regarding when
lookup("location") needs to be called and as I understand it
CANCEL is sort of an odd message that is not really
mid-dialog, and therefore not record-routed. So
lookup("location") needs to be called before t_relay()ing a CANCEL.
This is fine for calls between two UAs on the same SER proxy
since both UAs have a contact record and lookup("location")
will return TRUE.
But when calling SIP->PSTN, and you hang up from the SIP
side, the CANCEL is sent from the SIP UA to SER. Then SER
tries to find the contact record in the location table, but
since this is a PSTN destination, lookup(location) returns
false, thus a 404 and the CANCEL is not relayed to the PSTN gateway.
So what is the best way to process CANCEL messages? Just ignore
lookup("location") when it returns false for CANCEL messages?
My basic ser.cfg is like this:
route {
# sanity checks
if (method!="REGISTER") record_route();
if (loose_route()) {
t_relay();
break;
};
if (uri!=myself) {
t_relay();
break;
};
if (uri==myself) {
if (method=="REGISTER") {
save("location");
break;
};
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
t_relay();
}
Regards,
Paul
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers