
From victor.pascual.avila@gmail.com  Tue Jul  9 07:41:50 2013
Return-Path: <victor.pascual.avila@gmail.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC1421F9C6E for <straw@ietfa.amsl.com>; Tue,  9 Jul 2013 07:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n97WzV3HS3aD for <straw@ietfa.amsl.com>; Tue,  9 Jul 2013 07:41:50 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADEC21F9B17 for <straw@ietf.org>; Tue,  9 Jul 2013 07:41:49 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id fq12so4788661lab.38 for <straw@ietf.org>; Tue, 09 Jul 2013 07:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VdXINmwbH7DE+s5++c+Ep3mONhBskhihET5WxCnz8cY=; b=wIqz8u565Fw7GlgLvGAujGkFRf6TEEC0zmBDOOvkV0hhgce3tfM2MmXCSrwsBJtRgv /tvnbhviedR7ePoCQCq6+g9P8DmblosJv7lht1W0YN0BlduALfF8qcZ+WJ0sQ18GjC1+ Ghk1STwWuLMsEIGd9bVPbXNxzZ7Gtw40KCWfaalIysde3wf1sNhKin99cGt1+lqwsc6B S+6pkWmMX3UT5/OnKlgl7V2MuwzHSWFofiDVtv221MuVgkqIsgbK0PMI+pbZVO1+1bRy gI71dtV3SiV6PAsYXgiPhrm8i7tzqaH7bSZaGeEM7JTK4G75RJDuokZnDD/P1nRbBpgm C4Cw==
MIME-Version: 1.0
X-Received: by 10.112.185.40 with SMTP id ez8mr12706838lbc.31.1373380908807; Tue, 09 Jul 2013 07:41:48 -0700 (PDT)
Received: by 10.114.180.102 with HTTP; Tue, 9 Jul 2013 07:41:48 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se>
Date: Tue, 9 Jul 2013 21:41:48 +0700
Message-ID: <CAGTXFp_mQVwZ=VoWMJ3aq0fM4hy7hQDYHCVTeUgG9KShoCs2Qw@mail.gmail.com>
From: Victor Pascual Avila <victor.pascual.avila@gmail.com>
To: "straw@ietf.org" <straw@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Hadriel Kaplan <hadriel.kaplan@oracle.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [straw] Call for WG adoption: draft-kaplan-straw-sip-traceroute-01.txt
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 14:41:50 -0000

[As co-chair]

Hi,

The chairs declare rough consensus on adopting
draft-kaplan-straw-sip-traceroute-01. We request the author to submit
a draft-straw-00 version of the draft.

Thank You!

Regards,
-Victor

On Mon, Jun 17, 2013 at 2:56 PM, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> (As co-chair)
>
>
>
> Hi,
>
>
>
> Based on the discussions in Orlando, Hadriel has submitted a new version
> (-01) of draft-kaplan-straw-sip-traceroute:
>
>
>
> http://www.ietf.org/id/draft-kaplan-straw-sip-traceroute-01.txt
>
>
>
> As discussed, once the draft is submitted, the chairs will call for WG
> adoption of the draft, as base for the following WG charter delivery:
>
>
>
> =E2=80=9CA document defining the requirements for B2BUAs to support end-t=
o-end and
> hop-by-hop media-loopback test calls submitted to the IESG as PS=E2=80=9D
>
>
>
> So, as no other proposals to implement the delivery have been submitted, =
the
> chairs suggest that the WG adopts draft-kaplan-straw-sip-traceroute-01 as
> base for the delivery above, and that anyone who has issues with that rai=
ses
> those issues it on the list by Friday 5th July.
>
>
>
> Thanks!
>
>
>
> Christer & Victor
>
>
>
> Ps. The notes from Orlando can be found at:
> http://www.ietf.org/proceedings/86/minutes/minutes-86-straw
>
>
>
>
>
>
> _______________________________________________
> straw mailing list
> straw@ietf.org
> https://www.ietf.org/mailman/listinfo/straw
>



--
Victor Pascual =C3=81vila

From hadriel.kaplan@oracle.com  Sun Jul 14 20:13:34 2013
Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31D421F9ADD for <straw@ietfa.amsl.com>; Sun, 14 Jul 2013 20:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.457
X-Spam-Level: 
X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edpmqmiiok0S for <straw@ietfa.amsl.com>; Sun, 14 Jul 2013 20:13:29 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB821F9310 for <straw@ietf.org>; Sun, 14 Jul 2013 20:13:29 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6F3DQp1024879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <straw@ietf.org>; Mon, 15 Jul 2013 03:13:27 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6F3DPtC028545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <straw@ietf.org>; Mon, 15 Jul 2013 03:13:26 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6F3DPNI006115 for <straw@ietf.org>; Mon, 15 Jul 2013 03:13:25 GMT
Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 14 Jul 2013 20:13:25 -0700
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Jul 2013 23:13:24 -0400
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com>
To: "straw@ietf.org" <straw@ietf.org>
Message-Id: <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 03:13:34 -0000

FYI - the traceroute draft has now been submitted as a WG draft.

I've added the part for handling how to know when you've reached the =
final UAS.  It wasn't quite clear from emails, but I think there was =
rough consensus for putting something in the SDP answer.  So I've taken =
the initiative and chosen what that would be: a pre-defined sess-id =
value in the origin line.  That will probably cause someone heartburn, =
but the IETF doesn't charge us money to upload new versions of drafts, =
so I can change it to whatever we get consensus for.

-hadriel


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-straw-sip-traceroute-00.txt
> Date: July 14, 2013 10:59:57 PM EDT
> To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
>=20
>=20
> A new version of I-D, draft-straw-sip-traceroute-00.txt
> has been successfully submitted by Hadriel Kaplan and posted to the
> IETF repository.
>=20
> Filename:	 draft-straw-sip-traceroute
> Revision:	 00
> Title:		 A Media-based Traceroute Function for the =
Session Initiation Protocol (SIP)
> Creation date:	 2013-07-14
> Group:		 Individual Submission
> Number of pages: 6
> URL:             =
http://www.ietf.org/internet-drafts/draft-straw-sip-traceroute-00.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-straw-sip-traceroute
> Htmlized:        =
http://tools.ietf.org/html/draft-straw-sip-traceroute-00
>=20
>=20
> Abstract:
>   SIP already provides the ability to perform hop-by-hop traceroute
>   for SIP messages using the Max-Forwards header field, in order to
>   determine the reachability path of requests to a target.  A
>   mechanism for media-loopback calls has also been defined separately,
>   which enables test calls to be generated which result in media being
>   looped back to the originator.  This document describes a means of
>   performing hop-by-hop traceroute-style test calls using the media-
>   loopback mechanism, in order to test the media path when SIP
>   sessions go through media-relaying B2BUAs.
>=20
>=20
>=20
>=20
>=20
> The IETF Secretariat
>=20


From internet-drafts@ietf.org  Mon Jul 15 10:18:25 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF7211E80AD; Mon, 15 Jul 2013 10:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level: 
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrZ2499+IAnI; Mon, 15 Jul 2013 10:18:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA51621E8064; Mon, 15 Jul 2013 10:18:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130715171824.19411.71580.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jul 2013 10:18:24 -0700
Cc: straw@ietf.org
Subject: [straw] I-D Action: draft-ietf-straw-sip-traceroute-00.txt
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 17:18:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Sip Traversal Required for Applications t=
o Work Working Group of the IETF.

	Title           : A Media-based Traceroute Function for the Session Initia=
tion Protocol (SIP)
	Author(s)       : Hadriel Kaplan
	Filename        : draft-ietf-straw-sip-traceroute-00.txt
	Pages           : 6
	Date            : 2013-07-15

