Subject: [sipcore] #20: Handling canceled forks

From: "sipcore issue tracker" <[email-masked]>
Date: Tue, 31 Aug 2010 17:26:12 -0000

#20: Handling canceled forks
---------------------------------+------------------------------------------
 Reporter:  worley@…             |       Owner:            
     Type:  defect               |      Status:  new       
 Priority:  major                |   Milestone:  milestone1
Component:  rfc4244bis           |     Version:            
 Severity:  In WG Last Call      |    Keywords:            
---------------------------------+------------------------------------------
 Concerning this part of section 3 figure 1:

    |                |                |     200        |          |
    |                |                |<---------------|          |
    | History-Info: <sip:[email-masked];p=x>;index=1
    | History-Info: <sip:[email-masked];p=x>;index=1.1
    | History-Info: <sip:[email-masked]>;index=1.1.1;rc
    |                |                |                |          |
    |                |                |<===Proxy cancels INVITE==>|
    |                |                |                |          |
    |                |                |      487       |          |
    |                |                |<--------------------------|
    |                |     200        |                |          |
    |                |<---------------|                |          |
    | History-Info: <sip:[email-masked];p=x>;index=1
    | History-Info: <sip:[email-masked];p=x>;index=1.1
    | History-Info: <sip:[email-masked]>;index=1.1.1;rc
    | History-Info: <sip:[email-masked]?Reason=SIP;cause=487>;\
    |               index=1.1.2;rc

 In principle, the second 200 response shown above should be sent
 immediately after the first 200 response shown above was received from
 downstream.  But the received 200 response triggered "Proxy cancels
 INVITE", which led to Bob@phone to send the 487 response which is
 documented in the 4th History-Info value in the sent 200, which should
 have been sent before the 487 was received.

 One alternative is to put that 4th value in the upstream 200
 "preemptively", that is, documenting that the proxy *intends* to cancel
 the INVITE to Bob@phone.  But the proxy does not know that it will be
 successful in canceling the INVITE and receiving a 487 response -- there
 might already be a 200 en route from Bob@phone.  So the upstream 200 can't
 be sent until the 487 is received.

 Another alternative is to delay sending the upstream 200 until after all
 parallel forks have been disposed of.  But this would be complex and might
 take a significant amount of time.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/20>
sipcore <http://tools.ietf.org/sipcore/>