Re: processing a delay value in creating a response

It is my distinct impression that very few UACs actually send a Timestamp 
header. Even fewer would care about any 'delay' value, and typical values 
would likely be in the sub-second range. It may not be much trouble to add, 
but it will require timestamping of every request that comes in, which is 
overhead.

If the UAC wants to measure response time, it is much better off by taking a 
timestamp itself, and storing that in the transaction. I'll bet that many 
servers/proxies out there won't bother to play back the Timestamp in 100 
(and it won't work for non-INVITEs either)

Regards,
Jeroen

M. Rangnathan wrote:
> Hi Park,
>
> This is a SHOULD and hence is not a mandatory part of the spec. You
> can compute the delay in your application as the diff between the
> time you see the request in your application and the time you
> sendResponse. Its easy enough to do. I'll look into providing this
> support in the stack (but I have some other priorities at the moment
> so it will take a little while).
>
> Ranga
>
> Young-Geun Park wrote:
>
>> Hi, All
>>
>> the following is described in 8.2.6.1 rfc3261:
>>
>> If there is a delay in generating the response, the UAS
>>
>> SHOULD add a delay value into the Timestamp value in the response.
>>
>> This value MUST contain the difference between the time of sending of
>>
>> the response and receipt of the request, measured in seconds
>>
>> this part is omitted in implementation.
>>
>> so, I think that setting a delay value is needed in
>> SIPRequest.createResponse().
>>
>> is there any comment?
>>
>> Regards,
>>
>> Park
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> nist-sip mailing list
>> [email protected]
>> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip