Re: [reSIProcate-users] Overriding expiry times in REGISTER requests
Ideally all settings would be in one spot - the Profile classes. But
now we have backwards compatibility issues to be concerned about, if
we move existing settings. I suppose we could keep any exisitng
settings not in the profile and add equivalent profile settings that
would be used instead (if set).
Scott
On 7/31/08, Justin Matthews <jmatthewsr@xxxxxxxxx> wrote:
> Fyi, I have been doing this with a custom mod.
>
> For subscriptions the SubscriptionHandler is used to get the default, min
> and max and an override function contains the logic for choosing what to do
> with the message (reject with 423, force some other value).
>
> For registrations the master profile is used to retrieve the min, max and
> default values. I did not implement a handler, but it would be nice here so
> that the user can override default behavior, especially since there can be a
> global expires and individual expiration on each contact.
>
> To be consistent should the subscription min, max and default values also be
> put into profile, or should the settings for both be part of the handlers?
>
> I can add what I have if that helps.
>
> -justin
>
> -----Original Message-----
> From: resiprocate-users-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Scott Godin
> Sent: Thursday, July 31, 2008 9:11 AM
> To: Max Bowsher
> Cc: resiprocate-users
> Subject: Re: [reSIProcate-users] Overriding expiry times in REGISTER
> requests
>
> There is definately a lot more overhead in parsing a SIP request and
> building a response (processing a registration refresh) compared to
> just sending/receiving a CRLF. That being said, it seems reasonable
> to add support to ServerRegistration for imposing a maximum (and
> minimum) acceptable registration interval. If the client requests
> something outside this range then the server can just choose the
> closest allowable value. These settings could be added as virtual
> funcitons to ServerRegistrationHandler (similar to getDefaultExpires
> on ServerSubscriptionHandler) or as MasterProfile settings.
>
> Scott
>
> On Wed, Jul 30, 2008 at 1:14 PM, Max Bowsher <maxb@xxxxxxxxxxxxx> wrote:
>> I was thinking of overriding the expiry time in registrations to be a
>> maximum of 2 minutes, and using this to ensure that clients behind NAT
>> maintain an open NAT pinhole - I was considering this to be a preferable
>> solution to \r\n\r\n-style keepalives because there is implication in the
>> OpenSER docs that there exist NATs which won't keep a UDP pinhole alive
>> unless there is outbound traffic.
>>
>> RFC3261 says that the expiry the client passes to the server is a
> suggestion
>> only, so from a standards perspective this seems OK to me.
>>
>> However, DUM doesn't seem to have any support for doing this. Hacking
>> something into ServerRegistration doesn't look to be too hard, but I'm
>> wondering why the support is missing - Is it simply a case of no-one
> having
>> cause to implement it, or is it known that client support for the server
>> enforcing a short registration expiry is poor?
>>
>> Max.
>> _______________________________________________
>> resiprocate-users mailing list
>> resiprocate-users@xxxxxxxxxxxxxxx
>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>>
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>
>
--
Sent from Gmail for mobile | mobile.google.com