Subject: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-01: comments and question

From: Brett Tate <[email-masked]>
Date: Wed, 18 Feb 2015 08:28:11 -0500

Hi,

The following are a few initial comments concerning
draft-allen-dispatch-routing-out-of-dialog-request-01.

Thanks,
Brett

------

1) RFC 3725 indicates the following.

"Third party call control is possible using only the mechanisms
specified within RFC 3261 [1]."

This draft appears to currently prevent the above from occurring.
Similarly how do you foresee this draft impacting 3PCC call setup such as
those depicted within RFC 3725?

2) Section 3.5 indicates the following.

"One advantage of this approach is
that there may be some backward compatibility with this mechanism
because RFC 3261 [5] compliant UAs should use the embedded Route
header fields when constructing a request addressed to this Contact
URI."

That sentence should potentially be adjusted since RFC 3261 section 19.1.5
appears to indicate that the Route SHOULD NOT be honored.

"An implementation SHOULD NOT honor any requested Route header field
values in order to not be used as an unwitting agent in malicious
attacks."

---

From: Andrew Allen <[email-masked]>
Date: Sat, 21 Feb 2015 00:13:43 +0000

Brett

Thanks for reviewing the draft.

Responses inline

Andrew

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: Wednesday, February 18, 2015 8:28 AM
To: [email-masked]; [email-masked]
Subject: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-01: comments and question

Hi,

The following are a few initial comments concerning draft-allen-dispatch-routing-out-of-dialog-request-01.

Thanks,
Brett

------

"Third party call control is possible using only the mechanisms specified within RFC 3261 [1]."

This draft appears to currently prevent the above from occurring.
Similarly how do you foresee this draft impacting 3PCC call setup such as those depicted within RFC 3725?

[AA] It's not my draft that prevents this. In fact my draft is intended to address the problems that B2BUA intermediaries cause for REFER and SUBSCRIBE with RFC 3515 and RFC 6665. So it addresses problems with extensions working through B2BUAs not with RFC 3261. If the RFC 3725 procedures don't work through B2BUAs then that isn't something caused by this draft.

"One advantage of this approach is
that there may be some backward compatibility with this mechanism because RFC 3261 [5] compliant UAs should use the embedded Route header fields when constructing a request addressed to this Contact URI."

That sentence should potentially be adjusted since RFC 3261 section 19.1.5 appears to indicate that the Route SHOULD NOT be honored.

"An implementation SHOULD NOT honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks."

[AA] Good catch. This would seem to dispel the advantage of this idea which was proposed on the list during the discussion of an earlier version of the draft. I will change the text related to this proposal and mention the RFC 3261 text if there is a revision of this draft still advocating different alternatives.

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

---

From: Brett Tate <[email-masked]>
Date: Mon, 23 Feb 2015 09:23:24 -0500

Hi,

Thanks for the response; reply is inline.

> "Third party call control is possible using only
> the mechanisms specified within RFC 3261 [1]."
>
> This draft appears to currently prevent the above
> from occurring.  Similarly how do you foresee this
> draft impacting 3PCC call setup such as those
> depicted within RFC 3725?
>
> [AA] It's not my draft that prevents this. In fact
> my draft is intended to address the problems that
> B2BUA intermediaries cause for REFER and SUBSCRIBE
> with RFC 3515 and RFC 6665. So it addresses problems
> with extensions working through B2BUAs not with
> RFC 3261. If the RFC 3725 procedures don't work
> through B2BUAs then that isn't something caused by
> this draft.

I'm referring to 3PCC devices which are B2BUAs.  The draft's current
proposal is that the B2BUA not use its own Contact.

One of the potential solutions should mention the potential for B2BUA to
replace the Contact (with whatever you want to say concerning parameters).
This is potentially the only option which can continue to work for RFC
3725 3PCC B2BUAs desiring to remain interoperable with basic RFC 3261
devices.

Some of the use cases to consider when selecting/documenting a solution
should be 3PCC as documented within RFC 3725 (such as 10.1 and 10.2).