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
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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Friday, 11 March 2005 1:24 PM To: serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks Zeus - that makes sense. I don't know why I didn't think of that :-)
Paul
On Fri, 11 Mar 2005 14:25:05 +1100, Zeus Ng zeus.ng@isquare.com.au wrote:
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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Friday, 11 March 2005 1:24 PM To: serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
See inline.
Java Rockx wrote:
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.
A CANCEL only has a meaning before the final response (OK) is sent from the other UA. The CANCEL is matched using CSeq. However, AFAIK CANCEL can also be record-routed. It is only REGISTER messages that exclicitly (RFC3261) should not be record routed as it does not establish a dialog. However, record routing does not really help you with regards to lookup("location") as record-routing will give you the answer (ex. Call leg does not exists etc). One thing though, even though CANCEL should be handled as an INVITE, CANCEL cannot have authentication information and if your routing logic for CANCEL triggers an authentication, the CANCEL will not reach its destination.
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?
How do you handle INVITEs when lookup("location") fails? The request-URI should be the same as the initial INVITE and you should thus be able to do exactly the same with CANCELs. Even if you do lcr.
g-)
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Greger V. Teigre -
Java Rockx -
Juha Heinanen -
Zeus Ng