Opened 11 years ago

#20 new defect

Handling canceled forks

Reported by: worley@… Owned by:
Priority: major Milestone: milestone1
Component: rfc4244bis Version:
Severity: In WG Last Call Keywords:
Cc:

Description

Concerning this part of section 3 figure 1:

| | | 200 | |
| | |<---------------| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc
| | | | |
| | |<===Proxy cancels INVITE==>|
| | | | |
| | | 487 | |
| | |<--------------------------|
| | 200 | | |
| |<---------------| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc
| History-Info: <sip:bob@192.0.2.7?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.

Change History (0)

Note: See TracTickets for help on using tickets.