[SIPForum-discussion] Time interval between requests

[mustafa aydin]

Hi Vijay,
 
Thanks for your mail. As I mentioned earlier,  I am not sure whether  section 9.1  is also applicable for RE-INVITEs. Consider a scenario where UAS does not return 100 trying (typically, I am not waiting UAS to reply with 18x in re-invite scenarios) since 100 trying is an optional message, what will happen then, UAS will reply with 200 OK, but UAC actually  wants to terminate the transaction? 
 
Section 17 generally mentions about SIP timers (T1, etc), but it does not tell how much UAC should  wait before sending the second REQUEST (CANCEL in my scenario).
 
In addition, in the previous replies from other forum members, there were some comments   which say we can not CANCEL a Re-invite, please see the excerpt below from RFC 6141; 
 
RFC 6141
3.8.  Clarifications on Canceling Re-INVITEs
   Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS
   responding to a CANCEL request.  Such a UAS responds to the INVITE
   request with a 487 (Request Terminated) at the SHOULD level.  Per the
   rules specified in Section 3.3, if the INVITE request was a re-INVITE
   and some of its requested changes had already been executed, the UAS
   would return a 2xx response instead.
 
Regards,
Mustafa AYDIN


________________________________
From: Vijay Tiwari <vijay11tiwari at gmail.com>
To: mustafa aydin <mustafaydin82 at yahoo.com> 
Cc: "discussion at sipforum.org" <discussion at sipforum.org> 
Sent: Thursday, September 6, 2012 7:06 PM
Subject: Re: [SIPForum-discussion] Time interval between requests

Hello Mustafa

you can look at section 9.1 and section 17 of RFC 3261.

On 9/5/12, mustafa aydin <mustafaydin82 at yahoo.com> wrote:
> Hi All,
>
> Is there any time frame mentioned in RFCs which defines time interval
> between REQUESTS? For example, can UAC send CANCEL of a RE-INVITE just
> 0.0004 sec later ?  I tested some SIP servers , but none of them could
> handle the CANCEL properly when it comes just in such a short interval, but
> I  need to refer to RFCs in order to prove this wrong behaviour to vendor.
>
> Thanks,
> Mustafa AYDIN


-- 
They can because they think they can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120907/fb322dfe/attachment-0002.html>