Hi Daniel, Thar is correct, the top Via header branch param differs (has a .1 instead of .0 at the end), that doesn't seem to count according to RFC 3271 section 8.2.2.2 <https://tools.ietf.org/html/rfc3261#section-8.2.2.2>
Looking at the sip trace, the ACK for 415 is sent out before the 2nd branch INVITE. Unfortunately, inserting a 2 seconds sleep didn't help :( Regards, --Sergiu On Mon, May 7, 2018 at 6:21 AM, Daniel-Constantin Mierla <[email protected]> wrote: > Hello, > > the branch parameter value in top Via header is different, so this should > indicate is not the same branch. > > Have you look at the network traffic, is the ACK for 415 getting first to > device, before the 2nd branch INVITE? A that moment, the transaction should > be considered terminated and a new one started. > > My understanding of "merging request" is that it should be done if two > requests arrive at the same time, both still being active, without a final > response sent back. > > What you can try to see what happens is to add a sleep() of few seconds > for the 2nd branch and see if this time the device cleared the previous > transaction. Of course, not like a really good solution, but can reveal > what the device is doing. > > Cheers, > Daniel > > On 04.05.18 20:43, Sergiu Pojoga wrote: > > In continuation of previous > <https://marc.info/?l=sr-users&m=150730146302404&w=2>thread about > none/optional/compulsory SRTP handling... > > I used the suggested approach of *t_reuse_branch()* in a > *tm:branch-failure* detected by t_check_status("(415)|(488)") replies, > with the only difference of me doing it vice-versa from the suggested > mantra of offer SRTP first then fallback to RTP. > > It works... well, for some UACs, not so with others. > > The 'good' UACs happily accept an updated branch, like for e.g. Yealink, > will reply with "*488 Not Acceptable Here*" at first followed by a *200 > OK*. > > The 'bad' UACs, like for e.g. Bria || Zoiper, will issue a "*415 > Unsupported Media Type*" at first, and then a "*482 Merged Request*" > after receiving and updated branch with a different RTP profile. > > Rightfully so, they decided that the updated branch is a retransmission, > since both branches have the same CSeq, Call-ID and From tag. > The branch ID however differs, so does the RTP profile obviously. > > *Any suggestion on how to convince all UACs that the 2nd attempt is > different than the 1st one?* > > According to RFC 3261, a request is a merged request if ... > > "8.2.2.2 Merged Requests > > If the request has no tag in the To header field, the UAS core MUST > check the request against ongoing transactions. If the From tag, > Call-ID, and CSeq exactly match those associated with an ongoing > transaction, but the request does not match that transaction (based > on the matching rules in Section 17.2.3), the UAS core SHOULD > generate a 482 (Loop Detected) response and pass it to the server > transaction." > > > > > _______________________________________________ > Kamailio (SER) - Users Mailing > [email protected]https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com > >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
