Subject: [dispatch] WG: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-02.txt

From: <[email-masked]>
Date: Tue, 28 Oct 2014 15:36:14 +0100

Dear all,
yesterday I have uploaded a new version of the draft-jesske-dispatch-forking-answer-correlation.
I have tried to include all comments I received so far and added some new Call flows for discussion.

The draft is describing where a B2BUA provides a correlation mechanism to maintain a single dialog between UAC and B2BUA while between B2BUA and UAS1, UAS2, UAS3 ect. multiple early dialogs are existing.
We see the need for such a solution due to existing implementations not understanding multiples early dialogs or handling it in a wrong manner. More problematic are the cases where preconditions and early media is used.

Comments and improvements are welcome.

Thank you and Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Montag, 27. Oktober 2014 17:39
An: Jesske, Roland; Jesske, Roland
Betreff: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-02.txt

A new version of I-D, draft-jesske-dispatch-forking-answer-correlation-02.txt
has been successfully submitted by Roland Jesske and posted to the IETF repository.

Name:		draft-jesske-dispatch-forking-answer-correlation
Revision:	02
Title:		Correlation of multiple responses of forked INVITES in Back to Back User Agents
Document date:	2014-10-27
Group:		Individual Submission
Pages:		23
URL:            http://www.ietf.org/internet-drafts/draft-jesske-dispatch-forking-answer-correlation-02.txt
Status:         https://datatracker.ietf.org/doc/draft-jesske-dispatch-forking-answer-correlation/
Htmlized:       http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-jesske-dispatch-forking-answer-correlation-02

Abstract:
   This document describe how a correlation of multiple responses of a
   forked INVITE in Back to Back User Agents can apply.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Oct 2014 12:26:03 -0400

Roland,

General comment: I suggest that you label each of the messages in call 
flows to identify if they contain SDP, and if so which SDP. (That way we 
can tell which messages contain the same SDP.) Without that it is hard 
to follow.

Section 4.1:

I wonder if the example in figure 1 is too "easy". It would be more 
interesting if it was UAS_3 that returned the 200. (In that case a 
strategy by the UAC to latch onto the last received SDP in a 1xx, 
implicitly assuming serial forking, doesn't work.)

Section 4.2

In this case you propose hiding many of the 18x responses from the UAC. 
This assumes there is no important content in them that is of interest 
to the UAC. But that may not be the case. For instance there are 
semantic differences between 180, 181, 182, 183. Also, there could be 
Alert-Info in these that could influence the UAC user interface. What 
would you do about these?

Section 4.3:

Each of the updates contains an SDP offer. So the response to each of 
those updates will contain an answer. One *hopes* that those answers are 
identical or at least equivalent to the SDP in the initial INVITE. I 
guess you are assuming that. If that turns out not to be true then 
things get complicated.

I assume your intent is that F22 contains an SDP answer, and that F24 
contains equivalent SDP. If so, then update F28 is not needed. (But if 
the 200 had been received from UAS_3 then it would be.)

What SDP, if any, to include in F30 is arguable. Given that an answer 
has previously been sent in a reliable provisional, whatever it contains 
should be ignored by the UAC. Technically it should probably contain 
what was in the first provisional to contain SDP - in this case what was 
in F8. But that may cause trouble with some implementations. There is no 
perfect answer. Omitting SDP in the 200 may be the safest alternative. 
See RFC6337 for more on this.

I'm going to stop now. Lets sort this much out before addressing more.

	Thanks,
	Paul

On 10/28/14 10:36 AM, [email-masked] wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>