[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