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

[Rohan Mahy]

The later.
thanks,
-r

On Apr 25, 2008, at 6:25 AM, Byron Campen wrote:
> 	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/
>>
>