Abstract:
   SIP already provides the ability to perform hop-by-hop traceroute
   for SIP messages using the Max-Forwards header field, in order to
   determine the reachability path of requests to a target.  A
   mechanism for media-loopback calls has also been defined separately,
   which enables test calls to be generated which result in media being
   looped back to the originator.  This document describes a means of
   performing hop-by-hop traceroute-style test calls using the media-
   loopback mechanism, in order to test the media path when SIP
   sessions go through media-relaying B2BUAs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-straw-sip-traceroute

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-straw-sip-traceroute-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From victor.pascual.avila@gmail.com  Mon Jul 15 10:26:10 2013
Return-Path: <victor.pascual.avila@gmail.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC4311E8198 for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 10:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-xJR1SSrdaM for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 10:26:09 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id DE8D911E81B4 for <straw@ietf.org>; Mon, 15 Jul 2013 10:26:08 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id fs12so9711841lab.12 for <straw@ietf.org>; Mon, 15 Jul 2013 10:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dCA0jXbt4s0Cpi32rP9gZwcU5XfY9h+8IVM5dDrYvgM=; b=Q6qWGNUPOoxwrLPR2eDse52BWwubYG5MheXfMKjuRSoHQYJEySkQIW5W1+ISpY9Ezh L8WjUeNXgnMfQePRPTXX3O2hXVPas8ZUJyPeGG7Qofwm8O2MXHaY2YXNmfaQucT6e/yl YxDFE4E4cDyFytLyRlbTBblLvYxaH+LZgjKgHDhlqmoZIwgY88caQgm7JrQX6ILFRFeI PtqX32HS6aXPfZ6O4RG4w3Pxm9nxrEdbvIVypJw4Z54rIjnMkSIfKToE7MW3s8VeOT4r W/mi8ZRPHtox9X18S9iO+pbIeiCOi5u6jxtAAWx4yJmQGZ2xTzvz3XcMD6JdNybUobnA fAdg==
MIME-Version: 1.0
X-Received: by 10.152.88.42 with SMTP id bd10mr25311858lab.32.1373909167777; Mon, 15 Jul 2013 10:26:07 -0700 (PDT)
Received: by 10.114.180.102 with HTTP; Mon, 15 Jul 2013 10:26:07 -0700 (PDT)
In-Reply-To: <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com>
Date: Mon, 15 Jul 2013 19:26:07 +0200
Message-ID: <CAGTXFp8TNVO2=5PkYvw1OU8oe_ksDCnn+kmOn3MRnu=hCcmPaQ@mail.gmail.com>
From: Victor Pascual Avila <victor.pascual.avila@gmail.com>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "straw@ietf.org" <straw@ietf.org>
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 17:26:10 -0000

Please note the WG document is draft-ietf-straw-sip-traceroute-00[1]

[1] http://tools.ietf.org/html/draft-ietf-straw-sip-traceroute-00

On Mon, Jul 15, 2013 at 5:13 AM, Hadriel Kaplan
<hadriel.kaplan@oracle.com> wrote:
>
> FYI - the traceroute draft has now been submitted as a WG draft.
>
> I've added the part for handling how to know when you've reached the fina=
l UAS.  It wasn't quite clear from emails, but I think there was rough cons=
ensus for putting something in the SDP answer.  So I've taken the initiativ=
e and chosen what that would be: a pre-defined sess-id value in the origin =
line.  That will probably cause someone heartburn, but the IETF doesn't cha=
rge us money to upload new versions of drafts, so I can change it to whatev=
er we get consensus for.
>
> -hadriel
>
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-straw-sip-traceroute-00.txt
>> Date: July 14, 2013 10:59:57 PM EDT
>> To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
>>
>>
>> A new version of I-D, draft-straw-sip-traceroute-00.txt
>> has been successfully submitted by Hadriel Kaplan and posted to the
>> IETF repository.
>>
>> Filename:      draft-straw-sip-traceroute
>> Revision:      00
>> Title:                 A Media-based Traceroute Function for the Session=
 Initiation Protocol (SIP)
>> Creation date:         2013-07-14
>> Group:                 Individual Submission
>> Number of pages: 6
>> URL:             http://www.ietf.org/internet-drafts/draft-straw-sip-tra=
ceroute-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-straw-sip-tracero=
ute
>> Htmlized:        http://tools.ietf.org/html/draft-straw-sip-traceroute-0=
0
>>
>>
>> Abstract:
>>   SIP already provides the ability to perform hop-by-hop traceroute
>>   for SIP messages using the Max-Forwards header field, in order to
>>   determine the reachability path of requests to a target.  A
>>   mechanism for media-loopback calls has also been defined separately,
>>   which enables test calls to be generated which result in media being
>>   looped back to the originator.  This document describes a means of
>>   performing hop-by-hop traceroute-style test calls using the media-
>>   loopback mechanism, in order to test the media path when SIP
>>   sessions go through media-relaying B2BUAs.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> straw mailing list
> straw@ietf.org
> https://www.ietf.org/mailman/listinfo/straw



--
Victor Pascual =C3=81vila

