there is a broken grandstream sip ua that sometimes sends two initial invites back-to-back. according to wireshark, sr received them about 10 microseconds apart. sr then forwards the request to pstn gw, but i don't have wireshark dump of that side of the traffic. anyway, from the ua side i see that about 10 milliseconds after receiving the invites, sr replies to the ua "503 no more gateways available".
in my config that reply comes only from GW_FAILURE failure route, which is set up like this:
t_on_failure("GW_FAILURE"); t_set_fr("120000", "5000"); t_relay()
so no way should failure route get executed before 5 seconds, but in this back-to-back invite case it somehow gets executed almost immediately. i have not seen this behavior in other situation.
this looks like a bug to me. perhaps there is some race condition causing it? version of sr where this appears is 3.0.3.
-- juha
On Sep 30, 2010 at 14:10, Juha Heinanen jh@tutpro.com wrote:
there is a broken grandstream sip ua that sometimes sends two initial invites back-to-back. according to wireshark, sr received them about 10 microseconds apart. sr then forwards the request to pstn gw, but i don't have wireshark dump of that side of the traffic. anyway, from the ua side i see that about 10 milliseconds after receiving the invites, sr replies to the ua "503 no more gateways available".
in my config that reply comes only from GW_FAILURE failure route, which is set up like this:
t_on_failure("GW_FAILURE"); t_set_fr("120000", "5000"); t_relay()
so no way should failure route get executed before 5 seconds, but in this back-to-back invite case it somehow gets executed almost immediately. i have not seen this behavior in other situation.
this looks like a bug to me. perhaps there is some race condition causing it? version of sr where this appears is 3.0.3.
Are you sure that it does not receive a negative reply from the gateway that triggers the failure route?
Do you have any t_*() before t_on_faile() (e.g. t_newtran())? Anything special if t_relay() fails immediately?
Andrei
Andrei Pelinescu-Onciul writes:
Are you sure that it does not receive a negative reply from the gateway that triggers the failure route?
andrei,
as i mentioned, i don't have yet wireshark dump from gw side, but i see from sr syslog entry that sr is receiving "186 session progress" from the gw about 1 second later than sr had already sent "503 no more gateways" to the ua. so it is highly unlikely that the gw would send 186 after a negative reply.
Do you have any t_*() before t_on_faile() (e.g. t_newtran())? Anything special if t_relay() fails immediately?
this is the complete list of tm calls made:
t_on_reply("REPLY"); # includes t_check_status() calls t_on_failure("GW_FAILURE"); t_on_branch("PSTN_BRANCHES"); # PSTN_BRANCHES doesn't include tm stuff t_set_fr("120000", "5000"); t_relay();
i'll try to get a full pcap showing both ua and gw side.
-- juha
-
Andrei Pelinescu-Onciul -
Juha Heinanen