< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
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 3261The UAC MAY add an Expires header field (Section 20.19) to limit thevalidity 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.1Thanks in advance. <dum.zip>_______________________________________________ resiprocate-users mailing list resiprocate-users@xxxxxxxxxxxxxxx List Archive: http://list.resiprocate.org/archive/resiprocate-users/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature