
<html><head></head><body style="zoom: 0%;"><div dir="auto">Thank you for all the pointers, Donat</div>

<div class="gmail_quote" >On Dec 2, 2020, at 5:10 AM, Donat Zenichev <<a href="mailto:donat.zenichev@gmail.com" target="_blank">donat.zenichev@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div dir="ltr"><div>Hello Alex.</div><div>Firstly I would like to mention that t_on_failure() is only to be used when either of this is true:<br>- receiving of a negative reply that completes the transaction ;</div><div>- generation of a negative reply that completes the transaction ;</div><div><br></div><div>From the article given by the OpenSIPS team:<br>"It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches."</div><div>Please see: <a href="https://www.opensips.org/Documentation/Script-Routes-3-0">https://www.opensips.org/Documentation/Script-Routes-3-0</a></div><div><br></div><div>So that, the "with ACK+BYE combination" as you mentioned, will not be considered as a negative reply, that leads to a transaction ending.</div><div><br></div><div>Now getting back to the original question.</div><div>Quotation: "Assuming that there are lines in SDP that are not desirable. IS there any legal way to reject this call before it's answered from Opensips side . . . ".</div><div><br></div><div>It looks a bit strict-forward to drop the media session right away, if you see non-desirable SDP attributes.<br></div><div><br></div><div>I would first of all try to read this section <a href="https://tools.ietf.org/html/rfc6337#section-2.2">https://tools.ietf.org/html/rfc6337#section-2.2</a> of RFC 6337,</div><div>that defined at least 4 possible scenarios for SDP negotiations.<br></div><div>What I mean to say, is that there might be a way to manage SDP session, suppressing your carrier to use desired media attributes.</div><div>Still I want to underline "might be".<br></div><div><br></div><div>If SDP protocol allows us to negotiate parameters of the media session during the whole handshake sequence: INVITE -> 200OK -> ACK</div><div>Even though the scenarios are already predefined, you might try to let ACK have an SDP body to list needed attributes one more time.<br></div><div>Still this might be not working, since in the RFC 6337, you can see this definition:</div><div>"The answer cannot be updated, and a new offer cannot be sent in a subsequent reliable response for the same INVITE transaction."</div><div><br></div><div>So you might try to look into the following:</div><div>- INVITE (from your OpenSIPS instance) - sends SDP offer<br></div><div>- 183 provisional response / 200 OK - received from a carrier with SDP answer</div><div>- at this point you consider all the attributes for a desired media and send ACK containing SDP body with the very last list of desired parameters.</div><div><br></div><div>Again, this is just an idea which was never used in the practice.</div><div>I hope you will find my answer useful :)<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 1, 2020 at 7:08 PM Alex A <<a href="mailto:alex.a@gtanetworkconsulting.com">alex.a@gtanetworkconsulting.com</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"><u></u><div><div style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:10pt">Hi, <br><br>I have been trying to find a solution for a particular scenario: <br><br>Opensips sends INVITE to a carrier<br>Carrier responds 180 Ringing (no SDP)<br>Carrier responds 200OK with SDP<br><br>Assuming that there are lines in SDP that are not desirable: <br><br>a) IS there any legal way to reject this call before it's answered from Opensips side (with ACK+BYE combination)<br>b) in case, it possible - will the call proceed into t_on_failure block in this case? <br><br><br>Thank you greatly in advance.<br><br><br><div><br></div></div><br></div>_______________________________________________<br>

Users mailing list<br>

<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>

<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>

</blockquote></div><br clear="all"></blockquote></div></body></html>