28 Feb
2005
28 Feb
'05
11:48 a.m.
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
28 Feb
28 Feb
11:57 a.m.
New subject: [Serusers] Re: another cancel test
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.
12:11 p.m.
New subject: [Serusers] Re: another cancel test
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
12:43 p.m.
New subject: [Serusers] Re: another cancel test
Juha Heinanen wrote:
Andres writes:
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.
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
1 Mar
1 Mar
10:11 p.m.
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.
2 Mar
2 Mar
12:19 a.m.
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
12:36 a.m.
Juha Heinanen wrote:
Jan Janak 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.
if you have stateless INVITEs, you have to apply to CANCEL the same set
of modifications as for INVITE.
bogdan
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.
12:31 p.m.
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
1:15 a.m.
On 01-03 21:19, Juha Heinanen wrote:
Jan Janak writes:
I am sorry, I was wrong (I confused CANCELs with ACKs).
Jan.
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.
7004
days inactive
7006
days old
8 comments
4 participants
participants (4)
-
Andres -
Bogdan-Andrei IANCU -
Jan Janak -
Juha Heinanen