[OpenSIPS-Users] handling a 422

[Alex Balashov]

I see what you mean, yeah.  Unfortunately, session timers are for the 
UAs to negotiate from a design and SIP specification standpoint.  The 
only thing the SST module provides is a thin layer of SE value 
enforcement by the proxy.

In keeping with the sort of thing that a proxy is, it is not an ultimate 
negotiating party, as is true of many SIP attributes (SDP/media/codec 
parameters, Supported: header values, etc. for example).  All it can do 
is block requests that do not meet certain SE requests on behalf of a 
destination UA.  If not for the way the module hooks into the dialog 
module callbacks to allow dialog expiry to be connected with SST values, 
the entire functionality of the SST module could be replicated thusly:

    if(is_present_hf("Min_SE") && $hdr(Min-SE) > x) {
        sl_send_reply("422", "Session Timer Too Small");
        # append_hf() any other necessary headers.
        exit;
    }

If the destination UA has a problem, the proxy can't answer on behalf of 
the sender.

I agree, it's a sucky situation.

Jeff Pyle wrote:

> Right.  That was my fear.  In my case the UAC knows nothing of session
> timers.  Its UAS (Opensips) adds the SST headers and relays the request.  If
> the far end replies with a 422, by default Opensips will relay the 422 to
> the UAC who, well, won't know what to do with it.
> 
> It just doesn't seem fair to slap the UAC with a 422 it doesn't know how to
> handle.
> 
> See what I mean?
> 
> 
> - Jeff
> 
> 
> 
> On 8/18/09 9:10 AM, "Alex Balashov" <abalashov at evaristesys.com> wrote:
> 
>> The SST module is designed for a scenario in which the proxy serves as
>> the endpoint of the SST negotiation.  Otherwise, SST is up to the UA
>> endpoints to negotiate amongst themselves.  So, SST does not deal with a
>> situation in which the proxy *receives* a 422;  it only equips the proxy
>> to *send* a 422 if the Min-SE value from the request initiator does not
>> meet *its* desiderata.
>>
>> Jeff Pyle wrote:
>>
>>> It seems very strange to me to have to manually manipulate headers that an
>>> Opensips module added in the first place.  Seems like bad things could
>>> happen if the modules expects them to be there with certain values and they
>>> have different values or gone altogether.  If these headers are added in the
>>> request route does the same rule apply as with append_hf(), that is, they
>>> cannot be removed?
>>>
>>> The whole thing just seems odd.
>>>
>>>
>>> - Jeff
>>>
>>>
>>>
>>> On 8/18/09 9:01 AM, "Alex Balashov" <abalashov at evaristesys.com> wrote:
>>>
>>>> If I'm understanding the documentation correctly, you'd probably have to
>>>> do this with manual header manipulation.
>>>>
>>>> Jeff Pyle wrote:
>>>>
>>>>> On 8/18/09 8:51 AM, "Alex Balashov" <abalashov at evaristesys.com> wrote:
>>>>>
>>>>>> Sure, use a failure route and append_branch().
>>>>> Ok, but how do I adjust the timer value so it doesn't get 422'd again?  Or
>>>>> is this handled automatically?  The SST module documentation doesn't appear
>>>>> to cover this.
>>>>>
>>>>>
>>>>>
>>>>> - Jeff
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671