I think use of this feature is generally a bad idea and I would push for it to be deprecated in a future version of the standard. An application that is interested in setting this header would be better off setting an application-level timer and canceling the request.
If a UAS that receives this request ignores the Expires header, nothing bad really happens. If the UAS sends a 2xx to the request, the UAC should have code to just send a BYE.
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 mailing list