[SR-Users] Pleasing all kinds of UACs for RTP/SRTP with rtpengine

[Sergiu Pojoga]

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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180504/952b4021/attachment.html>