<div dir="ltr">You would achieve this in a failure route, detecting the 488|415 negative replies then resuming the branch with a different SDP profile.<div><br></div><div>However, as others have said already, not all UAs will accept this "hack". Some will consider the new branch with a CSeq NOT incrementing as retransmission - and reject it with something like "482 Merged Request".</div><div><br></div><div><a href="https://tools.ietf.org/html/rfc3261#section-8.2.2.2" rel="noreferrer" target="_blank" style="font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">https://tools.ietf.org/html/rfc3261#section-8.2.2.2</a><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">8.2.2.2 Merged Requests</span><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">If the request has no tag in the To header field, the UAS core MUST</span><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">check the request against ongoing transactions. If the From tag,</span><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">Call-ID, and CSeq exactly match those associated with an ongoing</span><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">transaction, but the request does not match that transaction (based</span><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">on the matching rules in Section 17.2.3), the UAS core SHOULD</span><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">generate a 482 (Loop Detected) response and pass it to the server</span><br style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">transaction.</span><br></div><div><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px"><br></span></div><div><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">Regards,</span></div><div><span style="color:rgb(43,46,47);font-family:"Lucida Sans Unicode","Lucida Grande",Tahoma,Verdana,sans-serif;font-size:14px">--Sergiu</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 27, 2022 at 6:26 PM Marrold <<a href="mailto:kamailio@marrold.co.uk">kamailio@marrold.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>Unfortunately in my experience "Opportunistic SRTP" support is broken in many UAs. There are (at least) two ways of doing it covered indirectly in <a href="https://tools.ietf.org/html/rfc3264" target="_blank">RFC3264</a> and the second explicitly in <a href="https://www.rfc-editor.org/rfc/rfc8643.html" target="_blank">RFC8643</a> and devices seem to handle them differently. I've seen end devices that <i>can </i>support SRTP choose to use standard RTP when offered the wrong type of SDP body.<br><br></div><div>One thing I considered (but haven't tested so far) is using a late offer to discover what format the end device expects before sending an offer, but that might cause interop problems of its own.<br><br></div><div>Cheers<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 27, 2022 at 10:54 PM Social Boh <<a href="mailto:social@bohboh.info" target="_blank">social@bohboh.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can examine the request but how examine the answer if is a Error? <br>
Using a failure route?<br>
<br>
Regards<br>
<br>
---<br>
I'm SoCIaL, MayBe<br>
<br>
El 27/01/2022 a las 5:39 p. m., Alex Balashov escribió:<br>
> Does an examination of the SDP offer and answer respectively not divine the issue?<br>
><br>
>> On Jan 27, 2022, at 5:35 PM, Social Boh <<a href="mailto:social@bohboh.info" target="_blank">social@bohboh.info</a>> wrote:<br>
>><br>
>> I'm trying to configure Kamailio to permit communication between devices:<br>
>><br>
>> some use TLS and SRTP<br>
>><br>
>> some UDP and RTP<br>
>><br>
>> with RTPEngine in the middle.<br>
>><br>
>> A priori I don't know if the device support SRTP or RTP so in the routing I have to detect on the fly how to act. The problem is this:<br>
>><br>
>> Call from RTP to SRTP device: 488 Not Acceptable here<br>
>><br>
>> Call from SRTP to RTP device: 415 Unsupported Media Type<br>
>><br>
>> Any hint?<br>
>><br>
>> Thank you<br>
>><br>
>>   Regards<br>
>><br>
>> -- <br>
>> ---<br>
>> I'm SoCIaL, MayBe<br>
>><br>
>><br>
>> __________________________________________________________<br>
>> Kamailio - Users Mailing List - Non Commercial Discussions<br>
>> * <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>> Important: keep the mailing list in the recipients, do not reply only to the sender!<br>
>> Edit mailing list options or unsubscribe:<br>
>> * <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
__________________________________________________________<br>
Kamailio - Users Mailing List - Non Commercial Discussions<br>
  * <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
Important: keep the mailing list in the recipients, do not reply only to the sender!<br>
Edit mailing list options or unsubscribe:<br>
  * <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>
__________________________________________________________<br>
Kamailio - Users Mailing List - Non Commercial Discussions<br>
  * <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
Important: keep the mailing list in the recipients, do not reply only to the sender!<br>
Edit mailing list options or unsubscribe:<br>
  * <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>