Hi all,
during my tests for the cr module i noticed some differences in the reply matching in sr tm and kamailio tm. My test "26" basically test the (cr) failure_route functionality with a simple sipp scenario.
On kamailio 1.5 branch my test is successful, the 503 reply is matched against the first INVITE and the failure_route is entered. On sip-router its not matched, a local 408 is generated after some time. I've attached the sip trace and the debug logs from both tests runs.
Perhaps the sip-router tm is more strict in the matching, so because of some problem in the sipp scenario it don't match? Would be cool if somebody with more experiences with sr tm could take a look to this. The scenario, configuration and test is test/unit/failure_route.xml, 26.cfg and 26.sh (same directory).
Thanks,
Henning
On May 20, 2009 at 16:15, Henning Westerholt henning.westerholt@1und1.de wrote:
Hi all,
during my tests for the cr module i noticed some differences in the reply matching in sr tm and kamailio tm. My test "26" basically test the (cr) failure_route functionality with a simple sipp scenario.
On kamailio 1.5 branch my test is successful, the 503 reply is matched against the first INVITE and the failure_route is entered. On sip-router its not matched, a local 408 is generated after some time. I've attached the sip trace and the debug logs from both tests runs.
Perhaps the sip-router tm is more strict in the matching, so because of some problem in the sipp scenario it don't match? Would be cool if somebody with more experiences with sr tm could take a look to this. The scenario, configuration and test is test/unit/failure_route.xml, 26.cfg and 26.sh (same directory).
It's a bug, not in tm, but in parse_cseq/parse_method, introduced when parse_cseq from ser was merged with parse_cseq from kamailio (we can celebrate the first discovered merge bug :-).
Thanks for the nice bug report, I'll try to fix it today.
Andrei
[...]