Subject: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments

From: Brett Tate <[email-masked]>
Date: Tue, 30 Sep 2014 13:48:18 -0400

Hi,

The following are few comments concerning
draft-jesske-dispatch-forking-answer-correlation-01.

Thanks,
Brett

-------

1) Section 1 indicates:

" Now the originating SIP device has to understand that two devices are
   ringing and one will answer the call.  No Problem since RFC3261
   [RFC3261] allows this and allows also the originating device to
   handle multiples responses.  But this is not mandated by RFC3261
   [RFC3261] and led to implementers choice.  There will the first
   problem apply that only one of the Responses will be taken into
   consideration for creating a dialog."

RFC 3261 mandates that the UAC be able to handle interactions with a
forking proxy.  However, I agree that some B2BUAs attempt to protect
clients from needing to support such functionality.

2) Section 2.8 indicates:

"Thus the only
   solution seen is to describe procedures which apply in B2BUA to
   support an correlation of multiples early dialogs and other received
   18x Responses."

I disagree with that statement.  One solution is to replace/upgrade the
deficient device so that it supports forking interactions.

3) Section 3 indicates:

" To provide the best user behavior a service provider shall have the
   possibility to correlate multiples received responses to one dialog
   leg to the UAC."

I disagree with that statement.  Folding multiple early dialogs onto a
single early dialog does not produce the best user experience.  It causes
ambiguities as various requests/response/headers/bodies traverse those
early dialogs.  It can cause the need for UAC to support RFC 3262 and RFC
3311 (if the B2BUA needs to communicate SDP modifications on an early
dialog).

4) Section 4.1 figure 1 shows CANCEL/200/487/ACK between UAC, PROXY, and
Forking Proxy.  This should not be occurring.

5) Section 4.2 figure 2 shows CANCEL/200/487/ACK between B2BUA and Forking
Proxy.  This should not be occurring.

6) Section 4.2 shows B2BUA only relaying first 18x.  What are you
proposing to do if the servers sent different 18x responses such as UAC_2
sent 181, UAC_3 sent 182, and UAC_4 sent 183?

7) Section 4.3 figure 3 shows CANCEL/200/487/ACK between B2BUA and Forking
Proxy.  This should not be occurring.

8) Section 4.4 figure 4 shows CANCEL/200 between B2BUA and Forking Proxy.
This should not be occurring.  It also looks like there is a subsequent
extra 200 response.

9) Section 4.4 figure 4 is missing the 487/ACK interaction with UAS_2.

10) Section 4.4 figure 4 F40 should maybe be drawn from UAS_4 to match
numbering and F57.

11) Section 4.4 second figure 4 should be figure 5.  My prior section 4.4
comments also apply to the second figure 4 (i.e. figure 5) although the F
numbering is different.