From pkyzivat@alum.mit.edu  Mon Jul 15 10:52:44 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A2821F9590 for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 10:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.186
X-Spam-Level: 
X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[AWL=0.251,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA5UckLwTzOB for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 10:52:39 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 0476511E819F for <straw@ietf.org>; Mon, 15 Jul 2013 10:52:30 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id 0bnV1m0031ei1Bg58hsWkG; Mon, 15 Jul 2013 17:52:30 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 0hsW1m0013ZTu2S3khsW89; Mon, 15 Jul 2013 17:52:30 +0000
Message-ID: <51E436DD.7020208@alum.mit.edu>
Date: Mon, 15 Jul 2013 13:52:29 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: straw@ietf.org
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com>
In-Reply-To: <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373910750; bh=aGSRa9iLC4O1AVsHDMOXehChrqxTYa+it+m1MEhfoTU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ncqICutoU4riitmANr5UAHOjMgqEfMN7jaXy4QxlhPri0KevF+Nc/AvTdsXsKK5oq KgRTOoDvPtmHgq5M/AiESjN+3Cfznz+WST0aoygtGDYEQLTj6nmgRUIelFcl0DGSS7 WItibJ5dLyf7+rLxKyX9wXBqLJ4QfYbAjD9RRBsdQKKSCOgBqGdgP97k59HnKb8ZEx n8Cnzpw0ni6fx5NZ5Fa/P3nTz8j7ZCYi0Nt9Gb0adjnKXqCYJrxCOV28624CVrpbsD mJntYkA9dBZMQ2wSK6pfRzE/aNAZ0OxwWHVXdpDBFITrvsjWjGVZOsZzOn2wB6phIK UOVD717EzTakw==
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 17:52:44 -0000

On 7/14/13 11:13 PM, Hadriel Kaplan wrote:
>
> FYI - the traceroute draft has now been submitted as a WG draft.
>
> I've added the part for handling how to know when you've reached the final UAS.  It wasn't quite clear from emails, but I think there was rough consensus for putting something in the SDP answer.  So I've taken the initiative and chosen what that would be: a pre-defined sess-id value in the origin line.  That will probably cause someone heartburn, but the IETF doesn't charge us money to upload new versions of drafts, so I can change it to whatever we get consensus for.

Yeah, I'm not too fond of the pre-defined sess-id.
(I have a problem with carving out restricted values from any namespace 
that has been previously defined to be unconstrained. And in any case, 
what doe Pi have to do with traceroute?)

I would be more comfortable with something more explicit.
It isn't evident to me that this needs to be in SDP either. It could 
easily be in SIP, since this is really about indicating that the 
response is from exhaustion of the Max-Forwards rather than from 
reaching the intended destination. E.g. a Reason header might work, or 
some new header. Or this might justify defining a new 2xx response code.

Actually,a new 2xx code sounds quite attractive to me. E.g., 205 Too 
Many Hops.

	Thanks,
	Paul

> -hadriel
>
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-straw-sip-traceroute-00.txt
>> Date: July 14, 2013 10:59:57 PM EDT
>> To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
>>
>>
>> A new version of I-D, draft-straw-sip-traceroute-00.txt
>> has been successfully submitted by Hadriel Kaplan and posted to the
>> IETF repository.
>>
>> Filename:	 draft-straw-sip-traceroute
>> Revision:	 00
>> Title:		 A Media-based Traceroute Function for the Session Initiation Protocol (SIP)
>> Creation date:	 2013-07-14
>> Group:		 Individual Submission
>> Number of pages: 6
>> URL:             http://www.ietf.org/internet-drafts/draft-straw-sip-traceroute-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-straw-sip-traceroute
>> Htmlized:        http://tools.ietf.org/html/draft-straw-sip-traceroute-00
>>
>>
>> Abstract:
>>    SIP already provides the ability to perform hop-by-hop traceroute
>>    for SIP messages using the Max-Forwards header field, in order to
>>    determine the reachability path of requests to a target.  A
>>    mechanism for media-loopback calls has also been defined separately,
>>    which enables test calls to be generated which result in media being
>>    looped back to the originator.  This document describes a means of
>>    performing hop-by-hop traceroute-style test calls using the media-
>>    loopback mechanism, in order to test the media path when SIP
>>    sessions go through media-relaying B2BUAs.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> straw mailing list
> straw@ietf.org
> https://www.ietf.org/mailman/listinfo/straw
>


From hadriel.kaplan@oracle.com  Mon Jul 15 11:29:37 2013
Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4328E11E8105 for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 11:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.161
X-Spam-Level: 
X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiH5irg+BozJ for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 11:29:29 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5041711E81C7 for <straw@ietf.org>; Mon, 15 Jul 2013 11:29:24 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6FITL85021397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 18:29:22 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6FITKBV028572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 18:29:21 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6FITKk8014554; Mon, 15 Jul 2013 18:29:20 GMT
Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 11:29:20 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <51E436DD.7020208@alum.mit.edu>
Date: Mon, 15 Jul 2013 14:29:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: straw@ietf.org
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 18:29:37 -0000

On Jul 15, 2013, at 1:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Yeah, I'm not too fond of the pre-defined sess-id.
> (I have a problem with carving out restricted values from any =
namespace that has been previously defined to be unconstrained. And in =
any case, what doe Pi have to do with traceroute?)

It brings it back full circle?
It's as easy as pi?
It's as wholesome as motherhood and apple pi?


> I would be more comfortable with something more explicit.
> It isn't evident to me that this needs to be in SDP either. It could =
easily be in SIP, since this is really about indicating that the =
response is from exhaustion of the Max-Forwards rather than from =
reaching the intended destination. E.g. a Reason header might work, or =
some new header. Or this might justify defining a new 2xx response code.
>=20
> Actually,a new 2xx code sounds quite attractive to me. E.g., 205 Too =
Many Hops.

The rationale for putting it in SDP, which I thought you had agreed with =
previously, was that using a new header/param/code would be less likely =
to survive its way back to the UAC - middleboxes would remove/change =
stuff.  Whereas with SDP, if the media-loopback SDP got through =
middleboxes to the device answering this thing, then the odds are good =
that something in the SDP answer would make it back as well.  Although =
now that I think about it, sess-id isn't a good one to pick because of =
the middlebox problem.  So something else in SDP then.

-hadriel


From pkyzivat@alum.mit.edu  Mon Jul 15 14:46:07 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FA621E80FD for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 14:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[AWL=-0.062,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_81=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrGF8jdAH5JF for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 14:46:02 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90821E80BD for <straw@ietf.org>; Mon, 15 Jul 2013 14:46:00 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id 0i5P1m0011vXlb85Alm0f8; Mon, 15 Jul 2013 21:46:00 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 0lm01m00L3ZTu2S3dlm09G; Mon, 15 Jul 2013 21:46:00 +0000
Message-ID: <51E46D97.5040802@alum.mit.edu>
Date: Mon, 15 Jul 2013 17:45:59 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com>
In-Reply-To: <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373924760; bh=JpJ9w0EkopmkIOpZeVkOQdB7FY9B630Gv6qE8eVscxs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dOgoNPQDc3KQnKFA7WR7pYfp9SyEurVFv2PZdspIT83DajpSRbUvHSZl5gUR15ySu ahVZP9iB+SekJC3awVPO6Akqdokpib3ZcX98fSlaQA9F7y+ytjnkfCEqA4zAxqxKSx f5IBGniu550f1Nmp1yJR6WwdlbnjU1NH8/bJ0pjUW7k2XlMXpf5ZgMNkQAlZ8Q+0rB 9NIXz9sRHdSsdJ1lRBBXeNezMykT9mOEfl9rKNzndQNNPe6eoO2FVpn+COSZ+pi6rA F0bhxwyLPaJGPFEUXkf2tj7R+6GMzt+X4+SzPUBFjjJNbEyP+vBf/8A7phXBKpgsPf 1hrRp9GAHOd2A==
Cc: straw@ietf.org
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 21:46:08 -0000

On 7/15/13 2:29 PM, Hadriel Kaplan wrote:
>
> On Jul 15, 2013, at 1:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
>> Yeah, I'm not too fond of the pre-defined sess-id.
>> (I have a problem with carving out restricted values from any namespace that has been previously defined to be unconstrained. And in any case, what doe Pi have to do with traceroute?)
>
> It brings it back full circle?
> It's as easy as pi?
> It's as wholesome as motherhood and apple pi?
>
>
>> I would be more comfortable with something more explicit.
>> It isn't evident to me that this needs to be in SDP either. It could easily be in SIP, since this is really about indicating that the response is from exhaustion of the Max-Forwards rather than from reaching the intended destination. E.g. a Reason header might work, or some new header. Or this might justify defining a new 2xx response code.
>>
>> Actually,a new 2xx code sounds quite attractive to me. E.g., 205 Too Many Hops.
>
> The rationale for putting it in SDP, which I thought you had agreed with previously, was that using a new header/param/code would be less likely to survive its way back to the UAC - middleboxes would remove/change stuff.  Whereas with SDP, if the media-loopback SDP got through middleboxes to the device answering this thing, then the odds are good that something in the SDP answer would make it back as well.  Although now that I think about it, sess-id isn't a good one to pick because of the middlebox problem.  So something else in SDP then.

OK, I guess we did have some discussion on that.

By that argument it must be something *existing* in SDP that is never 
messed with. That is a high bar.

You have a product that messes with SDP. When you do so, do you mess 
with the version? (It seems like you *ought* to, since you are changing it.)

Do you think that a new return code would cause trouble this way?
I would think that to be fairly innocuous. But there are no guarantees 
when going through a B2BUA.

	Thanks,
	Paul


From hadriel.kaplan@oracle.com  Mon Jul 15 19:12:58 2013
Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCB321E8097 for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 19:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level: 
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzkiBUalUAZc for <straw@ietfa.amsl.com>; Mon, 15 Jul 2013 19:12:51 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D666111E818E for <straw@ietf.org>; Mon, 15 Jul 2013 19:12:51 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6G2Cn7x027124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 02:12:50 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6G2Cmgj007899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 02:12:49 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6G2ClRQ010224; Tue, 16 Jul 2013 02:12:48 GMT
Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Jul 2013 19:12:47 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <51E46D97.5040802@alum.mit.edu>
Date: Mon, 15 Jul 2013 22:12:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: straw@ietf.org
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 02:12:58 -0000

On Jul 15, 2013, at 5:45 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> OK, I guess we did have some discussion on that.
>=20
> By that argument it must be something *existing* in SDP that is never =
messed with. That is a high bar.
>=20
> You have a product that messes with SDP. When you do so, do you mess =
with the version? (It seems like you *ought* to, since you are changing =
it.)

Sometimes yes, sometimes no.  But I'm not too worried about my product - =
it's more the *other* B2BUAs and SBCs I'm worried about.


> Do you think that a new return code would cause trouble this way?
> I would think that to be fairly innocuous. But there are no guarantees =
when going through a B2BUA.

I honestly have no idea.  I don't know what most vendor products would =
do with a previously-unknown response code number coming back.

It feels like the right thing to do from a protocol perspective, but I =
don't know what would happen.

We could also, in the same 205 response, insert a Reason header with =
"SIP;cause=3D483" as the value.  That way even if it's converted to a =
200 OK response, the Reason=20
header might make it back. (ugly hack, but the whole problem is ugly)

-hadriel


From pkyzivat@alum.mit.edu  Tue Jul 16 09:04:55 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11CD21F9A94 for <straw@ietfa.amsl.com>; Tue, 16 Jul 2013 09:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.218
X-Spam-Level: 
X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[AWL=0.219,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lch6HeIFzyP6 for <straw@ietfa.amsl.com>; Tue, 16 Jul 2013 09:04:50 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id F0D7F21F9A7E for <straw@ietf.org>; Tue, 16 Jul 2013 09:04:49 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta05.westchester.pa.mail.comcast.net with comcast id 0ysh1m00B1HzFnQ5544p96; Tue, 16 Jul 2013 16:04:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id 144p1m00F3ZTu2S3a44pAE; Tue, 16 Jul 2013 16:04:49 +0000
Message-ID: <51E56F20.7060707@alum.mit.edu>
Date: Tue, 16 Jul 2013 12:04:48 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com>
In-Reply-To: <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373990689; bh=fK+dT3wQrCXtTsEtS+ulR0YKqDLUImoc76d9UyHU+bQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FG99auDRGyUTy/c2N5awPTR7GB+gTFIxkPb9/YQk0XBjLYChpNsqwWBEPz137chsM XU/TJ1iytssGOWlXdG5Jx4tgfDTlWv7RAwSOcrLW0T5HQegL5ukYbnZGgolG+RTX2n PagW2d9HCngItQ+e5z9NrBsjRY2C5L777mlEmHV7mEk8RMcTaNTwM+GgYX/bp+e6qd MlUtGa2SFMfqYgStbqPWMCIIviibdedVUKffWSwM5ro44tV0EW2f07+a4PsXIn22bX g6WNAfgBIFt4eZCOYvw63v8lWNPoL1yd9/PdDfZY2SfUG2kYKcxsYocLTaWaF2WTrv Ac8n4yCnOJJ+w==
Cc: straw@ietf.org
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 16:04:56 -0000

On 7/15/13 10:12 PM, Hadriel Kaplan wrote:
>
> On Jul 15, 2013, at 5:45 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> OK, I guess we did have some discussion on that.
>>
>> By that argument it must be something *existing* in SDP that is never messed with. That is a high bar.
>>
>> You have a product that messes with SDP. When you do so, do you mess with the version? (It seems like you *ought* to, since you are changing it.)
>
> Sometimes yes, sometimes no.  But I'm not too worried about my product - it's more the *other* B2BUAs and SBCs I'm worried about.

Well, the fact that you say "sometimes yes" already suggests problems.

>> Do you think that a new return code would cause trouble this way?
>> I would think that to be fairly innocuous. But there are no guarantees when going through a B2BUA.
>
> I honestly have no idea.  I don't know what most vendor products would do with a previously-unknown response code number coming back.
>
> It feels like the right thing to do from a protocol perspective, but I don't know what would happen.
>
> We could also, in the same 205 response, insert a Reason header with "SIP;cause=483" as the value.  That way even if it's converted to a 200 OK response, the Reason
> header might make it back. (ugly hack, but the whole problem is ugly)

I like it!

I thought about the Reason header, but couldn't think of a way to use it 
without introducing a new reason namespace. What you suggest does it 
with existing ones. I don't see it as a bad hack.

	Thanks,
	Paul


From brett@broadsoft.com  Fri Jul 19 11:25:43 2013
Return-Path: <brett@broadsoft.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C1F21E80D2 for <straw@ietfa.amsl.com>; Fri, 19 Jul 2013 11:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdetK01U+Uy6 for <straw@ietfa.amsl.com>; Fri, 19 Jul 2013 11:25:37 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id A344621E80D3 for <straw@ietf.org>; Fri, 19 Jul 2013 11:25:37 -0700 (PDT)
Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 19 Jul 2013 11:25:27 -0700
Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 19 Jul 2013 11:25:27 -0700
From: Brett Tate <brett@broadsoft.com>
To: "straw@ietf.org" <straw@ietf.org>
Thread-Topic: [straw] draft-straw-sip-traceroute-00
Thread-Index: AQHOgj5CzJxCUgqu1Ee9cu9/VT5enJlsRGWA
Date: Fri, 19 Jul 2013 18:25:26 +0000
Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu>
In-Reply-To: <51E56F20.7060707@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.98.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 18:25:43 -0000

>>> Do you think that a new return code would cause=20
>>> trouble this way?  I would think that to be fairly=20
>>> innocuous. But there are no guarantees when going=20
>>> through a B2BUA.
>>
>> I honestly have no idea.  I don't know what most=20
>> vendor products would do with a previously-unknown=20
>> response code number coming back.

I know that the 205 with Reason solution will not work with all B2BUAs.  Ho=
wever, I assume that the B2BUA vendors/administrators would adjust as neede=
d.

>> It feels like the right thing to do from a protocol=20
>> perspective, but I don't know what would happen.
>>
>> We could also, in the same 205 response, insert a=20
>> Reason header with "SIP;cause=3D483" as the value. =20
>> That way even if it's converted to a 200 OK response,=20
>> the Reason header might make it back. (ugly hack,=20
>> but the whole problem is ugly)
>=20
> I like it!

As I mentioned within the following link, using the Reason header (or the o=
ther listed options) sounds okay to me.

http://www.ietf.org/mail-archive/web/straw/current/msg00131.html

The new status-code also sounds okay.  I'm not sure if the service needs a =
new status-code; however there are numerous 2xx values still available.  Al=
though potentially not intended, it might set a precedent of sending 2xx wi=
th a Reason header when B2BUA configured to answer a call to play treatment=
 because of other SIP failure responses.

Other than providing two ways to communicate the same thing, do we need bot=
h mechanisms?  For instance, are customers/vendors actually wanting/needing=
 both options?  Should the draft provide even more options so that it can w=
ork with even more middle boxes without requiring code/configuration modifi=
cation?

Thanks,
Brett


From pkyzivat@alum.mit.edu  Fri Jul 19 12:22:53 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A05F11E815B for <straw@ietfa.amsl.com>; Fri, 19 Jul 2013 12:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.251
X-Spam-Level: 
X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-r6-4RaKXNz for <straw@ietfa.amsl.com>; Fri, 19 Jul 2013 12:22:48 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA0511E8158 for <straw@ietf.org>; Fri, 19 Jul 2013 12:22:46 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta10.westchester.pa.mail.comcast.net with comcast id 2KMR1m0031HzFnQ5AKNmzR; Fri, 19 Jul 2013 19:22:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id 2KNm1m0073ZTu2S3aKNmUX; Fri, 19 Jul 2013 19:22:46 +0000
Message-ID: <51E99205.2010502@alum.mit.edu>
Date: Fri, 19 Jul 2013 15:22:45 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: straw@ietf.org
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local>
In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374261766; bh=cGJ3xg1zyqsd5CXOacW4PpTziDOQ9+iuvosOtYRN1qM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=W8fgUL3oMqkhg0GeT/f9No36dTc555/cEvXdgswj7q/E/2VOlMp3s1pwkRAhpkKZZ 7Vfz7x78D2ZATJn6U7meTmrW6ATZhptM4KLPWn7EmRWp6UgxS4KE8/gSj+ZJTDqbUy WHeq58VWMaQS73UN5HWRwrH0cos2pKdJIjqaWHvEoPVPUNJ1vEV90LTGmvDzOKyOqe rW/prVfV73jMJE7+BdkZkpwIu7X5oSlfmG2dDTCvhaacvdvmunG/mW0gXRZXxlAU2k VyJPBhvu0FyMcQeWka1ZAYLftza11Nkml6L5c6K6CzmKA1Ubf0TYnyRfO4QM/cBvOK DRsD8oOtu5xxQ==
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 19:22:53 -0000

On 7/19/13 2:25 PM, Brett Tate wrote:
>>>> Do you think that a new return code would cause
>>>> trouble this way?  I would think that to be fairly
>>>> innocuous. But there are no guarantees when going
>>>> through a B2BUA.
>>>
>>> I honestly have no idea.  I don't know what most
>>> vendor products would do with a previously-unknown
>>> response code number coming back.
>
> I know that the 205 with Reason solution will not work with all B2BUAs.  However, I assume that the B2BUA vendors/administrators would adjust as needed.
>
>>> It feels like the right thing to do from a protocol
>>> perspective, but I don't know what would happen.
>>>
>>> We could also, in the same 205 response, insert a
>>> Reason header with "SIP;cause=483" as the value.
>>> That way even if it's converted to a 200 OK response,
>>> the Reason header might make it back. (ugly hack,
>>> but the whole problem is ugly)
>>
>> I like it!
>
> As I mentioned within the following link, using the Reason header (or the other listed options) sounds okay to me.
>
> http://www.ietf.org/mail-archive/web/straw/current/msg00131.html
>
> The new status-code also sounds okay.  I'm not sure if the service needs a new status-code; however there are numerous 2xx values still available.  Although potentially not intended, it might set a precedent of sending 2xx with a Reason header when B2BUA configured to answer a call to play treatment because of other SIP failure responses.
>
> Other than providing two ways to communicate the same thing, do we need both mechanisms?  For instance, are customers/vendors actually wanting/needing both options?  Should the draft provide even more options so that it can work with even more middle boxes without requiring code/configuration modification?

What are the *two* mechanisms? Do you mean the 205 and the Reason?

My reasoning for the 205 is that while this is indeed a success 
response, it is far from a normal success response - it is distinctly weird.

The Reason provides more nuance as to *why* this odd response is being 
returned.

But I agree that a 200 with a Reason of 483 would be pretty weird for 
any other reason, so might be sufficient here.

	Thanks,
	Paul


From brett@broadsoft.com  Sat Jul 20 07:30:48 2013
Return-Path: <brett@broadsoft.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8F811E8110 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 07:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMdEl2eH9aqL for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 07:30:44 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 317D411E810C for <straw@ietf.org>; Sat, 20 Jul 2013 07:30:44 -0700 (PDT)
Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 20 Jul 2013 07:30:43 -0700
Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Sat, 20 Jul 2013 07:30:43 -0700
From: Brett Tate <brett@broadsoft.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "straw@ietf.org" <straw@ietf.org>
Thread-Topic: [straw] draft-straw-sip-traceroute-00
Thread-Index: AQHOhLVlORMb1PmhKUypZgf4s2pfopltni1w
Date: Sat, 20 Jul 2013 14:30:42 +0000
Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu>
In-Reply-To: <51E99205.2010502@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.98.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 14:30:48 -0000

> On 7/19/13 2:25 PM, Brett Tate wrote:
> >>>> Do you think that a new return code would cause
> >>>> trouble this way?  I would think that to be fairly
> >>>> innocuous. But there are no guarantees when going
> >>>> through a B2BUA.
> >>>
> >>> I honestly have no idea.  I don't know what most
> >>> vendor products would do with a previously-unknown
> >>> response code number coming back.
> >
> > I know that the 205 with Reason solution will not work with all
> B2BUAs.  However, I assume that the B2BUA vendors/administrators would
> adjust as needed.
> >
> >>> It feels like the right thing to do from a protocol
> >>> perspective, but I don't know what would happen.
> >>>
> >>> We could also, in the same 205 response, insert a
> >>> Reason header with "SIP;cause=3D483" as the value.
> >>> That way even if it's converted to a 200 OK response,
> >>> the Reason header might make it back. (ugly hack,
> >>> but the whole problem is ugly)
> >>
> >> I like it!
> >
> > As I mentioned within the following link, using the Reason header (or
> the other listed options) sounds okay to me.
> >
> > http://www.ietf.org/mail-archive/web/straw/current/msg00131.html
> >
> > The new status-code also sounds okay.  I'm not sure if the service
> needs a new status-code; however there are numerous 2xx values still
> available.  Although potentially not intended, it might set a precedent
> of sending 2xx with a Reason header when B2BUA configured to answer a
> call to play treatment because of other SIP failure responses.
> >
> > Other than providing two ways to communicate the same thing, do we
> need both mechanisms?  For instance, are customers/vendors actually
> wanting/needing both options?  Should the draft provide even more
> options so that it can work with even more middle boxes without
> requiring code/configuration modification?
>=20
> What are the *two* mechanisms? Do you mean the 205 and the Reason?

Yes.  The current proposal is for the middle box to send both 205 and the R=
eason header but allow the UAC to interpret the situation based upon either=
 mechanism since another middle might remove the Reason header or change th=
e 205 into a 200.

Thanks,
Brett

> My reasoning for the 205 is that while this is indeed a success
> response, it is far from a normal success response - it is distinctly
> weird.
>=20
> The Reason provides more nuance as to *why* this odd response is being
> returned.
>=20
> But I agree that a 200 with a Reason of 483 would be pretty weird for
> any other reason, so might be sufficient here.


From hadriel.kaplan@oracle.com  Sat Jul 20 07:43:38 2013
Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D424921F9970 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 07:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.503
X-Spam-Level: 
X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUxR1-LOAKuN for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 07:43:33 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6F52821F9E7C for <straw@ietf.org>; Sat, 20 Jul 2013 07:43:33 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6KEhU3F030881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 14:43:30 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6KEhTvE007223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 14:43:29 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6KEhSjc017122; Sat, 20 Jul 2013 14:43:28 GMT
Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Jul 2013 07:43:28 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local>
Date: Sat, 20 Jul 2013 10:43:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <53AA7A9D-0C5F-4E2A-B554-9767523B06DD@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local>
To: Brett Tate <brett@broadsoft.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "straw@ietf.org" <straw@ietf.org>
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 14:43:39 -0000

On Jul 19, 2013, at 2:25 PM, Brett Tate <brett@broadsoft.com> wrote:

> As I mentioned within the following link, using the Reason header (or =
the other listed options) sounds okay to me.
>=20
> http://www.ietf.org/mail-archive/web/straw/current/msg00131.html

Ahh, sorry missed that - I saw the email and my brain shut off when I =
saw "RFC 5373". :)


> Other than providing two ways to communicate the same thing, do we =
need both mechanisms?  For instance, are customers/vendors actually =
wanting/needing both options?  Should the draft provide even more =
options so that it can work with even more middle boxes without =
requiring code/configuration modification?

I don't know if vendors care either way - do you?  I don't.  I think =
doing two ways is already a bit silly but possibly justifiable for other =
reasons than to get through middleboxes; doing three or more would look =
crazy. :)

-hadriel


From hadriel.kaplan@oracle.com  Sat Jul 20 07:46:34 2013
Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E825A21F9F34 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 07:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.505
X-Spam-Level: 
X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snDG7e6aY8Ph for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 07:46:27 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 52C0E11E810E for <straw@ietf.org>; Sat, 20 Jul 2013 07:46:27 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6KEkMSX032315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 14:46:23 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6KEkLEt019792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 14:46:22 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6KEkLmC019783; Sat, 20 Jul 2013 14:46:21 GMT
Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Jul 2013 07:46:21 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local>
Date: Sat, 20 Jul 2013 10:46:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local>
To: Brett Tate <brett@broadsoft.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: straw@ietf.org
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 14:46:34 -0000

On Jul 20, 2013, at 10:30 AM, Brett Tate <brett@broadsoft.com> wrote:
>=20
> Yes.  The current proposal is for the middle box to send both 205 and =
the Reason header but allow the UAC to interpret the situation based =
upon either mechanism since another middle might remove the Reason =
header or change the 205 into a 200.

Well that's our unofficial reason for doing it - the official rationale =
would be the 205 indicates that some other system/UAC than the intended =
target is answering the request, and the Reason header indicats why it's =
answering the request.

See it sounds so reasonable, doesn't it?  :)

-hadriel


From pkyzivat@alum.mit.edu  Sat Jul 20 10:23:22 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4B21E80B3 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 10:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.254
X-Spam-Level: 
X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.183,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im+aINodQUoG for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 10:23:16 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 4664D21F9991 for <straw@ietf.org>; Sat, 20 Jul 2013 10:23:15 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id 2hG41m00416LCl058hPB8Q; Sat, 20 Jul 2013 17:23:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 2hPB1m00Z3ZTu2S3ShPB09; Sat, 20 Jul 2013 17:23:11 +0000
Message-ID: <51EAC77E.9020507@alum.mit.edu>
Date: Sat, 20 Jul 2013 13:23:10 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: straw@ietf.org
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local> <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com>
In-Reply-To: <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374340991; bh=ZyZoUfv8/15M6vCF6mKnhtkaXHI7zOqAionyt/OP6zc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fyW8E9PuqKOo6LKw8kz7Dh6BakpffORcUn+GIJ30Fu1li6mHwlQWDUrHQ/i/YOsD3 fnzZtUE2uQhvNGPakw8LbrALvODDYxA9oW5DdzYWeWpzIfl4GurS+D6TXqi5a7Qjy+ xl+JQWlGMsPJYfdCqu8mbwxjf0tWb+fat0FBUB0BvQxXOYDToSrJMJhXnyoBxwAHau X1BWMHbyQzuWlvmgxh5y2R96Pr5Kfz8b2YKWAf6G8GhrkLBPxEBvAVZ8XfFzTfHsxL 9MUwyis3R1O57SuVxY9isZx4GxWI3v7jLrIw1Ne2mrzTFdD+LhKvB5lkAkCZvpiRDb 80Jxz+F3TSZaQ==
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 17:23:22 -0000

On 7/20/13 10:46 AM, Hadriel Kaplan wrote:
>
> On Jul 20, 2013, at 10:30 AM, Brett Tate <brett@broadsoft.com> wrote:
>>
>> Yes.  The current proposal is for the middle box to send both 205 and the Reason header but allow the UAC to interpret the situation based upon either mechanism since another middle might remove the Reason header or change the 205 into a 200.
>
> Well that's our unofficial reason for doing it - the official rationale would be the 205 indicates that some other system/UAC than the intended target is answering the request, and the Reason header indicats why it's answering the request.
>
> See it sounds so reasonable, doesn't it?  :)

Sounds reasonable to me.

	Thanks,
	Paul


From brett@broadsoft.com  Sat Jul 20 10:45:41 2013
Return-Path: <brett@broadsoft.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DE111E8117 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 10:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hda753uOlSg7 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 10:45:28 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3A311E80E1 for <straw@ietf.org>; Sat, 20 Jul 2013 10:45:28 -0700 (PDT)
Received: from CASUMHUB04.citservers.local (172.16.98.225) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 20 Jul 2013 10:45:27 -0700
Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Sat, 20 Jul 2013 10:45:27 -0700
From: Brett Tate <brett@broadsoft.com>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>, "straw@ietf.org" <straw@ietf.org>
Thread-Topic: [straw] draft-straw-sip-traceroute-00
Thread-Index: AQHOhVfpB6hLQvT0g0KETZS2mLFq1pltpeuA
Date: Sat, 20 Jul 2013 17:45:26 +0000
Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196BD29D@MBX07.citservers.local>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local> <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com>
In-Reply-To: <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.98.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 17:45:41 -0000

> > Yes.  The current proposal is for the middle box to=20
> > send both 205 and the Reason header but allow the=20
> > UAC to interpret the situation based upon either=20
> > mechanism since another middle might remove the Reason
> > header or change the 205 into a 200.
>=20
> Well that's our unofficial reason for doing it - the=20
> official rationale would be the 205 indicates that some=20
> other system/UAC than the intended target is answering=20
> the request, and the Reason header indicats why it's=20
> answering the request.
>=20
> See it sounds so reasonable, doesn't it?  :)

:)

