From t.sudhirkumar@gmail.com Wed Feb 2 20:27:30 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CF53A67D3 for ; Wed, 2 Feb 2011 20:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3MJmpR5BebL for ; Wed, 2 Feb 2011 20:27:30 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id EE2A63A67A2 for ; Wed, 2 Feb 2011 20:27:26 -0800 (PST) Received: by gyd12 with SMTP id 12so345435gyd.31 for ; Wed, 02 Feb 2011 20:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Lnsku962RSd8C4Ik1qP3ajW6D3geqKLgWt5+XSC1q0g=; b=bVcKMfi8vblj8AR+pS7iinl9YNC1SzKjq+7VV8+1MBe26TPEhqyvYwI2awCFFCuZKr eHT22zku1Qcs/YfXe4yrEP8MVXp4Kh+gNXpmbEAGdQIYA93yGz5Zd6mr8LEmeSFHPyrk q/gYwIhK6pl/AbkgeNzxAZho0cLGu7iDzviOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SjZcJ9A8FCFIcyOVJPfulMxlpxtstjByn4EDJB693XyHcFcOTHJBzenySp/Y0kU4fS E4ROiKbPZ+OsTpw55f9ku/J7X4gBb6APh2lU64rho9NSsthbsXeRS5vn9tBopP2SAOQD OIAVfioGGIBVWJFbiqB2EoN40K7kWy4XTCbhQ= MIME-Version: 1.0 Received: by 10.90.58.29 with SMTP id g29mr13121875aga.188.1296707447994; Wed, 02 Feb 2011 20:30:47 -0800 (PST) Received: by 10.90.50.11 with HTTP; Wed, 2 Feb 2011 20:30:47 -0800 (PST) Date: Thu, 3 Feb 2011 10:00:47 +0530 Message-ID: From: Sudhir Kumar To: simple Content-Type: multipart/alternative; boundary=0016363105b1d0b9cc049b593a0f Subject: [Simple] Any open source MSRP server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 04:27:30 -0000 --0016363105b1d0b9cc049b593a0f Content-Type: text/plain; charset=ISO-8859-1 Hi All, I am looking for open source SIP Application sever supported with MSRP server. Is there any one?? any responses/pointers are highly appreciated!!! Thanks, Sudhir --0016363105b1d0b9cc049b593a0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

I am looking for open source SIP Application sev= er supported with MSRP server. Is there any one??

= any responses/pointers are highly=A0appreciated!!!

