<div><div dir="auto">Sitting by the evening's cup of a tea, and considering this, I just suddenly realized I have said nothing about UPDATE method. This one can be used to refresh SDP session parameters (attributes) during the early stage of the dialog.</div><div dir="auto"><br></div><div dir="auto">But from what I remember, usage of the UPDATE method within the early stage of a dialog, purpose of which is a refurbishment of media attributes, can only be sent when the first sequence of SDP offer <-> SDP answer is completed. So one should remember this.</div><div dir="auto"><br></div><div dir="auto">I have never used UPDATE method for such scenario, but theoretically this can work out.</div><div dir="auto"><br></div><div dir="auto">RFC 3311 is the one describing usage of the UPDATE method. Please see: <div><a href="https://tools.ietf.org/html/rfc3311">https://tools.ietf.org/html/rfc3311</a></div></div><div dir="auto"><br></div><div dir="auto">So yeah, one more advice here :)</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 2 Dec 2020 at 8:36 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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="zoom:0%"><div dir="auto">Thank you for all the pointers, Donat</div></div><div style="zoom:0%">
<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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<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" target="_blank">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" target="_blank">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" target="_blank">alex.a@gtanetworkconsulting.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><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 style="font-family:Verdana,Arial,Helvetica,sans-serif"><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></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></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><font style="background-color:rgb(255,255,255)" color="#0b5394">Best regards,<br></font></div><div dir="ltr"><font style="background-color:rgb(255,255,255)" color="#0b5394">Donat Zenichev<br><br></font></div></div></div></div></div></div></div></div>