For the "unofficial reason" to work, wouldn't the 205 also need to indicate=
 (without use of Reason header) why it's answering the request?

Concerning 205, a middle box can be configured to answer and play treatment=
s upon receiving a failure response (or determining a failure situation).  =
Should it start sending the 205 and Reason header to indicate why it answer=
ed the call?

Thanks,
Brett


From pkyzivat@alum.mit.edu  Sat Jul 20 11:01:46 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D0E11E811D for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.256
X-Spam-Level: 
X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U52wvSRpR6UR for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:01:40 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27911E8117 for <straw@ietf.org>; Sat, 20 Jul 2013 11:01:33 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2hZe1m0030SCNGk53i1Wjh; Sat, 20 Jul 2013 18:01:30 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 2i1V1m01G3ZTu2S3Vi1VvP; Sat, 20 Jul 2013 18:01:30 +0000
Message-ID: <51EAD079.5090407@alum.mit.edu>
Date: Sat, 20 Jul 2013 14:01:29 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: straw@ietf.org
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local> <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com> <576A8B541C219D4E9CEB1DF8C19C7B88196BD29D@MBX07.citservers.local>
In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196BD29D@MBX07.citservers.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374343290; bh=PDErF1oO5OMbSu9+co3/FktH5DYSIOvpGkyqAuyQ8OU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jt6Y2yaq5LKyHvlv05f3XHajk+uMLfzE0rIcuiLNX5+tuchRrhKp/vdjgc4H//qAS S1hi3rc1UmiRpBiLm9oowLuwcbmjUPCZgiPbi5oy6RKSAGaiun3EnRRrS5jeuef87J oA1Bg3guG/FMzvk6wS3WNwcVn9vRkLudhrdF/hpDeczeNN/3SpfUGGubW/QB/uBnQs gvJyAt70xjZ2hIPtqRjXnKnJh3nIlQEY0qQzRm4kXvIOdkKCDGPWwa7axs0gxXt7/g wOayvJSGTy6/iEZmqZEsfbQa/G68FH5sDD/BO/G+3YkoqihzZ1ju5Tn1Y6huxY+Bf2 VLcB0LCGv6UNA==
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 18:01:46 -0000

