[reSIProcate] [reSIProcate-users] Expires field in INVITE request
Byron Campen
bcampen at estacado.net
Thu Apr 24 09:33:32 CDT 2008
CCing to resip-devel:
Actually, the is UAC core behavior, so this sort of thing would
belong down in the stack, not DUM. I actually think that this would
be a good thing to implement. (Of course, we'd need to make it
configurable so repro wouldn't act on it; forwarding an INVITE with
an Expires shouldn't trigger timers and such, since that's the UAC's
job)
Anyone have a strong opinion on this?
Best regards,
Byron Campen
> According to RFC 3261
> The UAC MAY add an Expires header field (Section 20.19) to limit
> the
> validity of the invitation. If the time indicated in the Expires
> header field is reached and no final answer for the INVITE has been
> received, the UAC core SHOULD generate a CANCEL request for the
> INVITE, as per Section 9.
> As I far as I know resiprocate does not implement this behavior so
> I have made changes to the library. So I added one more timer -
> InviteExpires(see DumTimeout.hxx) that acts similar to StaleCall
> timer.
> I think that modifying library is not a good idea so, is there any
> other way to limit call duration while it has not received final
> answer? If no can you give any feedback on changes I have made
> especially on possible incorrect interaction with existing
> resiprocate code. I'm using resiprocate of version 1.1
> Thanks in advance.
> <dum.zip>_______________________________________________
> resiprocate-users mailing list
> resiprocate-users at resiprocate.org
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080424/5c2ae301/attachment.bin>
More information about the resiprocate-devel
mailing list