[reSIProcate] [reSIProcate-users] Expires field in INVITE request

[Byron Campen]

	So you're worried about the UAS doing something broken with the  
Expires value? Or are you maintaining that it would make code more  
complicated, without actually reducing the burden on the TU?

Best regards,
Byron Campen

>
> Hi Byron,
>
> 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.
>
> thanks,
> -rohan
>
>
> On Apr 24, 2008, at 7:33 AM, Byron Campen wrote:
>> 	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/
>>
>> _______________________________________________
>> resiprocate-users mailing list
>> resiprocate-users at resiprocate.org
>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080425/f5a73677/attachment.htm>