Thanks,
Sudhir
--0016363105b1d0b9cc049b593a0f-- From saghul@gmail.com Thu Feb 3 00:08:12 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCFE3A6897 for ; Thu, 3 Feb 2011 00:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYONnTltt1Sd for ; Thu, 3 Feb 2011 00:08:11 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 54DCA3A688B for ; Thu, 3 Feb 2011 00:08:11 -0800 (PST) Received: by qwi2 with SMTP id 2so787017qwi.31 for ; Thu, 03 Feb 2011 00:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=kedZDJJGTGoQqLieq984q0ZVK/Iqcotwax50A3Q4TVo=; b=OmBEH8nWf9db1ZqutSCrmzXmjCpqZ5SnZ8/ngvf/8xZ5YD1zITO+xDmBmCaf89Wr28 PsqKoGbUxq37wbA73+hIop8GxjI+z1ucPtpCIxXLR82ny1KAvvmneleusAp7QhfxsHib 33KZwwJ7fZFO1marBVU+hWSiEnfwcfcT8mXzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=bAYL5ikdxmiSKTJ28tvRfQIqmXpiBkDGSewiGLA4BeQzBs9+Ch+XoktwrWmCQ6MG1w 3jOoeZWVG98YAnff3nPmEY9DauwM0t7FpCAxUp23Ltnb0+mXEOgT7TVou+IXxMWg4r+2 UunZ8FeWOOAXJLnAQSBhsBeKGkieVDy6KMvUE= Received: by 10.224.19.138 with SMTP id a10mr6510288qab.399.1296720690734; Thu, 03 Feb 2011 00:11:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.8.82 with HTTP; Thu, 3 Feb 2011 00:11:10 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Date: Thu, 3 Feb 2011 09:11:10 +0100 Message-ID: To: Sudhir Kumar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple Subject: Re: [Simple] Any open source MSRP server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 08:08:12 -0000 Hi, On Thu, Feb 3, 2011 at 5:30 AM, Sudhir Kumar wrot= e: > Hi All, > I am looking for open source SIP Application sever supported with MSRP > server. Is there any one?? > any responses/pointers are highly=C2=A0appreciated!!! Not sure if its what you are looking for, but we recently launched SylkServer (http://sylkserver.com), an Open Source SIP Application server written in Python, and the default application for now is a conference server with both audio and MSRP switch features. Regards, --=20 /Sa=C3=BAl http://saghul.net | http://sipdoc.net From Achint.Aggarwal@globallogic.com Mon Feb 14 06:00:36 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B393A6D2F for ; Mon, 14 Feb 2011 06:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoDZASssieaO for ; Mon, 14 Feb 2011 06:00:34 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id 788273A6D45 for ; Mon, 14 Feb 2011 06:00:32 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hb4q5m0171sc for ; Mon, 14 Feb 2011 19:10:08 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.2.1.2841) with ESMTP; Mon, 14 Feb 2011 19:10:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBCC4D.34A302DD" Date: Mon, 14 Feb 2011 19:13:47 +0530 Message-ID: <1B8AC001C412D84987E59160179F9D2801CF23E4@ex3-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Inter- operation between ALG's and MSRP relays Thread-Index: AcvMTTQ15DadWVjCQgGHU29ZrPKbyA== From: "Achint Aggarwal" To: X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201102141340080062309 Subject: [Simple] Inter- operation between ALG's and MSRP relays X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 04:09:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCC4D.34A302DD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 Are the ALG's which support the sess-match draft (draft-ietf-simple-msrp-sessmatch-10) able to interoperate with MSRP relays which are compliant with rfc 4976??? =20 =20 =20 Regards Achint Aggarwal x-2951 =20 ------_=_NextPart_001_01CBCC4D.34A302DD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

Are the ALG’s which support the sess-match draft (draft-ietf-simple-msrp-sessmatch-10) able to = interoperate with MSRP relays which are compliant with rfc = 4976???

 

 

 

Regards

Achint Aggarwal

x-2951

 

------_=_NextPart_001_01CBCC4D.34A302DD-- From saghul@gmail.com Tue Feb 15 00:13:36 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05ACB3A6E57 for ; Tue, 15 Feb 2011 00:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxRJceMhBPWy for ; Tue, 15 Feb 2011 00:13:35 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id BF2AB3A6CD6 for ; Tue, 15 Feb 2011 00:13:34 -0800 (PST) Received: by qwi2 with SMTP id 2so3991862qwi.31 for ; Tue, 15 Feb 2011 00:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=5yxOLiLTnN+t/zpE5/FZG65TYChJFYMcUkwBmIU9zM4=; b=Vy55KWhZDOy0U4g131Q13TG2ZpXXnHy7WL+X/3yZkTT9xQDMaLhC1OnLvSabyzXaY5 L2EoWBvtpgtyUZBb7A2iZH3S5sSpSHRqwtMMFW0OsyMe4gYCZFXXe/aW4VXUXDcONYKM GcGwqoVL+2jNmEqb9Xm2soI8WJV7YY1RVRc/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=scT4yegLlAeD+Nq499nx8xzvkzEIQEt+XirIuY5sOC5KUZa815WbfZTPE2btr2KxWs R7pDRMcVA4a3xP6tJxXp3ZOOqHMOKlQEcg08cHy718RcCf7jL7gyNr8zujvxdUso1V6U 63aaPN5KSw+pQAX7kDfghKuBesQGBN9LWgiB8= Received: by 10.229.235.69 with SMTP id kf5mr3838976qcb.49.1297757639067; Tue, 15 Feb 2011 00:13:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.224.67 with HTTP; Tue, 15 Feb 2011 00:13:37 -0800 (PST) In-Reply-To: <1B8AC001C412D84987E59160179F9D2801CF23E4@ex3-del1.synapse.com> References: <1B8AC001C412D84987E59160179F9D2801CF23E4@ex3-del1.synapse.com> From: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Date: Tue, 15 Feb 2011 08:13:37 +0000 Message-ID: To: Achint Aggarwal Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Inter- operation between ALG's and MSRP relays X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:13:36 -0000 Hi, On Mon, Feb 14, 2011 at 1:43 PM, Achint Aggarwal wrote: > Hi, > > > > Are the ALG=E2=80=99s which support the sess-match draft > (draft-ietf-simple-msrp-sessmatch-10) able to interoperate with MSRP rela= ys > which are compliant with rfc 4976??? > If your ALG is not acting as a MSRP B2BUA and its modifying the path attribute the MSRP session will fail: "The sessmatch extension allows the usage of ALGs that do not implement MSRP B2BUA functionality in MSRP communications, unless TLS with name based authentication is used, and unless MSRP relays are used. In such cases ALGs need to implement MSRP B2BUA functionality, to prevent the MSRP communication from failing." In your case, as relays are being used, your ALG would need to be a MSRP B2= BUA. Regards, --=20 /Sa=C3=BAl http://saghul.net | http://sipdoc.net From ben@nostrum.com Thu Feb 17 12:40:09 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E4A3A6EA5 for ; Thu, 17 Feb 2011 12:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-9UIDDPI5KC for ; Thu, 17 Feb 2011 12:40:08 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 67EA33A6E55 for ; Thu, 17 Feb 2011 12:40:08 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1HKdJHW006670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Feb 2011 14:39:19 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2011 14:39:19 -0600 Message-Id: <9C9A6268-D554-4239-B372-718C78076EC3@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Jonathan Rosenberg Subject: [Simple] WGLC of draft-ietf-simple-simple-06 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 20:40:09 -0000 This is a Working Group Last Call on draft-ietf-simple-simple-06: http://tools.ietf.org/html/draft-ietf-simple-simple-06 Please note that this draft includes descriptions of = draft-ietf-simple-msrp-sessmatch and draft-ietf-simple-chat. These = drafts are still under discussion. The first is in AD review, and the = second is post WGLC. We expect to do a minor update of = draft-ietf-simple-simple to reflect the final disposition of those = drafts prior to publication. But the rest of the draft is ready for = WGLC. Also note that this is hopefully the last WGLC expected in SIMPLE! = (assuming we don't require a followup WGLC on one of the above mentioned = drafts.) The WGLC will conclude on 4 March 2011. Please send your comments, = including NITS and "this is ready to go" type comments, to the authors = and the working group mail list. Thanks! Ben. From Achint.Aggarwal@globallogic.com Thu Feb 17 21:46:27 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0633A6CAB for ; Thu, 17 Feb 2011 21:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2l1TXs+pz6Z for ; Thu, 17 Feb 2011 21:46:22 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id 387A33A6AA9 for ; Thu, 17 Feb 2011 21:46:20 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hbo3860171sk for ; Fri, 18 Feb 2011 11:11:20 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.2.1.2841) with ESMTP; Fri, 18 Feb 2011 11:11:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CBCF2F.3DBFB363"; type="multipart/alternative" Date: Fri, 18 Feb 2011 11:16:49 +0530 Message-ID: <1B8AC001C412D84987E59160179F9D2801E5D8D8@ex3-del1.synapse.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue with SBC/ALG interop with MSRP Relays Thread-Index: AcvPLzyapRu1eswzSvy0t1FFABD91w== From: "Achint Aggarwal" To: X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201102180541190072697 X-Mailman-Approved-At: Thu, 17 Feb 2011 21:52:47 -0800 Subject: [Simple] Issue with SBC/ALG interop with MSRP Relays X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 05:46:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBCF2F.3DBFB363" ------_=_NextPart_002_01CBCF2F.3DBFB363 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I am facing an issue while trying to implement an MSRP solution involving SBC and MSRP Relays. Following is the call scenario: =20 SBC/ALG Interop with MSRP Relays =20 Assumptions: 1. UA2 has authenticated to relay R2. 2. R2 supports the sessmatch draft (draft-ietf-simple-msrp-sessmatch-10) 3. SBC/ALG anchors MSRP media packets but does not intercept/modify them. So MSRP SEND packets will not be modified by SBC/ALG.=20 4. SBC does the topology hiding on both sides during SDP negotiation. 5. MSRP transport protocol is TCP. 6. For brevity not all the sdp parameters are shown. =20 Symbols used: R2 : URI & port of Relay R2 Sr1,Sr2 : Session ID of relay R2 U1,U2 : Uri's & Ports of UA1,UA2 Su1,Su2 : Session ID's of UA1, UA2 =20 M1,M2 : Uri's & ports of SBC/ALG =20 Call flow: =20 =20 UA1 SBC /ALG R2 UA2 =20 =20 (SDP Offer) --m=3Dpath: U1:Su1 =20 =20 =20 (SDP modified offer) =20 =20 m=3Dpath: M2:Su1 =20 =20 (SDP answer) =20 m=3Dpath: R2:Sr2, U2:Su2 =20 =20 (SDP modified answer) =20 m=3Dpath: M1:Sr2 =20 =20 =20 = =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 Session Established =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 =20 SEND To: M1:Sr2 Fr: U1:Su1 =20 (SBC/ALG routes the packet further without modifying it) =20 (Sess matches =20 To: M1:Sr2 due to Sr2 as per draft) =20 =20 Fr: U1:Su1 =20 =20 Issues: =20 1. Confusion over further routing (Even if session is matched how R2 will know where to further route this packet??) 2. Even if R2 routes SEND to UA2 then what will be there in "To-path:" header just before R2 forwards SEND??? =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Need some suggestions and comments. =20 =20 =20 Regards Achint Aggarwal =20 =20 =20 ------_=_NextPart_002_01CBCF2F.3DBFB363 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

