Re: [reSIProcate-users] Overriding expiry times in REGISTER requests
Looks good. I think the ServerRegistration settings belong in the
MasterProfile class as opposed to the profile class though – since it
doesn't make sense to have multiple UserProfiles for
ServerRegistrations. In general system wide settings are in
MasterProfile, settings that make sense to be different in multiple
UserProfiles go in Profile, and User specific settings go in
UserProfile.
Thanks,
Scott
On Fri, Aug 1, 2008 at 3:19 PM, Justin Matthews <jmatthewsr@xxxxxxxxx> wrote:
> 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/
>
>