Re: [sipcore] #19/#20: Show Cancel messaging/Handling canceled forks

[Mary Barnes <[e-mail]>]

Note, I've merged these two issues into a single response since they
are relevant to the same text/call flow.  I have corrected #19 such
that the 200 OK is sent before the Cancel.

As you note, there is a general problem here in terms of how the 487
is reported.  We cannot change basic SIP protocol processing.
However, the hi-entry received in the response at the UAC is
misleading  if we don't include a reason.  So, I think we have to do
the "pre-emptive" addition of the reason.

The parallel forking scenario also has the anomaly that the indices
don't necessarily reflect (obviously) the sequence of events per se.
But, I don't know a way around that one either and I think that's
another parallel forking is evil side effect that we'll have to live
with.  The only hint the UAC would have that there was parallel
forking is that the last hi-entry has a reason and the one prior
doesn't.  However, I think it would be better if the last entry is the
successful one and is more reflective of where the INVITE was
successfully received.  This means that some indices might be out or
order, but I do not think that should break anything since they are
from the same branch (i.e., the tree looks the same).

Thanks,
Mary.

On Tue, Aug 31, 2010 at 12:26 PM, sipcore issue tracker
<[e-mail]> wrote:
> #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:[e-mail];p=x>;index=1
>    | History-Info: <sip:[e-mail];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:[e-mail];p=x>;index=1
>    | History-Info: <sip:[e-mail];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.
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/20>
> sipcore <http://tools.ietf.org/sipcore/>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>