I am facing an issue while trying to implement an MSRP solution involving = SBC and MSRP Relays.

Following is the call scenario:

 

        =             &= nbsp;        SBC/ALG Interop with MSRP Relays

 <= /b>

Assumptions:=

1.       = UA2 has authenticated to relay R2.

2.       = R2 supports the sessmatch draft (draft<= /b>-ietf-simple-msrp-sessmatch<= /i>-10)

3.       = SBC/ALG anchors MSRP media packets but does not intercept/modify them. So MSRP = SEND packets will not be modified by SBC/ALG.

4.       = SBC does the topology hiding on both sides during SDP = negotiation.

5.       = MSRP transport protocol is TCP.

6.       = For brevity not all the sdp parameters are shown.

 

Symbols = used:

R2          &nb= sp;           &nbs= p;    = :            =    URI & port of Relay = R2

Sr1,Sr2         &nbs= p;         = :            =    Session ID of relay R2

U1,U2          =           = :            =    Uri’s & Ports of UA1,UA2

Su1,Su2         &nbs= p;       = :            =    Session ID’s of UA1, UA2

 

M1,M2          =         = :            =    Uri’s &  ports of SBC/ALG

 

Call = flow:

 

 

UA1          &n= bsp;           &nb= sp; =             &= nbsp;           &n= bsp;             SBC /ALG       =             &= nbsp;           &n= bsp;           &nb= sp;           = R2           =                    &= nbsp; UA2    

 

      (SDP = Offer)           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;         =      

      ­­m=3Dpath: U1:Su1         =             &= nbsp;           &n= bsp;       =      

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =                  &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    

           = ;            =          =             &= nbsp;           &n= bsp;           &nb= sp;           =             (SDP modified = offer)           &= nbsp;        

           = ;                = ;            =          =             &= nbsp;           &n= bsp;       =             m=3Dpath: M2:Su1

 

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          (SDP answer)

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           =        m=3Dpath: = R2:Sr2, U2:Su2

 

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   

           = ;            =             &= nbsp;            = (SDP modified answer)

   =              =             &= nbsp;           &n= bsp;           &nb= sp;           =       m=3Dpath: M1:Sr2           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            =

 

 

 


=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 Session = Established = =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

 

SEND

     To:  M1:Sr2

      Fr: U1:Su1 =             &= nbsp;        =

           = ;            =             &= nbsp;            = (SBC/ALG routes the packet further without modifying = it)

           = ;            =             &= nbsp;            =                    &= nbsp;           &n= bsp;           &nb= sp;    =             &= nbsp;   =             &= nbsp;           &n= bsp;       =             &= nbsp;    (Sess matches

           = ;            =             &= nbsp;            =                  &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;          =             &= nbsp;        To: M1:Sr2       due to Sr2 as per = draft)     

           = ;            =             &= nbsp;            =             &= nbsp;           &n= bsp;           &nb= sp;           =             &= nbsp;           &n= bsp;            Fr: U1:Su1

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;       Issues:    =

1. Confusion over further = routing (Even if session is matched how R2 will know where to further route this packet??)

2. Even if R2 routes SEND = to UA2 then what will be there in “To-path:” header just before R2 forwards SEND???

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;                &= nbsp;    

           = ;               &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  

 

 

 

 

 

 

 

 

 

 

 

 

 

Need some suggestions and comments.

 

 

 

Regards

Achint = Aggarwal

 

 

 

