[asterisk-dev] [Code Review]: Add Expires header to SIP PUBLISH responses

[Mark Michelson]

> On June 28, 2012, 11:16 a.m., Olle E Johansson wrote:
> > Are we sure that we actually send another PUBLISH before the current one expires?
> 
> gareth wrote:
>     This change only affects responses to PUBLISH requests. It would be up to the sending device to refresh the dialog.
> 
> Olle E Johansson wrote:
>     If you PUBLISH and the event expires, you are supposed to update your PUBLISH. This needs to be in the PUBLISH framework. If you add expiry, this needs to mean something in the code.
>     
>     A presence server will erase your state at expiry otherwise, which is NOT what you want.

PUBLISH expiry (from the UAS side at least) already exists in the code. The problem being fixed is that the Expires header was not being added in a 200 OK sent from Asterisk.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2003/#review6598
-----------------------------------------------------------


On June 25, 2012, 10:50 p.m., gareth wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2003/
> -----------------------------------------------------------
> 
> (Updated June 25, 2012, 10:50 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Successful (ie: 200 OK) responses to SIP PUBLISH requests need to have an Expires header as per RFC 3903 section 6.6.
> 
> This patch adds SIP_PUBLISH to the list of methods that need an Expires header added in respprep().
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 369389 
> 
> Diff: https://reviewboard.asterisk.org/r/2003/diff
> 
> 
> Testing
> -------
> 
> It compiles.
> 
> 
> Thanks,
> 
> gareth
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120629/50ce94c8/attachment-0001.htm>