[OpenSIPS-Users] handling a 422

[Jeff Pyle]

Hey, asking is free.  :)

My solution is to increase my min_se value to the least common denominator.
That reduces its usefulness for me but it's better than not having it at
all.

Thanks for the reality check.



- Jeff



On 8/18/09 9:44 AM, "Alex Balashov" <abalashov at evaristesys.com> wrote:

> 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
>