On 7/20/13 1:45 PM, Brett Tate wrote:
>>> Yes.  The current proposal is for the middle box to
>>> send both 205 and the Reason header but allow the
>>> UAC to interpret the situation based upon either
>>> mechanism since another middle might remove the Reason
>>> header or change the 205 into a 200.
>>
>> Well that's our unofficial reason for doing it - the
>> official rationale would be the 205 indicates that some
>> other system/UAC than the intended target is answering
>> the request, and the Reason header indicats why it's
>> answering the request.
>>
>> See it sounds so reasonable, doesn't it?  :)
>
> :)
>
> For the "unofficial reason" to work, wouldn't the 205 also need to indicate (without use of Reason header) why it's answering the request?
>
> Concerning 205, a middle box can be configured to answer and play treatments upon receiving a failure response (or determining a failure situation).  Should it start sending the 205 and Reason header to indicate why it answered the call?

Maybe.

But I think it depends a bit on the identity of the middle box.

If it is authorized to act on behalf of the R-URI of the request, then 
its response should probably get a 200. In other cases this 205 response 
is appropriate.

So for your example, if the middle box is on the callee side you would 
get a 200, but if the middle box is on the caller side then a 205.

But it will probably take some careful wordsmithing to get a clear 
definition for this.

	Thanks,
	Paul


