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.
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. I have never used UPDATE method for such scenario, but theoretically this can work out. RFC 3311 is the one describing usage of the UPDATE method. Please see: https://tools.ietf.org/html/rfc3311 So yeah, one more advice here :) On Wed, 2 Dec 2020 at 8:36 PM, Alex A <[email protected]> wrote: > Thank you for all the pointers, Donat > On Dec 2, 2020, at 5:10 AM, Donat Zenichev <[email protected]> > wrote: >> >> Hello Alex. >> Firstly I would like to mention that t_on_failure() is only to be used >> when either of this is true: >> - receiving of a negative reply that completes the transaction ; >> - generation of a negative reply that completes the transaction ; >> >> From the article given by the OpenSIPS team: >> "It contains a set of actions to be taken each transaction that received >> only negative replies (>=300) for all branches." >> Please see: https://www.opensips.org/Documentation/Script-Routes-3-0 >> >> So that, the "with ACK+BYE combination" as you mentioned, will not be >> considered as a negative reply, that leads to a transaction ending. >> >> Now getting back to the original question. >> 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 . . . ". >> >> It looks a bit strict-forward to drop the media session right away, if >> you see non-desirable SDP attributes. >> >> I would first of all try to read this section >> https://tools.ietf.org/html/rfc6337#section-2.2 of RFC 6337, >> that defined at least 4 possible scenarios for SDP negotiations. >> What I mean to say, is that there might be a way to manage SDP session, >> suppressing your carrier to use desired media attributes. >> Still I want to underline "might be". >> >> If SDP protocol allows us to negotiate parameters of the media session >> during the whole handshake sequence: INVITE -> 200OK -> ACK >> Even though the scenarios are already predefined, you might try to let >> ACK have an SDP body to list needed attributes one more time. >> Still this might be not working, since in the RFC 6337, you can see this >> definition: >> "The answer cannot be updated, and a new offer cannot be sent in a >> subsequent reliable response for the same INVITE transaction." >> >> So you might try to look into the following: >> - INVITE (from your OpenSIPS instance) - sends SDP offer >> - 183 provisional response / 200 OK - received from a carrier with SDP >> answer >> - 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. >> >> Again, this is just an idea which was never used in the practice. >> I hope you will find my answer useful :) >> >> >> >> >> >> On Tue, Dec 1, 2020 at 7:08 PM Alex A <[email protected]> >> wrote: >> >>> Hi, >>> >>> I have been trying to find a solution for a particular scenario: >>> >>> Opensips sends INVITE to a carrier >>> Carrier responds 180 Ringing (no SDP) >>> Carrier responds 200OK with SDP >>> >>> Assuming that there are lines in SDP that are not desirable: >>> >>> a) IS there any legal way to reject this call before it's answered from >>> Opensips side (with ACK+BYE combination) >>> b) in case, it possible - will the call proceed into t_on_failure block >>> in this case? >>> >>> >>> Thank you greatly in advance. >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
