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

[Sergiu Pojoga]

 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 <miconda at gmail.com>
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 Listsr-users at lists.kamailio.orghttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180507/b4b26d19/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bria.png
Type: image/png
Size: 19040 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180507/b4b26d19/attachment.png>