------_=_NextPart_002_01CBCF2F.3DBFB363-- ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhAgAeAncAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB ABwCgAAAAAAAAAIVjI+py+0Po5y02ouz3rz7D4biSEIFADs= ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhCwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgAI AQcAgAAAAAAAAAJEhI+py+0Po5y02ouzPiHsD4biSJbm1XXnyrbuC09pasz2jef6zvf+DwwKh8Si 8SiMKZfMpnNxe0qn1OpmZs1qt1xVogAAOw== ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhUwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgBQ AQcAgAAAAAAAAAJNhI+py+0Po5y02ouz3ryfEHjiSJbmiaYqCYLrC8fyTNdU2xr4zvf+DwwKh8Si 8YhMKpfMpvN5tEmn1KrVyrtqt9yud4L7isfkMs2VKAAAOw== ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image004.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.gif Content-Location: image004.gif R0lGODlhUwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAwBQ AQcAgAAAAAAAAAJOhB9xy+0Po5y02ouz3rz7D0ZJEpbmiabqyrbgOLryTNf2jU/wzvf+DwwKh8Si 8YhMKpfMpvN5NPBy1Kr1is0iYtqu9wsO6xTisvmMVhUAADs= ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image005.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.gif Content-Location: image005.gif R0lGODlhCwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAI AQcAgAAAAAAAAAJEhB9xy+0Po5y02ouz3rzHlHjiSJbmiaYWCKruC8fyLLH2jef6zvf+DwwKh8Si 8Sg03GjMpvMJrbWi1Kr1Sgpht9zutQAAOw== ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image006.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image006.gif Content-Location: image006.gif R0lGODlhAgAuAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB ACwBgAAAAAAAAAIPjI+py+0Po5y02ouz3rwAADs= ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image007.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image007.gif Content-Location: image007.gif R0lGODlhCwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgAH AQgAgAAAAAAAAAJJhI+py+0Po5y02ouzPmH7D4biSJZXgJrqyrbuO6GyIdf2jef6zvf+DwwKh8Si 8eiDKZfMpnOBe0qn1GrGZs1qt9oZ9wsOuzqJAgA7 ------_=_NextPart_001_01CBCF2F.3DBFB363 Content-Type: image/gif; name="image008.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image008.gif Content-Location: image008.gif R0lGODlhzwAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgDM AAcAgAAAAAAAAAI7hI+py+0Po5y02qtCwLz7D4aipGnjiabqWpWl4cbyTNf2jef6zvf+D2QJh8Qi RWZMKpdDF/MJjXZMiQIAOw== ------_=_NextPart_001_01CBCF2F.3DBFB363-- From ben@nostrum.com Thu Feb 17 22:19:57 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006223A6CD1 for ; Thu, 17 Feb 2011 22:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rqhR1485I9D for ; Thu, 17 Feb 2011 22:19:55 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 689203A6CAB for ; Thu, 17 Feb 2011 22:19:54 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1I6J6VR054851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Feb 2011 00:19:06 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-21--272317106 From: Ben Campbell In-Reply-To: <1B8AC001C412D84987E59160179F9D2801E5D8D8@ex3-del1.synapse.com> Date: Fri, 18 Feb 2011 00:19:06 -0600 Message-Id: <773F9CE5-C64F-4405-814C-09BB37444344@nostrum.com> References: <1B8AC001C412D84987E59160179F9D2801E5D8D8@ex3-del1.synapse.com> To: Achint Aggarwal X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Issue with SBC/ALG interop with MSRP Relays X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 06:19:57 -0000 --Apple-Mail-21--272317106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (As individual) Hi, I think you've found 2 problems: 1) I don't think draft-ietf-simple-msrp-sessmatch contemplated that the = SBC would do topology hiding in the SDP path attribute. That simply = isn't going to work if a relay is involved, since the route past the = relay is lost. 2) The sessmatch draft does not, if I recall correctly, extend RFC = 4976--so I don't expect that relays in general will implement it. I = guess there might be an argument that 4976 inherits the session matching = rules from RFC 4975, which is extended by sessmatch. But I don't think = the authors contemplated that sessmatch would be implemented by relays. = (I'm sure they will correct me if I am mistaken on that point.) In any case, I think you've highlighted why an SBC that modified the SDP = path attribute but does not modify the To-Path in a SEND request is not = interoperable with RFC 4976 relays in the precise case where such = interoperability would be most important. Christer, do you have any thoughts on this? Thanks! Ben. On Feb 17, 2011, at 11:46 PM, Achint Aggarwal wrote: > Hi, > I am facing an issue while trying to implement an MSRP solution = involving SBC and MSRP Relays. > Following is the call scenario [...] --Apple-Mail-21--272317106 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi,

I am facing an issue while trying to implement an MSRP solution involving = SBC and MSRP Relays.

Following= is the call = scenario


[..= .]

= --Apple-Mail-21--272317106-- From Achint.Aggarwal@globallogic.com Thu Feb 17 23:08:55 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F723A68DD for ; Thu, 17 Feb 2011 23:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJP+bEL274mT for ; Thu, 17 Feb 2011 23:08:48 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id EF8FB3A6CDA for ; Thu, 17 Feb 2011 23:08:45 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hboct60171se for ; Fri, 18 Feb 2011 12:33:45 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.2.1.2841) with ESMTP; Fri, 18 Feb 2011 12:33:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CBCF3A.C1DE8B05"; type="multipart/alternative" Date: Fri, 18 Feb 2011 12:39:15 +0530 Message-ID: <1B8AC001C412D84987E59160179F9D2801E5DA0E@ex3-del1.synapse.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Issue with SBC/ALG interop with MSRP Relays Thread-Index: AcvPLzyapRu1eswzSvy0t1FFABD91wAB1OOA From: "Achint Aggarwal" To: X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201102180703450081312 X-Mailman-Approved-At: Fri, 18 Feb 2011 06:23:57 -0800 Subject: Re: [Simple] Issue with SBC/ALG interop with MSRP Relays X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 07:08:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBCF3A.C1DE8B05" ------_=_NextPart_002_01CBCF3A.C1DE8B05 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 I think the figure I posted on the forum got distorted during the posting. So I am redrawing it here: =20 Assumptions: =20 UA2 has authenticated to relay R2 supports sessmatch draft (draft-ietf-simple-msrp-sessmatch-10) SBC/ALG anchors MSRP media packets but does not modify/intercept them. SO they will not modify MSRP SEND packets SBC does the topology hiding o both sides during SDP negotiation MSRP transport protocol is TCP For brevity not all SDP parameters are shown. =20 Symbols used: =20 R2 : URI and port of Relay R2 Sr2 : Session ID of Relay R2 U1,U2 : Uri's and ports of UA1,UA2 =20 Su1,Su2 : Session ID's of UA1,UA2 M1,M2 : Uri's & ports of SBC/ALG =20 Call Flow: =20 =20 UA1 SBC/ALG R2 UA2 (SDP Offer) =20 m=3Dpath:U1,Su1 m=3Dpath:M2,Sr1 (So for UA2, M2 is the offerer) =20 (SDP Answer) m=3Dpath:M1,Sr2 m=3Dpath:R2,Sr2,U2,Su2 =20 (For UA1, M1 is the answerer) =20 =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=3DSession Established=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 =20 SEND (SBC doesn't modify SEND To:M1,Sr2 anything and just To:M1,Sr2 Fr:U1,Su1 sends it R2) Fr:U1,Su1 (Here R2 matches the session using Sr2 as per the sessmatch draft) =20 Issues: 1. Even post session matching, where will R2 route the packet?? 2. If R2 decides to send it to UA2, what will be there in the "To:" header?? =20 Need some suggestions and comments. =20 Regards Achint Aggarwal =20 ________________________________ From: Achint Aggarwal=20 Sent: Friday, February 18, 2011 11:17 AM To: 'simple@ietf.org' Subject: Issue with SBC/ALG interop with MSRP Relays =20 Hi, I am facing an issue while trying to implement an MSRP solution involving SBC and MSRP Relays. Following is the call scenario: =20 SBC/ALG Interop with MSRP Relays =20 Assumptions: 1. UA2 has authenticated to relay R2. 2. R2 supports the sessmatch draft (draft-ietf-simple-msrp-sessmatch-10) 3. SBC/ALG anchors MSRP media packets but does not intercept/modify them. So MSRP SEND packets will not be modified by SBC/ALG.=20 4. SBC does the topology hiding on both sides during SDP negotiation. 5. MSRP transport protocol is TCP. 6. For brevity not all the sdp parameters are shown. =20 Symbols used: R2 : URI & port of Relay R2 Sr1,Sr2 : Session ID of relay R2 U1,U2 : Uri's & Ports of UA1,UA2 Su1,Su2 : Session ID's of UA1, UA2 =20 M1,M2 : Uri's & ports of SBC/ALG =20 Call flow: =20 =20 UA1 SBC /ALG R2 UA2 =20 =20 (SDP Offer) --m=3Dpath: U1:Su1 =20 =20 =20 (SDP modified offer) =20 =20 m=3Dpath: M2:Su1 =20 =20 (SDP answer) =20 m=3Dpath: R2:Sr2, U2:Su2 =20 =20 (SDP modified answer) =20 m=3Dpath: M1:Sr2 =20 =20 =20 = =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 Session Established =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 =20 SEND To: M1:Sr2 Fr: U1:Su1 =20 (SBC/ALG routes the packet further without modifying it) =20 (Sess matches =20 To: M1:Sr2 due to Sr2 as per draft) =20 =20 Fr: U1:Su1 =20 =20 Issues: =20 1. Confusion over further routing (Even if session is matched how R2 will know where to further route this packet??) 2. Even if R2 routes SEND to UA2 then what will be there in "To-path:" header just before R2 forwards SEND??? =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Need some suggestions and comments. =20 =20 =20 Regards Achint Aggarwal =20 =20 =20 ------_=_NextPart_002_01CBCF3A.C1DE8B05 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think the figure I posted on the forum got distorted during the = posting.

So I am redrawing it here:

 

Assumptions= :

 

UA2 has authenticated to relay

R2 supports sessmatch draft = (draft-ietf-simple-msrp-sessmatch-10)

SBC/ALG anchors MSRP media packets but does not modify/intercept them. SO they = will not modify MSRP SEND packets

SBC does the topology hiding o both sides during SDP = negotiation

MSRP transport protocol is TCP

For brevity not all SDP parameters are shown.

 

Symbols = used:

 

R2    =       :     URI and port of Relay = R2

Sr2   =       :     Session ID of Relay R2

U1,U2       = :     Uri’s and ports of UA1,UA2   

Su1,Su2     = :     Session ID’s of UA1,UA2

M1,M2       = :     Uri’s & ports of SBC/ALG

 

Call = Flow:

 <= /b>

 

UA1       &= nbsp;           &n= bsp; = SBC/ALG           =             = R2            = ;    UA2

(SDP Offer)

 

     = = m=3Dpath:U1,Su1         &nbs= p;   m=3Dpath:M2,Sr1         =             &= nbsp;             (So for UA2, M2 is the offerer)

       &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;         (SDP Answer)

     =             &= nbsp;           m=3Dpath:M1,Sr2         &nbs= p;            = ;        =       m=3Dpath:R2,Sr2,U2,Su2    =

(For UA1, M1 is the answerer)

 

=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=3DSession = Established=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

 

     = SEND  =             &= nbsp;     (SBC doesn’t = modify           SEND       

      = To:M1,Sr2          &nbs= p;   =20 anything and just =            = To:M1,Sr2

      = Fr:U1,Su1         =          sends it = R2)           &nbs= p;   Fr:U1,Su1 (Here R2 matches the session using Sr2 as per the sessmatch = draft)

      =

       &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   Issues:

1.    Even post session matching, where will R2 route = the packet??

2.    If R2 decides to send it to UA2, what will be = there in the “To:” header??

 <= /p>

Need some suggestions and comments.

 

Regards

Achint = Aggarwal

 

From: Achint = Aggarwal
Sent: Friday, February = 18, 2011 11:17 AM
To: 'simple@ietf.org'
Subject: Issue with = SBC/ALG interop with MSRP Relays

 

Hi,

I am facing an issue while trying to implement an MSRP solution involving = SBC and MSRP Relays.

Following is the call scenario:

 

        =             &= nbsp;        SBC/ALG Interop with MSRP Relays

 <= /b>

Assumptions:=

1.       = UA2 has authenticated to relay R2.

2.       = R2 supports the sessmatch draft (draft<= /b>-ietf-simple-msrp-sessmatch<= /i>-10)

3.       = SBC/ALG anchors MSRP media packets but does not intercept/modify them. So MSRP = SEND packets will not be modified by SBC/ALG.

4.       = SBC does the topology hiding on both sides during SDP = negotiation.

5.       = MSRP transport protocol is TCP.

6.       = For brevity not all the sdp parameters are shown.

 

Symbols = used:

R2          &nb= sp;           &nbs= p;    :            =    URI & port of Relay = R2

Sr1,Sr2         &nbs= p;         :            =    Session ID of relay R2

U1,U2          =           :            =    Uri’s & Ports of UA1,UA2

Su1,Su2         &nbs= p;       :            =    Session ID’s of UA1, UA2

 

M1,M2          =         :            =    Uri’s &  ports of SBC/ALG

 

Call = flow:

 

 

UA1          &n= bsp;           &nb= sp;             &= nbsp;           &n= bsp;             SBC /ALG                   &= nbsp;           &n= bsp;           &nb= sp;           R2           =                    &= nbsp; UA2    

 

      (SDP Offer)           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;              

      ­­m=3Dpath: U1:Su1                     &= nbsp;           &n= bsp;            

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;                             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    

           = ;            =                      &= nbsp;           &n= bsp;           &nb= sp;                       (SDP modified offer)           &= nbsp;        

           = ;                = ;            =                      &= nbsp;           &n= bsp;                   = m=3Dpath: M2:Su1

 

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          (SDP = answer)

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;                  m=3Dpath: R2:Sr2, U2:Su2

 

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   

           = ;            =             &= nbsp;            (SDP modified answer)

                            &= nbsp;           &n= bsp;           &nb= sp;                 m=3Dpath: M1:Sr2           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           

 

 

 


=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 Session = Established =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

 

SEND

     To:  M1:Sr2

      Fr: U1:Su1             &= nbsp;       

           = ;            =             &= nbsp;            (SBC/ALG routes the packet further without modifying = it)

           = ;            =             &= nbsp;                               &= nbsp;           &n= bsp;           &nb= sp;                &= nbsp;               &= nbsp;           &n= bsp;                   &= nbsp;    (Sess matches

           = ;            =             &= nbsp;                             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;                      &= nbsp;        To: M1:Sr2      =  due to Sr2 as per draft)      =

           = ;            =             &= nbsp;                        &= nbsp;           &n= bsp;           &nb= sp;                       &= nbsp;           &n= bsp;            Fr: U1:Su1

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;           

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;                        &= nbsp;           &n= bsp;       Issues:    =

1. Confusion over further = routing (Even if session is matched how R2 will know where to further route this packet??)

2. Even if R2 routes SEND = to UA2 then what will be there in “To-path:” header just before R2 forwards SEND???

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;                &= nbsp;    

           = ;               &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  

 

 

 

 

 

 

 

 

 

 

 

 

 

Need some suggestions and comments.

 

 

 

Regards

Achint = Aggarwal

 

 

 

------_=_NextPart_002_01CBCF3A.C1DE8B05-- ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhDwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgAL AQgAgAAAAAAAAAJKhI+py+0Po5y02ouzXmH7D4biSJZbgJrqyrbue6GyIdf2jef6zvf+DwwKh8Si 8SiEKZfMpvOBe0qn1OrHZs1qt1xaqgsOi12dRAEAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhXgAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgBa AAgAgAAAAAAAAAIqhI+py+0PU4i02kuDxrz7poXfSFrhWX7nyrbuC8fyvKZObee6qPf2lCgAADs= ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhsAAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAMAAgCs AAgAgAAAAAAAAAI6hB+ny+0Po5y02otB2Ln7D4bitJXjiaaqWLbuC8fyTNf2jef6Tq/+DwwaXMKi 8ZgxIZfMpiLhjEpTBQA7 ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image004.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.gif Content-Location: image004.gif R0lGODlhHAEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAMAAgAY AQgAgAAAAAAAAAJKhB+ny+0Po5y02ouz3ryrAHriSJbmiaYdyKruC8fyvLH2jef6zvf+DwwKh8Si 8YhMAmnMpvMJ1dyi1Kr1Gmtht9yud5L4isfkZgEAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image005.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.gif Content-Location: image005.gif R0lGODlhjAAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgCI AAgAgAAAAAAAAAI1hI+py+0Po5wt0Iuz3tyE34XiSDLf6Z3qyrbuC8fyTNc2WOb67rT8D9StgsRi B2VMKieWRAEAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image006.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image006.gif Content-Location: image006.gif R0lGODlhSQAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgBF AAgAgAAAAAAAAAImhI+py+0bnpy0noCt3hV744XiSJbmiY7cyoJqC1tiTHdZjUtRUgAAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image007.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image007.gif Content-Location: image007.gif R0lGODlhAgAeAncAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB ABwCgAAAAAAAAAIVjI+py+0Po5y02ouz3rz7D4biSEIFADs= ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image008.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image008.gif Content-Location: image008.gif R0lGODlhCwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgAI AQcAgAAAAAAAAAJEhI+py+0Po5y02ouzPiHsD4biSJbm1XXnyrbuC09pasz2jef6zvf+DwwKh8Si 8SiMKZfMpnNxe0qn1OpmZs1qt1xVogAAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image009.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image009.gif Content-Location: image009.gif R0lGODlhUwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgBQ AQcAgAAAAAAAAAJNhI+py+0Po5y02ouz3ryfEHjiSJbmiaYqCYLrC8fyTNdU2xr4zvf+DwwKh8Si 8YhMKpfMpvN5tEmn1KrVyrtqt9yud4L7isfkMs2VKAAAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image010.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image010.gif Content-Location: image010.gif R0lGODlhUwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAwBQ AQcAgAAAAAAAAAJOhB9xy+0Po5y02ouz3rz7D0ZJEpbmiabqyrbgOLryTNf2jU/wzvf+DwwKh8Si 8YhMKpfMpvN5NPBy1Kr1is0iYtqu9wsO6xTisvmMVhUAADs= ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image011.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image011.gif Content-Location: image011.gif R0lGODlhCwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgAI AQcAgAAAAAAAAAJEhB9xy+0Po5y02ouz3rzHlHjiSJbmiaYWCKruC8fyLLH2jef6zvf+DwwKh8Si 8Sg03GjMpvMJrbWi1Kr1Sgpht9zutQAAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image012.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image012.gif Content-Location: image012.gif R0lGODlhAgAuAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB ACwBgAAAAAAAAAIPjI+py+0Po5y02ouz3rwAADs= ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image014.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image014.gif Content-Location: image014.gif R0lGODlhCwEMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgAH AQgAgAAAAAAAAAJJhI+py+0Po5y02ouzPmH7D4biSJZXgJrqyrbuO6GyIdf2jef6zvf+DwwKh8Si 8eiDKZfMpnOBe0qn1GrGZs1qt9oZ9wsOuzqJAgA7 ------_=_NextPart_001_01CBCF3A.C1DE8B05 Content-Type: image/gif; name="image015.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image015.gif Content-Location: image015.gif R0lGODlhzwAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAgDM AAcAgAAAAAAAAAI7hI+py+0Po5y02qtCwLz7D4aipGnjiabqWpWl4cbyTNf2jef6zvf+D2QJh8Qi RWZMKpdDF/MJjXZMiQIAOw== ------_=_NextPart_001_01CBCF3A.C1DE8B05-- From saghul@gmail.com Wed Feb 23 00:32:27 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EB23A6809 for ; Wed, 23 Feb 2011 00:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwE6SlDJwbll for ; Wed, 23 Feb 2011 00:32:26 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 041963A67EE for ; Wed, 23 Feb 2011 00:32:25 -0800 (PST) Received: by qyk7 with SMTP id 7so3431147qyk.10 for ; Wed, 23 Feb 2011 00:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=kxa8wFANfTXLlB5km2+AxO030K+YSEXeCiKaPMfrfAA=; b=mIU4+5m512TkBlkoJaEFgbyeqTKwJQ2qz5VBPDIxYURlrUtlUJnae9NpVfrITEksCh baWCOoV/dojFnNpBlxSevUnafMxEOpvvZAf5VyYcDiGywVYnUPGvN0HTt4+8OhgLGIBZ Q4xRNkho4NIsHTvOT1XLDxx7YcFTTcGBUNChU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=j+lvVwG8DfASvzEQkr6tqai71TLhXES+hD2v5dJAcyE6cBIWBdax70UWhKPzgdkPwR MLSMJHH1OPlF3r70v8pVYGfoCXIq/bV5qjt4xvKt78NuanelTLmkPq2TJXG8Dj+PbrOT mhqHie0TPSfLdfxKyUozINN8S6hFiUTYtxoXk= Received: by 10.229.218.17 with SMTP id ho17mr2910695qcb.87.1298449992184; Wed, 23 Feb 2011 00:33:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.224.67 with HTTP; Wed, 23 Feb 2011 00:32:52 -0800 (PST) In-Reply-To: <1B8AC001C412D84987E59160179F9D2801E5DA0E@ex3-del1.synapse.com> References: <1B8AC001C412D84987E59160179F9D2801E5DA0E@ex3-del1.synapse.com> From: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Date: Wed, 23 Feb 2011 08:32:52 +0000 Message-ID: To: Achint Aggarwal Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Issue with SBC/ALG interop with MSRP Relays X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 08:32:27 -0000 Hi Achint, My understanding of this situation as per the sessmatch draft is the following: you'll need to implement MSRP B2BUA functionality in your ALG if you want to support relays. >From section 5.4: "The sessmatch extension allows the usage of ALGs that do not implement MSRP B2BUA functionality in MSRP communications, unless TLS with name based authentication is used, and unless MSRP relays are used. In such cases ALGs need to implement MSRP B2BUA functionality, to prevent the MSRP communication from failing." This is mentioned in section 5.4 under the 'TLS' title which could be a bit misleading, since it also defines what to do about relays. If the draft is not updated specifically mentioning updates to RFC4976 compliant endpoints I see no other way os proceeding in the case you mention. Regards, -- /Sa=C3=BAl http://saghul.net | http://sipdoc.net From Achint.Aggarwal@globallogic.com Wed Feb 23 06:46:44 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F5B3A6A15 for ; Wed, 23 Feb 2011 06:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awb5hzbVIXJ1 for ; Wed, 23 Feb 2011 06:46:43 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id 9B1EA3A68D5 for ; Wed, 23 Feb 2011 06:46:42 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hckea20171sk for ; Wed, 23 Feb 2011 20:11:33 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.2.1.2841) with ESMTP; Wed, 23 Feb 2011 20:11:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD368.959277E2" Date: Wed, 23 Feb 2011 20:17:24 +0530 Message-ID: <1B8AC001C412D84987E59160179F9D2801F5DB2D@ex3-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP relay queries Thread-Index: AcvTaJUl5vvSjU//SRm4096f7rX5yg== From: "Achint Aggarwal" To: X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201102231441330061961 Subject: [Simple] MSRP relay queries X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:46:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD368.959277E2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Are there any MSRP relays deployed which supports sessmatch draft draft-ietf-simple-msrp-sessmatch-10.txt?? =20 Is there any vendor who has an MSRP relay in its product line?? =20 =20 Regards Achint Aggarwal =20 ------_=_NextPart_001_01CBD368.959277E2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 
Are there any MSRP relays deployed which =
supports sessmatch draft draft-ietf-simpl=
e-msrp-sessmatch-10.txt??=



 



