Subject: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00

From: <[email-masked]>
Date: Fri, 19 Sep 2014 08:36:34 +0200

Hi,

We've submitted a new draft, draft-jesske-dispatch-forking-answer-correlation-00

Since forking was defined for SIP problems on the functionality are existing. We have identified that not all entities in networks will understand multiples provisional responses sent back for each forking leg where an INVITE was sent to. This will either result in an restriction of the reachability of the terminating user or in worst case scenarios in non successful call. In cases of where different networks are within the call path involved, this will restrict the terminating service provider to satisfy his customers in providing the forking feature and  also transit service providers in providing a high rate of successful calls.
The draft describes use cases and shows possibilities how to correlate all received provisional responses (including preconditions and 100rel)  in a intermediate entity to allow to interact with networks/entities (UA's, networks, MGCF) which are not able/willing to understand and handle responses of a forked call.

A first draft (which needs improvement) can be seen under:

http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-00

I would be happy to have comments.

Thank you and Best Regards

Roland

Mit freundlichen Grüßen; With Best Regards
Roland Jesske

Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Carsten Müller
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2014 14:25:03 -0400

Roland,

Some comments:

Section 1 says:

    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 ted to implementers choice.  There will the first
    problem apply that only one of the Responses will be taken into
    consideration.

I disagree that 3261 doesn't mandate handling responses from multiple 
forks. By defining that the request MAY be forked, it implies that the 
UAC must be prepared for responses from multiple forks. What it doesn't 
do is require *how* the responses from multiple forks are to be handled, 
as long as the basic transaction and dialog semantics are followed.

The minimum that the UAC can do is recognize when multiple early or 
final dialogs are established and then dispose of them. Final responses 
on *each* dialog require an ACK. And then if the final response was a 
2xx, then the dialog must (eventually) be terminated in some way.

UACs that can't do this are *broken*.

    This document will describe how a correlation for multiples early
    dialogs and other received Responses can done within a B2BUA as
    described in the taxonomy document RFC7029 [RFC7029] The role of the
    B2BUA is a Signaling/Media Plane B2BUA Role.  Thus many possible use
    cases which will be possible looking on the used features are
    considered in this document

If this is really about how B2BUAs do it, then perhaps this belongs in 
STRAW.

Section 1.2 says:

    SIP defined in RFC3261 [RFC3261]describes how forking should apply.
    Also rules for UA for responses and merged requests are defined.  But
    it is not stated how a forking correlation should apply and what is
    needed.  ...

I don't understand what you mean. Responses on different forks have 
distinct to-tags but share the same from-tag and call-id. This is all 
clear in 3261. This is the *purpose* of the to-tag!

If you mean it doesn't describe how a B2BUA should do correlation, then 
yes, I agree it does not. It doesn't say how a B2BUA does *anything*. 
(Other than that it must act properly as a UA on each "side".)

Figure 1:

This has errors. It shows dialog-specific CANCEL requests. There is no 
such thing. CANCEL is addressed exactly the way the INVITE was (no 
to-tag and hence not dialog-specific), and operates in a hop-by-hop 
basis. It is the responsibility of the forking proxy to send CANCEL to 
each remaining early dialog after it has forwarded the 200 back to the 
UAC. (And it is the responsibility of the UAC to be prepared to deal 
with a subsequent 2xx from another fork, if one happens to get through.)

Section 1.3:

    Figure 1 shows an normal example of forking.  With receiving 18x the
    UAC has to open transaction. where UAS_2 and UAS_3 does reject the
    call with a 4xx.  So only UAA_4 answers the dialog correctly.

I can't understand this paragraph. Is it describing a variant of figure 
1 that isn't shown?

Section 1.4, Figure 2:

Exactly what do the numbers in the parentheses (e.g., "18x (2)") mean? 
In the prior figure I took them to identify dialog ids. But that doesn't 
work in this figure.

And how is the B2BUA managing dialog ids? Is it presenting a single 
to-tag to the UAC, or is it using separate to-tags corresponding to the 
different to-tags it is receiving from the forking proxy? Both are 
possible, but the resulting signaling is distinctly different.

I'm guessing that it is trying to maintain a single dialog to the UAC.

    With arriving a new 18x with additional codecs included have to
    result in an UPDATE containing the SDP of the preceding 18x.  The
    important fact is that the B2BUA has to anchor the media plane as
    well as acting as signalling B2BUA.

You aren't showing PRACKs so reliable provisionals must not be in use. 
In that case, the initial O/A isn't complete until the 200 response to 
the INVITE. Until then there can be no changes to the SDP. So the 
UPDATEs can't do what you want them to do.

You *could* do this if 18x (2) to the UAC was a reliable provisional. In 
that case the B2BUA would *not* be required to anchor the media.

It appears that sections 1.5, 1.6, 1.7 were intended to be subsections 
of 1.5.

Section 1.6:

    Where the B2BUA decides to path the required 100rel the UAC will send
    then the PRACK and waits for the 200 OK.  In case there are further
    18x with other type of SDP arriving at the B2BUA the UAC needs to be
    informed about change of codec.  The UAC has again to sent the PRACK.

I think you meant "pass" rather than "path".

There are multiple possibilities here. The B2BUA could treat each fork 
separately - different to-tags - just like would happen if it were a 
true proxy. In that case it doesn't need to anchor the media, though it 
still can if it wants. The UAC must be capable of supporting multiple 
early dialogs.

If it only uses a single to-tag toward the UAC, then it can/must use 
UPDATEs as you show in figure 2. Again it may/may-not anchor the media.

Section 1.7:

    This use case describes the case where preconditions will be used.
    This apply in mobile networks where resource reservation is used.
    The Precondition mechanism in RFC3312 [RFC3312] shows the needed
    additional procedures.  A B2BUA doing correlation in between to
    allows only one early dialog sent back to the UAC.  The B2BUA has to
    anchor the SIP Dialogs as well as the media reservation streams.

This depends on the cases I mentioned for 1.6. Certainly the 
straightforward way is to anchor the media and handle the preconditions 
separately on the two sides.

Section 1.8:

This seems incomplete, so I can't comment.

General comment: are you intending to cover both B2BUAs that do and 
don't anchor media, or only those that do?

If you are only intending to handle media anchoring B2BUAs, then say 
that clearly, and it will be easier to discuss all the rest.

If you also intend to handle B2BUAs that *don't* anchor media, then it 
is probably better to treat those cases separately, because they are 
very different.

If you are thinking that a B2BUA might dynamically decide whether to 
anchor or not based on the details of the offers, then do the other 
cases first. I think this is very hard, and maybe not possible.

	Thanks,
	Paul

On 9/19/14 2:36 AM, [email-masked] wrote:
> Hi,
> We’ve submitted a new draft,
> draft-jesske-dispatch-forking-answer-correlation-00
> Since forking was defined for SIP problems on the functionality are
> existing. We have identified that not all entities in networks will
> understand multiples provisional responses sent back for each forking
> leg where an INVITE was sent to. This will either result in an
> restriction of the reachability of the terminating user or in worst case
> scenarios in non successful call. In cases of where different networks
> are within the call path involved, this will restrict the terminating
> service provider to satisfy his customers in providing the forking
> feature and  also transit service providers in providing a high rate of
> successful calls.
> The draft describes use cases and shows possibilities how to correlate
> all received provisional responses (including preconditions and 100rel)
> in a intermediate entity to allow to interact with networks/entities
> (UA’s, networks, MGCF) which are not able/willing to understand and
> handle responses of a forked call.
> _http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-00_
> _http://www.telekom.com_
> *Große Veränderungen fangen klein an **–**Ressourcen schonen und nicht
> jede E-Mail drucken.*
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Sep 2014 18:34:18 +0000

(As STRAW co-chair)

Hi Paul,

> If this is really about how B2BUAs do it, then perhaps this belongs in STRAW.

I actually told Roland to submit the draft to DISPATCH, as it doesn't address any of the current STRAW deliveries.

But, if there is no need to go via DISPATCH, we can ask Roland to submit to STRAW directly :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2014 14:40:51 -0400

> But, if there is no need to go via DISPATCH, we can ask Roland to submit to STRAW directly :)

It is perhaps proper that it first come to dispatch.

Consider my comment a suggestion that DISPATCH ought to dispatch it to 
STRAW.

	Thanks,
	Paul

---

From: "Roland Jesske" <[email-masked]>
Date: Wed, 24 Sep 2014 19:35:50 +0200

Hello Paul,
Thank you very much for your review of my draft.
Comments are inline.
I'm working at the next version of the document and will incoperate your valunable input.

Roland

> Gesendet: Freitag, 19. September 2014 um 20:25 Uhr
> Von: "Paul Kyzivat" <[email-masked]>
> An: [email-masked]
> Betreff: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00
> Roland,
> 
> Some comments:
> 
> Section 1 says:
> 

> as long as the basic transaction and dialog semantics are followed.
[RJ] I could agree if the forking proxy knows what UAC the request is from. But I cannot 
identify it. I thought that was one the reason to provide the caller preferences.
If I as service provider know what clients my customers are using and sending it with the request
then the proxy could decide to fork based on that information.
But when I terminate my request in another network and fork it to a couple of UAS
I have no clue if the UAC is able to accept multiple responses.

Or do did I oversee something?

> final dialogs are established and then dispose of them. 

[RJ] So looking on your comment below. Ignore the early dialogs and then cancel when 200 OK is arriving.