From hadriel.kaplan@oracle.com  Sat Jul 20 11:02:17 2013
Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C142F11E8117 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.506
X-Spam-Level: 
X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54kiDjI9cSf8 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:02:11 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD2111E80E1 for <straw@ietf.org>; Sat, 20 Jul 2013 11:02:11 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6KI27MT030987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Jul 2013 18:02:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6KI26sp013964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jul 2013 18:02:07 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6KI26qk008667; Sat, 20 Jul 2013 18:02:06 GMT
Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Jul 2013 11:02:06 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196BD29D@MBX07.citservers.local>
Date: Sat, 20 Jul 2013 14:02:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EAFF0B6-22B4-445B-B2ED-11DD42330374@oracle.com>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local> <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com> <576A8B541C219D4E9CEB1DF8C19C7B88196BD29D@MBX07.citservers.local>
To: Brett Tate <brett@broadsoft.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "straw@ietf.org" <straw@ietf.org>
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 18:02:17 -0000

On Jul 20, 2013, at 1:45 PM, Brett Tate <brett@broadsoft.com> wrote:

> For the "unofficial reason" to work, wouldn't the 205 also need to =
indicate (without use of Reason header) why it's answering the request?

In what way?  I mean isn't that arguably the purpose/role of a Reason =
header in a success response? (though Reason headers in responses only =
showed up after the Reason header got defined, if I recall, because it =
was for requests originally... I have to find the RFC...)


