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

From: Sergio Ibanez candela <[email-masked]>
Date: Wed, 1 Oct 2014 03:40:35 -0700 (PDT)

Hi,

Some comments regarding draft-jesske-dispatch-forking-answer-correlation-01.

1) It has already been mentioned, but the UAC don't have to send a CANCEL for the non-confirmed early dialogs after the 200OK. This is incorrect. The forking proxy should cancel all the legs that have not been confirmed. The UAC will just consider them as terminated after 64*T1 after the first 200OK.

2) Do you have any specific logic to identify which 18x responses are going to be forwarded back to the UAC and which won't? In your examples I see that, in the case of reliable responses, each provisional response will update the dialog towards the UAC, and therefore always taking the latest one. Is this just an example?, do you have any logic in mind to channel this updates? 

3) What happens if the UAC does not support reliable responses?

4) The early media scenario has not been covered, but I guess it'll be related to 4.3 and 4.4, and in this cases the dialog towards the UAC is always updated with the newest SDP. Will this mean that the audio will be also updated to the latest one? 

Thanks,

Sergio

---

From: <[email-masked]>
Date: Wed, 1 Oct 2014 14:50:03 +0200

Hi Brett
Thank you for your comments and review of my draft.
Answers and some questions inline.
I will update the draft accordingly.

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Brett Tate [mailto:[email-masked]]
> Gesendet: Dienstag, 30. September 2014 19:48
> An: Jesske, Roland; [email-masked]
> Betreff: draft-jesske-dispatch-forking-answer-correlation-01: comments
> 
> 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. 
OK I agree that normally a correct interaction should happen at least when a 200 OK arrives.
Regarding RFC 3261 the 200 OK must be handled correct. There is nothing stated about the 18x. 
Ok my concern is the handling of provisional responses versus final responses.

I will rewrite it correctly.

> However, I agree that some B2BUAs attempt to protect
> clients from needing to support such functionality.
> 
Yes that is real life, as we observed.

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

Yes I can agree on that but it is not possible to do that in each case.
We cannot mandate the devices used within other networks. 
And from our observations there are many cases where we have such problems.
So there is something what we have to do to satisfy our customers which are using more than one device reachable under one "number".

> 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).
>
OK I try to reword as follows:

To provide the best user behavior a service provider shall have the
   possibility to correlate multiples received responses to apply a successful creation of a dialog which imply that the used capabilities of the UAC shall be taken into consideration.

Is this OK?

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

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

OK I change it.
 
> 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?
>

That is something that I should handle also in addition.
Question is if I put it directly into the regarding sections or do it in an own section.

181 itself shows that the call is forwarded. From my understanding it will not contain any SDP. 
Thus when requesting 100rel it will be acknowledged by the B2BUA (PRACK) but no activity will apply at the originating leg.
Because it is not sure which of the early dialogs will be in final state later on.

Per RFC 3261 182 sows that the called party is temporarily unavailable, but the server has
   decided to queue the call rather than reject it. Thus no SDP will be included into this provisional response.
As for 181 it will be acknowledged by the B2BUA (PRACK) but no activity will apply at the originating leg.
Because it is not sure which of the early dialogs will be in final state later on

When succeeding responses containing will be received by the B2BUA it should apply accordingly as described in the draft. 

Is this OK for you?

> 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.
>
7+8) So in the case where a provisional response ins made reliable (incl. reservation of resources) it is still valid that the forking proxy is responsible to release the early dialogs.
MY understanding is that if you make something reliable than the UA store everything what was received. 
So now with receiving the 200 OK by the B2BUA for one of the dialogs all other early (and reliable made) dialogs are destroyed.
And no further action has to be taken by the UAC (B2BUA) only the forking proxy. Right?

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

OK change it.
 
> 10) Section 4.4 figure 4 F40 should maybe be drawn from UAS_4 to match
> numbering and F57.
> 
I don't want it to make it to complicated and do the use case only for two UAS.
I will adopt the figure.

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

Yes I will change it. Also applying it to the use case where only 2 UAC are in the call.

Thank you for your comments.

---

From: <[email-masked]>
Date: Wed, 1 Oct 2014 15:43:32 +0200

Hi Sergio,
Answers Inline.

Best Regards

Roland

> Von: Sergio Ibanez candela [mailto:[email-masked]]
> Gesendet: Mittwoch, 1. Oktober 2014 12:41
> An: [email-masked]; Jesske, Roland
> Betreff: RE: [dispatch] draft-jesske-dispatch-forking-answer-
> correlation-01: comments
> 
> Hi,
> 
> 1) It has already been mentioned, but the UAC don't have to send a
> CANCEL for the non-confirmed early dialogs after the 200OK. This is
> incorrect. The forking proxy should cancel all the legs that have not
> been confirmed. The UAC will just consider them as terminated after
> 64*T1 after the first 200OK.

OK that I will change.

> 
> 2) Do you have any specific logic to identify which 18x responses are
> going to be forwarded back to the UAC and which won't? In your examples
> I see that, in the case of reliable responses, each provisional response
> will update the dialog towards the UAC, and therefore always taking the
> latest one. Is this just an example?, do you have any logic in mind to
> channel this updates?
> 

