From nobody Mon Mar 3 03:42:54 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF621A000E for ; Mon, 3 Mar 2014 03:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E1TZ0mqcVKs for ; Mon, 3 Mar 2014 03:42:51 -0800 (PST) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 32D991A0055 for ; Mon, 3 Mar 2014 03:42:50 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u57so1207639wes.36 for ; Mon, 03 Mar 2014 03:42:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=71gB1u1H1ILatyYi3t7op2Tuj5z1lyWIe/vHzzmYxKA=; b=X8cpnOsEX9bQ5kcVjQ3zbvY3ENoAX/nvm1MG7a+UqXv/SUTYBRJ8MQl/RX62Td3Eu3 u8LYgF00WRAtuj2KS3AD5se8cD1w1y8Lmk5G0MElojCz/F9QNcOGgy4aVl+GoYMvGRrJ +uX82UvjagWutmCqjJa3Taz0R4lkOTn6eoTftocOPNyxHn1ZMC4cW/HFTwVjCC7iJ7A+ lWx1FP4xTkddRY3u3BC/NxMxQkDGX0WSBPQZS9OVE/2Pj+KTLLuzMrJTcbYY5SvfLAFq opUoRvRD4FduDw2RdL1VieCMJaJJepdIaNKY0cuSJFNlHeN61a8IXPQ/ShE4QJNIWCK3 J2wA== X-Gm-Message-State: ALoCoQm52fjvBe/Ti7OZE2NIGhC2NDD/ieg/hw0fWBOFFxpnCwOYgzQmjtO8jTlHlNqSdk3Xzucx X-Received: by 10.194.206.102 with SMTP id ln6mr16735883wjc.43.1393846967507; Mon, 03 Mar 2014 03:42:47 -0800 (PST) Received: from dhcp-a736.meeting.ietf.org (dhcp-a736.meeting.ietf.org. [31.133.167.54]) by mx.google.com with ESMTPSA id uq2sm33933896wjc.5.2014.03.03.03.42.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 03:42:46 -0800 (PST) From: Yana Stamcheva Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <82EA0401-4B3D-4F8A-9A8E-6A2DF57CD86B@jitsi.org> Date: Mon, 3 Mar 2014 11:42:44 +0000 To: stox@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/stox/qCLCKm8g0lLpo4gOLdUlLrSj4DM Subject: [Stox] Status and agenda update X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:42:53 -0000 Hi all, We're not currently meeting at IETF 89, but here's a quick status and = milestones update.=20 Goals and milestones: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Done: - Feb 12, 2014: draft-ietf-stox-presence in RFC-Editor's Queue = (http://www.rfc-editor.org/queue2.html#draft-ietf-stox-presence) - Feb 26, 2014: draft-ietf-stox-core in RFC-Editor's Queue = (http://www.rfc-editor.org/queue2.html#draft-ietf-stox-core) Future:=20 - March 10, 2014: WG chairs send to ADs shepherd write-ups for documents = draft-ietf-stox-chat and draft-ietf-stox-im - March 14, 2014: Start WGLC on draft-ietf-stox-groupchat - End of April, 2014: Virtual Interim Meeting focused on = draft-ietf-stox-media - This means the document should be updated and = should be addressing the issues raised by Jonathan Lennox and Paul = Kyzivat by mid April. - Beginning of June 2014: Start WGLC on draft-ietf-stox-media - End of June 2014: Submit last document to the IESG Let the chairs know if you have any comments or suggestions on the = agenda. Best regards, Yana= From nobody Tue Mar 4 17:35:35 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BD71A00DD for ; Tue, 4 Mar 2014 17:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7Zv4GCqelGL for ; Tue, 4 Mar 2014 17:35:29 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B62B31A00E8 for ; Tue, 4 Mar 2014 17:35:29 -0800 (PST) Received: from aither.local (unknown [86.176.103.76]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B2395403C4; Tue, 4 Mar 2014 18:35:25 -0700 (MST) Message-ID: <53167F5C.30801@stpeter.im> Date: Wed, 05 Mar 2014 01:35:24 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yana Stamcheva , stox@ietf.org References: <82EA0401-4B3D-4F8A-9A8E-6A2DF57CD86B@jitsi.org> In-Reply-To: <82EA0401-4B3D-4F8A-9A8E-6A2DF57CD86B@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/8IgGirKqzQk7i-M9dNoYFNbNOHs Subject: Re: [Stox] Status and agenda update X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 01:35:32 -0000 That all looks good to me. I'll commit to incorporating feedback as quickly as it comes in (and to working on the -media document with Emil and Saúl in a timely manner, too). Peter On 3/3/14, 11:42 AM, Yana Stamcheva wrote: > Hi all, > > We're not currently meeting at IETF 89, but here's a quick status and milestones update. > > Goals and milestones: > ============================ > Done: > - Feb 12, 2014: draft-ietf-stox-presence in RFC-Editor's Queue (http://www.rfc-editor.org/queue2.html#draft-ietf-stox-presence) > > - Feb 26, 2014: draft-ietf-stox-core in RFC-Editor's Queue (http://www.rfc-editor.org/queue2.html#draft-ietf-stox-core) > > Future: > - March 10, 2014: WG chairs send to ADs shepherd write-ups for documents draft-ietf-stox-chat and draft-ietf-stox-im > > - March 14, 2014: Start WGLC on draft-ietf-stox-groupchat > > - End of April, 2014: Virtual Interim Meeting focused on draft-ietf-stox-media - This means the document should be updated and should be addressing the issues raised by Jonathan Lennox and Paul Kyzivat by mid April. > > - Beginning of June 2014: Start WGLC on draft-ietf-stox-media > > - End of June 2014: Submit last document to the IESG > > Let the chairs know if you have any comments or suggestions on the agenda. > > Best regards, > Yana > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From nobody Tue Mar 11 15:10:17 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D02A1A0852; Tue, 11 Mar 2014 15:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4SwM0zExXGA; Tue, 11 Mar 2014 15:10:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1E11A0800; Tue, 11 Mar 2014 15:10:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140311221008.12510.76696.idtracker@ietfa.amsl.com> Date: Tue, 11 Mar 2014 15:10:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/vlwidAaB2_1BKpjUrOePN75amTs Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-chat-06.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:10:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions Authors : Peter Saint-Andre Salvatore Loreto Filename : draft-ietf-stox-chat-06.txt Pages : 18 Date : 2014-03-11 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-chat-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 11 15:10:37 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37A21A086C; Tue, 11 Mar 2014 15:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlYV0Q8rs1Wb; Tue, 11 Mar 2014 15:10:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B481A0823; Tue, 11 Mar 2014 15:10:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140311221023.21003.22112.idtracker@ietfa.amsl.com> Date: Tue, 11 Mar 2014 15:10:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/HYtiRt_5nuArqnF_SCzrLi4zu4s Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-im-08.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:10:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging Authors : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-im-08.txt Pages : 12 Date : 2014-03-11 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-im-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 16 14:40:32 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3361A031E; Sun, 16 Mar 2014 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxqIp7x-anob; Sun, 16 Mar 2014 14:40:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A79B31A0139; Sun, 16 Mar 2014 14:40:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140316214025.2212.69958.idtracker@ietfa.amsl.com> Date: Sun, 16 Mar 2014 14:40:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/gYrLNzMi5oQsYVVwwptdQXSnyNw Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-03.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:40:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Authors : Peter Saint-Andre Saul Ibarra Salvatore Loreto Filename : draft-ietf-stox-groupchat-03.txt Pages : 35 Date : 2014-03-16 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-groupchat-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 19 20:39:17 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650111A07FF for ; Wed, 19 Mar 2014 20:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFB7rWh9TpR6 for ; Wed, 19 Mar 2014 20:39:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 98F651A0496 for ; Wed, 19 Mar 2014 20:39:11 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22D3E4032A; Wed, 19 Mar 2014 21:39:02 -0600 (MDT) Message-ID: <532A62D5.3060200@stpeter.im> Date: Wed, 19 Mar 2014 21:39:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Kyzivat , stox@ietf.org References: <52CEDF2D.9090607@alum.mit.edu> In-Reply-To: <52CEDF2D.9090607@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/Qce3YB5jynQWojV3ftah38rg5VE Subject: Re: [Stox] STOX Virtual Interim Meeting 2013-12-17 Minutes X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 03:39:14 -0000 Paul, thanks for the feedback and my apologies for the extremely slow reply. On 1/9/14, 10:41 AM, Paul Kyzivat wrote: > As requested, I have taken a look at treatment of Hold in section 6 of > draft-ietf-stox-media-02. > > The draft says: > > The same semantics are also > supported by Jingle through the "senders" element and its "initiator" > and "responder" values. > > [example to follow] > > In addition to these semantics however Jingle also defines a more > concise way for achieving the same, which consists in sending a > "hold" command within a "session-info" action: > > Before I can make any useful comments I need to get educated on some > aspects of xmpp. (I *browsed* XEP 0166, but couldn't quickly figure this > out.) Hopefully somebody can clue me in on the following: > > 1) I see that the "senders" element has values that correspond 1:1 with > SDP sendrecv/sendonly/recvonly/inactive. Are there equivalent > constraints on O/A behavior? Specifically that: > > Offer Permissible Answer > ----- ------------------ > sendrecv sendrecv/sendonly/recvonly/inactive > sendonly recvonly/inactive > recvonly sendonly/inactive > inactive inactive Although those constraints look reasonable, I think the original Jingle authors were not aware of them when defining the protocol. In general, Jingle implementations are simpler than SIP implementations, and might tend to assume senders='both' / a=sendrecv. Also, not all uses of the 'senders' attribute quite follow the offer/answer model - see, for instance, the content-modify action: ### The content-modify action is used to change the direction of an existing content definition through modification of the 'senders' attribute. If the recipient deems the directionality of a content-modify action to be unacceptable, it MAY reply with a contrary content-modify action, terminate the session, or simply refuse to send or accept application data in the new direction. In any case, the recipient MUST NOT send a content-accept action in response to the content-modify. ### > 2) Are the "senders" element values semantically equivalent to the > corresponding SDP attributes in their implications to how the > corresponding RTP stream is used? As far as I understand those implications, yes. > 3)) What are the precise semantics of the "hold" command within a > "session-info" action? Those are defined in XEP-0167 for RTP sessions (not in the core Jingle spec): ### The payload indicates that the principal is temporarily not listening for media from the other party. It is RECOMMENDED for the parties to handle informational messages as follows (where the holdee is the party that receives the hold message and the holder is the party that sends the hold message): * The holdee SHOULD stop sending media. * The holdee MUST keep accepting media (this ensures that the holder can immediately start sending media again when switching back from hold to active, or can send hold music or other media). * The holder MAY continue to send media (e.g. hold music). * The holder MAY silently drop all media that it receives from the holdee. ### - http://xmpp.org/extensions/xep-0167.html#info-hold > Is it formally equivalent to "initiator" on every > media session? Hmm, not quite, because either party can send a hold payload, and the semantics of the hold depend on who is sending it. In any case, as I recall from the discussion in Vancouver, we were trying to formulate a recommended approach based on the behavior of existing Jingle implementations. I think we still need to do a bit of field research to figure out what's most prevalent (e.g., using 'senders' or the informational hold message). Emil, what does Jitsi do? Are you aware of how other implementations behave? Peter From nobody Wed Mar 19 20:45:42 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99241A0823 for ; Wed, 19 Mar 2014 20:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRAURYAsXnLY for ; Wed, 19 Mar 2014 20:45:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B9D0A1A0345 for ; Wed, 19 Mar 2014 20:45:40 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DC7EE4032A; Wed, 19 Mar 2014 21:45:31 -0600 (MDT) Message-ID: <532A645A.3080605@stpeter.im> Date: Wed, 19 Mar 2014 21:45:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jonathan Lennox , "stox@ietf.org" References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> In-Reply-To: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/7XDenhhxGJUOK0DdyiCgTlKJwo0 Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 03:45:42 -0000 Once again, my apologies for the slow reply. On 1/9/14, 10:31 AM, Jonathan Lennox wrote: > I was thinking about the issue that unlike RFC 5245, XEP-176's > definition of ICE doesn't support fallback to a non-ICE mode. Correct. > It occurred to me that SIP has a way of saying "do ICE, or fail the > call": putting a "Require: ice" SIP option tag (from RFC 5768) in the > SIP INVITE. > > Should we recommend this? It clearly has the right semantics, and > will prevent interop failure when a non-ICE SIP endpoint answers a > XEP-176 Jingle call. Theoretically that makes sense. > My concern, though, is whether there are a) endpoints that implement > RFC 5245 but not RFC 5768, or b) non-media-terminating B2BUAs that > will pass ICE parameters through, but will reject calls with Require > headers they don't know. In either of these cases, adding this > Require header would cause a call that would otherwise have worked to > fail. That would be bad. > Any thoughts, especially from folks who know the state of deployed > SIP better than I do? Inquiring minds want to know. :-) Peter From nobody Wed Mar 19 20:50:41 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83761A046C for ; Wed, 19 Mar 2014 20:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPi8OeU5qehk for ; Wed, 19 Mar 2014 20:50:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 35FF01A0350 for ; Wed, 19 Mar 2014 20:50:38 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 59EDF4032A; Wed, 19 Mar 2014 21:50:29 -0600 (MDT) Message-ID: <532A6584.7000105@stpeter.im> Date: Wed, 19 Mar 2014 21:50:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jonathan Lennox , "stox@ietf.org" References: <1CFAA181-4E37-42EF-A5B4-70737C697B9E@vidyo.com> In-Reply-To: <1CFAA181-4E37-42EF-A5B4-70737C697B9E@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/1kUKYs73oruR4fF9VZ43ueehyf8 Subject: Re: [Stox] stox-media: format parameter translation X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 03:50:40 -0000 On 1/9/14, 10:22 AM, Jonathan Lennox wrote: > This is the issue I brought up at the Interim -- I'll try to put it > in writing. > > The point I raised is that the stox-media draft's section on format > parameter translation should try to focus on media types which are > actually used by existing, deployed Jingle clients, since this is > probably a relatively small set. The important question is which > payload formats in use by existing Jingle clients have SDP fmtp > formats that don't follow the normal semicolon-separated parameter > model. > > I of course haven't done a full inventory of such payload formats, > but two that seem reasonably likely and I think should be > particularly called out are: > > audio/telephone-event: RFC 4733: the fmtp contains the value of an > implicit "events" parameter. That one seems relevant. > audio/red: RFC 2198, with its media type registration in RFC 3555: > the fmtp is the payload types of the encompassed formats. The RFC > 3555 definition of the actual media type parameters is weird (in an > attempt to make it self-contained), and I doubt that any Jingle > client that does RED would actually use it that way. So we need to > figure out what any actual Jingle implementations do. > > Does anyone have a reasonably-authoritative list of which RTP payload > formats are supported by existing Jingle clients? I do not, but it's a small enough universe that we can poll the developers. (I expect it's mostly limited to common audio and video payloads - Speex, Opus, etc. - but we'll find out.) > Does anyone know > of any other real-world usage of codecs that have unusual fmtp > encodings? I think audio/telephone-event is a possibility. > Someone on the call mentioned that they thought that > Speex's was weird, but as far as I can tell, it's a normal > semicolon-separated encoding. Agreed. Peter From nobody Thu Mar 20 19:56:46 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7021E1A0883; Thu, 20 Mar 2014 19:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw_nzw4ft6fY; Thu, 20 Mar 2014 19:56:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FF31A087F; Thu, 20 Mar 2014 19:56:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140321025637.18865.91851.idtracker@ietfa.amsl.com> Date: Thu, 20 Mar 2014 19:56:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/4FndFOOfU9QWntFtBlhCiT0uvYc Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-media-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 02:56:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions Authors : Peter Saint-Andre Saul Ibarra Emil Ivov Filename : draft-ietf-stox-media-04.txt Pages : 25 Date : 2014-03-20 Abstract: This document defines a bidirectional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Session Initiation Protocol (SIP) and systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-media/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-media-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-media-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 20 19:58:30 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C3E1A088B for ; Thu, 20 Mar 2014 19:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd1IBwjJY1EW for ; Thu, 20 Mar 2014 19:58:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB21A0889 for ; Thu, 20 Mar 2014 19:58:26 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 854164010C; Thu, 20 Mar 2014 20:58:17 -0600 (MDT) Message-ID: <532BAAC8.9040705@stpeter.im> Date: Thu, 20 Mar 2014 20:58:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: stox@ietf.org References: <20140321025637.18865.91851.idtracker@ietfa.amsl.com> In-Reply-To: <20140321025637.18865.91851.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/IYIFBc62qqkUs12KBDayVmT03Xg Subject: Re: [Stox] I-D Action: draft-ietf-stox-media-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 02:58:28 -0000 A bit of a general cleanup and editorial review... On 3/20/14, 8:56 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. > > Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions > Authors : Peter Saint-Andre > Saul Ibarra > Emil Ivov > Filename : draft-ietf-stox-media-04.txt > Pages : 25 > Date : 2014-03-20 > > Abstract: > This document defines a bidirectional protocol mapping for use by > gateways that enable the exchange of media signalling messages > between systems that implement the Session Initiation Protocol (SIP) > and systems that implement the Jingle extensions to the Extensible > Messaging and Presence Protocol (XMPP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-media/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stox-media-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-media-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From nobody Tue Mar 25 01:44:36 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16CD1A038D for ; Tue, 25 Mar 2014 01:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkzmY4LxMdZ6 for ; Tue, 25 Mar 2014 01:44:33 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 53A771A038C for ; Tue, 25 Mar 2014 01:44:32 -0700 (PDT) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 64D7516DC6C6 for ; Tue, 25 Mar 2014 09:44:30 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1085) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <20140316214025.2212.69958.idtracker@ietfa.amsl.com> Date: Tue, 25 Mar 2014 09:44:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33DC5A1F-0F09-4F68-8803-8F9259D2DF62@ag-projects.com> References: <20140316214025.2212.69958.idtracker@ietfa.amsl.com> To: stox@ietf.org X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stox/fYmrUWnbDhKl7j2Avi54M9qgHu8 Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-03.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 08:44:35 -0000 I checked the diff and all is good for me, thanks Peter! I have no further comments on this document. On Mar 16, 2014, at 10:40 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIP-TO-XMPP Working Group of the = IETF. >=20 > Title : Interworking between the Session Initiation = Protocol (SIP) and the Extensible Messaging and Presence Protocol = (XMPP): Groupchat > Authors : Peter Saint-Andre > Saul Ibarra > Salvatore Loreto > Filename : draft-ietf-stox-groupchat-03.txt > Pages : 35 > Date : 2014-03-16 >=20 > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of instant messages in the context of a multiparty chat > session among users of the Session Initiation Protocol (SIP) and > users of the Extensible Messaging and Presence Protocol (XMPP). > Specifically, this document defines a mapping between the SIP-based > Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat > (MUC) extension. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stox-groupchat-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-groupchat-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=FAl Ibarra Corretg=E9 AG Projects From nobody Tue Mar 25 01:50:45 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205491A0162 for ; Tue, 25 Mar 2014 01:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1vOHhVf_vJh for ; Tue, 25 Mar 2014 01:50:42 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 979CD1A036F for ; Tue, 25 Mar 2014 01:50:42 -0700 (PDT) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 02E1A16DC6C6; Tue, 25 Mar 2014 09:50:40 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <532A62D5.3060200@stpeter.im> Date: Tue, 25 Mar 2014 09:50:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52CEDF2D.9090607@alum.mit.edu> <532A62D5.3060200@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stox/uezpFJGLMM5Aw-KLC1LbnyQYIhk Cc: stox@ietf.org, Paul Kyzivat Subject: Re: [Stox] STOX Virtual Interim Meeting 2013-12-17 Minutes X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 08:50:44 -0000 Hi, On Mar 20, 2014, at 4:39 AM, Peter Saint-Andre wrote: > Paul, thanks for the feedback and my apologies for the extremely slow = reply. >=20 > On 1/9/14, 10:41 AM, Paul Kyzivat wrote: >> As requested, I have taken a look at treatment of Hold in section 6 = of >> draft-ietf-stox-media-02. >>=20 >> The draft says: >>=20 >> The same semantics are also >> supported by Jingle through the "senders" element and its = "initiator" >> and "responder" values. >>=20 >> [example to follow] >>=20 >> In addition to these semantics however Jingle also defines a more >> concise way for achieving the same, which consists in sending a >> "hold" command within a "session-info" action: >>=20 >> Before I can make any useful comments I need to get educated on some >> aspects of xmpp. (I *browsed* XEP 0166, but couldn't quickly figure = this >> out.) Hopefully somebody can clue me in on the following: >>=20 >> 1) I see that the "senders" element has values that correspond 1:1 = with >> SDP sendrecv/sendonly/recvonly/inactive. Are there equivalent >> constraints on O/A behavior? Specifically that: >>=20 >> Offer Permissible Answer >> ----- ------------------ >> sendrecv sendrecv/sendonly/recvonly/inactive >> sendonly recvonly/inactive >> recvonly sendonly/inactive >> inactive inactive >=20 > Although those constraints look reasonable, I think the original = Jingle authors were not aware of them when defining the protocol. In = general, Jingle implementations are simpler than SIP implementations, = and might tend to assume senders=3D'both' / a=3Dsendrecv. Also, not all = uses of the 'senders' attribute quite follow the offer/answer model - = see, for instance, the content-modify action: >=20 Hum. Actually the XEP does mention compatibility with SDP O/A model:=20 "Which parties in the session will be generating content (i.e., the = direction in which a Jingle session is active); the allowable values are = "both", "initiator", "none", and "responder" (where the default is = "both"). Note that the defined values of the 'senders' attribute in = Jingle correspond to the SDP attributes of "sendrecv", "sendonly", = "inactive", and "recvonly" defined in RFC 4566 [30] and used in the = offer-answer model RFC 3264." However that element is *optional* except for content-modify. IIRC we = did discuss about recommended practices, since this didn't seem to be = very used out there. FWIW, when I worked on the SIP-XMPP gateway = functionality for SylkServer I relied solely on session-info with = 'hold'. This does of course limit the possible translation scenarios = (ie, starting a session with a=3Dinactive) though. -- Sa=FAl Ibarra Corretg=E9 AG Projects From nobody Tue Mar 25 01:55:24 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277E01A01FF for ; Tue, 25 Mar 2014 01:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gneyYfbQB8o6 for ; Tue, 25 Mar 2014 01:55:22 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3173E1A015E for ; Tue, 25 Mar 2014 01:55:22 -0700 (PDT) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id A740116DC6C6; Tue, 25 Mar 2014 09:55:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <532A645A.3080605@stpeter.im> Date: Tue, 25 Mar 2014 09:55:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stox/DAGf6YIwfr8PXTY5E8eiC_Lhmlc Cc: Jonathan Lennox , "stox@ietf.org" Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 08:55:23 -0000 On Mar 20, 2014, at 4:45 AM, Peter Saint-Andre wrote: > Once again, my apologies for the slow reply. >=20 > On 1/9/14, 10:31 AM, Jonathan Lennox wrote: >> I was thinking about the issue that unlike RFC 5245, XEP-176's >> definition of ICE doesn't support fallback to a non-ICE mode. >=20 > Correct. >=20 >> It occurred to me that SIP has a way of saying "do ICE, or fail the >> call": putting a "Require: ice" SIP option tag (from RFC 5768) in the >> SIP INVITE. >>=20 >> Should we recommend this? It clearly has the right semantics, and >> will prevent interop failure when a non-ICE SIP endpoint answers a >> XEP-176 Jingle call. >=20 > Theoretically that makes sense. Agreed. Maybe a gateway could do ICE on behalf of the non-ICE capable = endpoint, so can we say this is implementation specific and thus add a = MAY to it? >=20 >> My concern, though, is whether there are a) endpoints that implement >> RFC 5245 but not RFC 5768, or b) non-media-terminating B2BUAs that >> will pass ICE parameters through, but will reject calls with Require >> headers they don't know. In either of these cases, adding this >> Require header would cause a call that would otherwise have worked to >> fail. >=20 > That would be bad. >=20 >> Any thoughts, especially from folks who know the state of deployed >> SIP better than I do? >=20 > Inquiring minds want to know. :-) >=20 FWIW, in Blink we do use the option tag in the Contact header but we = don't add the Requires header, since we can work fine without ICE. Can't = say what SBCs do though... -- Sa=FAl Ibarra Corretg=E9 AG Projects From nobody Tue Mar 25 01:58:47 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7897F1A03A1 for ; Tue, 25 Mar 2014 01:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OibRAi8bBz1N for ; Tue, 25 Mar 2014 01:58:45 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 063B91A0379 for ; Tue, 25 Mar 2014 01:58:44 -0700 (PDT) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5EAFE16DC6C6; Tue, 25 Mar 2014 09:58:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <532A6584.7000105@stpeter.im> Date: Tue, 25 Mar 2014 09:58:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D07DA47-ED22-47F6-A892-0541B83A60F9@ag-projects.com> References: <1CFAA181-4E37-42EF-A5B4-70737C697B9E@vidyo.com> <532A6584.7000105@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stox/GSWNefSbHy3NLaC8lISP3Tq2wBg Cc: Jonathan Lennox , "stox@ietf.org" Subject: Re: [Stox] stox-media: format parameter translation X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 08:58:46 -0000 On Mar 20, 2014, at 4:50 AM, Peter Saint-Andre wrote: > On 1/9/14, 10:22 AM, Jonathan Lennox wrote: >> This is the issue I brought up at the Interim -- I'll try to put it >> in writing. >>=20 >> The point I raised is that the stox-media draft's section on format >> parameter translation should try to focus on media types which are >> actually used by existing, deployed Jingle clients, since this is >> probably a relatively small set. The important question is which >> payload formats in use by existing Jingle clients have SDP fmtp >> formats that don't follow the normal semicolon-separated parameter >> model. >>=20 >> I of course haven't done a full inventory of such payload formats, >> but two that seem reasonably likely and I think should be >> particularly called out are: >>=20 >> audio/telephone-event: RFC 4733: the fmtp contains the value of an >> implicit "events" parameter. >=20 > That one seems relevant. >=20 >> audio/red: RFC 2198, with its media type registration in RFC 3555: >> the fmtp is the payload types of the encompassed formats. The RFC >> 3555 definition of the actual media type parameters is weird (in an >> attempt to make it self-contained), and I doubt that any Jingle >> client that does RED would actually use it that way. So we need to >> figure out what any actual Jingle implementations do. >>=20 >> Does anyone have a reasonably-authoritative list of which RTP payload >> formats are supported by existing Jingle clients? >=20 > I do not, but it's a small enough universe that we can poll the = developers. (I expect it's mostly limited to common audio and video = payloads - Speex, Opus, etc. - but we'll find out.) >=20 >> Does anyone know >> of any other real-world usage of codecs that have unusual fmtp >> encodings? >=20 > I think audio/telephone-event is a possibility. >=20 >> Someone on the call mentioned that they thought that >> Speex's was weird, but as far as I can tell, it's a normal >> semicolon-separated encoding. >=20 > Agreed. >=20 Same goes for H264 format AFAIS. It has many parameters, but in the end = it's just a list of attribute=3Dvalue separated by semicolons. -- Sa=FAl Ibarra Corretg=E9 AG Projects From nobody Tue Mar 25 07:08:28 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5CB1A014B for ; Tue, 25 Mar 2014 07:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyn6lRmaruyc for ; Tue, 25 Mar 2014 07:08:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E78331A0145 for ; Tue, 25 Mar 2014 07:08:24 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2901D4010C; Tue, 25 Mar 2014 08:08:22 -0600 (MDT) Message-ID: <53318DD5.4040408@stpeter.im> Date: Tue, 25 Mar 2014 08:08:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , stox@ietf.org References: <20140316214025.2212.69958.idtracker@ietfa.amsl.com> <33DC5A1F-0F09-4F68-8803-8F9259D2DF62@ag-projects.com> In-Reply-To: <33DC5A1F-0F09-4F68-8803-8F9259D2DF62@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/gDpEfDnU48tO-_WM8ICaNmpzKgE Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-03.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:08:26 -0000 On 3/25/14, 2:44 AM, Saúl Ibarra Corretgé wrote: > I checked the diff and all is good for me, thanks Peter! Thanks for checking. The one thing I still need to do is make the protocol flow diagrams consistent with the other documents in the series. I'll try to do that today or tonight. Peter From nobody Tue Mar 25 07:15:54 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDAA1A0150 for ; Tue, 25 Mar 2014 07:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.869 X-Spam-Level: * X-Spam-Status: No, score=1.869 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BLdE9Nh7F-r for ; Tue, 25 Mar 2014 07:15:52 -0700 (PDT) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id E77391A011B for ; Tue, 25 Mar 2014 07:15:51 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/25/2014 10:15:47 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-126/SG:2 3/25/2014 10:15:39 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.888917 p=-0.984574 Source White X-Signature-Violations: 0-0-0-4740-c X-Note-419: 0 ms. Fail:1 Chk:1342 of 1342 total X-Note: SCH-CT/SI:1-1342/SG:1 3/25/2014 10:15:35 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 108858203; Tue, 25 Mar 2014 10:15:47 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Tue, 25 Mar 2014 09:15:47 -0500 From: Jonathan Lennox To: =?Windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= Thread-Topic: [Stox] Stox-media: Should XEP-176 translations have Require: ice? Thread-Index: AQHPDWCXO0GcUwCdhEOXXqfhFzsiY5rqFr0AgAgyOQCAAFmKAA== Date: Tue, 25 Mar 2014 14:15:46 +0000 Message-ID: References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <73BBF8791FAE0343BF3B5A5B28EB9760@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/wGjpsZQfrjUaEUUNkHMYSvKyZXI Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:15:53 -0000 On Mar 25, 2014, at 4:55 AM, Sa=FAl Ibarra Corretg=E9 wrote: >>=20 >>=20 >>> It occurred to me that SIP has a way of saying "do ICE, or fail the >>> call": putting a "Require: ice" SIP option tag (from RFC 5768) in the >>> SIP INVITE. >>>=20 >>> Should we recommend this? It clearly has the right semantics, and >>> will prevent interop failure when a non-ICE SIP endpoint answers a >>> XEP-176 Jingle call. >>=20 >> Theoretically that makes sense. >=20 > Agreed. Maybe a gateway could do ICE on behalf of the non-ICE capable end= point, so can we say this is implementation specific and thus add a MAY to = it? Right, of course. I was talking about how you=92d want to handle a signali= ng-only gateway. >>> My concern, though, is whether there are a) endpoints that implement >>> RFC 5245 but not RFC 5768, or b) non-media-terminating B2BUAs that >>> will pass ICE parameters through, but will reject calls with Require >>> headers they don't know. In either of these cases, adding this >>> Require header would cause a call that would otherwise have worked to >>> fail. >>=20 >> That would be bad. >>=20 >>> Any thoughts, especially from folks who know the state of deployed >>> SIP better than I do? >>=20 >> Inquiring minds want to know. :-) >>=20 >=20 > FWIW, in Blink we do use the option tag in the Contact header but we don'= t add the Requires header, since we can work fine without ICE. Can't say wh= at SBCs do though=85 When you say =93can work fine without ICE=94, do you mean you support full = RFC 5245 fallback to the use of the m/c line for media? That does indeed s= ound like the case when you should have the Contact tag but not the require= s header. From nobody Tue Mar 25 10:37:50 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8921A01E9 for ; Tue, 25 Mar 2014 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5xuQWdK07KE for ; Tue, 25 Mar 2014 10:37:26 -0700 (PDT) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id 64ADF1A0158 for ; Tue, 25 Mar 2014 10:37:26 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id my13so305059bkb.22 for ; Tue, 25 Mar 2014 10:37:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q5y/TdtBhFNQqKFTQClOK6RUy0acnOm8I93ff0nqk0U=; b=Tdc721mZz6Gbj/FshYc/5xIfNnLcAa5TuPlI74HSaD6m6xtkE5y0oF8hZ6vW1/P/b/ rajmvjSQXYy1GXI24ZXZBKrYfyBveF9hw9PFAMbKkX2J/AvM/wyn8nckW9gCvbgFzP2Z iCHWB6U2MdoB8RCguicGM8uy7hPKCH5npjtrh4Y8bUprL1XA1VwGuhjkAEDOEA6SU7IO O6JY7xhUNcL5W9y0zmkpiMvJje6wXIrDNVeWAiYp9qecL60DmHsfpiFp/20jXalRDPph OMrlnX/PDrW4iruQOwzB6ECJZFQNSfmI4auvKtbtQ9n8ch77OHl322jNkmoptypzplrr TNeA== X-Gm-Message-State: ALoCoQk39JuqvZzGnCbUrMvRB6XAJaysyPUqVQZq13qtgv28lManwdFU1YM+NOm0WOTP7SwsfPMY X-Received: by 10.204.168.206 with SMTP id v14mr5878308bky.26.1395769044481; Tue, 25 Mar 2014 10:37:24 -0700 (PDT) Received: from camionet.u-strasbg.fr (mininet.u-strasbg.fr. [130.79.91.162]) by mx.google.com with ESMTPSA id ci7sm19811279bkc.0.2014.03.25.10.37.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 10:37:22 -0700 (PDT) Message-ID: <5331BED1.3070202@jitsi.org> Date: Tue, 25 Mar 2014 18:37:21 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jonathan Lennox , =?windows-1252?Q?Sa=FAl_Ibarr?= =?windows-1252?Q?a_Corretg=E9?= References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/fVs86oXby3onvMdB2JGDsy_pBnw Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:37:29 -0000 On 25.03.14, 15:15, Jonathan Lennox wrote: > > On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé wrote: >>> >>> >>>> It occurred to me that SIP has a way of saying "do ICE, or fail the >>>> call": putting a "Require: ice" SIP option tag (from RFC 5768) in the >>>> SIP INVITE. >>>> >>>> Should we recommend this? It clearly has the right semantics, and >>>> will prevent interop failure when a non-ICE SIP endpoint answers a >>>> XEP-176 Jingle call. >>> >>> Theoretically that makes sense. >> >> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE capable endpoint, so can we say this is implementation specific and thus add a MAY to it? > > Right, of course. I was talking about how you’d want to handle a signaling-only gateway. There's also "XEP-0177: Jingle Raw UDP Transport Method" which is basically equivalent to ICE-less SIP. That said, I don't mind mandating ICE at all. Emil -- https://jitsi.org From nobody Tue Mar 25 11:04:24 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD941A01DF for ; Tue, 25 Mar 2014 11:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYABzc2rLjvw for ; Tue, 25 Mar 2014 11:04:02 -0700 (PDT) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id D09A31A0157 for ; Tue, 25 Mar 2014 11:04:01 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/25/2014 2:03:57 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-78/SG:2 3/25/2014 2:03:38 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.89194 p=-0.979794 Source White X-Signature-Violations: 0-0-0-4386-c X-Note-419: 15.6005 ms. Fail:1 Chk:1342 of 1342 total X-Note: SCH-CT/SI:1-1342/SG:1 3/25/2014 2:03:42 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 83042374; Tue, 25 Mar 2014 14:03:57 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Tue, 25 Mar 2014 13:03:56 -0500 From: Jonathan Lennox To: Emil Ivov Thread-Topic: [Stox] Stox-media: Should XEP-176 translations have Require: ice? Thread-Index: AQHPDWCXO0GcUwCdhEOXXqfhFzsiY5rqFr0AgAgyOQCAAFmKAIAAOFCAgAAHbIA= Date: Tue, 25 Mar 2014 18:03:55 +0000 Message-ID: References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> <5331BED1.3070202@jitsi.org> In-Reply-To: <5331BED1.3070202@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/ma3tP_mM5ouapKBS5RX5U2qrAAU Cc: "stox@ietf.org" , =?Windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= , Peter Saint-Andre Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 18:04:05 -0000 On Mar 25, 2014, at 1:37 PM, Emil Ivov wrote: > On 25.03.14, 15:15, Jonathan Lennox wrote: >>=20 >> On Mar 25, 2014, at 4:55 AM, Sa=FAl Ibarra Corretg=E9 wrote: >>>>=20 >>>>=20 >>>>> It occurred to me that SIP has a way of saying "do ICE, or fail the >>>>> call": putting a "Require: ice" SIP option tag (from RFC 5768) in the >>>>> SIP INVITE. >>>>>=20 >>>>> Should we recommend this? It clearly has the right semantics, and >>>>> will prevent interop failure when a non-ICE SIP endpoint answers a >>>>> XEP-176 Jingle call. >>>>=20 >>>> Theoretically that makes sense. >>>=20 >>> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE capable e= ndpoint, so can we say this is implementation specific and thus add a MAY t= o it? >>=20 >> Right, of course. I was talking about how you=92d want to handle a sign= aling-only gateway. >=20 > There's also "XEP-0177: Jingle Raw UDP Transport Method" which is basical= ly equivalent to ICE-less SIP. >=20 > That said, I don't mind mandating ICE at all. Right, but there=92s no way for a Jingle client to offer a choice between X= EP-176 and XEP-177, whereas RFC 5245 requires that both ICE and fallback no= n-ICE be supported. RFC 5768 allows a signaling-only XMPP-to-SIP gateway to (mostly) express th= e XMPP semantic that ICE is required, with no fallback supported. However,= using it would mean failures if you hit a device that supports (or passes)= RFC 5245 but not RFC 5768.= From nobody Tue Mar 25 11:12:45 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266A11A01B9 for ; Tue, 25 Mar 2014 11:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ3jqH_AKrAw for ; Tue, 25 Mar 2014 11:12:19 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id A827C1A01F3 for ; Tue, 25 Mar 2014 11:12:15 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so569714wgh.8 for ; Tue, 25 Mar 2014 11:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KzzeKzMat1Dh5w1Or8bPqdOdpt0h5YDXAXCT9i/4Y5I=; b=QkccgLWowmrplkMD5DfXSccuthmIsA5u3vHOJCLmnnKkFPE2SeYGOgdoFFJJKaYL62 adlnyenj7DUqSt98SkkW0cDvrEwatEh3RTRCKLuKOCHbhmyCrtCCCilYSkra9Veau3/l WErSwSKJSNrqlPnEoVZdfBbvbyZ+Clp5bzkRdbvmDZ24J4wywxz4BAfM2umxp+qKRUoE NPpzwiTwHIPQQnIsiKn1XifmNEiJrJoAUhHUkGHXgQHyHxR+6oBNgrZ1+5Lxa8s32m5s mALaJKdQ3x1oz/xI5VfTRDW8p8QvEPLY+D7vTmuxVZk8ExK8WfO+GbFDc72V70q6+aF6 avrA== X-Gm-Message-State: ALoCoQl2tawwVlXBeJhC02udD4XHOWAVL0Z8OhuxeGMxQ2Nl0WLhXgmelvvP3LPs0U6qEL/d2ui2 X-Received: by 10.181.13.15 with SMTP id eu15mr24076533wid.38.1395771133713; Tue, 25 Mar 2014 11:12:13 -0700 (PDT) Received: from camionet.u-strasbg.fr ([2001:660:4701:1001:b0dd:77cc:4e5e:d0b0]) by mx.google.com with ESMTPSA id t6sm52569047wix.4.2014.03.25.11.12.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 11:12:12 -0700 (PDT) Message-ID: <5331C6FA.4070201@jitsi.org> Date: Tue, 25 Mar 2014 19:12:10 +0100 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jonathan Lennox References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> <5331BED1.3070202@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/q-waqlCoDc8SAHDNh7FsVS1eBTo Cc: "stox@ietf.org" , =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= , Peter Saint-Andre Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 18:12:21 -0000 On 25.03.14, 19:03, Jonathan Lennox wrote: > > On Mar 25, 2014, at 1:37 PM, Emil Ivov wrote: > >> On 25.03.14, 15:15, Jonathan Lennox wrote: >>> >>> On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé wrote: >>>>> >>>>> >>>>>> It occurred to me that SIP has a way of saying "do ICE, or fail the >>>>>> call": putting a "Require: ice" SIP option tag (from RFC 5768) in the >>>>>> SIP INVITE. >>>>>> >>>>>> Should we recommend this? It clearly has the right semantics, and >>>>>> will prevent interop failure when a non-ICE SIP endpoint answers a >>>>>> XEP-176 Jingle call. >>>>> >>>>> Theoretically that makes sense. >>>> >>>> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE capable endpoint, so can we say this is implementation specific and thus add a MAY to it? >>> >>> Right, of course. I was talking about how you’d want to handle a signaling-only gateway. >> >> There's also "XEP-0177: Jingle Raw UDP Transport Method" which is basically equivalent to ICE-less SIP. >> >> That said, I don't mind mandating ICE at all. > > Right, but there’s no way for a Jingle client to offer a choice between XEP-176 and XEP-177, whereas RFC 5245 requires that both ICE and fallback non-ICE be supported. > > RFC 5768 allows a signaling-only XMPP-to-SIP gateway to (mostly) express the XMPP semantic that ICE is required, with no fallback supported. However, using it would mean failures if you hit a device that supports (or passes) RFC 5245 but not RFC 5768. Agreed! -- https://jitsi.org From nobody Tue Mar 25 15:12:36 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F281A0236 for ; Tue, 25 Mar 2014 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4Kkfzb0d03Q for ; Tue, 25 Mar 2014 15:12:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7BE1A0221 for ; Tue, 25 Mar 2014 15:12:32 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 351324010C; Tue, 25 Mar 2014 16:12:29 -0600 (MDT) Message-ID: <5331FF4D.8010900@stpeter.im> Date: Tue, 25 Mar 2014 16:12:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jonathan Lennox , Emil Ivov References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> <5331BED1.3070202@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/t7mMNXBq0w8PwnUZdsvcpjJP7gM Cc: "stox@ietf.org" , =?windows-1252?Q?Sa=FAl_Ibarra_C?= =?windows-1252?Q?orretg=E9?= Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 22:12:35 -0000 On 3/25/14, 12:03 PM, Jonathan Lennox wrote: > > On Mar 25, 2014, at 1:37 PM, Emil Ivov wrote: > >> On 25.03.14, 15:15, Jonathan Lennox wrote: >>> >>> On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé >>> wrote: >>>>> >>>>> >>>>>> It occurred to me that SIP has a way of saying "do ICE, or >>>>>> fail the call": putting a "Require: ice" SIP option tag >>>>>> (from RFC 5768) in the SIP INVITE. >>>>>> >>>>>> Should we recommend this? It clearly has the right >>>>>> semantics, and will prevent interop failure when a non-ICE >>>>>> SIP endpoint answers a XEP-176 Jingle call. >>>>> >>>>> Theoretically that makes sense. >>>> >>>> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE >>>> capable endpoint, so can we say this is implementation specific >>>> and thus add a MAY to it? >>> >>> Right, of course. I was talking about how you’d want to handle a >>> signaling-only gateway. >> >> There's also "XEP-0177: Jingle Raw UDP Transport Method" which is >> basically equivalent to ICE-less SIP. >> >> That said, I don't mind mandating ICE at all. > > Right, but there’s no way for a Jingle client to offer a choice > between XEP-176 and XEP-177, whereas RFC 5245 requires that both ICE > and fallback non-ICE be supported. Well, an XMPP initiator would not offer the ice-udp transport method if the responder didn't advertise support via XMPP service discovery (i.e., only advertised support for raw-udp). So, in general, fallback shouldn't really be necessary. However, we have defined a protocol flow for it just in case: http://xmpp.org/extensions/xep-0176.html#fallback Peter From nobody Tue Mar 25 20:03:54 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F221A0296; Tue, 25 Mar 2014 20:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKBhqZeYd1YG; Tue, 25 Mar 2014 20:03:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EBA1A0035; Tue, 25 Mar 2014 20:03:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140326030347.20805.26381.idtracker@ietfa.amsl.com> Date: Tue, 25 Mar 2014 20:03:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/9jGLitzX3lihcq8AqP9cxq_n36U Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 03:03:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Authors : Peter Saint-Andre Saul Ibarra Salvatore Loreto Filename : draft-ietf-stox-groupchat-04.txt Pages : 38 Date : 2014-03-25 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-groupchat-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 25 20:05:00 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221371A0297; Tue, 25 Mar 2014 20:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-TQvPmKgYzY; Tue, 25 Mar 2014 20:04:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 237E81A0035; Tue, 25 Mar 2014 20:04:55 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4B3F44010C; Tue, 25 Mar 2014 21:04:53 -0600 (MDT) Message-ID: <533243D4.10801@stpeter.im> Date: Tue, 25 Mar 2014 21:04:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20140326030347.20805.26381.idtracker@ietfa.amsl.com> In-Reply-To: <20140326030347.20805.26381.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/0wvrQ-UCnKUfGtCv_WNj0uH-2Co Cc: stox@ietf.org Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 03:04:57 -0000 As promised, I've made the protocol flow diagrams consistent with the other STOX documents. Peter On 3/25/14, 9:03 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. > > Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat > Authors : Peter Saint-Andre > Saul Ibarra > Salvatore Loreto > Filename : draft-ietf-stox-groupchat-04.txt > Pages : 38 > Date : 2014-03-25 > > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of instant messages in the context of a multiparty chat > session among users of the Session Initiation Protocol (SIP) and > users of the Extensible Messaging and Presence Protocol (XMPP). > Specifically, this document defines a mapping between the SIP-based > Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat > (MUC) extension. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stox-groupchat-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From nobody Wed Mar 26 04:09:32 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A68A1A0185 for ; Wed, 26 Mar 2014 04:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3_CkGeBlSEh for ; Wed, 26 Mar 2014 04:09:28 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 970D51A0181 for ; Wed, 26 Mar 2014 04:09:28 -0700 (PDT) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E3FA816DC718; Wed, 26 Mar 2014 12:09:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 26 Mar 2014 12:09:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88B0B8A1-4FBC-4596-A5FF-7378DA5458D9@ag-projects.com> References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> To: Jonathan Lennox X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stox/Ju_eblIoJ1ee0bxko8PCjuG30d8 Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 11:09:30 -0000 On Mar 25, 2014, at 3:15 PM, Jonathan Lennox wrote: >=20 > On Mar 25, 2014, at 4:55 AM, Sa=FAl Ibarra Corretg=E9 = wrote: >>>=20 >>>=20 >>>> It occurred to me that SIP has a way of saying "do ICE, or fail the >>>> call": putting a "Require: ice" SIP option tag (from RFC 5768) in = the >>>> SIP INVITE. >>>>=20 >>>> Should we recommend this? It clearly has the right semantics, and >>>> will prevent interop failure when a non-ICE SIP endpoint answers a >>>> XEP-176 Jingle call. >>>=20 >>> Theoretically that makes sense. >>=20 >> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE capable = endpoint, so can we say this is implementation specific and thus add a = MAY to it? >=20 > Right, of course. I was talking about how you=92d want to handle a = signaling-only gateway. Ah, by bad, sorry. As Peter pointed out there is a fallback mechanism, = so if the Jingle endpoint advertised support for raw UDP it should be = possible to fallback. In case it didn't there is nothing that can be = done. >=20 >>>> My concern, though, is whether there are a) endpoints that = implement >>>> RFC 5245 but not RFC 5768, or b) non-media-terminating B2BUAs that >>>> will pass ICE parameters through, but will reject calls with = Require >>>> headers they don't know. In either of these cases, adding this >>>> Require header would cause a call that would otherwise have worked = to >>>> fail. >>>=20 >>> That would be bad. >>>=20 >>>> Any thoughts, especially from folks who know the state of deployed >>>> SIP better than I do? >>>=20 >>> Inquiring minds want to know. :-) >>>=20 >>=20 >> FWIW, in Blink we do use the option tag in the Contact header but we = don't add the Requires header, since we can work fine without ICE. Can't = say what SBCs do though=85 >=20 > When you say =93can work fine without ICE=94, do you mean you support = full RFC 5245 fallback to the use of the m/c line for media? That does = indeed sound like the case when you should have the Contact tag but not = the requires header. >=20 Yep. -- Sa=FAl Ibarra Corretg=E9 AG Projects From nobody Wed Mar 26 08:50:27 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4EC1A02D8 for ; Wed, 26 Mar 2014 08:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctRXTNkcniV4 for ; Wed, 26 Mar 2014 08:50:23 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id B90501A018F for ; Wed, 26 Mar 2014 08:50:22 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/26/2014 11:50:19 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-310/SG:5 3/26/2014 11:50:02 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.938978 p=-0.982565 Source White X-Signature-Violations: 0-0-0-21904-c X-Note-419: 15.6005 ms. Fail:1 Chk:1342 of 1342 total X-Note: SCH-CT/SI:1-1342/SG:1 3/26/2014 11:50:12 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 83345406; Wed, 26 Mar 2014 11:50:18 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 26 Mar 2014 10:50:17 -0500 From: Jonathan Lennox To: Peter Saint-Andre Thread-Topic: [Stox] Stox-media: Should XEP-176 translations have Require: ice? Thread-Index: AQHPDWCXO0GcUwCdhEOXXqfhFzsiY5rqFr0AgAgyOQCAAFmKAIAAOFCAgAAHbICAAEVzgIABJ4sA Date: Wed, 26 Mar 2014 15:50:16 +0000 Message-ID: References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> <5331BED1.3070202@jitsi.org> <5331FF4D.8010900@stpeter.im> In-Reply-To: <5331FF4D.8010900@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_E7E5D3715B964D608C72BF7DCA477465vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/VxLKq6JavE0HSk51CVpIfrkUkKU Cc: "stox@ietf.org" , Emil Ivov , =?Windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:50:25 -0000 --_000_E7E5D3715B964D608C72BF7DCA477465vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 25, 2014, at 6:12 PM, Peter Saint-Andre > wrote: On 3/25/14, 12:03 PM, Jonathan Lennox wrote: On Mar 25, 2014, at 1:37 PM, Emil Ivov > wrote: On 25.03.14, 15:15, Jonathan Lennox wrote: On Mar 25, 2014, at 4:55 AM, Sa=FAl Ibarra Corretg=E9 > wrote: It occurred to me that SIP has a way of saying "do ICE, or fail the call": putting a "Require: ice" SIP option tag (from RFC 5768) in the SIP INVITE. Should we recommend this? It clearly has the right semantics, and will prevent interop failure when a non-ICE SIP endpoint answers a XEP-176 Jingle call. Theoretically that makes sense. Agreed. Maybe a gateway could do ICE on behalf of the non-ICE capable endpoint, so can we say this is implementation specific and thus add a MAY to it? Right, of course. I was talking about how you=92d want to handle a signaling-only gateway. There's also "XEP-0177: Jingle Raw UDP Transport Method" which is basically equivalent to ICE-less SIP. That said, I don't mind mandating ICE at all. Right, but there=92s no way for a Jingle client to offer a choice between XEP-176 and XEP-177, whereas RFC 5245 requires that both ICE and fallback non-ICE be supported. Well, an XMPP initiator would not offer the ice-udp transport method if the= responder didn't advertise support via XMPP service discovery (i.e., only = advertised support for raw-udp). So, in general, fallback shouldn't really = be necessary. However, we have defined a protocol flow for it just in case: http://xmpp.org/extensions/xep-0176.html#fallback The problem with that flow is the statement "Based on capabilities informat= ion, the gateway knows that the SIP endpoint does not support ICE=94. Unfo= rtunately, SIP doesn=92t really have any workable way of providing capabili= ties information, which is why RFC 5245 (and so much of the rest of SIP) is= single-exchange fallback. An alternative flow is possible, where you only send the transport-replace = on the Jingle side if the SIP answer indicates no ICE support, and then sen= d a SIP re-INVITE with the addresses in the transport-accept. It=92ll resu= lt a fairly substantial post-answer delay before the media will get through= , though. Here=92s a sketch: Romeo Gateway Juliet | | | | session-initiate | | | (audio definition) | | |------------------------>| | | ack | | |<------------------------| SIP INVITE (ICE) | | |------------------------>| | transport-replace | 200 OK (Raw UDP) | | (Raw UDP) |<------------------------| |<------------------------| | | ack | | |------------------------>| | | transport-accept | | |------------------------>| | | ack | | |<------------------------| SIP INVITE (Raw UDP) | | |------------------------>| | | 200 OK (Raw UDP) | | session-accept |<------------------------| |<------------------------| | | ack | | |------------------------>| | | MEDIA SESSION | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D>| | | | This flow also relies on the SIP side not changing its local IP address and= port in response to a re-INVITE with a changed address, or the XMPP side n= ot changing its in response to a transport-replace maintaining raw UDP; oth= erwise, the gateway can get into an infinite re-INVITE/transport-replace lo= op. --_000_E7E5D3715B964D608C72BF7DCA477465vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 25, 2014, at 6:12 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

On 3/25/14, 12:03 PM, Jonathan Lennox wrote:

On Mar 25, 2014, at 1:37 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 25.03.14, 15:15, Jonathan Lennox wrote:

On Mar 25, 2014, at 4:55 AM, Sa=FAl Ibarra Corretg=E9
<saul@ag-projects.com> wr= ote:


It occurred to me that SIP has a way of saying &q= uot;do ICE, or
fail the call": putting a "Require: ice" SIP option tag
(from RFC 5768) in the SIP INVITE.

Should we recommend this?  It clearly has the right
semantics, and will prevent interop failure when a non-ICE
SIP endpoint answers a XEP-176 Jingle call.

Theoretically that makes sense.

Agreed. Maybe a gateway could do ICE on behalf of the non-ICE
capable endpoint, so can we say this is implementation specific
and thus add a MAY to it?

Right, of course.  I was talking about how you=92d want to handle a signaling-only gateway.

There's also "XEP-0177: Jingle Raw UDP Transport Method" which is=
basically equivalent to ICE-less SIP.

That said, I don't mind mandating ICE at all.

Right, but there=92s no way for a Jingle client to offer a choice
between XEP-176 and XEP-177, whereas RFC 5245 requires that both ICE
and fallback non-ICE be supported.

Well, an XMPP initiator would not offer the ice-udp transport method if the= responder didn't advertise support via XMPP service discovery (i.e., only = advertised support for raw-udp). So, in general, fallback shouldn't really = be necessary. However, we have defined a protocol flow for it just in case:

http://xmpp.o= rg/extensions/xep-0176.html#fallback

The problem with that flow is the statement "Based on capabilitie= s information, the gateway knows that the SIP endpoint does not support ICE= =94.  Unfortunately, SIP doesn=92t really have any workable way of pro= viding capabilities information, which is why RFC 5245 (and so much of the rest of SIP) is single-exchange fallback.

An alternative flow is possible, where you only send the transport-rep= lace on the Jingle side if the SIP answer indicates no ICE support, and the= n send a SIP re-INVITE with the addresses in the transport-accept.  It= =92ll result a fairly substantial post-answer delay before the media will get through, though.

Here=92s a sketch:

Romeo            =
        Gateway           &nbs=
p;        Juliet
  |       &n=
bsp;                 |    =
;                     |
  |   session-initiate      |     =
                    |
  |   (audio definition)    |       &=
nbsp;                 |
 =
; |------------------------>|             =
            |
  |   ack  =
;                 |     &=
nbsp;                   |
  |<------------------------|   SIP INVITE (ICE)   =
;   |
  |               =
          |------------------------>|
&nb=
sp; |   transport-replace     |   200 OK (Raw UDP) =
;     |
  |   (Raw UDP)       &nbs=
p;     |<------------------------|
  |<---------=
---------------|                 &n=
bsp;       |
  |   ack       =
            |         &nb=
sp;               |
  |------=
------------------>|               &n=
bsp;         |
  |   transport-accept &=
nbsp;    |                =
;         |
  |------------------------>|=
                     &nbs=
p;   |
  |   ack           &n=
bsp;       |              =
;           |
  |<------------------=
------|   SIP INVITE (Raw UDP)  |
  |     &n=
bsp;                   |------=
------------------>|
  |           &=
nbsp;             |   200 OK (Raw UDP)&n=
bsp;     |
  |   session-accept     &nb=
sp;  |<------------------------|
  |<----------------=
--------|                   &n=
bsp;     |
  |   ack         =
          |           &nb=
sp;             |
  |-------------=
----------->|                 &n=
bsp;       |
  |         &nbs=
p;          MEDIA SESSION       &nb=
sp;          |
  |<=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
 =
 |                     &n=
bsp;   |                  =
;       |
This flow also relies on the SIP side not changing its loca= l IP address and port in response to a re-INVITE with a changed address, or= the XMPP side not changing its in response to a transport-replace maintain= ing raw UDP; otherwise, the gateway can get into an infinite re-INVITE/transport-replace loop.
--_000_E7E5D3715B964D608C72BF7DCA477465vidyocom_--