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

[Nils Ohlmeier]

On Friday 05 August 2005 10:06, Klaus Darilion wrote:
> You can also use the sipping feature in nathelper to send SIP packets
> which should keep the NAT binding alive.

This is unfortunately only true for some NAT devices. Some of them dont count 
outside-to-inside traffic to the keepalive for a hole .

Kanakatti, depending on the snom devices which you have an upgrade of the 
firmware will bring you a NAT keepalive ping on the snom devices, which can 
be set to values below 1 minute.

  Nils

> 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
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers