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

From: <[email-masked]>
Date: Mon, 3 Nov 2014 17:11:03 +0100

Hi Paul,
Thank you for your comments.

Here are my comments:

> -----Ursprüngliche Nachricht-----
> Von: dispatch [mailto:[email-masked]] Im Auftrag von Paul
> Kyzivat
> Gesendet: Donnerstag, 30. Oktober 2014 17:26
> An: [email-masked]
> Betreff: Re: [dispatch] WG: New Version Notification for draft-jesske-
> dispatch-forking-answer-correlation-02.txt
> 
> 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.)

That is true. So I will redraw the figure.

> 
> 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?

Yes indeed. So it will be the best way to describe for each response code the action that should be done in case of multiples responses.

I see:

180/183 is already described.

181 is the call forwarding use case. Seen from this point of view I should describe a specific call forwarding scenario.
Since the 180 will come from an further UAS_3 and 181 is only the information from

UAC         B2BUA            UAS_1            UAS_2 UAS_3 UAS_4
|              |               |                |     |     |
|- INVITE F1-->|               |                |     |     |
|              |- INVITE F2 -->|- INVITE F3(2)->|     |     |
|              |<-- 181 (1) F6-|                |     |     |
|<-- 181 (1) F6|               |<-- 180 (2) F6--|     |     |
|              |<- 180 (2) F7 -|                |     |     |
|<- 180 (1) F8-|               |                |     |     |

Here a further discussion is needed
A 181 could include SDP in the case when an application will do some early media.

Question for me is if 182 will have the same behavior.
Such an answer will include an SDP to allow an announcement saying call is queued

> 
> 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.

Yes. In cases where the SDP Codecs are the same then there is no big issue. 
But the case where the answer is different less codecs.
Payload type.

> 
> 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.)

Yes that is true. It looks that I have a clash in my figure which I need to correct. 
> 
> 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.

Of course if SDP is included it must be the same. But considering that the SDP should be deleted is indeed the safest way.
I will adopt the regarding discussion in my paper.

Thank you for the hint.

I will come up with some proposals for discussion.

Thank you and Best Regards

Roland

> 
> 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:
> > 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
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch