[Serusers] Changing 'expires' value in response to REGISTER

Klaus Darilion klaus.mailinglists at pernau.at
Fri Aug 5 10:06:32 CEST 2005


You can also use the sipping feature in nathelper to send SIP packets 
which should keep the NAT binding alive.

klaus

Kanakatti Mahesh Subramanya wrote:
> yah, we've already done that with the ones that we can.
> 
> The problem (hmm.  i think 'issue' is a better fit here) is that we 
> actually allow our users quite a bit of freedom when it comes to playing 
> around with the settings.
> What I'm trying to do is set it up so that if *they* are comfortable 
> with the effects of changing their expires, i'm not going to stop them 
> (kinda libertarian in our approach, i guess)
> 
> With the Sipuras, you can get away with this.  They've separated their 
> keep-alive process from the registration process, so everything works out.
> With the Snoms, however, the only way to keep the NAT pinholes open is 
> to re-register every 30 seconds.
> Which brings us back to the original issue - the Snoms, by default, 
> can't register at less than 1 minute intervals. So, I need some 
> mechanism by which I can manipulate the value that I send back in the 
> Contact header when they register
> 
> Back to the drawing board.....
> 
> cheers, and thanx.
> 
> 
> 
> Andres wrote:
> 
>> Kanakatti Mahesh Subramanya wrote:
>>
>>> This works successfully with the Snoms.
>>>
>>> However, it also successfully breaks Sipuras (of which we have quite 
>>> a few too)
>>>
>>> And, rfc3261 never actually sez. that teh UAC must accept the value I 
>>> send back (weird...)
>>>
>>> Any other ideas??
>>>
>> On Sipura these 2 Values control what you want:
>>
>> Reg Min Expires:
>> Minimum registration expiration time allowed
>> from the proxy in the Expires header or as a
>> Contact header parameter. If proxy returns
>> something less this value, then the minimum
>> value is used.
>>
>> Reg Max Expires:
>> Maximum registration expiration time allowed
>> from the proxy in the Min-Expires header. If
>> value is larger than this, then the maximum
>> value is used
>>
>> Just set the Reg Min Expires value to say 1 second and it should 
>> therefore accept the value of 30 in the Expires Header.
>>
>> Cheers.
>>
>>
>>> cheers
>>>
>>> Andres wrote:
>>>
>>>> Kanakatti Mahesh Subramanya wrote:
>>>>
>>>>> And the beat goes on...
>>>>>
>>>>> I 've got a bunch of Snom's that have a minimum register interval 
>>>>> of 1 minute.
>>>>>
>>>>> I *know* that I can get them to register every 30 seconds if I set 
>>>>> the 'expires' value in the Contact header of the '200 OK' response 
>>>>> to the REGISTER request appropriately (whew)
>>>>> e.g., instead of returning
>>>>> Contact: <sip:jake.foobaz at 1.2.3.4:49154>;expires=60
>>>>> I return
>>>>> Contact: <sip:jake.foobaz at 1.2.3.4:49154>;expires=30
>>>>>
>>>>> The question is - how do I change the 'expires' value?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> How about using a global parameter like:
>>>>
>>>> 1.3.3. max_expires (integer)
>>>>
>>>>   The maximum expires value of a Contact, values higher than
>>>>   this maximum will be automatically set to the maximum. Value 0
>>>>   disables the checking.
>>>>
>>>>   Default value is 0.
>>>>
>>>>   Example 1-3. Set max_expires parameter
>>>> ...
>>>> modparam("registrar", "max_expires", 120)
>>>>
>>>>
>>>>>
>>>>> append_to_reply() isn't relevant - i don't want another header
>>>>> subst() on the request's 'Expires' header isn't useful since 
>>>>> build_contact() seems to extract it's values from the original 
>>>>> request.  Any changes I made to it seem to be ignored
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> cheers
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>  
>>>>>
>>>>
>>>>
>>
>>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list