> Concerning 205, a middle box can be configured to answer and play =
treatments upon receiving a failure response (or determining a failure =
situation).  Should it start sending the 205 and Reason header to =
indicate why it answered the call?

I was thinking that if we move forward with this idea, I'd separate it =
out and submit a new I-D into DISPATCH for a 205 response.  The current =
sip-traceroute draft would normatively reference and say to use this new =
205 draft, for the traceroute use case.  The 205 draft would =
informationally reference the sip-traceroute draft as its motivating =
use-case, but one could imagine 205 could be sent back for cases where a =
middlebox answered a call due to a failure response.

Obviously today they do that already, using 200, and that's fine - but =
they could send back a 205 with a Reason header instead if it would be =
useful to them.  For example if a voicemail picked up it might prefer to =
send back a 205, so that upstream systems could terminate immediately; =
or for example if a media server picked it up to play the "your number =
could not be reached as dialed" type thing, there'd be SIP layer info of =
that.  That might be useful if the originating UAC could try something =
else immediately without user intervention - for example the current =
"international dialing assistance" thing some mobile phones do, where =
they figure out you meant to add your country-code to dialed-numbers =
when you're roaming in another country.

=46rom a practical perspective it would be up the answerer if it wanted =
to use this new response or not, and most probably wouldn't change =
behavior; but one could if it was useful for some reason.

This would create a new dependency for the sip-traceroute draft, and =
delay its publication, but I don't think we're in a big hurry or =
anything.

-hadriel


From christer.holmberg@ericsson.com  Sat Jul 20 11:08:40 2013
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B77521F8445 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.61
X-Spam-Level: 
X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[AWL=0.638,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOc2SozQdE7M for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:08:28 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E706821E80BE for <straw@ietf.org>; Sat, 20 Jul 2013 11:08:27 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f586d000001a55-1f-51ead2185c56
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3F.E4.06741.812DAE15; Sat, 20 Jul 2013 20:08:24 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 20 Jul 2013 20:08:23 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "straw@ietf.org" <straw@ietf.org>
Thread-Topic: draft-straw-sip-traceroute-00: Still one instance of B2bua-Hops
Thread-Index: Ac6FdB5BooZKjhJwSOau5yb3Nocukg==
Date: Sat, 20 Jul 2013 18:08:23 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3E05F9@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3E05F9ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvra7EpVeBBt8361rcan7M6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOntz1gLJkhUvFxxirWBcbdoFyMnh4SAiUTf4e1sELaYxIV7 64FsLg4hgcOMEpsXtrKDJIQEFjNKLGwW7mLk4GATsJDo/qcNEhYRUJWY8OUmI4gtLOAhsXfx b2aIuK/E9MfHWCBsPYnFi5+xgtgsQPUn5twGq+EFqrmx5xBYnBFo7/dTa5hAbGYBcYkPB68z Q9wjILFkz3koW1Ti5eN/rBC2kkTjkiesEPX5Eh8vzWeEmCkocXLmE5YJjEKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRPTcxMye93HATIzDoD275rbuD8dQ5kUOM 0hwsSuK8m/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpgVDhit3L5/nI1yf37Hn6UY+ia v36a2W3724t1N6yP7b6kZsF41vSe672ygNaZsyxflO9e3bzvTnWgySl7PZalhXl/j62eu53n m8yBJUcPHIndLChWu4XDPE2L6TWTkVf4/f8PthzZfOv6ml1XWuyPlc5sv7j+d2vpoqjC/uft z0UVmzeeklQyP6jEUpyRaKjFXFScCAD41mrTSAIAAA==
Subject: [straw] draft-straw-sip-traceroute-00: Still one instance of B2bua-Hops
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 18:08:40 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C3E05F9ESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

(As individual)

Hi,

There is still one instance of "B2bua-Hops" in the draft. Please fix it in =
the next version :)

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C3E05F9ESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.Shkpostityyli17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 70.85pt 2.0cm;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"FI" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">(As individual)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">There is still one instance of =
&#8220;B2bua-Hops&#8221; in the draft. Please fix it in the next version
</span><span lang=3D"EN-US" style=3D"font-family:Wingdings">J</span><span l=
ang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Christer<o:p></o:p></span></p>
</div>
</body>
</html>

--_000_7594FB04B1934943A5C02806D1A2204B1C3E05F9ESESSMB209erics_--

From brett@broadsoft.com  Sat Jul 20 11:27:10 2013
Return-Path: <brett@broadsoft.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7B21E80C1 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NGHOI4c2gE4 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:27:05 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id E40A111E811D for <straw@ietf.org>; Sat, 20 Jul 2013 11:27:05 -0700 (PDT)
Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 20 Jul 2013 11:27:05 -0700
Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Sat, 20 Jul 2013 11:27:05 -0700
From: Brett Tate <brett@broadsoft.com>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>, "straw@ietf.org" <straw@ietf.org>
Thread-Topic: [straw] draft-straw-sip-traceroute-00
Thread-Index: AQHOhXNCiexLMniw9E6cFVoyUfu3CZlt3MHg
Date: Sat, 20 Jul 2013 18:27:04 +0000
Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196BD2C6@MBX07.citservers.local>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local> <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com> <576A8B541C219D4E9CEB1DF8C19C7B88196BD29D@MBX07.citservers.local> <1EAFF0B6-22B4-445B-B2ED-11DD42330374@oracle.com>
In-Reply-To: <1EAFF0B6-22B4-445B-B2ED-11DD42330374@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.98.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 18:27:11 -0000

