2016-03-18 Daniel-Constantin Mierla <mico...@gmail.com> wrote: > My guess that the sbc_5 is so poor implemented that it takes the Via > from last request, which is CANCEL, but CANCEL is a hop-by-hop request > in this case. If my guess is confirmed, the implementation of sbc_5 is > really far away from RFC3261, something that I haven't probably seen > since 2002/3. > > To test, you can try to use forward() for CANCEL instead of t_relay(). > But you need to know where to send it -- same address as for INVITE -- > you can hardcode some values in config for sake of simplicity to test. A > proper workaround can be built using htable module to store where the > invite was sent, using call-id as a key.
Hi Grant, Daniel I accidentally found this 2016 thread and wanted to share my different solution. I ran into similar issue: 487 reply from SIP phone UA came with insufficient Via headers after CANCEL. In fact situation looked exactly like described above: Via stack for reply to INVITE seem to be taken incorrectly from CANCEL. I did not observe any errors from Kamailio, but Asterisk chan_sip (original INVITE sender) spits: --- parse_via: received request without a Via header handle_incoming: Dropping this SIP message with Call-ID 'abc', it's incomplete --- My quick solution was to reply locally with t_reply() when branch with missing second via was winning: --- ...usrloc lookup()... +t_on_branch_failure("TOUSER"); t_on_failure("FAILURE_TOUSER"); route(RELAY); +event_route[tm:branch-failure:TOUSER] +{ + # Save branch ruid if broken Via detected + # If this branch wins, Via will be "fixed" with local reply + if ( $T_rpl($sel(via[2])) == $null ) $avp(secondviamissing) = $T(ruid); +} + failure_route[FAILURE_TOUSER] { + if ( $avp(secondviamissing) != $null && $avp(secondviamissing) == $T(ruid) ) + { + # Some UAs (VP530P 23.70.74.5) seem to copy Via stack from CANCEL + # Lets "add" missing Via by creating internal reply + append_to_reply("X-log: viafix\r\n"); + t_reply("$T(reply_code)", "$T_reply_reason"); + exit; + } } --- That seems to do the trick, at least in simple non-branching case. What do you think? (other than using single $avp(secondviamissing) for whole transaction...) -- Mikko _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users