andres,
i made another simpler cancel test. first sip:jh@test.fi invites sip:gs@test.fi, and gs starts ringing. then jh sends cancel to r-uri sip:gs@test.fi, which ser.cfg immediately at the start of the script t_relay()s out, i.e., without doing anything to the request. the result is that ser correctly sends a cancel to the ip address/port of gs.
my conclusion of this is that cancels don't need to be processed by ser.cfg, just relayed out. perhaps others familiar with tm mystics can confirm or deny this.
-- juha
Juha Heinanen wrote:
andres,
i made another simpler cancel test. first sip:jh@test.fi invites sip:gs@test.fi, and gs starts ringing. then jh sends cancel to r-uri sip:gs@test.fi, which ser.cfg immediately at the start of the script t_relay()s out, i.e., without doing anything to the request. the result is that ser correctly sends a cancel to the ip address/port of gs.
my conclusion of this is that cancels don't need to be processed by ser.cfg, just relayed out. perhaps others familiar with tm mystics can confirm or deny this.
That may be true for users that are local to the SER, but I just made a simple test on my lab server (with CVS HEAD), and it does not work for PSTN redirections.
A simple routing scenario like the one below will send the INVITE to route(7), but the CANCEL will never get there. The only way the CANCEL gets there is to place another if statement with reference to method=="CANCEL" and route it.
if (method=="INVITE") { if ((uri=~"sip:01305[0-9]{7}@.*")){ if (!is_user_in("credentials","ld")) { route(7); break; }; }; }; . . route[7] { rewritehostport("XXXX.telesip.net:5066"); if (!t_relay()) { sl_reply_error(); };
This is frustrating:(
Andres.
Andres writes:
That may be true for users that are local to the SER, but I just made a simple test on my lab server (with CVS HEAD), and it does not work for PSTN redirections.
it should not matter if r-uri is rewritten as result of location lookup or rewritehostport.
A simple routing scenario like the one below will send the INVITE to route(7), but the CANCEL will never get there. The only way the CANCEL gets there is to place another if statement with reference to method=="CANCEL" and route it.
are you sure that your script calls t_relay() on the cancel request? if so, where according to ethereal did ser sent the cancel or did you get some error message in syslog? has your gw replied with trying or ringing before you issue cancel?
-- juha
Juha Heinanen wrote:
Andres writes:
That may be true for users that are local to the SER, but I just made a simple test on my lab server (with CVS HEAD), and it does not work for PSTN redirections.
it should not matter if r-uri is rewritten as result of location lookup or rewritehostport.
A simple routing scenario like the one below will send the INVITE to route(7), but the CANCEL will never get there. The only way the CANCEL gets there is to place another if statement with reference to method=="CANCEL" and route it.
are you sure that your script calls t_relay() on the cancel request? if so, where according to ethereal did ser sent the cancel or did you get some error message in syslog? has your gw replied with trying or ringing before you issue cancel?
Just found the mistake in our ser.cfg. It turns our that at the bottom of our main logic we had our Voicemail routing code. So if local user was not in location database then the call was to be routed to Voicemail (route 6). This was below all of our PSTN gateway routing code. I never even considered that the CANCEL message would pass through that part but I guess it did!
# If destination user is OFFLINE then send to Voicemail Server if ((!lookup("location")) { if (method == "INVITE"){ route(6); break; } else { sl_send_reply("404", "Not Found"); break; }; };
Changing the code to the following fixed the issue:
# If destination user is OFFLINE then send to Voicemail Server if ((!lookup("location")) & (does_uri_exist())) { if (method == "INVITE"){ route(6); break; } else { sl_send_reply("404", "Not Found"); break; }; };
Thanks Juha for your valuable insight. We will now be making more extensive testing your LCR module now that we worked out this issue. We will let you on the results.
Regards, Andres.
-- juha
On 28-02 08:48, Juha Heinanen wrote:
andres,
i made another simpler cancel test. first sip:jh@test.fi invites sip:gs@test.fi, and gs starts ringing. then jh sends cancel to r-uri sip:gs@test.fi, which ser.cfg immediately at the start of the script t_relay()s out, i.e., without doing anything to the request. the result is that ser correctly sends a cancel to the ip address/port of gs.
my conclusion of this is that cancels don't need to be processed by ser.cfg, just relayed out. perhaps others familiar with tm mystics can confirm or deny this.
Actually I think that you should apply exactly the same logic as when processing the INVITE. CANCEL can be also sent end-to-end and in this case the user location lookup would be necessary to route it to the callee.
Jan.
Jan Janak writes:
Actually I think that you should apply exactly the same logic as when processing the INVITE. CANCEL can be also sent end-to-end and in this case the user location lookup would be necessary to route it to the callee.
jan,
under what circumstances cancel is sent end-to-end? my understanding from rfc3261 is that if a proxy has STATEFULLY forwarded an invite, the corresponding cancel is always a hop-by-hop request. if invite was forwarded statelessly, then also cancel must be forwarded statelessly in the same way as invite, because there is no response context for it.
so, if ser.cfg forwards all invites statefully, t_relay can be called on cancels without any request uri rewriting.
-- juha
Juha Heinanen wrote:
Jan Janak writes:
Actually I think that you should apply exactly the same logic as when processing the INVITE. CANCEL can be also sent end-to-end and in this case the user location lookup would be necessary to route it to the callee.
jan,
under what circumstances cancel is sent end-to-end? my understanding from rfc3261 is that if a proxy has STATEFULLY forwarded an invite, the corresponding cancel is always a hop-by-hop request. if invite was forwarded statelessly, then also cancel must be forwarded statelessly in the same way as invite, because there is no response context for it.
so, if ser.cfg forwards all invites statefully, t_relay can be called on cancels without any request uri rewriting.
SER does hop-by-hop CANCEL propagation. If the corresponding INVITE was forwarded statefully, TM will forward the CANCEL to exactly the same RURI as the INVITE disregarding completely the original CANCEL RURI - so in this case you have just to relay the CANCEL and TM will take care to send it to the right location. if you have stateless INVITEs, you have to apply to CANCEL the same set of modifications as for INVITE.
bogdan
Bogdan-Andrei IANCU writes:
SER does hop-by-hop CANCEL propagation. If the corresponding INVITE was forwarded statefully, TM will forward the CANCEL to exactly the same RURI as the INVITE disregarding completely the original CANCEL RURI - so in this case you have just to relay the CANCEL and TM will take care to send it to the right location.
thanks bogdan for confirming this. and to jan, thanks that you answered.
-- juha
On 01-03 21:19, Juha Heinanen wrote:
Jan Janak writes:
Actually I think that you should apply exactly the same logic as when processing the INVITE. CANCEL can be also sent end-to-end and in this case the user location lookup would be necessary to route it to the callee.
jan,
under what circumstances cancel is sent end-to-end? my understanding from rfc3261 is that if a proxy has STATEFULLY forwarded an invite, the corresponding cancel is always a hop-by-hop request. if invite was forwarded statelessly, then also cancel must be forwarded statelessly in the same way as invite, because there is no response context for it.
I am sorry, I was wrong (I confused CANCELs with ACKs).
Jan.
-
Andres -
Bogdan-Andrei IANCU -
Jan Janak -
Juha Heinanen