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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 >>>>>> [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 >> >> >> _______________________________________________ >> 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