> Final responses

[RJ] So in case a UAC receives two 200 OK even not supporting multipes dialogs 
it must choose one to terminate it with a BYE after sending ACK.

> UACs that can't do this are *broken*.

[RJ] OK.
So I will reword my section taking that into consideration.

> If this is really about how B2BUAs do it, then perhaps this belongs in

[RJ] Yes this is my intention

> clear in 3261. This is the *purpose* of the to-tag!

[RJ] Yes I agree

> (Other than that it must act properly as a UA on each "side".)

[RJ] Yes I agree. This is what we want to describe since we have a couple of B2BUA in our network.

> with a subsequent 2xx from another fork, if one happens to get through.)

[RJ] So only one CANCEL and that will forked to the remaining dialogs.
I will change the figure.

> I can't understand this paragraph. Is it describing a variant of figure

[RJ] Yes I will rewrite the text and sections in an other way.

> In the prior figure I took them to identify dialog ids. But that doesn't

[RJ] I'd like to show to which UA the SIP messages are belonging to. I try to do it in a more unresandable way.

> I'm guessing that it is trying to maintain a single dialog to the UAC.

[RJ] Yes you are right. This needs more text to describe this. ALso how to handle the to-tags and dialog ID's

> UPDATEs can't do what you want them to do.

[RJ] OK will change it.

> that case the B2BUA would *not* be required to anchor the media.

[RJ] This use case I describe in the next section.

> It appears that sections 1.5, 1.6, 1.7 were intended to be subsections

[RJ] I will do a complete reorder of all sections. I hope that will fit then.

> I think you meant "pass" rather than "path".

[RJ] Yes

> UPDATEs as you show in figure 2. Again it may/may-not anchor the media.

[RJ] Yes that is what I want to describe.

> separately on the two sides.

[RJ] Yes that is what I will describe in this section.

> This seems incomplete, so I can't comment.

[RJ] Agreed I have to do ther more work

> that clearly, and it will be easier to discuss all the rest.

[RJ] I like to deskribe some cases where the B2BUA anchor the media and at least one where not.
But I will do the description exactly and state where I see that the B2BUA has to anchor media and 
the case where tha B2BUA has not to anchor the media. 

> is probably better to treat those cases separately, because they are

[RJ] Yes I agree.
> cases first. I think this is very hard, and maybe not possible.

[RJ] I agree with you. As longer I'm looking into this issue I see that some cases will not 
work as I thought first.

Thanks,
Paul

[RJ] Thank you very much for your comments.