Ok I see I have a lack of description.
I see only the need to UPDATE the leg when the 18x contains a different SDP.
My understanding is that the B2BUA will add the additional codec.
Thus the UAC will made the SDP reliable.
Perhaps there are also other possibilities for a proper negotiation are also possible.

I'm open for further solutions which we could document in addition or adopt it. 
Also some conclusions  to describe what would be the best way to apply.

> 3) What happens if the UAC does not support reliable responses?

Then the initial INVITE will not include 100rel and the provisional response will not require 100rel.
That would then apply to Figure 2.

> 
> 4) The early media scenario has not been covered, but I guess it'll be
> related to 4.3 and 4.4, and in this cases the dialog towards the UAC is
> always updated with the newest SDP. Will this mean that the audio will
> be also updated to the latest one?
> 

That is my place holder section. So there are a couple of possibilities. Ind I would like to describe what happens when two erly media are in the path.
Perhaps also some race conditions.

Thank you 

Best Regards

Roland

---

From: Brett Tate <[email-masked]>
Date: Wed, 1 Oct 2014 12:04:16 -0400

Hi Roland,

Reply is inline.

> > RFC 3261 mandates that the UAC be able to handle interactions with
> > a forking proxy.
>

RFC 3261 indicates how the UAC must/should/may behave (some aspects updated
by RFC 6026 and RFC 6141); this includes the impacts of receiving INVITE's
18x or 2xx on a known or unknown dialog.  However, it frequently defers the
human interaction decisions to the implementor.

Similarly, a device can be fully compliant with RFC 3261 but decide to have
a service to terminate call after or before answer (or individual early
dialogs before answer) if more than 1 dialog was observed during call setup.
Such a "service" likely indicates that the device doesn't really support
forking proxies (or maybe doesn't trust forking interactions).

> > I disagree with that statement.  One solution is to replace/upgrade
> > the deficient device so that it supports forking interactions.
> >
>
> So there is something what we have to do to satisfy our customers which
> are
> using more than one device reachable under one "number".

That is the issue.  Someone deployed devices which are causing forking
related interoperability issues.  B2BUAs are frequently used to help
overcome (while attempting to avoid) interoperability issues.  Thus it is a
matter of deciding if the IETF wants to do anything (such as producing an
RFC) to help remedy the issue.

> > 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
>    possibility to correlate multiples received responses to apply a
> successful
> creation of a dialog which imply that the used capabilities of the UAC
> shall be
> taken into consideration.
>
> Is this OK?

The following might be good enough for now:

"To improve interoperability with devices which do not support forking, a
service provider shall have the possibility to use a B2BUA to correlate
multiple dialogs into a single dialog."

> Question is if I put it directly into the regarding sections or do it in
> an own
> section.
>
> 181 itself shows that the call is forwarded. From my understanding it will
> not
> contain any SDP.

Similar to the other 18x responses, the SDP is optional.

> Thus when requesting 100rel it will be acknowledged by the B2BUA (PRACK)
> but no activity will apply at the originating leg.

The B2BUA never knows which known/unknown dialog will generate the first
INVITE 2xx response.

The proposal delays communicating a 18x to caller.

> Per RFC 3261 182 sows that the called party is temporarily unavailable,
> but
> the server has
>    decided to queue the call rather than reject it. Thus no SDP will be
> included
> into this provisional response.

Similar to the other 18x responses, the SDP is optional.

> As for 181 it will be acknowledged by the B2BUA (PRACK) but no activity
> will
> apply at the originating leg.
> When succeeding responses containing will be received by the B2BUA it
> should apply accordingly as described in the draft.
>
> Is this OK for you?

The proposal delays communicating a 18x to caller and may result in call
release since B2BUA preventing caller from receiving 18x responses during
call setup.

> > This should not be occurring.  It also looks like there is a
> > subsequent extra 200 response.
> >
> 7+8) So in the case where a provisional response ins made reliable (incl.
> reservation of resources) it is still valid that the forking proxy is
> responsible to
> release the early dialogs.
> So now with receiving the 200 OK by the B2BUA for one of the dialogs all
> other early (and reliable made) dialogs are destroyed.

See RFC 3261 section 16.7 step 10.  The forking proxy MUST send CANCEL;
however a subsequent 2xx for INVITE may still be received by the caller.
Thus you'd likely want the B2BUA to ACK/BYE late INVITE 2xx responses.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 13:01:27 -0400

I generally agree with Brett. (I usually do.)

One comment:

> multiple dialogs into a single dialog."

Instead of "correlate", I suggest "multiplex":

"To improve interoperability with devices which do not support forking, 
a service provider shall have the possibility to use a B2BUA to 
multiplex multiple downstream dialogs into a single dialog toward the 
caller."

There is substantially more to do than simply correlate.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 2 Oct 2014 15:24:19 +0200

Hi Brett,
thank you for your comments.
Reply inline.

> Gesendet: Mittwoch, 1. Oktober 2014 18:04
> Betreff: RE: draft-jesske-dispatch-forking-answer-correlation-01:
> comments
> 
> Hi Roland,
> 
> Reply is inline.
> 
> RFC 3261 indicates how the UAC must/should/may behave (some aspects
> updated by RFC 6026 and RFC 6141); this includes the impacts of
> receiving INVITE's 18x or 2xx on a known or unknown dialog.  However, it
> frequently defers the human interaction decisions to the implementor.
> 
> Similarly, a device can be fully compliant with RFC 3261 but decide to
> have a service to terminate call after or before answer (or individual
> early dialogs before answer) if more than 1 dialog was observed during
> call setup.

Thank you for clarification. So I see that there is at least everything described but 
It is more as you said the: "it frequently defers the human interaction decisions to the implementor"

I take your words and will implement it in the draft. Also I will take the RFC6026 and RFC6141 into consideration.

> > So there is something what we have to do to satisfy our customers
> > which are using more than one device reachable under one "number".
> 
> overcome (while attempting to avoid) interoperability issues.  Thus it
> is a matter of deciding if the IETF wants to do anything (such as
> producing an
> > > I disagree with that statement.  Folding multiple early dialogs onto
> > > a single early dialog does not produce the best user experience.  It
> > > 3311 (if the B2BUA needs to communicate SDP modifications on an
> > > early dialog).
> > >
> > successful creation of a dialog which imply that the used capabilities
> > of the UAC shall be taken into consideration.
> >
> > Is this OK?
> 
> correlate multiple dialogs into a single dialog."

OK I will take the words including Paul's change from correlate to multiplex.
I hope that is OK for you.

> Similar to the other 18x responses, the SDP is optional.

OK.
I was thinking to use 181 more as an indication. 
But you are right. It could be also to include SDP 
With early media to play an announcement where the caller gets some more information.

> 
> > Thus when requesting 100rel it will be acknowledged by the B2BUA
> > (PRACK) but no activity will apply at the originating leg.

OK. 

> >    decided to queue the call rather than reject it. Thus no SDP will
> > be included into this provisional response.
> 

Yes. It is the same as for 181.
So I will have some words on 181 and 182 
> 
> > As for 181 it will be acknowledged by the B2BUA (PRACK) but no
> > activity will apply at the originating leg.
> release since B2BUA preventing caller from receiving 18x responses
> during call setup.

Yes then the B2BUA has to assure that the timers which are running do not fire and terminate the call.
In the normal case I see that the B2BUA receiving 18x responses that do not contain any SDP 
does not need to be forwarded to the UAC.

My example is the 181 which is not containing any SDP. So the call is forwarded by an UAS_2 to another UAS_3.
UAS_2 sends an 181 without SDP only indicating that the INVITE was forwarded.
Seen from forking perspective the 181 has no value for the UAC since it is not interesting as long as UAS_3 sends the 200OK first.

So now the tricky part starts.
There could be also a requirement from the caller that he does not like to have calls forwarded.
Then he needs the forwarding information.
Either then the B2BUA has to sent first the 181 and then the 200OK which will really delay the call as you said.
Or the B2BUA send's back the 200 OK with the History-Info header indicating the call forwarding. But that assumes that the UAC supports RFC4244/7044. 
Thus the Caller gets the indication that the call was forwarded and the caller can decide if he wants to reject the call or not.  

I think I have to do some more description on such scenarios.

> > responsible to release the early dialogs.
> > So now with receiving the 200 OK by the B2BUA for one of the dialogs
> > all other early (and reliable made) dialogs are destroyed.

I will add some words with regard to lately received 200 OK.

Roland

---

From: <[email-masked]>
Date: Thu, 2 Oct 2014 15:26:00 +0200

Thank you Paul,
I will take the sentence using "multiplex".

Best Regards

Roland

> Von: dispatch [mailto:[email-masked]] Im Auftrag von Paul
> Kyzivat
> Gesendet: Mittwoch, 1. Oktober 2014 19:01
> An: [email-masked]
> Betreff: Re: [dispatch] draft-jesske-dispatch-forking-answer-
> correlation-01: comments
> 
> > "To improve interoperability with devices which do not support
> > forking, a service provider shall have the possibility to use a B2BUA
> > to correlate multiple dialogs into a single dialog."
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 2 Oct 2014 16:58:36 -0400

> From: Paul Kyzivat <[email-masked]>

> Instead of "correlate", I suggest "multiplex":

This is an important change.  Normally the term "answer correlation"
describes how the UAC determines which RTP streams correspond to which
1xx responses it receives.

But if the purpose of this draft is to describe how a B2BUA can
multiplex multiple early dialogs so that the UAC does not have to be
aware of them, the draft should also describe in detail the
considerations which apply to media streams.  E.g., if the UAC cannot
process multiple early dialogs, would it be able to process multiple
early media streams?  I expect that in this situation, the B2BUA would
be expected to multiplex the media in some manner, and we should
describe what the constraints are for doing that.

Dale