Is
there any vendor who has an MSRP relay in its product =
line??



 



 



Regards



Achint =
Aggarwal



 
------_=_NextPart_001_01CBD368.959277E2-- From ben@nostrum.com Wed Feb 23 06:52:05 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961833A68A4 for ; Wed, 23 Feb 2011 06:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGFwH3xpfaLv for ; Wed, 23 Feb 2011 06:52:04 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id EA1993A6A14 for ; Wed, 23 Feb 2011 06:51:59 -0800 (PST) Received: from [IPv6:::1] (adsl-75-53-54-123.dsl.rcsntx.sbcglobal.net [75.53.54.123]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1NEpR6D030332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Feb 2011 08:51:28 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1-190423793 From: Ben Campbell In-Reply-To: <1B8AC001C412D84987E59160179F9D2801F5DB2D@ex3-del1.synapse.com> Date: Wed, 23 Feb 2011 09:51:27 -0500 Message-Id: <1FFA1B12-4036-4809-B0CD-978388A3C731@nostrum.com> References: <1B8AC001C412D84987E59160179F9D2801F5DB2D@ex3-del1.synapse.com> To: "Achint Aggarwal" X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.123 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] MSRP relay queries X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:52:05 -0000 --Apple-Mail-1-190423793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please keep in mind that not all vendors are willing to talk about = unannounced products on an IETF work group list. Thanks! Ben. On Feb 23, 2011, at 9:47 AM, Achint Aggarwal wrote: > Are there any MSRP relays deployed which supports sessmatch draft = draft-ietf-simple-msrp-sessmatch-10.txt?? > =20 > Is there any vendor who has an MSRP relay in its product line?? > =20 > =20 > Regards > Achint Aggarwal > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-1-190423793 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Please keep in mind that not all vendors are willing to talk about unannounced products on an IETF work group list.

Thanks!

Ben.

On Feb 23, 2011, at 9:47 AM, Achint Aggarwal wrote:

Are there any MSRP relays deployed which supports sessmatch draft draft-ietf-simple-msrp-sessmatch-10.txt??

 

