Hello,
On 14.08.17 14:30, Mikko Lehto wrote: > 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...) > Could be a workaround, indeed. But I guess you can do it directly in the failure_route, without event_route, testing if the reply has a second via there and using t_reply() if not. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users