> > For the "unofficial reason" to work, wouldn't the 205=20
> > also need to indicate (without use of Reason header)=20
> > why it's answering the request?
>=20
> In what way?

You indicated that the "unofficial reason" was reflected by my statement "s=
end both 205 and the Reason header but allow the UAC to interpret the situa=
tion based upon either mechanism since another middle might remove the Reas=
on header or change the 205 into a 200".

If the 205 was received without Reason, how would the UAC know that the rec=
eived 205 (without Reason) was because of draft-straw-sip-traceroute's Max-=
Forwards stuff instead of another use for 205?

Thanks,
Brett


From christer.holmberg@ericsson.com  Sat Jul 20 11:32:44 2013
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982D411E8123 for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.811
X-Spam-Level: 
X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgTdGYKo0X9A for <straw@ietfa.amsl.com>; Sat, 20 Jul 2013 11:32:39 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 06FEB11E811D for <straw@ietf.org>; Sat, 20 Jul 2013 11:32:38 -0700 (PDT)
X-AuditID: c1b4fb38-b7f456d000002e83-9f-51ead7c580fb
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 92.D3.11907.5C7DAE15; Sat, 20 Jul 2013 20:32:37 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 20 Jul 2013 20:32:37 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>, Brett Tate <brett@broadsoft.com>
Thread-Topic: [straw] draft-straw-sip-traceroute-00
Thread-Index: AQHOgQlNyXvuM1IkTkqzZbzD6/fsnJll5IuAgAAKSgCAADbzgIAASooAgADoeACABN5JAIAAEASAgAFAvACAAAReAIAAMgoAgAAEpgCAACcPkA==
Date: Sat, 20 Jul 2013 18:32:36 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3E0622@ESESSMB209.ericsson.se>
References: <20130715025957.14214.78161.idtracker@ietfa.amsl.com> <CCF95343-A61C-48B3-AF57-8A05CD466498@oracle.com> <51E436DD.7020208@alum.mit.edu> <57AD32EC-09E1-4A48-8E4A-0805B3219DDD@oracle.com> <51E46D97.5040802@alum.mit.edu> <95591D74-52E9-47C3-97FC-1E52201CDAC2@oracle.com> <51E56F20.7060707@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD0F4@MBX07.citservers.local> <51E99205.2010502@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196BD262@MBX07.citservers.local> <3479332D-6CDC-4E4C-B6D3-C298D8B873D2@oracle.com> <576A8B541C219D4E9CEB1DF8C19C7B88196BD29D@MBX07.citservers.local> <1EAFF0B6-22B4-445B-B2ED-11DD42330374@oracle.com>
In-Reply-To: <1EAFF0B6-22B4-445B-B2ED-11DD42330374@oracle.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre7R668CDZZO1Ldonv+P0eLTpk/M FreaH7M6MHv8uB3osWTJTyaPj09vsQQwR3HZpKTmZJalFunbJXBlfHq8nKXgumzF538T2BoY X4l3MXJySAiYSJxddoARwhaTuHBvPVsXIxeHkMBRRon7n9qZIZzFjBLLvh5i7WLk4GATsJDo /qcN0iAiECTx6XILE4jNLKAqMaW5kxXEFhYwkvi1aic7RI2xxOZLM1kg7DqJf68ngi1jAaq/ 83wCWJxXwFfi6LyZjBC7ZrJKzH/XBFbEKWAnMaHxFNhQRqDrvp9aA7VMXOLDwevMEFcLSCzZ cx7KFpV4+fgfK4StJNG45AkrRL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMXIUpxYn5aYbGWxiBEbOwS2/LXYwXv5rc4hRmoNFSZx3i96ZQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MfTvX/P14cM7VSf8aGYJS+Zuep7Bsm2VjO6VObE61+3dr1ZA/ KkH57r/et814Unc++/2M3tO+jd+zV/XWvatgYK/doJFXwhfYaj5NJ2VdxV2DueG/Lx3WZI5h Tnn0rnTP5hXi3lc+6p/53B/0QGe14NlvTzOd1z5//GzeMQH/JXsTTZ+vuvdhrxJLcUaioRZz UXEiAALgQDFqAgAA
Cc: "straw@ietf.org" <straw@ietf.org>
Subject: Re: [straw] draft-straw-sip-traceroute-00
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/straw>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 18:32:44 -0000

(As co-chair and individual)

Hi,

As co-chair:

Q1: As was discussed in Orlando, we are not chartered to define new SIP hea=
der fields. I would say the same applies for new SIP response codes. And, a=
s Hadriel said below, we would need to go to DISPATCH (or SIPCORE) in order=
 to do such work.


As individual:

Q2: Instead of a new response code, couldn't we simply use e.g. a media fea=
ture tag, indicating "I am a B2BUA, and I have a capability to perform trac=
eroute-style test calls using the media-loopback mechanism"? Media feature =
tags do not require an RFC. We could still use a Reason header field with a=
 483 value.

Q3: I also believe the UAC needs to indicate its capability of performing t=
he test calls. Otherwise a B2BUA could answer the call, and if the UAC does=
 not understand the 205 response/media feature tag/whatever-mechanism-we-wi=
ll-use it may think that it has reached the indicated target.


Regards,

Christer









-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: straw-bounces@ietf.org [mailto:straw-bounces@ietf.org] Puo=
lesta Hadriel Kaplan
L=E4hetetty: 20. hein=E4kuuta 2013 21:02
Vastaanottaja: Brett Tate
Kopio: straw@ietf.org
Aihe: Re: [straw] draft-straw-sip-traceroute-00


On Jul 20, 2013, at 1:45 PM, Brett Tate <brett@broadsoft.com> wrote:

> For the "unofficial reason" to work, wouldn't the 205 also need to indica=
te (without use of Reason header) why it's answering the request?

In what way?  I mean isn't that arguably the purpose/role of a Reason heade=
r in a success response? (though Reason headers in responses only showed up=
 after the Reason header got defined, if I recall, because it was for reque=
sts originally... I have to find the RFC...)


> Concerning 205, a middle box can be configured to answer and play treatme=
nts upon receiving a failure response (or determining a failure situation).=
  Should it start sending the 205 and Reason header to indicate why it answ=
ered the call?

I was thinking that if we move forward with this idea, I'd separate it out =
and submit a new I-D into DISPATCH for a 205 response.  The current sip-tra=
ceroute draft would normatively reference and say to use this new 205 draft=
, for the traceroute use case.  The 205 draft would informationally referen=
ce the sip-traceroute draft as its motivating use-case, but one could imagi=
ne 205 could be sent back for cases where a middlebox answered a call due t=
o a failure response.

Obviously today they do that already, using 200, and that's fine - but they=
 could send back a 205 with a Reason header instead if it would be useful t=
o them.  For example if a voicemail picked up it might prefer to send back =
a 205, so that upstream systems could terminate immediately; or for example=
 if a media server picked it up to play the "your number could not be reach=
ed as dialed" type thing, there'd be SIP layer info of that.  That might be=
 useful if the originating UAC could try something else immediately without=
 user intervention - for example the current "international dialing assista=
nce" thing some mobile phones do, where they figure out you meant to add yo=
ur country-code to dialed-numbers when you're roaming in another country.

>From a practical perspective it would be up the answerer if it wanted to us=
e this new response or not, and most probably wouldn't change behavior; but=
 one could if it was useful for some reason.

This would create a new dependency for the sip-traceroute draft, and delay =
its publication, but I don't think we're in a big hurry or anything.

-hadriel

_______________________________________________
straw mailing list
straw@ietf.org
https://www.ietf.org/mailman/listinfo/straw