Is there any vendor who has an MSRP relay in its product line??

 

 

Regards

Achint Aggarwal

 

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

--Apple-Mail-1-190423793-- From wwwrun@rfc-editor.org Mon Feb 28 09:59:26 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6B53A6C0C; Mon, 28 Feb 2011 09:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIR2zJI8ZBoX; Mon, 28 Feb 2011 09:59:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 70B743A6A0F; Mon, 28 Feb 2011 09:59:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A3C7DE073A; Mon, 28 Feb 2011 10:00:26 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110228180026.A3C7DE073A@rfc-editor.org> Date: Mon, 28 Feb 2011 10:00:26 -0800 (PST) Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 6135 on An Alternative Connection Model for the Message Session Relay Protocol (MSRP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:59:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6135 Title: An Alternative Connection Model for the Message Session Relay Protocol (MSRP) Author: C. Holmberg, S. Blau Status: Standards Track Stream: IETF Date: February 2011 Mailbox: christer.holmberg@ericsson.com, staffan.blau@ericsson.com Pages: 8 Characters: 17262 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-msrp-acm-10.txt URL: http://www.rfc-editor.org/rfc/rfc6135.txt This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Achint.Aggarwal@globallogic.com Mon Feb 28 21:28:26 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645833A6B12 for ; Mon, 28 Feb 2011 21:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9emBvvKE8Kg for ; Mon, 28 Feb 2011 21:28:23 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id E3E283A6A5A for ; Mon, 28 Feb 2011 21:28:21 -0800 (PST) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hdi1bs0171s3 for ; Tue, 1 Mar 2011 10:38:07 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.2.1.2841) with ESMTP; Tue, 01 Mar 2011 10:38:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD7CF.852E1D20" Date: Tue, 1 Mar 2011 10:44:19 +0530 Message-ID: <1B8AC001C412D84987E59160179F9D2802009B32@ex3-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection reuse query Thread-Index: AcvXz4TfUfPaWlNHTbiYyIgkfbaVhg== From: "Achint Aggarwal" To: X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201103010508060014677 Cc: Umang Singh Subject: [Simple] TCP connection reuse query X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 05:28:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD7CF.852E1D20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 RFC 4976 Section 3 says: "For client-to-client communication, the sender of a message typically opens a new TCP connection (with or without TLS) if one is needed. Relays reuse existing connections first, but can open new connections (typically to other relays) to deliver requests such as SEND or REPORT." =20 Consider a scenario where an MSRP client establishes an MSRP session and client's relay opens a connection with its next hop to route the MSRP packets coming to it from the client. Now if the same client wants to start another session then how can the same relay reuse the same connection opened earlier for this new session?? =20 Regards Achint Aggarwal =20 ------_=_NextPart_001_01CBD7CF.852E1D20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC 4976 Section 3 says:

“For client-to-client =
communication, the sender of a message =
typically
   opens a new TCP =
connection (with or without TLS) if one is =
needed.
   Relays reuse =
existing connections first, but can open new =
connections
   (typically to other =
relays) to deliver requests such as SEND =
or
   =
REPORT.”
 


Consider
a scenario where an MSRP client establishes an MSRP session and =
client’s
relay opens a connection with its next hop to route the MSRP packets =
coming to
it from the client.



Now
if the same client wants to start another session then how can the same =
relay
reuse the same connection opened earlier for this new =
session??



 



Regards



Achint
Aggarwal



 
------_=_NextPart_001_01CBD7CF.852E1D20-- From ben@nostrum.com Mon Feb 28 21:37:31 2011 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA2B3A6A88 for ; Mon, 28 Feb 2011 21:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvNWlRvTIvXe for ; Mon, 28 Feb 2011 21:37:29 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 5EB223A6A5A for ; Mon, 28 Feb 2011 21:37:29 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p215b56o005894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Feb 2011 23:37:05 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4-675562470 From: Ben Campbell In-Reply-To: <1B8AC001C412D84987E59160179F9D2802009B32@ex3-del1.synapse.com> Date: Mon, 28 Feb 2011 23:37:05 -0600 Message-Id: <57F36E23-F8E4-46B0-B680-B8B7CB874BB8@nostrum.com> References: <1B8AC001C412D84987E59160179F9D2802009B32@ex3-del1.synapse.com> To: Achint Aggarwal X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] TCP connection reuse query X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 05:37:32 -0000 --Apple-Mail-4-675562470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 28, 2011, at 11:14 PM, Achint Aggarwal wrote: > Hi, > =20 > RFC 4976 Section 3 says: > =93For client-to-client communication, the sender of a message = typically > opens a new TCP connection (with or without TLS) if one is needed. > Relays reuse existing connections first, but can open new = connections > (typically to other relays) to deliver requests such as SEND or > REPORT.=94 > =20 > Consider a scenario where an MSRP client establishes an MSRP session = and client=92s relay opens a connection with its next hop to route the = MSRP packets coming to it from the client. > Now if the same client wants to start another session then how can the = same relay reuse the same connection opened earlier for this new = session?? The general idea is, If the relay receives a SEND request where the next = hop URI in the To-Path field resolves to an address and port to which = the relay already has a TCP connection, it sends the forwards the = request over that connection. Of course, it only works if the next hop is the same for both sessions. Ben.= --Apple-Mail-4-675562470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Feb 28, 2011, at 11:14 PM, Achint = Aggarwal wrote:

RFC 4976 Section 3 = says:
=93For client-to-client communication, the sender =
of a message typically
   opens a new TCP connection (with or =
without TLS) if one is needed.
   Relays reuse existing connections =
first, but can open new connections
   (typically to other relays) to =
deliver requests such as SEND or
   =
REPORT.=94
Consider a scenario where an MSRP =
client establishes an MSRP session and client=92s relay opens a =
connection with its next hop to route the MSRP packets coming to it from =
the client.
Now if the same client wants to = start another session then how can the same relay reuse the same = connection opened earlier for this new = session??

The general idea is, If the relay receives a SEND request where = the next hop URI in the To-Path field resolves to an address and port to = which the relay already has a TCP connection, it sends the forwards the = request over that connection.

Of course, it = only works if the next hop is the same for both = sessions.

Ben.
= --Apple-Mail-4-675562470--