On 9/19/14 2:36 AM, [email-masked] wrote:
> _http://www.telekom.com[http://www.telekom.com]_
>
> Erleben, was verbindet.
>
> https://www.ietf.org/mailman/listinfo/dispatch[https://www.ietf.org/mailman/listinfo/dispatch]
>

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch[https://www.ietf.org/mailman/listinfo/dispatch]

---

From: "Roland Jesske" <[email-masked]>
Date: Wed, 24 Sep 2014 19:38:16 +0200

Hi Paul,

I intend to do so.

Best Regards

Roland

Gesendet: Freitag, 19. September 2014 um 20:40 Uhr

An: "Christer Holmberg" <[email-masked]>, "[email-masked]" <[email-masked]>

On 9/19/14 2:34 PM, Christer Holmberg wrote:

STRAW.

Thanks,

Paul

dispatch mailing list

[email-masked]

---

From: "Roland Jesske" <[email-masked]>
Date: Wed, 24 Sep 2014 19:40:33 +0200

If people would like to have it I can do this.

Thank you

Roland

Gesendet: Freitag, 19. September 2014 um 20:34 Uhr

Von: "Christer Holmberg" <[email-masked]>

An: "Paul Kyzivat" <[email-masked]>, "[email-masked]" <[email-masked]>

(As STRAW co-chair)

Hi Paul,

Regards,

Christer

dispatch mailing list

[email-masked]

---

From: Mary Barnes <[email-masked]>
Date: Fri, 26 Sep 2014 12:25:23 -0500

This discussion should continue in the DISPATCH WG until we get community
consensus that people think this problem is worth solving and that there
are people willing to do the work to complete a solution.  As Christer
notes, this work is currently not within the scope of the current STRAW
charter and so it's not clear it should be immediately dispatched there.

Per the deadlines on the DISPATCH WG wiki, based on the DISPATCH WG chairs
discussion with the ADs, we will post the list of topics and the handling
thereof for the IETF-91 timeframe on October 13th.

At this point, the only technical comments have been from Paul.

Regards,
Mary
as DISPATCH WG co-chair

On Fri, Sep 19, 2014 at 1:34 PM, Christer Holmberg <
[email-masked]> wrote:

> I actually told Roland to submit the draft to DISPATCH, as it doesn't
> address any of the current STRAW deliveries.
>

---

From: <[email-masked]>
Date: Tue, 30 Sep 2014 07:17:28 +0200

Hi Mary,
Thank you for your mail and clarification.

Now I have a reworked version of the draft which is now available.

A new version of I-D, draft-jesske-dispatch-forking-answer-correlation-01.txt

has been successfully submitted by Roland Jesske and posted to the IETF repository.

Name:       draft-jesske-dispatch-forking-answer-correlation

Revision:   01

Title:            Correlation of multiple responses of forked INVITES in Back to Back User Agents

Document date:    2014-09-29

Group:            Individual Submission

Pages:            18

URL:            http://www.ietf.org/internet-drafts/draft-jesske-dispatch-forking-answer-correlation-01.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-01

Diff:           http://www.ietf.org/rfcdiff?url2=draft-jesske-dispatch-forking-answer-correlation-01

Abstract:

   This document describe how a correlation of multiple responses of a

   forked INVITE in Back to Back User Agents can apply.

Based on Paul’s comments I have restructured the draft. And changed the call flows.

I would be happy to get comments and of course an indication that people would like to proceed with the work on the draft.

Roland

Von: dispatch [mailto:[email-masked]] Im Auftrag von Mary Barnes
Gesendet: Freitag, 26. September 2014 19:25
An: Christer Holmberg
Cc: [email-masked]
Betreff: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00

This discussion should continue in the DISPATCH WG until we get community consensus that people think this problem is worth solving and that there are people willing to do the work to complete a solution.  As Christer notes, this work is currently not within the scope of the current STRAW charter and so it's not clear it should be immediately dispatched there.

Per the deadlines on the DISPATCH WG wiki, based on the DISPATCH WG chairs discussion with the ADs, we will post the list of topics and the handling thereof for the IETF-91 timeframe on October 13th.

Regards,
Mary
as DISPATCH WG co-chair

On Fri, Sep 19, 2014 at 1:34 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

(As STRAW co-chair)

Hi Paul,

Regards,

Christer

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch