Am Mittwoch, 5. September 2018, 14:03:10 CEST schrieb Володимир Іванець:
I wanted to ask those who know if Kamailio's behavior I'm facing is expected or I should make some improvements to the configuration. Kamailio version is 5.1.0.
I have a route where RTPEngine parameters are being collected and *rtpengine_offer()* is called. After that *t_on_reply("REPLY_SIP_TO_SIP");* followed by the *t_on_failure("FAILURE_SIP_TO_SIP");* are used. The idea is to process all responces except 415 or 488 from UAC as usual in *onreply_route[REPLY_SIP_TO_SIP]* and use *failure_route[FAILURE_SIP_TO_SIP]* to update SDP with *rtpengine_offer()* if necessary.
*onreply_route[REPLY_SIP_TO_SIP]* just goes to *exit;* if *$rs* equals 415 or 488. This works fine with Htek phone which sends 100, 180 and then 488. But I can not see *failure_route[FAILURE_SIP_TO_SIP]* execution for calls to Zoiper which replies with 100 and immediately 415.
t_on_failure(failure_route) documentation says: "Sets failure routing block, to which control is passed after a transaction completed with a negative result but before sending a final reply." and to be honest I don't really understand how lacking of responce prevents failure_route from executing.
Hello,
I did not understand you completely here. Did you receive a 415 and the failure route is not entered, or you did not receive a response as stated in the last sentence?
If the failure_route is entered for the 488, then it should be also entered for the 415. I am not aware of a special handling of this code in tm. (Only that 415 is one of the replies that get a priority comparing to normal 4xx.)
I would suggest to try with debugging enabled and compare the logs for a working, and for a non-working call. You could also try to concentrate on one problem first, like the failure_route topic, and then combining this with the reply_route.
Best regards,
Henning