[OpenSIPS-Users] Is it possible to Reject 200OK

[Donat Zenichev]

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 <alex.a at gtanetworkconsulting.com>
wrote:

> Thank you for all the pointers, Donat
> On Dec 2, 2020, at 5:10 AM, Donat Zenichev <donat.zenichev at gmail.com>
> 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 <alex.a at gtanetworkconsulting.com>
>> 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
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20201202/77690d61/attachment-0001.html>