Re: [reSIProcate-users] Overriding expiry times in REGISTER requests
Change checked in. New params in Profile.hxx can be set for the master
profile to override default behavior.
Let me know if the logic needs modification or if further info on this
change is required.
Thanks,
-justin
-----Original Message-----
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Friday, August 01, 2008 11:03 AM
To: Justin Matthews; Scott Godin; Max Bowsher; resiprocate-users
Subject: RE: [reSIProcate-users] Overriding expiry times in REGISTER
requests
Ah - good point - you may want different values for different events.
-----Original Message-----
From: resiprocate-users-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Justin
Matthews
Sent: Friday, August 01, 2008 10:56 AM
To: 'Scott Godin'; 'Max Bowsher'; 'resiprocate-users'
Subject: Re: [reSIProcate-users] Overriding expiry times in REGISTER
requests
I can add what I have with the addition of virtual handlers in
ServerRegistrationHandler for getting the expires value for the "global"
expires and each individual contact expires value. Should be able to add
this later today, we can then modify it if needed.
Since SubscriptionHandlers are added to DUM per event type, does it make
sense to just leave the settings as-is and not add them to Profile?
Adding
to profile may just add some confusion.
-justin
-----Original Message-----
From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott
Godin
Sent: Thursday, July 31, 2008 9:20 PM
To: Justin Matthews; Max Bowsher; resiprocate-users
Subject: 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
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/