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

[Mary Barnes <[e-mail]>]

In reconsidering this issue, I'm now of a mind that we should just not
include the entry for the canceled fork in the response since it
really doesn't add any value since it's undetermined at the time the
response is sent what really happened to that leg.  This is only in
the case of parallel forking, which is always an anomaly.  Unless
someone strongly disagrees, I'll update the text appropriately
(including bullet 6 in the indexing section).

Mary.

On Tue, Oct 12, 2010 at 5:37 PM, Mary Barnes <[e-mail]> wrote:
> 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
>>
>