From bliss-bounces@ietf.org Tue Jun 05 14:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdSt-0008El-6H; Tue, 05 Jun 2007 14:09:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdSr-0008B4-Vy for bliss@ietf.org; Tue, 05 Jun 2007 14:09:05 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvdSq-0000QC-CM for bliss@ietf.org; Tue, 05 Jun 2007 14:09:05 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l55I8tt0010814; Tue, 5 Jun 2007 12:08:56 -0600 Message-ID: <4665A6AE.5060906@ntt-at.com> Date: Tue, 05 Jun 2007 11:08:46 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [BLISS] Internet-Drafts Submissions Cutoff Dates and Agenda for Chicago IETF X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org For your information, followings are the cutoff dates for draft submission. 2 July: Deadline for -00 drafts 9 July: Deadline for -01 and higher drafts At Chicago IETF, we are going to have 2 hours on Tuesday, as it was mentioned by the AD the charter is going under IETF last call, so we might be having another BoF. Whether it be another BoF or a WG session, if you have an agenda items, now is the time to let us know. Regards Shida ------ MSG from IESG Secretary ---------------------------------- There are two (2) Internet-Draft cutoff dates for the 69th IETF Meeting in Chicago, IL, USA: July 2nd: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, July 2nd at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 25th at 9:00 AM ET. July 9th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, July 9th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 23rd at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 69th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_69.html. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jun 07 21:37:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTPp-0004oC-Dx; Thu, 07 Jun 2007 21:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwTPj-0004iM-47 for bliss@ietf.org; Thu, 07 Jun 2007 21:37:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwTPh-0004PX-M1 for bliss@ietf.org; Thu, 07 Jun 2007 21:37:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2007 18:37:17 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="491705034:sNHT43578324" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l581bHoi028601 for ; Thu, 7 Jun 2007 18:37:17 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l581bGaJ018079 for ; Fri, 8 Jun 2007 01:37:17 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2B2D7B8C-1E2D-4D41-9C1C-FFE7FDE79FCE@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: bliss@ietf.org From: Cullen Jennings Date: Thu, 7 Jun 2007 18:36:24 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=121; t=1181266637; x=1182130637; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20BLISS=20was=20aproved=20as=20a=20WG |Sender:=20; bh=RuueulGTvhAo8jg3/Uy9rY0npKZI0Mj5rekz51JCTHs=; b=jj8P60rGdXNHEx3p4xjOcSkv38k5kAd75+8YBUi7k+7e2pRuqW09PIVgzRYaTF4jZFiPFdnF ED44XkREyKc650iCnsmN0Izl23O3mYbFrCugioLOn5g3naLUqeu1oktz; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [BLISS] BLISS was aproved as a WG X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Just wanted to let folks know that the IESG approved the WG today. Congratulation and now the hard part starts :-) _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 13 05:33:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyPEZ-00030s-2t; Wed, 13 Jun 2007 05:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyPEW-0002uG-Bz; Wed, 13 Jun 2007 05:33:44 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyPEU-0008V0-QK; Wed, 13 Jun 2007 05:33:44 -0400 Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 14 Jun 2007 04:01:17 +0530 X-IronPort-AV: i="4.16,415,1175452200"; d="scan'208"; a="82088797:sNHT91261898" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5D9Xe7W005071; Wed, 13 Jun 2007 15:03:40 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5D9X7er023701; Wed, 13 Jun 2007 09:33:13 GMT Received: from xmb-blr-413.apac.cisco.com ([64.104.140.142]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 15:03:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2007 15:03:05 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tunneling of Q931 messages over SIP thread-index: AcetndgmJaMhnFpSToagRsCBlnt2qQ== From: "Jayesh Sangpal (jsangpal)" To: , , , , , , , "Michael Hammer (mhammer)" , , , , , , , , X-OriginalArrivalTime: 13 Jun 2007 09:33:06.0156 (UTC) FILETIME=[D8C442C0:01C7AD9D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=419; t=1181727220; x=1182591220; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsangpal@cisco.com; z=From:=20=22Jayesh=20Sangpal=20(jsangpal)=22=20 |Subject:=20Tunneling=20of=20Q931=20messages=20over=20SIP |Sender:=20; bh=WD8c3mHMIrC0TZwpalhPxVEuPnWY0WNSEKNa9OSbOSQ=; b=i76VXMdy/rsbUcRU7buLFPvy1zDCCOHcuiu7zWCKugtAYsrk4G8zT4+mmGWGqNNXNW5ULQ1S TZsTjGwSzPNcCetUopb/JwSBVBY2Ak1+WPdUX63RVZkwB+QMqHhVsOAe; Authentication-Results: ind-dkim-1; header.From=jsangpal@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [BLISS] Tunneling of Q931 messages over SIP X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi experts, I have a requirement where the 'ISDN Q931 messages' are to be tunneled across SIP trunk. RFC 3204 defines a MIME type explicitly for QSIG messages. (application/qsig). I have few doubts on that. 1)Is there any such standard for Q931 messages ? 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only about QSIG and not generically about Q931 messages ? Thanks in Advance, Jayesh =20 =20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jun 14 09:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypE2-0001fx-KK; Thu, 14 Jun 2007 09:18:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypDz-0001fU-Nb; Thu, 14 Jun 2007 09:18:55 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HypDy-0001fB-6Q; Thu, 14 Jun 2007 09:18:55 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 14 Jun 2007 15:18:35 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 15:18:23 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] Tunneling of Q931 messages over SIP Date: Thu, 14 Jun 2007 15:18:23 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD4117652@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP Thread-Index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4Q From: "Jesske, R" To: , , , , , , , , , , , , , , , , X-OriginalArrivalTime: 14 Jun 2007 13:18:23.0339 (UTC) FILETIME=[7C0C73B0:01C7AE86] X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Question is what do you want to tunnel? All Messages? Or only the needed? e.G HLC, LLC? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com]=20 > Gesendet: Mittwoch, 13. Juni 2007 11:33 > An: bliss@ietf.org; sipping@ietf.org;=20 > john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > patrick.mourot@sxb.bsf.alcatel.fr;=20 > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > eric_zimmerer@yahoo.com; Aparna.Vemuri@Qwest.com;=20 > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > sip-implementors@cs.columbia.edu > Betreff: [BLISS] Tunneling of Q931 messages over SIP >=20 >=20 > Hi experts, > I have a requirement where the 'ISDN Q931 messages' are to be tunneled > across SIP trunk. > RFC 3204 defines a MIME type explicitly for QSIG messages. > (application/qsig). > I have few doubts on that. > 1)Is there any such standard for Q931 messages ? > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only about QSIG > and not generically about Q931 messages ? >=20 >=20 > Thanks in Advance, > Jayesh > =20 > =20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Jun 14 09:40:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypYX-0005bW-TH; Thu, 14 Jun 2007 09:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypYW-0005bD-Ck; Thu, 14 Jun 2007 09:40:08 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HypYV-0000lD-Oy; Thu, 14 Jun 2007 09:40:08 -0400 Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 15 Jun 2007 08:07:57 +0530 X-IronPort-AV: i="4.16,421,1175452200"; d="scan'208"; a="82182943:sNHT79192844" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5EDe50P006743; Thu, 14 Jun 2007 19:10:05 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5EDdWfM017404; Thu, 14 Jun 2007 13:39:32 GMT Received: from xmb-blr-413.apac.cisco.com ([64.104.140.142]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 19:09:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Thu, 14 Jun 2007 19:09:30 +0530 Message-ID: In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4117652@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP thread-index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19A= From: "Jayesh Sangpal (jsangpal)" To: "Jesske, R" , , , , , , , , "Michael Hammer (mhammer)" , , , , , , , , , "Elwell, John" X-OriginalArrivalTime: 14 Jun 2007 13:39:32.0637 (UTC) FILETIME=[709BF4D0:01C7AE89] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2098; t=1181828405; x=1182692405; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsangpal@cisco.com; z=From:=20=22Jayesh=20Sangpal=20(jsangpal)=22=20 |Subject:=20RE=3A=20[BLISS]=20Tunneling=20of=20Q931=20messages=20over=20S IP |Sender:=20; bh=4ZfBtt/hzVXJAeRNxWQo3vEkaZ0c8CYNMfgCyXaHiNc=; b=cyAeFrtUP5ahY8opbn+y/Vx2HT2Z1fwGBdJgzqyiPUFl6leeOfFUo+KhE9wXosZhwxt7byk6 Nj65ZdF7bdJDlZNE+XYXZnGQORXsk+4JDV8eM+8ybANoOpnmfNI5Vu+Y; Authentication-Results: ind-dkim-1; header.From=jsangpal@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: "Muthu ArulMozhi Perumal \(mperumal\)" , "Faisal Siyavudeen \(fsiyavud\)" , "Toleti Danayya Naidu \(naidud\)" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I want tunnel Complete Message and all the messages. -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Thursday, June 14, 2007 6:48 PM To: Jayesh Sangpal (jsangpal); bliss@ietf.org; sipping@ietf.org; = john.elwell@siemenscomms.co.uk; frank.derks@philips.com; = patrick.mourot@sxb.bsf.alcatel.fr; olivier.rousseau@col.bsf.alcatel.fr; = drage@lucent.com; Michael Hammer (mhammer); jon.peterson@neustar.biz; = subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; = eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com; = mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu Subject: AW: [BLISS] Tunneling of Q931 messages over SIP Question is what do you want to tunnel? All Messages? Or only the needed? e.G HLC, LLC? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > Gesendet: Mittwoch, 13. Juni 2007 11:33 > An: bliss@ietf.org; sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; Michael Hammer=20 > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > Betreff: [BLISS] Tunneling of Q931 messages over SIP >=20 >=20 > Hi experts, > I have a requirement where the 'ISDN Q931 messages' are to be tunneled = > across SIP trunk. > RFC 3204 defines a MIME type explicitly for QSIG messages. > (application/qsig). > I have few doubts on that. > 1)Is there any such standard for Q931 messages ? > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only about QSIG=20 > and not generically about Q931 messages ? >=20 >=20 > Thanks in Advance, > Jayesh > =20 > =20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Jun 18 06:13:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0EES-0008Sk-JU; Mon, 18 Jun 2007 06:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0EEQ-0008SI-SE; Mon, 18 Jun 2007 06:13:10 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0EEQ-0002uB-Bw; Mon, 18 Jun 2007 06:13:10 -0400 Received: from gauravk (unknown [221.134.154.130]) (Authenticated sender: gkheterpal@ismartpanache.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 2CEB5758051; Mon, 18 Jun 2007 05:13:00 -0500 (CDT) From: "Gaurav Kheterpal" To: "'Jayesh Sangpal \(jsangpal\)'" , "'Jesske, R'" , , , , , , , , "'Michael Hammer \(mhammer\)'" , , , , , , , , , "'Elwell, John'" Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Mon, 18 Jun 2007 15:44:37 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19AAwlNowA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070618101301.2CEB5758051@smtpauth00.csee.onr.siteprotect.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "'Muthu ArulMozhi Perumal \(mperumal\)'" , "'Faisal Siyavudeen \(fsiyavud\)'" , "'Toleti Danayya Naidu \(naidud\)'" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org This has been discussed a few times on SIPPPING. Please refer to http://www1.ietf.org/mail-archive/web/sipping/current/msg02069.html I hope this helps. Regards, Gaurav > -----Original Message----- > From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > Sent: Thursday, June 14, 2007 7:10 PM > To: Jesske, R; bliss@ietf.org; sipping@ietf.org; > john.elwell@siemenscomms.co.uk; frank.derks@philips.com; > patrick.mourot@sxb.bsf.alcatel.fr; = olivier.rousseau@col.bsf.alcatel.fr; > drage@lucent.com; Michael Hammer (mhammer); jon.peterson@neustar.biz; > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; = lyndon_ong@yahoo.com; > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu; Elwell, = John > Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen (fsiyavud); > Toleti Danayya Naidu (naidud) > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > I want tunnel Complete Message and all the messages. >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Thursday, June 14, 2007 6:48 PM > To: Jayesh Sangpal (jsangpal); bliss@ietf.org; sipping@ietf.org; > john.elwell@siemenscomms.co.uk; frank.derks@philips.com; > patrick.mourot@sxb.bsf.alcatel.fr; = olivier.rousseau@col.bsf.alcatel.fr; > drage@lucent.com; Michael Hammer (mhammer); jon.peterson@neustar.biz; > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; = lyndon_ong@yahoo.com; > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > Subject: AW: [BLISS] Tunneling of Q931 messages over SIP >=20 > Question is what do you want to tunnel? > All Messages? Or only the needed? e.G HLC, LLC? >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > Gesendet: Mittwoch, 13. Juni 2007 11:33 > > An: bliss@ietf.org; sipping@ietf.org; = john.elwell@siemenscomms.co.uk; > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; Michael = Hammer > > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com; > > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com; > > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com; > > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > > Betreff: [BLISS] Tunneling of Q931 messages over SIP > > > > > > Hi experts, > > I have a requirement where the 'ISDN Q931 messages' are to be = tunneled > > across SIP trunk. > > RFC 3204 defines a MIME type explicitly for QSIG messages. > > (application/qsig). > > I have few doubts on that. > > 1)Is there any such standard for Q931 messages ? > > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only about = QSIG > > and not generically about Q931 messages ? > > > > > > Thanks in Advance, > > Jayesh > > > > > > > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > > >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jun 19 16:18:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k9b-0004AO-BO; Tue, 19 Jun 2007 16:18:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k0K-00074w-71 for bliss@ietf.org; Tue, 19 Jun 2007 16:08:44 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jvM-0001VD-Sn for bliss@ietf.org; Tue, 19 Jun 2007 16:03:37 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJW0090VFPPH4@siemenscomms.co.uk> for bliss@ietf.org; Tue, 19 Jun 2007 21:03:25 +0100 (BST) Date: Tue, 19 Jun 2007 21:03:35 +0100 From: "Elwell, John" In-reply-to: To: bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E9D2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: I-D ACTION:draft-elwell-bliss-dnd-00.txt Thread-Index: Aceyq2B792I3toSuTtG7yeo0tl8wVwAAXlTw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Comments are solicited on this draft, which is a first step at trying to pull together some of the discussions relating to DND during the last year. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 19 June 2007 20:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-elwell-bliss-dnd-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An Analysis of Do Not Disturb (DND) > Implementations in the Session Initiation Protocol (SIP) > Author(s) : J. Elwell, M. Vakil > Filename : draft-elwell-bliss-dnd-00.txt > Pages : 12 > Date : 2007-6-19 > > Do Not Disturb (DND) is a commonly used expression for indicating a > condition where a human user of real-time communications does not > wish to be interrupted by incoming calls or other forms of > communication. This document discusses the nature of DND, ways of > observing DND, and limitations of and possible improvements to DND > support in the Session Initiation Protocol (SIP) and the Rich > Presence Information Data Format (RPID). > > This work is being discussed on the bliss@ietf.org mailing list. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-elwell-bliss-dnd-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-elwell-bliss-dnd-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-elwell-bliss-dnd-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jun 19 19:24:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0n3l-0007JF-8v; Tue, 19 Jun 2007 19:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0n3j-0007DQ-MO for bliss@ietf.org; Tue, 19 Jun 2007 19:24:27 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0n3j-00081c-BZ for bliss@ietf.org; Tue, 19 Jun 2007 19:24:27 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5JNOOe15493; Tue, 19 Jun 2007 23:24:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt Date: Tue, 19 Jun 2007 18:24:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE3D32@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E9D2@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt Thread-Index: Aceyq2B792I3toSuTtG7yeo0tl8wVwAAXlTwAAYCNCA= References: <0D5F89FAC29E2C41B98A6A762007F5D019E9D2@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi John, Good start, but I think there are things missing in there. For example, there is the concept of a "Semi-permanent setting" (i.e., you change your status to DND), and there is also dynamic "Do Not Disturb" that you can do when an incoming request. I believe that the you are focussing strictly on the first one. But it seems to me that it should apply to both "DND" (static) and "Decline" (dynamic), except for the discussion of presence status. I do think that a 480 or 486 are both valid and appropriate in most cases (when you don't want to affect the other branches). As for the "what do we do with 6XX", my take is that we should do the following: - It should only be valid within the scope of the target domain. - Proxies of the target domain should be able to interpret the 6XX coming from a UAS as they see fit. For example, they may decide to treat a 603 as a 486 if they have a policy to not allow global rejections. (there are many reasons to do so, not just voicemail). That leaves a good solution for manufacturers: - An equipment vendor can have a "Busy Here" and "Busy Everywhere" option, but the=20 network operator can avoid problems by treating them both as local if there are compelling reasons to do it (e.g., forward to operator, voicemail, pool, etc.).=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Tuesday, June 19, 2007 13:04 > To: bliss@ietf.org > Subject: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt >=20 > Comments are solicited on this draft, which is a first step=20 > at trying to pull together some of the discussions relating=20 > to DND during the last year.=20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 19 June 2007 20:50 > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-elwell-bliss-dnd-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : An Analysis of Do Not Disturb (DND)=20 > > Implementations in the Session Initiation Protocol (SIP) > > Author(s) : J. Elwell, M. Vakil > > Filename : draft-elwell-bliss-dnd-00.txt > > Pages : 12 > > Date : 2007-6-19 > > =09 > > Do Not Disturb (DND) is a commonly used expression for=20 > indicating a > > condition where a human user of real-time communications does not > > wish to be interrupted by incoming calls or other forms of > > communication. This document discusses the nature of=20 > DND, ways of > > observing DND, and limitations of and possible=20 > improvements to DND > > support in the Session Initiation Protocol (SIP) and the Rich > > Presence Information Data Format (RPID). > >=20 > > This work is being discussed on the bliss@ietf.org mailing list. > >=20 > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-elwell-bliss-dnd-00.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-elwell-bliss-dnd-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-elwell-bliss-dnd-00.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 05:43:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wif-0001bW-SG; Wed, 20 Jun 2007 05:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wie-0001bI-Js for bliss@ietf.org; Wed, 20 Jun 2007 05:43:20 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wid-0006tK-SV for bliss@ietf.org; Wed, 20 Jun 2007 05:43:20 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJX0030QHNVEY@siemenscomms.co.uk> for bliss@ietf.org; Wed, 20 Jun 2007 10:43:07 +0100 (BST) Date: Wed, 20 Jun 2007 10:43:17 +0100 From: "Elwell, John" Subject: RE: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt In-reply-to: <1ECE0EB50388174790F9694F77522CCF10EE3D32@zrc2hxm0.corp.nortel.com> To: Francois Audet , bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019EA22@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt Thread-Index: Aceyq2B792I3toSuTtG7yeo0tl8wVwAAXlTwAAYCNCAAFiUzwA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D019E9D2@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3D32@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Francois, Thanks for your comments. See below. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 20 June 2007 00:24 > To: Elwell, John; bliss@ietf.org > Subject: RE: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt > > Hi John, > > Good start, but I think there are things missing in there. > > For example, there is the concept of a "Semi-permanent setting" (i.e., > you change > your status to DND), and there is also dynamic "Do Not > Disturb" that you > can do when > an incoming request. > > I believe that the you are focussing strictly on the first one. But it > seems to me > that it should apply to both "DND" (static) and "Decline" (dynamic), > except for the > discussion of presence status. [JRE] You could indeed decide, on receipt of a call, to say you are in DND for that call. I guess a simple "decline" perhaps needs to make a distinction between "DND" (perhaps with a duration) and "I don't want to talk to you at all", which is how 603 could be interpreted. I can add some discussion of this for the next version. > > I do think that a 480 or 486 are both valid and appropriate in most > cases (when you don't want > to affect the other branches). > > As for the "what do we do with 6XX", my take is that we should do the > following: > - It should only be valid within the scope of the target domain. [JRE] You mean the domain of the UA that issues the 6xx? So if I send a request to user1@example1.com and that gets forwarded to user2@example2.com, then if user2's UA issues a 6xx it should apply to other destinations in example2.com but not to other destinations in example1.com? Also, would the 6xx then prevent the example2.com proxy from forwarding to user3@example3.com? > - Proxies of the target domain should be able to interpret the 6XX > coming from a UAS as they > see fit. For example, they may decide to treat a 603 as a > 486 if they > have a policy to > not allow global rejections. (there are many reasons to do so, not > just voicemail). > > That leaves a good solution for manufacturers: > - An equipment vendor can have a "Busy Here" and "Busy Everywhere" > option, but the > network operator can avoid problems by treating them both > as local if > there are > compelling reasons to do it (e.g., forward to operator, voicemail, > pool, etc.). [JRE] I am not sure whether the scope of 6xx is something to be solved just for DND or more generally. In the latter case it may not fit in this draft. > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Tuesday, June 19, 2007 13:04 > > To: bliss@ietf.org > > Subject: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt > > > > Comments are solicited on this draft, which is a first step > > at trying to pull together some of the discussions relating > > to DND during the last year. > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: 19 June 2007 20:50 > > > To: i-d-announce@ietf.org > > > Subject: I-D ACTION:draft-elwell-bliss-dnd-00.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > directories. > > > > > > > > > Title : An Analysis of Do Not Disturb (DND) > > > Implementations in the Session Initiation Protocol (SIP) > > > Author(s) : J. Elwell, M. Vakil > > > Filename : draft-elwell-bliss-dnd-00.txt > > > Pages : 12 > > > Date : 2007-6-19 > > > > > > Do Not Disturb (DND) is a commonly used expression for > > indicating a > > > condition where a human user of real-time > communications does not > > > wish to be interrupted by incoming calls or other forms of > > > communication. This document discusses the nature of > > DND, ways of > > > observing DND, and limitations of and possible > > improvements to DND > > > support in the Session Initiation Protocol (SIP) and the Rich > > > Presence Information Data Format (RPID). > > > > > > This work is being discussed on the bliss@ietf.org > mailing list. > > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-elwell-bliss-dnd-00.txt > > > > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > > the message. > > > You can also visit > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. > Login with the > > > username "anonymous" and a password of your e-mail address. After > > > logging in, type "cd internet-drafts" and then "get > > > draft-elwell-bliss-dnd-00.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-elwell-bliss-dnd-00.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 06:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xfn-0000Pl-U1; Wed, 20 Jun 2007 06:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xfl-0000PJ-Q2; Wed, 20 Jun 2007 06:44:25 -0400 Received: from [82.108.230.130] (helo=EiconLON.eicon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xfh-00035c-Np; Wed, 20 Jun 2007 06:44:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Wed, 20 Jun 2007 11:44:16 +0100 Message-ID: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP Thread-Index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19ABJ/UiwA== References: From: "Martyn Davies" To: "Jayesh Sangpal \(jsangpal\)" X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: frank.derks@philips.com, drage@lucent.com, john.elwell@siemenscomms.co.uk, "Michael Hammer \(mhammer\)" , "Toleti Danayya Naidu \(naidud\)" , jon.peterson@neustar.biz, "Muthu ArulMozhi Perumal \(mperumal\)" , eric_zimmerer@yahoo.com, subhodeep.sarkar@wipro.com, Rolf.Vautz@Tenovis.com, bliss@ietf.org, lyndon_ong@yahoo.com, sip-implementors@cs.columbia.edu, patrick.mourot@sxb.bsf.alcatel.fr, olivier.rousseau@col.bsf.alcatel.fr, mzonoun@nortelnetworks.com, "Faisal Siyavudeen \(fsiyavud\)" , sipping@ietf.org, Aparna.Vemuri@qwest.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org As you said, QSig is a superset of Q931, so the distinction probably = doesn't matter in this case. In my direct experience of QSig, the only = difference in practice from Q931 is the large number of FACILITY = messages containing Invoke commands, for example in Path Replacement = sequences. It looks from the RFC examples that the complete Q931/QSIG header is = there embedded in any case, so the tunnel itself doesn't need to know = what the content is, as long as the two endpoints are running matching = protocols. Regards, Martyn =20 | Martyn Davies, Principal Consultant | Dialogic | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK | Tel: +44 1628 641 790 x 210=20 | Cell: +44 7881 908 381=20 | Follow Me: +44 7031 911 586=20 | martyn.davies@dialogic.com | blog: http://www.dialogic.com/drc | blog: http://voipsa.org/blog =20 Company Registration Number 2017909 Registered in England and Wales =20 This e-mail is intended only for the named recipient(s) and may contain = information that is privileged, confidential and/or exempt from = disclosure under applicable law. No waiver of privilege, confidence or = otherwise is intended by virtue of communication via the internet. Any = unauthorized use, dissemination or copying is strictly prohibited. If = you have received this e-mail in error, or are not named as a recipient, = please immediately notify the sender and destroy all copies of this = e-mail. =20 =20 -----Original Message----- From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com]=20 Sent: Thursday, June 14, 2007 2:40 PM To: Jesske, R; bliss@ietf.org; sipping@ietf.org; = john.elwell@siemenscomms.co.uk; frank.derks@philips.com; = patrick.mourot@sxb.bsf.alcatel.fr; olivier.rousseau@col.bsf.alcatel.fr; = drage@lucent.com; Michael Hammer (mhammer); jon.peterson@neustar.biz; = subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; = eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com; = mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu; Elwell, = John Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen (fsiyavud); = Toleti Danayya Naidu (naidud) Subject: RE: [BLISS] Tunneling of Q931 messages over SIP I want tunnel Complete Message and all the messages. -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Thursday, June 14, 2007 6:48 PM To: Jayesh Sangpal (jsangpal); bliss@ietf.org; sipping@ietf.org; = john.elwell@siemenscomms.co.uk; frank.derks@philips.com; = patrick.mourot@sxb.bsf.alcatel.fr; olivier.rousseau@col.bsf.alcatel.fr; = drage@lucent.com; Michael Hammer (mhammer); jon.peterson@neustar.biz; = subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; = eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com; = mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu Subject: AW: [BLISS] Tunneling of Q931 messages over SIP Question is what do you want to tunnel? All Messages? Or only the needed? e.G HLC, LLC? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > Gesendet: Mittwoch, 13. Juni 2007 11:33 > An: bliss@ietf.org; sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; Michael Hammer=20 > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > Betreff: [BLISS] Tunneling of Q931 messages over SIP >=20 >=20 > Hi experts, > I have a requirement where the 'ISDN Q931 messages' are to be tunneled = > across SIP trunk. > RFC 3204 defines a MIME type explicitly for QSIG messages. > (application/qsig). > I have few doubts on that. > 1)Is there any such standard for Q931 messages ? > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only about QSIG=20 > and not generically about Q931 messages ? >=20 >=20 > Thanks in Advance, > Jayesh > =20 > =20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 06:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xqT-0007ea-7r; Wed, 20 Jun 2007 06:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xqS-0007Vh-3f; Wed, 20 Jun 2007 06:55:28 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xqE-0005ZU-Oa; Wed, 20 Jun 2007 06:55:15 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5KAsQh4028498; Wed, 20 Jun 2007 05:54:27 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 05:54:26 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:54:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Wed, 20 Jun 2007 12:54:15 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001303CB5@DEEXC1U01.de.lucent.com> In-Reply-To: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP Thread-Index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19ABJ/UiwAAAaozQ References: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> From: "DRAGE, Keith \(Keith\)" To: "Martyn Davies" , "Jayesh Sangpal \(jsangpal\)" X-OriginalArrivalTime: 20 Jun 2007 10:54:23.0994 (UTC) FILETIME=[5D1385A0:01C7B329] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: frank.derks@philips.com, john.elwell@siemenscomms.co.uk, jon.peterson@neustar.biz, "Toleti Danayya Naidu \(naidud\)" , "Muthu ArulMozhi Perumal \(mperumal\)" , eric_zimmerer@yahoo.com, subhodeep.sarkar@wipro.com, Rolf.Vautz@Tenovis.com, "ROUSSEAU, OLIVIER \(OLIVIER\)" , bliss@ietf.org, lyndon_ong@yahoo.com, sip-implementors@cs.columbia.edu, "Michael Hammer \(mhammer\)" , mzonoun@nortelnetworks.com, "Faisal Siyavudeen \(fsiyavud\)" , sipping@ietf.org, "MOUROT, PATRICK \(PATRICK\)" , Aparna.Vemuri@qwest.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org > doesn't need to know what the content is, as long as the two=20 > endpoints are running matching protocols. And therein lies your problem. The MIME type is there to tell you which protocol is meant to be run. The key difference between the two protocols, is that QSIG runs a state = machine at both ends based on the user side state machine in Q.931. The = Q.931 protocol has different user and network side state machines. I suggest you also view the current thread on INFO usage in the SIP WG = list in regard to this part of the issue. Regards Keith=20 > -----Original Message----- > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > Sent: Wednesday, June 20, 2007 11:44 AM > To: Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; DRAGE, Keith (Keith);=20 > john.elwell@siemenscomms.co.uk; Michael Hammer (mhammer);=20 > Toleti Danayya Naidu (naidud); jon.peterson@neustar.biz;=20 > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 >=20 > As you said, QSig is a superset of Q931, so the distinction=20 > probably doesn't matter in this case. In my direct=20 > experience of QSig, the only difference in practice from Q931=20 > is the large number of FACILITY messages containing Invoke=20 > commands, for example in Path Replacement sequences. >=20 > It looks from the RFC examples that the complete Q931/QSIG=20 > header is there embedded in any case, so the tunnel itself=20 > doesn't need to know what the content is, as long as the two=20 > endpoints are running matching protocols. >=20 > Regards, Martyn > =20 > | Martyn Davies, Principal Consultant > | Dialogic > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > | Tel: +44 1628 641 790 x 210 > | Cell: +44 7881 908 381 > | Follow Me: +44 7031 911 586 > | martyn.davies@dialogic.com > | blog: http://www.dialogic.com/drc > | blog: http://voipsa.org/blog > =20 > Company Registration Number 2017909 > Registered in England and Wales > =20 > This e-mail is intended only for the named recipient(s) and=20 > may contain information that is privileged, confidential=20 > and/or exempt from disclosure under applicable law. No waiver=20 > of privilege, confidence or otherwise is intended by virtue=20 > of communication via the internet. Any unauthorized use,=20 > dissemination or copying is strictly prohibited. If you have=20 > received this e-mail in error, or are not named as a=20 > recipient, please immediately notify the sender and destroy=20 > all copies of this e-mail. > =20 > =20 > -----Original Message----- > From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > Sent: Thursday, June 14, 2007 2:40 PM > To: Jesske, R; bliss@ietf.org; sipping@ietf.org;=20 > john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > patrick.mourot@sxb.bsf.alcatel.fr;=20 > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > sip-implementors@cs.columbia.edu; Elwell, John > Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen=20 > (fsiyavud); Toleti Danayya Naidu (naidud) > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > I want tunnel Complete Message and all the messages. >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Thursday, June 14, 2007 6:48 PM > To: Jayesh Sangpal (jsangpal); bliss@ietf.org;=20 > sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr;=20 > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > sip-implementors@cs.columbia.edu > Subject: AW: [BLISS] Tunneling of Q931 messages over SIP >=20 > Question is what do you want to tunnel? > All Messages? Or only the needed? e.G HLC, LLC? >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > Gesendet: Mittwoch, 13. Juni 2007 11:33 > > An: bliss@ietf.org; sipping@ietf.org;=20 > john.elwell@siemenscomms.co.uk;=20 > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer=20 > > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > > Betreff: [BLISS] Tunneling of Q931 messages over SIP > >=20 > >=20 > > Hi experts, > > I have a requirement where the 'ISDN Q931 messages' are to=20 > be tunneled=20 > > across SIP trunk. > > RFC 3204 defines a MIME type explicitly for QSIG messages. > > (application/qsig). > > I have few doubts on that. > > 1)Is there any such standard for Q931 messages ? > > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only=20 > about QSIG=20 > > and not generically about Q931 messages ? > >=20 > >=20 > > Thanks in Advance, > > Jayesh > > =20 > > =20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 06:55:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xqd-00082j-LS; Wed, 20 Jun 2007 06:55:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xqa-0007v3-LB; Wed, 20 Jun 2007 06:55:36 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xpE-00057K-Es; Wed, 20 Jun 2007 06:54:13 -0400 Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 21 Jun 2007 05:23:20 +0530 X-IronPort-AV: i="4.16,442,1175452200"; d="scan'208"; a="82523346:sNHT169495572" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KAs999013284; Wed, 20 Jun 2007 16:24:09 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KArNfM028405; Wed, 20 Jun 2007 10:53:24 GMT Received: from xmb-blr-413.apac.cisco.com ([64.104.140.142]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 16:23:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Wed, 20 Jun 2007 16:23:21 +0530 Message-ID: In-Reply-To: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP thread-index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19ABJ/UiwAAASYCA From: "Jayesh Sangpal (jsangpal)" To: "Martyn Davies" X-OriginalArrivalTime: 20 Jun 2007 10:53:23.0895 (UTC) FILETIME=[39412470:01C7B329] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5639; t=1182336849; x=1183200849; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsangpal@cisco.com; z=From:=20=22Jayesh=20Sangpal=20(jsangpal)=22=20 |Subject:=20RE=3A=20[BLISS]=20Tunneling=20of=20Q931=20messages=20over=20S IP |Sender:=20; bh=Lzxtfu9eO5EYaeFv8lLHAYGgu9OLqsvzC5AzlAFMh+k=; b=RmgGQ0EG4Bd2Kg3naumd0mT2LSdSsbk8WerxUZ/pBf+CS0xttgfFQoxKpjOMElWAsW/Fp2qh jQefZJcz4EBw10GQ+BilyOhmwL3jMi4noXdvwtcLJBvCOVzZVyRAZisC; Authentication-Results: ind-dkim-1; header.From=jsangpal@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: frank.derks@philips.com, drage@lucent.com, john.elwell@siemenscomms.co.uk, "Michael Hammer \(mhammer\)" , "Toleti Danayya Naidu \(naidud\)" , jon.peterson@neustar.biz, "Muthu ArulMozhi Perumal \(mperumal\)" , eric_zimmerer@yahoo.com, subhodeep.sarkar@wipro.com, Rolf.Vautz@Tenovis.com, bliss@ietf.org, lyndon_ong@yahoo.com, sip-implementors@cs.columbia.edu, patrick.mourot@sxb.bsf.alcatel.fr, olivier.rousseau@col.bsf.alcatel.fr, mzonoun@nortelnetworks.com, "Faisal Siyavudeen \(fsiyavud\)" , sipping@ietf.org, Aparna.Vemuri@qwest.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Thanks for the reply Martyn. Please see responses inline [JAS] -----Original Message----- From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 Sent: Wednesday, June 20, 2007 4:14 PM To: Jayesh Sangpal (jsangpal) Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen (fsiyavud); = Toleti Danayya Naidu (naidud); Jesske, R; bliss@ietf.org; = sipping@ietf.org; john.elwell@siemenscomms.co.uk; = frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; = olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; Michael Hammer = (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com; = Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com; = Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com; = mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu; Elwell, = John Subject: RE: [BLISS] Tunneling of Q931 messages over SIP As you said, QSig is a superset of Q931, so the distinction probably = doesn't matter in this case. =20 [JAS] I guess its other way round.. Q931 is superset of QSIG... In my direct experience of QSig, the only difference in practice from = Q931 is the large number of FACILITY messages containing Invoke = commands, for example in Path Replacement sequences. [JAS] Yes that's correct It looks from the RFC examples that the complete Q931/QSIG header is = there embedded in any case, so the tunnel itself doesn't need to know = what the content is, as long as the two endpoints are running matching = protocols. [JAS] But if we reuse the tunnel (established by application/qsig), for = transporting something else than QSIG, won't it may cause = interoperability issues. So why I expected an explicit MIME type for Q931 data (NON QSIG). -Jayesh Regards, Martyn =20 | Martyn Davies, Principal Consultant | Dialogic | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK | Tel: +44 1628 641 790 x 210 | Cell: +44 7881 908 381 | Follow Me: +44 7031 911 586 | martyn.davies@dialogic.com | blog: http://www.dialogic.com/drc | blog: http://voipsa.org/blog =20 Company Registration Number 2017909 Registered in England and Wales =20 This e-mail is intended only for the named recipient(s) and may contain = information that is privileged, confidential and/or exempt from = disclosure under applicable law. No waiver of privilege, confidence or = otherwise is intended by virtue of communication via the internet. Any = unauthorized use, dissemination or copying is strictly prohibited. If = you have received this e-mail in error, or are not named as a recipient, = please immediately notify the sender and destroy all copies of this = e-mail. =20 =20 -----Original Message----- From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] Sent: Thursday, June 14, 2007 2:40 PM To: Jesske, R; bliss@ietf.org; sipping@ietf.org; = john.elwell@siemenscomms.co.uk; frank.derks@philips.com; = patrick.mourot@sxb.bsf.alcatel.fr; olivier.rousseau@col.bsf.alcatel.fr; = drage@lucent.com; Michael Hammer (mhammer); jon.peterson@neustar.biz; = subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; = eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com; = mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu; Elwell, = John Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen (fsiyavud); = Toleti Danayya Naidu (naidud) Subject: RE: [BLISS] Tunneling of Q931 messages over SIP I want tunnel Complete Message and all the messages. -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net] Sent: Thursday, June 14, 2007 6:48 PM To: Jayesh Sangpal (jsangpal); bliss@ietf.org; sipping@ietf.org; = john.elwell@siemenscomms.co.uk; frank.derks@philips.com; = patrick.mourot@sxb.bsf.alcatel.fr; olivier.rousseau@col.bsf.alcatel.fr; = drage@lucent.com; Michael Hammer (mhammer); jon.peterson@neustar.biz; = subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; = eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com; = mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu Subject: AW: [BLISS] Tunneling of Q931 messages over SIP Question is what do you want to tunnel? All Messages? Or only the needed? e.G HLC, LLC? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > Gesendet: Mittwoch, 13. Juni 2007 11:33 > An: bliss@ietf.org; sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; Michael Hammer=20 > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > Betreff: [BLISS] Tunneling of Q931 messages over SIP >=20 >=20 > Hi experts, > I have a requirement where the 'ISDN Q931 messages' are to be tunneled = > across SIP trunk. > RFC 3204 defines a MIME type explicitly for QSIG messages. > (application/qsig). > I have few doubts on that. > 1)Is there any such standard for Q931 messages ? > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only about QSIG=20 > and not generically about Q931 messages ? >=20 >=20 > Thanks in Advance, > Jayesh > =20 > =20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 07:47:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yeq-0007ug-0C; Wed, 20 Jun 2007 07:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yeo-0007uQ-10; Wed, 20 Jun 2007 07:47:30 -0400 Received: from [82.108.230.130] (helo=EiconLON.eicon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0yel-0001iR-Po; Wed, 20 Jun 2007 07:47:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Wed, 20 Jun 2007 12:47:25 +0100 Message-ID: <2D48FF2CE7A2D74C8FE566B2AEF3295C0136215F@EiconLON.eicon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP Thread-Index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19ABJ/UiwAAAaozQAAG4zzA= References: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> <5D1A7985295922448D5550C94DE2918001303CB5@DEEXC1U01.de.lucent.com> From: "Martyn Davies" To: "DRAGE, Keith \(Keith\)" , "Jayesh Sangpal \(jsangpal\)" X-Spam-Score: 0.5 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: frank.derks@philips.com, john.elwell@siemenscomms.co.uk, jon.peterson@neustar.biz, "Toleti Danayya Naidu \(naidud\)" , "Muthu ArulMozhi Perumal \(mperumal\)" , eric_zimmerer@yahoo.com, subhodeep.sarkar@wipro.com, Rolf.Vautz@Tenovis.com, "ROUSSEAU, OLIVIER \(OLIVIER\)" , bliss@ietf.org, lyndon_ong@yahoo.com, sip-implementors@cs.columbia.edu, "Michael Hammer \(mhammer\)" , mzonoun@nortelnetworks.com, "Faisal Siyavudeen \(fsiyavud\)" , sipping@ietf.org, "MOUROT, PATRICK \(PATRICK\)" , Aparna.Vemuri@qwest.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org > The MIME type is there to tell you which protocol is meant to be run. That's true, but in practice it's often difficult to enumerate all the = possible variations in any case. Already this RFC is too ambiguous as = at the very least it should use 'version' or 'base' to allow you to = specify whether it is ISO or ECMA QSig. This incompatibility of 'two = QSigs' is a very common problem for interconnecting PBXes. In the same = way, you could use the version field to suggest that the protocol is = plain vanilla Q.931. They've obviously made a more manful attempt in the RFC's ISUP section, = to enumerate sub-types of ISUP, but again in practice it won't cover all = the ISUPs that are out there. The problem's just too big. Regards, Martyn =20 | Martyn Davies, Principal Consultant | Dialogic | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK | Tel: +44 1628 641 790 x 210=20 | Cell: +44 7881 908 381=20 | Follow Me: +44 7031 911 586=20 | martyn.davies@dialogic.com | blog: http://www.dialogic.com/drc | blog: http://voipsa.org/blog =20 Company Registration Number 2017909 Registered in England and Wales =20 This e-mail is intended only for the named recipient(s) and may contain = information that is privileged, confidential and/or exempt from = disclosure under applicable law. No waiver of privilege, confidence or = otherwise is intended by virtue of communication via the internet. Any = unauthorized use, dissemination or copying is strictly prohibited. If = you have received this e-mail in error, or are not named as a recipient, = please immediately notify the sender and destroy all copies of this = e-mail. =20 =20 -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Wednesday, June 20, 2007 11:54 AM To: Martyn Davies; Jayesh Sangpal (jsangpal) Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk; Michael = Hammer (mhammer); Toleti Danayya Naidu (naidud); = jon.peterson@neustar.biz; Muthu ArulMozhi Perumal (mperumal); = eric_zimmerer@yahoo.com; subhodeep.sarkar@wipro.com; = Rolf.Vautz@Tenovis.com; bliss@ietf.org; lyndon_ong@yahoo.com; = sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK); ROUSSEAU, = OLIVIER (OLIVIER); mzonoun@nortelnetworks.com; Faisal Siyavudeen = (fsiyavud); sipping@ietf.org; Aparna.Vemuri@qwest.com Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > doesn't need to know what the content is, as long as the two=20 > endpoints are running matching protocols. And therein lies your problem. The MIME type is there to tell you which protocol is meant to be run. The key difference between the two protocols, is that QSIG runs a state = machine at both ends based on the user side state machine in Q.931. The = Q.931 protocol has different user and network side state machines. I suggest you also view the current thread on INFO usage in the SIP WG = list in regard to this part of the issue. Regards Keith=20 > -----Original Message----- > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > Sent: Wednesday, June 20, 2007 11:44 AM > To: Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; DRAGE, Keith (Keith);=20 > john.elwell@siemenscomms.co.uk; Michael Hammer (mhammer);=20 > Toleti Danayya Naidu (naidud); jon.peterson@neustar.biz;=20 > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 >=20 > As you said, QSig is a superset of Q931, so the distinction=20 > probably doesn't matter in this case. In my direct=20 > experience of QSig, the only difference in practice from Q931=20 > is the large number of FACILITY messages containing Invoke=20 > commands, for example in Path Replacement sequences. >=20 > It looks from the RFC examples that the complete Q931/QSIG=20 > header is there embedded in any case, so the tunnel itself=20 > doesn't need to know what the content is, as long as the two=20 > endpoints are running matching protocols. >=20 > Regards, Martyn > =20 > | Martyn Davies, Principal Consultant > | Dialogic > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > | Tel: +44 1628 641 790 x 210 > | Cell: +44 7881 908 381 > | Follow Me: +44 7031 911 586 > | martyn.davies@dialogic.com > | blog: http://www.dialogic.com/drc > | blog: http://voipsa.org/blog > =20 > Company Registration Number 2017909 > Registered in England and Wales > =20 > This e-mail is intended only for the named recipient(s) and=20 > may contain information that is privileged, confidential=20 > and/or exempt from disclosure under applicable law. No waiver=20 > of privilege, confidence or otherwise is intended by virtue=20 > of communication via the internet. Any unauthorized use,=20 > dissemination or copying is strictly prohibited. If you have=20 > received this e-mail in error, or are not named as a=20 > recipient, please immediately notify the sender and destroy=20 > all copies of this e-mail. > =20 > =20 > -----Original Message----- > From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > Sent: Thursday, June 14, 2007 2:40 PM > To: Jesske, R; bliss@ietf.org; sipping@ietf.org;=20 > john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > patrick.mourot@sxb.bsf.alcatel.fr;=20 > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > sip-implementors@cs.columbia.edu; Elwell, John > Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen=20 > (fsiyavud); Toleti Danayya Naidu (naidud) > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > I want tunnel Complete Message and all the messages. >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Thursday, June 14, 2007 6:48 PM > To: Jayesh Sangpal (jsangpal); bliss@ietf.org;=20 > sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr;=20 > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > sip-implementors@cs.columbia.edu > Subject: AW: [BLISS] Tunneling of Q931 messages over SIP >=20 > Question is what do you want to tunnel? > All Messages? Or only the needed? e.G HLC, LLC? >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > Gesendet: Mittwoch, 13. Juni 2007 11:33 > > An: bliss@ietf.org; sipping@ietf.org;=20 > john.elwell@siemenscomms.co.uk;=20 > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer=20 > > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > > Betreff: [BLISS] Tunneling of Q931 messages over SIP > >=20 > >=20 > > Hi experts, > > I have a requirement where the 'ISDN Q931 messages' are to=20 > be tunneled=20 > > across SIP trunk. > > RFC 3204 defines a MIME type explicitly for QSIG messages. > > (application/qsig). > > I have few doubts on that. > > 1)Is there any such standard for Q931 messages ? > > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only=20 > about QSIG=20 > > and not generically about Q931 messages ? > >=20 > >=20 > > Thanks in Advance, > > Jayesh > > =20 > > =20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 08:20:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zB9-0006ts-Ih; Wed, 20 Jun 2007 08:20:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zB7-0006tO-Iu; Wed, 20 Jun 2007 08:20:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0zB6-00006F-2l; Wed, 20 Jun 2007 08:20:53 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2007 08:20:52 -0400 X-IronPort-AV: i="4.16,442,1175486400"; d="scan'208"; a="124109845:sNHT69528502" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KCKpNT018124; Wed, 20 Jun 2007 08:20:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KCKX5f018158; Wed, 20 Jun 2007 12:20:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 08:20:33 -0400 Received: from [10.86.242.62] ([10.86.242.62]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 08:20:32 -0400 Message-ID: <46791B8F.60400@cisco.com> Date: Wed, 20 Jun 2007 08:20:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [BLISS] Tunneling of Q931 messages over SIP References: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> <5D1A7985295922448D5550C94DE2918001303CB5@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001303CB5@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Jun 2007 12:20:32.0875 (UTC) FILETIME=[65F82BB0:01C7B335] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6555; t=1182342051; x=1183206051; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Tunneling=20of=20Q931=20messages=20over=20S IP |Sender:=20 |To:=20=22DRAGE,=20Keith=20\(Keith\)=22=20; bh=zucVOjBMKSonzB9pCB1/RESSrVBjBB/pf+8WZCb3yF0=; b=pfSZuyOKxCcvbQffRIVHQohFB2h9odux2B9fLNg+i1SmoKjNMytvSyDZ4mJIsNhF5fWk1xfv 5MtpDCHZXoD6bVuvaziUGN50As5KHcdD4c/8GB8LKQNq6m1jge0PuCsY; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: frank.derks@philips.com, john.elwell@siemenscomms.co.uk, jon.peterson@neustar.biz, "Toleti Danayya Naidu \(naidud\)" , "Muthu ArulMozhi Perumal \(mperumal\)" , Martyn Davies , eric_zimmerer@yahoo.com, subhodeep.sarkar@wipro.com, Rolf.Vautz@Tenovis.com, "ROUSSEAU, OLIVIER \(OLIVIER\)" , bliss@ietf.org, lyndon_ong@yahoo.com, sip-implementors@cs.columbia.edu, "Michael Hammer \(mhammer\)" , mzonoun@nortelnetworks.com, "Faisal Siyavudeen \(fsiyavud\)" , sipping@ietf.org, "MOUROT, PATRICK \(PATRICK\)" , Aparna.Vemuri@qwest.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Keith, Are you suggesting that any further variants of this sort *not* use INFO, and instead use some other mechanism? Paul DRAGE, Keith (Keith) wrote: >> doesn't need to know what the content is, as long as the two >> endpoints are running matching protocols. > > And therein lies your problem. > > The MIME type is there to tell you which protocol is meant to be run. > > The key difference between the two protocols, is that QSIG runs a state machine at both ends based on the user side state machine in Q.931. The Q.931 protocol has different user and network side state machines. > > I suggest you also view the current thread on INFO usage in the SIP WG list in regard to this part of the issue. > > Regards > > Keith > >> -----Original Message----- >> From: Martyn Davies [mailto:Martyn.Davies@dialogic.com] >> Sent: Wednesday, June 20, 2007 11:44 AM >> To: Jayesh Sangpal (jsangpal) >> Cc: frank.derks@philips.com; DRAGE, Keith (Keith); >> john.elwell@siemenscomms.co.uk; Michael Hammer (mhammer); >> Toleti Danayya Naidu (naidud); jon.peterson@neustar.biz; >> Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com; >> subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; >> bliss@ietf.org; lyndon_ong@yahoo.com; >> sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK); >> ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com; >> Faisal Siyavudeen (fsiyavud); sipping@ietf.org; >> Aparna.Vemuri@qwest.com >> Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >> >> >> As you said, QSig is a superset of Q931, so the distinction >> probably doesn't matter in this case. In my direct >> experience of QSig, the only difference in practice from Q931 >> is the large number of FACILITY messages containing Invoke >> commands, for example in Path Replacement sequences. >> >> It looks from the RFC examples that the complete Q931/QSIG >> header is there embedded in any case, so the tunnel itself >> doesn't need to know what the content is, as long as the two >> endpoints are running matching protocols. >> >> Regards, Martyn >> >> | Martyn Davies, Principal Consultant >> | Dialogic >> | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK >> | Tel: +44 1628 641 790 x 210 >> | Cell: +44 7881 908 381 >> | Follow Me: +44 7031 911 586 >> | martyn.davies@dialogic.com >> | blog: http://www.dialogic.com/drc >> | blog: http://voipsa.org/blog >> >> Company Registration Number 2017909 >> Registered in England and Wales >> >> This e-mail is intended only for the named recipient(s) and >> may contain information that is privileged, confidential >> and/or exempt from disclosure under applicable law. No waiver >> of privilege, confidence or otherwise is intended by virtue >> of communication via the internet. Any unauthorized use, >> dissemination or copying is strictly prohibited. If you have >> received this e-mail in error, or are not named as a >> recipient, please immediately notify the sender and destroy >> all copies of this e-mail. >> >> >> -----Original Message----- >> From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] >> Sent: Thursday, June 14, 2007 2:40 PM >> To: Jesske, R; bliss@ietf.org; sipping@ietf.org; >> john.elwell@siemenscomms.co.uk; frank.derks@philips.com; >> patrick.mourot@sxb.bsf.alcatel.fr; >> olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; >> Michael Hammer (mhammer); jon.peterson@neustar.biz; >> subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; >> eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; >> lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com; >> sip-implementors@cs.columbia.edu; Elwell, John >> Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen >> (fsiyavud); Toleti Danayya Naidu (naidud) >> Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >> >> I want tunnel Complete Message and all the messages. >> >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: Thursday, June 14, 2007 6:48 PM >> To: Jayesh Sangpal (jsangpal); bliss@ietf.org; >> sipping@ietf.org; john.elwell@siemenscomms.co.uk; >> frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; >> olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; >> Michael Hammer (mhammer); jon.peterson@neustar.biz; >> subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; >> eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com; >> lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com; >> sip-implementors@cs.columbia.edu >> Subject: AW: [BLISS] Tunneling of Q931 messages over SIP >> >> Question is what do you want to tunnel? >> All Messages? Or only the needed? e.G HLC, LLC? >> >> Best Regards >> >> Roland >> >>> -----Ursprüngliche Nachricht----- >>> Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] >>> Gesendet: Mittwoch, 13. Juni 2007 11:33 >>> An: bliss@ietf.org; sipping@ietf.org; >> john.elwell@siemenscomms.co.uk; >>> frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; >>> olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; >> Michael Hammer >>> (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com; >>> Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com; >>> Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com; >>> mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu >>> Betreff: [BLISS] Tunneling of Q931 messages over SIP >>> >>> >>> Hi experts, >>> I have a requirement where the 'ISDN Q931 messages' are to >> be tunneled >>> across SIP trunk. >>> RFC 3204 defines a MIME type explicitly for QSIG messages. >>> (application/qsig). >>> I have few doubts on that. >>> 1)Is there any such standard for Q931 messages ? >>> 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only >> about QSIG >>> and not generically about Q931 messages ? >>> >>> >>> Thanks in Advance, >>> Jayesh >>> >>> >>> >>> _______________________________________________ >>> BLISS mailing list >>> BLISS@ietf.org >>> https://www1.ietf.org/mailman/listinfo/bliss >>> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 10:14:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10x6-0007H2-EK; Wed, 20 Jun 2007 10:14:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10x5-0007Cv-DQ for bliss@ietf.org; Wed, 20 Jun 2007 10:14:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10x2-000650-TR for bliss@ietf.org; Wed, 20 Jun 2007 10:14:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2007 10:14:29 -0400 X-IronPort-AV: i="4.16,443,1175486400"; d="scan'208"; a="63246254:sNHT57939768" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KEESoW019349; Wed, 20 Jun 2007 10:14:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KEEPBq021727; Wed, 20 Jun 2007 14:14:28 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:14:28 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:14:28 -0400 Message-ID: <46793645.2030108@cisco.com> Date: Wed, 20 Jun 2007 10:14:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Francois Audet Subject: Re: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt References: <0D5F89FAC29E2C41B98A6A762007F5D019E9D2@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3D32@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10EE3D32@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2007 14:14:28.0068 (UTC) FILETIME=[500FDA40:01C7B345] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6275; t=1182348868; x=1183212868; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20RE=3A=20I-D=20ACTION=3Adraft-elwell-bliss-d nd-00.txt |Sender:=20 |To:=20Francois=20Audet=20; bh=c2q202NCGAA6XPqtR7T6sd+9STxK2gsy2UG6Wc6zs+M=; b=Ur9t/mJU8UDHbNLMTeC+PhMGn6seICOgYQKGzbCl946LdKhF9ilG7e60cOEQsdFrz6Xc7Dsh ah65E6H0NhY4Tk5fypOZK+icXKQClsd4gBcVZQ9AcU4aLAt3fxMObHjL; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I agree that this is a good start at addressing the problem. Something you allude to in the requirements, but don't discuss much is this issue of policy control between the UAS and a proxy in the domain of its AOR that may be acting for it. In particular, you are suggesting that the UAS is providing data for the proxy to use in carrying out policies for the user of the UAS. This could be a complex subject. I think it is potentially distinct from communicating reasons from the UAS/Proxy back to the UAC. In particular, there should be no reason for the UAS to lie about it reason for rejection when talking to its own proxy, but good reasons to do so when formulating a response to the UAC. I'm not convinced that we need to be more explicit in responses to the UAC - the existing set seem rich enough to me. The fact that these may be generated in multiple circumstances is a feature, not a limitation. (This is analogous to using sendonly/recvonly/inactive for hold rather than *explicitly* indicating hold.) It may be worth considering if there are needs to communicate more nuances about policy preferences between the UAS and its own proxy. Thanks, Paul Francois Audet wrote: > Hi John, > > Good start, but I think there are things missing in there. > > For example, there is the concept of a "Semi-permanent setting" (i.e., > you change > your status to DND), and there is also dynamic "Do Not Disturb" that you > can do when > an incoming request. > > I believe that the you are focussing strictly on the first one. But it > seems to me > that it should apply to both "DND" (static) and "Decline" (dynamic), > except for the > discussion of presence status. > > I do think that a 480 or 486 are both valid and appropriate in most > cases (when you don't want > to affect the other branches). > > As for the "what do we do with 6XX", my take is that we should do the > following: > - It should only be valid within the scope of the target domain. > - Proxies of the target domain should be able to interpret the 6XX > coming from a UAS as they > see fit. For example, they may decide to treat a 603 as a 486 if they > have a policy to > not allow global rejections. (there are many reasons to do so, not > just voicemail). > > That leaves a good solution for manufacturers: > - An equipment vendor can have a "Busy Here" and "Busy Everywhere" > option, but the > network operator can avoid problems by treating them both as local if > there are > compelling reasons to do it (e.g., forward to operator, voicemail, > pool, etc.). > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Tuesday, June 19, 2007 13:04 >> To: bliss@ietf.org >> Subject: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt >> >> Comments are solicited on this draft, which is a first step >> at trying to pull together some of the discussions relating >> to DND during the last year. >> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: 19 June 2007 20:50 >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-elwell-bliss-dnd-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : An Analysis of Do Not Disturb (DND) >>> Implementations in the Session Initiation Protocol (SIP) >>> Author(s) : J. Elwell, M. Vakil >>> Filename : draft-elwell-bliss-dnd-00.txt >>> Pages : 12 >>> Date : 2007-6-19 >>> >>> Do Not Disturb (DND) is a commonly used expression for >> indicating a >>> condition where a human user of real-time communications does not >>> wish to be interrupted by incoming calls or other forms of >>> communication. This document discusses the nature of >> DND, ways of >>> observing DND, and limitations of and possible >> improvements to DND >>> support in the Session Initiation Protocol (SIP) and the Rich >>> Presence Information Data Format (RPID). >>> >>> This work is being discussed on the bliss@ietf.org mailing list. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-elwell-bliss-dnd-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a >> message to >>> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >>> the message. >>> You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then "get >>> draft-elwell-bliss-dnd-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-elwell-bliss-dnd-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 12:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I133L-0003ch-It; Wed, 20 Jun 2007 12:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I133K-0003cR-2K for bliss@ietf.org; Wed, 20 Jun 2007 12:29:06 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I133J-0007hs-LQ for bliss@ietf.org; Wed, 20 Jun 2007 12:29:06 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5KGT0M18424; Wed, 20 Jun 2007 16:29:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt Date: Wed, 20 Jun 2007 11:28:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10F3AAEF@zrc2hxm0.corp.nortel.com> In-Reply-To: <46793645.2030108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt Thread-Index: AcezRVOQ3xSYF6PISjSdq09dcJmBrwAEg1OQ References: <0D5F89FAC29E2C41B98A6A762007F5D019E9D2@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3D32@zrc2hxm0.corp.nortel.com> <46793645.2030108@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org That's kind of what I am thinking as well. I don't beleive we need "more codepoints", but I think we may need to say more about the policies. Paul, on the "no reason for the UAS to lie about its reason for rejection when talking to its own proxy", I don't think that's the real issue. The issue is that the UAS may be using a reason that goes against the policies of it's proxies. (Misconfiguration, stupid end-user, stupid device manufacturer,=20 etc.). Specically, it could be using 6XX reasons when its proxy has a policy to always provide some alternative treatment (e.g., route to another agent, voicemail, etc). In my mind, it would suffice to explain this in the document.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, June 20, 2007 07:14 > To: Audet, Francois (SC100:3055) > Cc: Elwell, John; bliss@ietf.org > Subject: Re: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt >=20 > I agree that this is a good start at addressing the problem. >=20 > Something you allude to in the requirements, but don't=20 > discuss much is this issue of policy control between the UAS=20 > and a proxy in the domain of its AOR that may be acting for=20 > it. In particular, you are suggesting that the UAS is=20 > providing data for the proxy to use in carrying out policies=20 > for the user of the UAS. This could be a complex subject. >=20 > I think it is potentially distinct from communicating reasons=20 > from the UAS/Proxy back to the UAC. In particular, there=20 > should be no reason for the UAS to lie about it reason for=20 > rejection when talking to its own proxy, but good reasons to=20 > do so when formulating a response to the UAC. >=20 > I'm not convinced that we need to be more explicit in=20 > responses to the UAC - the existing set seem rich enough to=20 > me. The fact that these may be generated in multiple=20 > circumstances is a feature, not a limitation.=20 > (This is analogous to using sendonly/recvonly/inactive for=20 > hold rather than *explicitly* indicating hold.) >=20 > It may be worth considering if there are needs to communicate=20 > more nuances about policy preferences between the UAS and its=20 > own proxy. >=20 > Thanks, > Paul >=20 > Francois Audet wrote: > > Hi John, > >=20 > > Good start, but I think there are things missing in there. > >=20 > > For example, there is the concept of a "Semi-permanent=20 > setting" (i.e.,=20 > > you change your status to DND), and there is also dynamic "Do Not=20 > > Disturb" that you can do when an incoming request. > >=20 > > I believe that the you are focussing strictly on the first=20 > one. But it=20 > > seems to me that it should apply to both "DND" (static) and=20 > "Decline"=20 > > (dynamic), except for the discussion of presence status. > >=20 > > I do think that a 480 or 486 are both valid and appropriate in most=20 > > cases (when you don't want to affect the other branches). > >=20 > > As for the "what do we do with 6XX", my take is that we=20 > should do the > > following: > > - It should only be valid within the scope of the target domain. > > - Proxies of the target domain should be able to interpret the 6XX=20 > > coming from a UAS as they > > see fit. For example, they may decide to treat a 603 as a 486 if=20 > > they have a policy to > > not allow global rejections. (there are many reasons to=20 > do so, not=20 > > just voicemail). > >=20 > > That leaves a good solution for manufacturers: > > - An equipment vendor can have a "Busy Here" and "Busy Everywhere" > > option, but the=20 > > network operator can avoid problems by treating them both=20 > as local=20 > > if there are > > compelling reasons to do it (e.g., forward to operator,=20 > voicemail,=20 > > pool, etc.). > >=20 > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens.com] > >> Sent: Tuesday, June 19, 2007 13:04 > >> To: bliss@ietf.org > >> Subject: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt > >> > >> Comments are solicited on this draft, which is a first=20 > step at trying=20 > >> to pull together some of the discussions relating to DND=20 > during the=20 > >> last year. > >> > >>> -----Original Message----- > >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>> Sent: 19 June 2007 20:50 > >>> To: i-d-announce@ietf.org > >>> Subject: I-D ACTION:draft-elwell-bliss-dnd-00.txt > >>> > >>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >>> directories. > >>> > >>> > >>> Title : An Analysis of Do Not Disturb (DND)=20 > >>> Implementations in the Session Initiation Protocol (SIP) > >>> Author(s) : J. Elwell, M. Vakil > >>> Filename : draft-elwell-bliss-dnd-00.txt > >>> Pages : 12 > >>> Date : 2007-6-19 > >>> =09 > >>> Do Not Disturb (DND) is a commonly used expression for > >> indicating a > >>> condition where a human user of real-time=20 > communications does not > >>> wish to be interrupted by incoming calls or other forms of > >>> communication. This document discusses the nature of > >> DND, ways of > >>> observing DND, and limitations of and possible > >> improvements to DND > >>> support in the Session Initiation Protocol (SIP) and the Rich > >>> Presence Information Data Format (RPID). > >>> > >>> This work is being discussed on the bliss@ietf.org=20 > mailing list. > >>> > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-elwell-bliss-dnd-00.txt > >>> > >>> To remove yourself from the I-D Announcement list, send a > >> message to > >>> i-d-announce-request@ietf.org with the word unsubscribe in > >> the body of > >>> the message. > >>> You can also visit > >>> https://www1.ietf.org/mailman/listinfo/I-D-announce > >>> to change your subscription settings. > >>> > >>> Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > >>> username "anonymous" and a password of your e-mail address. After=20 > >>> logging in, type "cd internet-drafts" and then "get=20 > >>> draft-elwell-bliss-dnd-00.txt". > >>> > >>> A list of Internet-Drafts directories can be found in=20 > >>> http://www.ietf.org/shadow.html or=20 > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >>> Internet-Drafts can also be obtained by e-mail. > >>> > >>> Send a message to: > >>> mailserv@ietf.org. > >>> In the body type: > >>> "FILE /internet-drafts/draft-elwell-bliss-dnd-00.txt". > >>> =09 > >>> NOTE: The mail server at ietf.org can return the document in > >>> MIME-encoded form by using the "mpack" utility. To use this > >>> feature, insert the command "ENCODING mime" before the "FILE" > >>> command. To decode the response(s), you will need "munpack" or > >>> a MIME-compliant mail reader. Different MIME-compliant > >> mail readers > >>> exhibit different behavior, especially when dealing with > >>> "multipart" MIME messages (i.e. documents which have been split > >>> up into multiple messages), so check your local documentation on > >>> how to manipulate these messages. > >>> > >>> Below is the data which will enable a MIME compliant mail reader=20 > >>> implementation to automatically retrieve the ASCII version of the=20 > >>> Internet-Draft. > >>> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 12:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13G8-0001qE-IQ; Wed, 20 Jun 2007 12:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13G7-0001pW-Hq for bliss@ietf.org; Wed, 20 Jun 2007 12:42:19 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13G6-0003tk-8L for bliss@ietf.org; Wed, 20 Jun 2007 12:42:19 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5KGgFO16861; Wed, 20 Jun 2007 16:42:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt Date: Wed, 20 Jun 2007 11:42:14 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10F3AB47@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019EA22@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt Thread-Index: Aceyq2B792I3toSuTtG7yeo0tl8wVwAAXlTwAAYCNCAAFiUzwAAOwDvA References: <0D5F89FAC29E2C41B98A6A762007F5D019E9D2@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3D32@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D019EA22@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Wednesday, June 20, 2007 02:43 > To: Audet, Francois (SC100:3055); bliss@ietf.org > Subject: RE: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt > > > As for the "what do we do with 6XX", my take is that we=20 > should do the > > following: > > - It should only be valid within the scope of the target domain. > [JRE] You mean the domain of the UA that issues the 6xx? So=20 > if I send a request to user1@example1.com and that gets=20 > forwarded to user2@example2.com, then if user2's UA issues a=20 > 6xx it should apply to other destinations in example2.com but=20 > not to other destinations in example1.com? Correct. > Also, would the 6xx then prevent the example2.com proxy from=20 > forwarding to user3@example3.com? I think this depends on it's local policy as per my other email. > [JRE] I am not sure whether the scope of 6xx is something to=20 > be solved just for DND or more generally. In the latter case=20 > it may not fit in this draft. For now, I suggest we document it in your draft and see what the group wants to do with it. You could flag it as OPEN ISSUE. It may be as simple as a clarification or errata to 3261, or it may be something bigger. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 13:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13Ya-000062-7h; Wed, 20 Jun 2007 13:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13YX-0008W3-IZ; Wed, 20 Jun 2007 13:01:21 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13YS-00079u-8L; Wed, 20 Jun 2007 13:01:20 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5KGvgZ3020876; Wed, 20 Jun 2007 11:58:04 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:57:59 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 18:57:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Wed, 20 Jun 2007 18:57:53 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001303F5B@DEEXC1U01.de.lucent.com> In-Reply-To: <46791B8F.60400@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP Thread-Index: AcezNYcw/3fWNUeSR42hj5677eVGvwAEqg1A References: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> <5D1A7985295922448D5550C94DE2918001303CB5@DEEXC1U01.de.lucent.com> <46791B8F.60400@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 20 Jun 2007 16:57:55.0123 (UTC) FILETIME=[2585B030:01C7B35C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.5 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: frank.derks@philips.com, john.elwell@siemenscomms.co.uk, jon.peterson@neustar.biz, "Toleti Danayya Naidu \(naidud\)" , "Muthu ArulMozhi Perumal \(mperumal\)" , Martyn Davies , eric_zimmerer@yahoo.com, subhodeep.sarkar@wipro.com, Rolf.Vautz@Tenovis.com, "ROUSSEAU, OLIVIER \(OLIVIER\)" , bliss@ietf.org, lyndon_ong@yahoo.com, sip-implementors@cs.columbia.edu, "Michael Hammer \(mhammer\)" , mzonoun@nortelnetworks.com, "Faisal Siyavudeen \(fsiyavud\)" , sipping@ietf.org, "MOUROT, PATRICK \(PATRICK\)" , Aparna.Vemuri@qwest.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org No, Merely pointing out that DSS1 (Q.931) and QSIG are definitely not the = same protocol if you need to run the state machine, and that the = limitations of identifying the usage of INFO are being discussed on the = SIP list. Regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, June 20, 2007 1:21 PM > To: DRAGE, Keith (Keith) > Cc: Martyn Davies; Jayesh Sangpal (jsangpal);=20 > frank.derks@philips.com; john.elwell@siemenscomms.co.uk;=20 > jon.peterson@neustar.biz; Toleti Danayya Naidu (naidud);=20 > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; ROUSSEAU,=20 > OLIVIER (OLIVIER); bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; Michael Hammer (mhammer);=20 > mzonoun@nortelnetworks.com; Faisal Siyavudeen (fsiyavud);=20 > sipping@ietf.org; MOUROT, PATRICK (PATRICK); Aparna.Vemuri@qwest.com > Subject: Re: [BLISS] Tunneling of Q931 messages over SIP >=20 > Keith, >=20 > Are you suggesting that any further variants of this sort=20 > *not* use INFO, and instead use some other mechanism? >=20 > Paul >=20 > DRAGE, Keith (Keith) wrote: > >> doesn't need to know what the content is, as long as the two=20 > >> endpoints are running matching protocols. > >=20 > > And therein lies your problem. > >=20 > > The MIME type is there to tell you which protocol is meant=20 > to be run. > >=20 > > The key difference between the two protocols, is that QSIG=20 > runs a state machine at both ends based on the user side=20 > state machine in Q.931. The Q.931 protocol has different user=20 > and network side state machines. > >=20 > > I suggest you also view the current thread on INFO usage in=20 > the SIP WG list in regard to this part of the issue. > >=20 > > Regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: Martyn Davies [mailto:Martyn.Davies@dialogic.com] > >> Sent: Wednesday, June 20, 2007 11:44 AM > >> To: Jayesh Sangpal (jsangpal) > >> Cc: frank.derks@philips.com; DRAGE, Keith (Keith);=20 > >> john.elwell@siemenscomms.co.uk; Michael Hammer (mhammer); Toleti=20 > >> Danayya Naidu (naidud); jon.peterson@neustar.biz; Muthu ArulMozhi=20 > >> Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > >> subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > bliss@ietf.org;=20 > >> lyndon_ong@yahoo.com; sip-implementors@cs.columbia.edu; MOUROT,=20 > >> PATRICK (PATRICK); ROUSSEAU, OLIVIER (OLIVIER);=20 > >> mzonoun@nortelnetworks.com; Faisal Siyavudeen (fsiyavud);=20 > >> sipping@ietf.org; Aparna.Vemuri@qwest.com > >> Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >> > >> > >> As you said, QSig is a superset of Q931, so the=20 > distinction probably=20 > >> doesn't matter in this case. In my direct experience of QSig, the=20 > >> only difference in practice from Q931 is the large number=20 > of FACILITY=20 > >> messages containing Invoke commands, for example in Path=20 > Replacement=20 > >> sequences. > >> > >> It looks from the RFC examples that the complete Q931/QSIG=20 > header is=20 > >> there embedded in any case, so the tunnel itself doesn't=20 > need to know=20 > >> what the content is, as long as the two endpoints are running=20 > >> matching protocols. > >> > >> Regards, Martyn > >> =20 > >> | Martyn Davies, Principal Consultant Dialogic Kings=20 > Chase, 107-123=20 > >> | King St, Maidenhead, SL6 1DP, UK > >> | Tel: +44 1628 641 790 x 210 > >> | Cell: +44 7881 908 381 > >> | Follow Me: +44 7031 911 586 > >> | martyn.davies@dialogic.com > >> | blog: http://www.dialogic.com/drc > >> | blog: http://voipsa.org/blog > >> =20 > >> Company Registration Number 2017909 > >> Registered in England and Wales > >> =20 > >> This e-mail is intended only for the named recipient(s) and may=20 > >> contain information that is privileged, confidential and/or exempt=20 > >> from disclosure under applicable law. No waiver of privilege,=20 > >> confidence or otherwise is intended by virtue of communication via=20 > >> the internet. Any unauthorized use, dissemination or copying is=20 > >> strictly prohibited. If you have received this e-mail in error, or=20 > >> are not named as a recipient, please immediately notify the sender=20 > >> and destroy all copies of this e-mail. > >> =20 > >> =20 > >> -----Original Message----- > >> From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > >> Sent: Thursday, June 14, 2007 2:40 PM > >> To: Jesske, R; bliss@ietf.org; sipping@ietf.org;=20 > >> john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > >> patrick.mourot@sxb.bsf.alcatel.fr; > >> olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer=20 > >> (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > >> Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > >> Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com;=20 > >> mzonoun@nortelnetworks.com;=20 > sip-implementors@cs.columbia.edu; Elwell,=20 > >> John > >> Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen=20 > (fsiyavud);=20 > >> Toleti Danayya Naidu (naidud) > >> Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >> > >> I want tunnel Complete Message and all the messages. > >> > >> -----Original Message----- > >> From: Jesske, R [mailto:R.Jesske@t-com.net] > >> Sent: Thursday, June 14, 2007 6:48 PM > >> To: Jayesh Sangpal (jsangpal); bliss@ietf.org; sipping@ietf.org;=20 > >> john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > >> patrick.mourot@sxb.bsf.alcatel.fr; > >> olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > Michael Hammer=20 > >> (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > >> Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > >> Aparna.Vemuri@qwest.com; lyndon_ong@yahoo.com;=20 > >> mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > >> Subject: AW: [BLISS] Tunneling of Q931 messages over SIP > >> > >> Question is what do you want to tunnel? > >> All Messages? Or only the needed? e.G HLC, LLC? > >> > >> Best Regards > >> > >> Roland > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > >>> Gesendet: Mittwoch, 13. Juni 2007 11:33 > >>> An: bliss@ietf.org; sipping@ietf.org; > >> john.elwell@siemenscomms.co.uk; > >>> frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > >>> olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com; > >> Michael Hammer > >>> (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > >>> Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > >>> Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > >>> mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > >>> Betreff: [BLISS] Tunneling of Q931 messages over SIP > >>> > >>> > >>> Hi experts, > >>> I have a requirement where the 'ISDN Q931 messages' are to > >> be tunneled > >>> across SIP trunk. > >>> RFC 3204 defines a MIME type explicitly for QSIG messages. > >>> (application/qsig). > >>> I have few doubts on that. > >>> 1)Is there any such standard for Q931 messages ? > >>> 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only > >> about QSIG > >>> and not generically about Q931 messages ? > >>> > >>> > >>> Thanks in Advance, > >>> Jayesh > >>> =20 > >>> =20 > >>> > >>> _______________________________________________ > >>> BLISS mailing list > >>> BLISS@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/bliss > >>> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 16:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17Fk-0007Qj-VE; Wed, 20 Jun 2007 16:58:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17Fi-0007QQ-AR; Wed, 20 Jun 2007 16:58:10 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I17Fg-0007J9-JO; Wed, 20 Jun 2007 16:58:10 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJY003D1CWJBF@siemenscomms.co.uk>; Wed, 20 Jun 2007 21:57:56 +0100 (BST) Date: Wed, 20 Jun 2007 21:58:05 +0100 From: "Elwell, John" Subject: RE: [BLISS] Tunneling of Q931 messages over SIP In-reply-to: <2D48FF2CE7A2D74C8FE566B2AEF3295C0136215F@EiconLON.eicon.com> To: Martyn Davies , "DRAGE, Keith (Keith)" , "Jayesh Sangpal (jsangpal)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019EAD5@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP Thread-Index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19ABJ/UiwAAAaozQAAG4zzAAEz9iwA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <2D48FF2CE7A2D74C8FE566B2AEF3295C01362149@EiconLON.eicon.com> <5D1A7985295922448D5550C94DE2918001303CB5@DEEXC1U01.de.lucent.com> <2D48FF2CE7A2D74C8FE566B2AEF3295C0136215F@EiconLON.eicon.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: frank.derks@philips.com, john.elwell@siemenscomms.co.uk, jon.peterson@neustar.biz, "Toleti Danayya Naidu \(naidud\)" , "Muthu ArulMozhi Perumal \(mperumal\)" , eric_zimmerer@yahoo.com, subhodeep.sarkar@wipro.com, Rolf.Vautz@Tenovis.com, "ROUSSEAU, OLIVIER \(OLIVIER\)" , bliss@ietf.org, lyndon_ong@yahoo.com, sip-implementors@cs.columbia.edu, "Michael Hammer \(mhammer\)" , mzonoun@nortelnetworks.com, "Faisal Siyavudeen \(fsiyavud\)" , sipping@ietf.org, "MOUROT, PATRICK \(PATRICK\)" , Aparna.Vemuri@qwest.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org ISO and Ecma QSIG have been identical for many years. There was an early = Ecma version that was not compatible, but that was obsoleted a long, = long time ago. The IANA assignment of MIME type clearly states it is for = the ISO/IEC version, and hence for the recent Ecma version too. When RFC = 3204 was written, no need was seen for a means of identifying the old = Ecma version. Another difference between QSIG and Q.931 is the meaning of the Channel = Identification information element, which in QSIG identifies logical = channels, which do not necessarily correspond to physical timeslots and = whose range is not constrained to the capacity of any single physical = layer. John=20 > -----Original Message----- > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > Sent: 20 June 2007 12:47 > To: DRAGE, Keith (Keith); Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk;=20 > jon.peterson@neustar.biz; Toleti Danayya Naidu (naidud);=20 > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; ROUSSEAU,=20 > OLIVIER (OLIVIER); bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; Michael Hammer (mhammer);=20 > mzonoun@nortelnetworks.com; Faisal Siyavudeen (fsiyavud);=20 > sipping@ietf.org; MOUROT, PATRICK (PATRICK); Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > > The MIME type is there to tell you which protocol is meant=20 > to be run. >=20 > That's true, but in practice it's often difficult to=20 > enumerate all the possible variations in any case. Already=20 > this RFC is too ambiguous as at the very least it should use=20 > 'version' or 'base' to allow you to specify whether it is ISO=20 > or ECMA QSig. This incompatibility of 'two QSigs' is a very=20 > common problem for interconnecting PBXes. In the same way,=20 > you could use the version field to suggest that the protocol=20 > is plain vanilla Q.931. >=20 > They've obviously made a more manful attempt in the RFC's=20 > ISUP section, to enumerate sub-types of ISUP, but again in=20 > practice it won't cover all the ISUPs that are out there. =20 > The problem's just too big. >=20 > Regards, Martyn >=20 > =20 > | Martyn Davies, Principal Consultant > | Dialogic > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > | Tel: +44 1628 641 790 x 210=20 > | Cell: +44 7881 908 381=20 > | Follow Me: +44 7031 911 586=20 > | martyn.davies@dialogic.com > | blog: http://www.dialogic.com/drc > | blog: http://voipsa.org/blog > =20 > Company Registration Number 2017909 > Registered in England and Wales > =20 > This e-mail is intended only for the named recipient(s) and=20 > may contain information that is privileged, confidential=20 > and/or exempt from disclosure under applicable law. No waiver=20 > of privilege, confidence or otherwise is intended by virtue=20 > of communication via the internet. Any unauthorized use,=20 > dissemination or copying is strictly prohibited. If you have=20 > received this e-mail in error, or are not named as a=20 > recipient, please immediately notify the sender and destroy=20 > all copies of this e-mail. > =20 > =20 >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Wednesday, June 20, 2007 11:54 AM > To: Martyn Davies; Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk;=20 > Michael Hammer (mhammer); Toleti Danayya Naidu (naidud);=20 > jon.peterson@neustar.biz; Muthu ArulMozhi Perumal (mperumal);=20 > eric_zimmerer@yahoo.com; subhodeep.sarkar@wipro.com;=20 > Rolf.Vautz@Tenovis.com; bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > > doesn't need to know what the content is, as long as the two=20 > > endpoints are running matching protocols. >=20 > And therein lies your problem. >=20 > The MIME type is there to tell you which protocol is meant to be run. >=20 > The key difference between the two protocols, is that QSIG=20 > runs a state machine at both ends based on the user side=20 > state machine in Q.931. The Q.931 protocol has different user=20 > and network side state machines. >=20 > I suggest you also view the current thread on INFO usage in=20 > the SIP WG list in regard to this part of the issue. >=20 > Regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > > Sent: Wednesday, June 20, 2007 11:44 AM > > To: Jayesh Sangpal (jsangpal) > > Cc: frank.derks@philips.com; DRAGE, Keith (Keith);=20 > > john.elwell@siemenscomms.co.uk; Michael Hammer (mhammer);=20 > > Toleti Danayya Naidu (naidud); jon.peterson@neustar.biz;=20 > > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > bliss@ietf.org; lyndon_ong@yahoo.com;=20 > > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > > Aparna.Vemuri@qwest.com > > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >=20 > >=20 > > As you said, QSig is a superset of Q931, so the distinction=20 > > probably doesn't matter in this case. In my direct=20 > > experience of QSig, the only difference in practice from Q931=20 > > is the large number of FACILITY messages containing Invoke=20 > > commands, for example in Path Replacement sequences. > >=20 > > It looks from the RFC examples that the complete Q931/QSIG=20 > > header is there embedded in any case, so the tunnel itself=20 > > doesn't need to know what the content is, as long as the two=20 > > endpoints are running matching protocols. > >=20 > > Regards, Martyn > > =20 > > | Martyn Davies, Principal Consultant > > | Dialogic > > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > > | Tel: +44 1628 641 790 x 210 > > | Cell: +44 7881 908 381 > > | Follow Me: +44 7031 911 586 > > | martyn.davies@dialogic.com > > | blog: http://www.dialogic.com/drc > > | blog: http://voipsa.org/blog > > =20 > > Company Registration Number 2017909 > > Registered in England and Wales > > =20 > > This e-mail is intended only for the named recipient(s) and=20 > > may contain information that is privileged, confidential=20 > > and/or exempt from disclosure under applicable law. No waiver=20 > > of privilege, confidence or otherwise is intended by virtue=20 > > of communication via the internet. Any unauthorized use,=20 > > dissemination or copying is strictly prohibited. If you have=20 > > received this e-mail in error, or are not named as a=20 > > recipient, please immediately notify the sender and destroy=20 > > all copies of this e-mail. > > =20 > > =20 > > -----Original Message----- > > From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > Sent: Thursday, June 14, 2007 2:40 PM > > To: Jesske, R; bliss@ietf.org; sipping@ietf.org;=20 > > john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > > patrick.mourot@sxb.bsf.alcatel.fr;=20 > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > > sip-implementors@cs.columbia.edu; Elwell, John > > Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen=20 > > (fsiyavud); Toleti Danayya Naidu (naidud) > > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >=20 > > I want tunnel Complete Message and all the messages. > >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: Thursday, June 14, 2007 6:48 PM > > To: Jayesh Sangpal (jsangpal); bliss@ietf.org;=20 > > sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr;=20 > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > > sip-implementors@cs.columbia.edu > > Subject: AW: [BLISS] Tunneling of Q931 messages over SIP > >=20 > > Question is what do you want to tunnel? > > All Messages? Or only the needed? e.G HLC, LLC? > >=20 > > Best Regards > >=20 > > Roland > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > > Gesendet: Mittwoch, 13. Juni 2007 11:33 > > > An: bliss@ietf.org; sipping@ietf.org;=20 > > john.elwell@siemenscomms.co.uk;=20 > > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer=20 > > > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > > > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > > > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > > > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > > > Betreff: [BLISS] Tunneling of Q931 messages over SIP > > >=20 > > >=20 > > > Hi experts, > > > I have a requirement where the 'ISDN Q931 messages' are to=20 > > be tunneled=20 > > > across SIP trunk. > > > RFC 3204 defines a MIME type explicitly for QSIG messages. > > > (application/qsig). > > > I have few doubts on that. > > > 1)Is there any such standard for Q931 messages ? > > > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only=20 > > about QSIG=20 > > > and not generically about Q931 messages ? > > >=20 > > >=20 > > > Thanks in Advance, > > > Jayesh > > > =20 > > > =20 > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 17:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17Yf-0004AX-T7; Wed, 20 Jun 2007 17:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17Ye-0004AS-VJ for bliss@ietf.org; Wed, 20 Jun 2007 17:17:44 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I17Yd-0003Ml-Ds for bliss@ietf.org; Wed, 20 Jun 2007 17:17:44 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5KLHef05006 for ; Wed, 20 Jun 2007 21:17:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Wed, 20 Jun 2007 16:17:32 -0500 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019EAD5@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP thread-index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19ABJ/UiwAAAaozQAAG4zzAAEz9iwAAAoo5w From: "Mary Barnes" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi all, Just a note on the email mechanics of this thread. It's being = cross-posted to both sip-implementors and sipping WG mailing lists. = It's not getting posted on the SIPPING list due to too many recipients = and I'm not authorizing it's being posted for that reason. There is = also at least one dead email address on this list (Mo Zonoun). If folks really think they need input from SIPPING folks that aren't yet = on this BLISS list, then please post a note on SIPPING WG mailing list = with a pointer to this thread. If you think it's more relevant to = SIPPING, then move it that list. But, please remove all the = cross-postings and cc's and keep the discussion on a single list. Thanks, Mary Barnes SIPPING WG co-chair -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: Wednesday, June 20, 2007 3:58 PM To: Martyn Davies; DRAGE, Keith (Keith); Jayesh Sangpal (jsangpal) Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk; = jon.peterson@neustar.biz; Toleti Danayya Naidu (naidud); Muthu ArulMozhi = Perumal (mperumal); eric_zimmerer@yahoo.com; Sarkar, Subhodeep WIPRO = (External:WBNG:3R42); Rolf.Vautz@Tenovis.com; ROUSSEAU, OLIVIER = (OLIVIER); bliss@ietf.org; lyndon_ong@yahoo.com; = sip-implementors@cs.columbia.edu; Michael Hammer (mhammer); = mzonoun@nortelnetworks.com; Faisal Siyavudeen (fsiyavud); = sipping@ietf.org; MOUROT, PATRICK (PATRICK); Aparna.Vemuri@qwest.com Subject: RE: [BLISS] Tunneling of Q931 messages over SIP ISO and Ecma QSIG have been identical for many years. There was an early = Ecma version that was not compatible, but that was obsoleted a long, = long time ago. The IANA assignment of MIME type clearly states it is for = the ISO/IEC version, and hence for the recent Ecma version too. When RFC = 3204 was written, no need was seen for a means of identifying the old = Ecma version. Another difference between QSIG and Q.931 is the meaning of the Channel = Identification information element, which in QSIG identifies logical = channels, which do not necessarily correspond to physical timeslots and = whose range is not constrained to the capacity of any single physical = layer. John=20 > -----Original Message----- > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > Sent: 20 June 2007 12:47 > To: DRAGE, Keith (Keith); Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk;=20 > jon.peterson@neustar.biz; Toleti Danayya Naidu (naidud);=20 > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; ROUSSEAU,=20 > OLIVIER (OLIVIER); bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; Michael Hammer (mhammer);=20 > mzonoun@nortelnetworks.com; Faisal Siyavudeen (fsiyavud);=20 > sipping@ietf.org; MOUROT, PATRICK (PATRICK); Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > > The MIME type is there to tell you which protocol is meant=20 > to be run. >=20 > That's true, but in practice it's often difficult to=20 > enumerate all the possible variations in any case. Already=20 > this RFC is too ambiguous as at the very least it should use=20 > 'version' or 'base' to allow you to specify whether it is ISO=20 > or ECMA QSig. This incompatibility of 'two QSigs' is a very=20 > common problem for interconnecting PBXes. In the same way,=20 > you could use the version field to suggest that the protocol=20 > is plain vanilla Q.931. >=20 > They've obviously made a more manful attempt in the RFC's=20 > ISUP section, to enumerate sub-types of ISUP, but again in=20 > practice it won't cover all the ISUPs that are out there. =20 > The problem's just too big. >=20 > Regards, Martyn >=20 > =20 > | Martyn Davies, Principal Consultant > | Dialogic > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > | Tel: +44 1628 641 790 x 210=20 > | Cell: +44 7881 908 381=20 > | Follow Me: +44 7031 911 586=20 > | martyn.davies@dialogic.com > | blog: http://www.dialogic.com/drc > | blog: http://voipsa.org/blog > =20 > Company Registration Number 2017909 > Registered in England and Wales > =20 > This e-mail is intended only for the named recipient(s) and=20 > may contain information that is privileged, confidential=20 > and/or exempt from disclosure under applicable law. No waiver=20 > of privilege, confidence or otherwise is intended by virtue=20 > of communication via the internet. Any unauthorized use,=20 > dissemination or copying is strictly prohibited. If you have=20 > received this e-mail in error, or are not named as a=20 > recipient, please immediately notify the sender and destroy=20 > all copies of this e-mail. > =20 > =20 >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Wednesday, June 20, 2007 11:54 AM > To: Martyn Davies; Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk;=20 > Michael Hammer (mhammer); Toleti Danayya Naidu (naidud);=20 > jon.peterson@neustar.biz; Muthu ArulMozhi Perumal (mperumal);=20 > eric_zimmerer@yahoo.com; subhodeep.sarkar@wipro.com;=20 > Rolf.Vautz@Tenovis.com; bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > > doesn't need to know what the content is, as long as the two=20 > > endpoints are running matching protocols. >=20 > And therein lies your problem. >=20 > The MIME type is there to tell you which protocol is meant to be run. >=20 > The key difference between the two protocols, is that QSIG=20 > runs a state machine at both ends based on the user side=20 > state machine in Q.931. The Q.931 protocol has different user=20 > and network side state machines. >=20 > I suggest you also view the current thread on INFO usage in=20 > the SIP WG list in regard to this part of the issue. >=20 > Regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > > Sent: Wednesday, June 20, 2007 11:44 AM > > To: Jayesh Sangpal (jsangpal) > > Cc: frank.derks@philips.com; DRAGE, Keith (Keith);=20 > > john.elwell@siemenscomms.co.uk; Michael Hammer (mhammer);=20 > > Toleti Danayya Naidu (naidud); jon.peterson@neustar.biz;=20 > > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > bliss@ietf.org; lyndon_ong@yahoo.com;=20 > > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > > Aparna.Vemuri@qwest.com > > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >=20 > >=20 > > As you said, QSig is a superset of Q931, so the distinction=20 > > probably doesn't matter in this case. In my direct=20 > > experience of QSig, the only difference in practice from Q931=20 > > is the large number of FACILITY messages containing Invoke=20 > > commands, for example in Path Replacement sequences. > >=20 > > It looks from the RFC examples that the complete Q931/QSIG=20 > > header is there embedded in any case, so the tunnel itself=20 > > doesn't need to know what the content is, as long as the two=20 > > endpoints are running matching protocols. > >=20 > > Regards, Martyn > > =20 > > | Martyn Davies, Principal Consultant > > | Dialogic > > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > > | Tel: +44 1628 641 790 x 210 > > | Cell: +44 7881 908 381 > > | Follow Me: +44 7031 911 586 > > | martyn.davies@dialogic.com > > | blog: http://www.dialogic.com/drc > > | blog: http://voipsa.org/blog > > =20 > > Company Registration Number 2017909 > > Registered in England and Wales > > =20 > > This e-mail is intended only for the named recipient(s) and=20 > > may contain information that is privileged, confidential=20 > > and/or exempt from disclosure under applicable law. No waiver=20 > > of privilege, confidence or otherwise is intended by virtue=20 > > of communication via the internet. Any unauthorized use,=20 > > dissemination or copying is strictly prohibited. If you have=20 > > received this e-mail in error, or are not named as a=20 > > recipient, please immediately notify the sender and destroy=20 > > all copies of this e-mail. > > =20 > > =20 > > -----Original Message----- > > From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > Sent: Thursday, June 14, 2007 2:40 PM > > To: Jesske, R; bliss@ietf.org; sipping@ietf.org;=20 > > john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > > patrick.mourot@sxb.bsf.alcatel.fr;=20 > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > > sip-implementors@cs.columbia.edu; Elwell, John > > Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen=20 > > (fsiyavud); Toleti Danayya Naidu (naidud) > > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >=20 > > I want tunnel Complete Message and all the messages. > >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: Thursday, June 14, 2007 6:48 PM > > To: Jayesh Sangpal (jsangpal); bliss@ietf.org;=20 > > sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr;=20 > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > > sip-implementors@cs.columbia.edu > > Subject: AW: [BLISS] Tunneling of Q931 messages over SIP > >=20 > > Question is what do you want to tunnel? > > All Messages? Or only the needed? e.G HLC, LLC? > >=20 > > Best Regards > >=20 > > Roland > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > > Gesendet: Mittwoch, 13. Juni 2007 11:33 > > > An: bliss@ietf.org; sipping@ietf.org;=20 > > john.elwell@siemenscomms.co.uk;=20 > > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer=20 > > > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > > > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > > > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > > > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > > > Betreff: [BLISS] Tunneling of Q931 messages over SIP > > >=20 > > >=20 > > > Hi experts, > > > I have a requirement where the 'ISDN Q931 messages' are to=20 > > be tunneled=20 > > > across SIP trunk. > > > RFC 3204 defines a MIME type explicitly for QSIG messages. > > > (application/qsig). > > > I have few doubts on that. > > > 1)Is there any such standard for Q931 messages ? > > > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only=20 > > about QSIG=20 > > > and not generically about Q931 messages ? > > >=20 > > >=20 > > > Thanks in Advance, > > > Jayesh > > > =20 > > > =20 > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Jun 20 17:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17a2-0004Kx-Dl; Wed, 20 Jun 2007 17:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17a1-0004Jp-2R for bliss@ietf.org; Wed, 20 Jun 2007 17:19:09 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I17a0-0003cB-H7 for bliss@ietf.org; Wed, 20 Jun 2007 17:19:09 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5KLJ6f05553 for ; Wed, 20 Jun 2007 21:19:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Date: Wed, 20 Jun 2007 16:19:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Tunneling of Q931 messages over SIP thread-index: AcetndgmJaMhnFpSToagRsCBlnt2qQA6GB4QAABM19ABJ/UiwAAAaozQAAG4zzAAEz9iwAAAoo5wAABOQVA= From: "Mary Barnes" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Just a note that as I was typing this, John Elwell has moved this thread = to the SIPPING list. Thanks! Mary -----Original Message----- From: Barnes, Mary (RICH2:AR00)=20 Sent: Wednesday, June 20, 2007 4:18 PM To: bliss@ietf.org Subject: RE: [BLISS] Tunneling of Q931 messages over SIP Hi all, Just a note on the email mechanics of this thread. It's being = cross-posted to both sip-implementors and sipping WG mailing lists. = It's not getting posted on the SIPPING list due to too many recipients = and I'm not authorizing it's being posted for that reason. There is = also at least one dead email address on this list (Mo Zonoun). If folks really think they need input from SIPPING folks that aren't yet = on this BLISS list, then please post a note on SIPPING WG mailing list = with a pointer to this thread. If you think it's more relevant to = SIPPING, then move it that list. But, please remove all the = cross-postings and cc's and keep the discussion on a single list. Thanks, Mary Barnes SIPPING WG co-chair -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: Wednesday, June 20, 2007 3:58 PM To: Martyn Davies; DRAGE, Keith (Keith); Jayesh Sangpal (jsangpal) Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk; = jon.peterson@neustar.biz; Toleti Danayya Naidu (naidud); Muthu ArulMozhi = Perumal (mperumal); eric_zimmerer@yahoo.com; Sarkar, Subhodeep WIPRO = (External:WBNG:3R42); Rolf.Vautz@Tenovis.com; ROUSSEAU, OLIVIER = (OLIVIER); bliss@ietf.org; lyndon_ong@yahoo.com; = sip-implementors@cs.columbia.edu; Michael Hammer (mhammer); = mzonoun@nortelnetworks.com; Faisal Siyavudeen (fsiyavud); = sipping@ietf.org; MOUROT, PATRICK (PATRICK); Aparna.Vemuri@qwest.com Subject: RE: [BLISS] Tunneling of Q931 messages over SIP ISO and Ecma QSIG have been identical for many years. There was an early = Ecma version that was not compatible, but that was obsoleted a long, = long time ago. The IANA assignment of MIME type clearly states it is for = the ISO/IEC version, and hence for the recent Ecma version too. When RFC = 3204 was written, no need was seen for a means of identifying the old = Ecma version. Another difference between QSIG and Q.931 is the meaning of the Channel = Identification information element, which in QSIG identifies logical = channels, which do not necessarily correspond to physical timeslots and = whose range is not constrained to the capacity of any single physical = layer. John=20 > -----Original Message----- > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > Sent: 20 June 2007 12:47 > To: DRAGE, Keith (Keith); Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk;=20 > jon.peterson@neustar.biz; Toleti Danayya Naidu (naidud);=20 > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com; ROUSSEAU,=20 > OLIVIER (OLIVIER); bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; Michael Hammer (mhammer);=20 > mzonoun@nortelnetworks.com; Faisal Siyavudeen (fsiyavud);=20 > sipping@ietf.org; MOUROT, PATRICK (PATRICK); Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > > The MIME type is there to tell you which protocol is meant=20 > to be run. >=20 > That's true, but in practice it's often difficult to=20 > enumerate all the possible variations in any case. Already=20 > this RFC is too ambiguous as at the very least it should use=20 > 'version' or 'base' to allow you to specify whether it is ISO=20 > or ECMA QSig. This incompatibility of 'two QSigs' is a very=20 > common problem for interconnecting PBXes. In the same way,=20 > you could use the version field to suggest that the protocol=20 > is plain vanilla Q.931. >=20 > They've obviously made a more manful attempt in the RFC's=20 > ISUP section, to enumerate sub-types of ISUP, but again in=20 > practice it won't cover all the ISUPs that are out there. =20 > The problem's just too big. >=20 > Regards, Martyn >=20 > =20 > | Martyn Davies, Principal Consultant > | Dialogic > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > | Tel: +44 1628 641 790 x 210=20 > | Cell: +44 7881 908 381=20 > | Follow Me: +44 7031 911 586=20 > | martyn.davies@dialogic.com > | blog: http://www.dialogic.com/drc > | blog: http://voipsa.org/blog > =20 > Company Registration Number 2017909 > Registered in England and Wales > =20 > This e-mail is intended only for the named recipient(s) and=20 > may contain information that is privileged, confidential=20 > and/or exempt from disclosure under applicable law. No waiver=20 > of privilege, confidence or otherwise is intended by virtue=20 > of communication via the internet. Any unauthorized use,=20 > dissemination or copying is strictly prohibited. If you have=20 > received this e-mail in error, or are not named as a=20 > recipient, please immediately notify the sender and destroy=20 > all copies of this e-mail. > =20 > =20 >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Wednesday, June 20, 2007 11:54 AM > To: Martyn Davies; Jayesh Sangpal (jsangpal) > Cc: frank.derks@philips.com; john.elwell@siemenscomms.co.uk;=20 > Michael Hammer (mhammer); Toleti Danayya Naidu (naidud);=20 > jon.peterson@neustar.biz; Muthu ArulMozhi Perumal (mperumal);=20 > eric_zimmerer@yahoo.com; subhodeep.sarkar@wipro.com;=20 > Rolf.Vautz@Tenovis.com; bliss@ietf.org; lyndon_ong@yahoo.com;=20 > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > Aparna.Vemuri@qwest.com > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP >=20 > > doesn't need to know what the content is, as long as the two=20 > > endpoints are running matching protocols. >=20 > And therein lies your problem. >=20 > The MIME type is there to tell you which protocol is meant to be run. >=20 > The key difference between the two protocols, is that QSIG=20 > runs a state machine at both ends based on the user side=20 > state machine in Q.931. The Q.931 protocol has different user=20 > and network side state machines. >=20 > I suggest you also view the current thread on INFO usage in=20 > the SIP WG list in regard to this part of the issue. >=20 > Regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Martyn Davies [mailto:Martyn.Davies@dialogic.com]=20 > > Sent: Wednesday, June 20, 2007 11:44 AM > > To: Jayesh Sangpal (jsangpal) > > Cc: frank.derks@philips.com; DRAGE, Keith (Keith);=20 > > john.elwell@siemenscomms.co.uk; Michael Hammer (mhammer);=20 > > Toleti Danayya Naidu (naidud); jon.peterson@neustar.biz;=20 > > Muthu ArulMozhi Perumal (mperumal); eric_zimmerer@yahoo.com;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > bliss@ietf.org; lyndon_ong@yahoo.com;=20 > > sip-implementors@cs.columbia.edu; MOUROT, PATRICK (PATRICK);=20 > > ROUSSEAU, OLIVIER (OLIVIER); mzonoun@nortelnetworks.com;=20 > > Faisal Siyavudeen (fsiyavud); sipping@ietf.org;=20 > > Aparna.Vemuri@qwest.com > > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >=20 > >=20 > > As you said, QSig is a superset of Q931, so the distinction=20 > > probably doesn't matter in this case. In my direct=20 > > experience of QSig, the only difference in practice from Q931=20 > > is the large number of FACILITY messages containing Invoke=20 > > commands, for example in Path Replacement sequences. > >=20 > > It looks from the RFC examples that the complete Q931/QSIG=20 > > header is there embedded in any case, so the tunnel itself=20 > > doesn't need to know what the content is, as long as the two=20 > > endpoints are running matching protocols. > >=20 > > Regards, Martyn > > =20 > > | Martyn Davies, Principal Consultant > > | Dialogic > > | Kings Chase, 107-123 King St, Maidenhead, SL6 1DP, UK > > | Tel: +44 1628 641 790 x 210 > > | Cell: +44 7881 908 381 > > | Follow Me: +44 7031 911 586 > > | martyn.davies@dialogic.com > > | blog: http://www.dialogic.com/drc > > | blog: http://voipsa.org/blog > > =20 > > Company Registration Number 2017909 > > Registered in England and Wales > > =20 > > This e-mail is intended only for the named recipient(s) and=20 > > may contain information that is privileged, confidential=20 > > and/or exempt from disclosure under applicable law. No waiver=20 > > of privilege, confidence or otherwise is intended by virtue=20 > > of communication via the internet. Any unauthorized use,=20 > > dissemination or copying is strictly prohibited. If you have=20 > > received this e-mail in error, or are not named as a=20 > > recipient, please immediately notify the sender and destroy=20 > > all copies of this e-mail. > > =20 > > =20 > > -----Original Message----- > > From: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > Sent: Thursday, June 14, 2007 2:40 PM > > To: Jesske, R; bliss@ietf.org; sipping@ietf.org;=20 > > john.elwell@siemenscomms.co.uk; frank.derks@philips.com;=20 > > patrick.mourot@sxb.bsf.alcatel.fr;=20 > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > > sip-implementors@cs.columbia.edu; Elwell, John > > Cc: Muthu ArulMozhi Perumal (mperumal); Faisal Siyavudeen=20 > > (fsiyavud); Toleti Danayya Naidu (naidud) > > Subject: RE: [BLISS] Tunneling of Q931 messages over SIP > >=20 > > I want tunnel Complete Message and all the messages. > >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: Thursday, June 14, 2007 6:48 PM > > To: Jayesh Sangpal (jsangpal); bliss@ietf.org;=20 > > sipping@ietf.org; john.elwell@siemenscomms.co.uk;=20 > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr;=20 > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer (mhammer); jon.peterson@neustar.biz;=20 > > subhodeep.sarkar@wipro.com; Rolf.Vautz@Tenovis.com;=20 > > eric_zimmerer@yahoo.com; Aparna.Vemuri@qwest.com;=20 > > lyndon_ong@yahoo.com; mzonoun@nortelnetworks.com;=20 > > sip-implementors@cs.columbia.edu > > Subject: AW: [BLISS] Tunneling of Q931 messages over SIP > >=20 > > Question is what do you want to tunnel? > > All Messages? Or only the needed? e.G HLC, LLC? > >=20 > > Best Regards > >=20 > > Roland > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Jayesh Sangpal (jsangpal) [mailto:jsangpal@cisco.com] > > > Gesendet: Mittwoch, 13. Juni 2007 11:33 > > > An: bliss@ietf.org; sipping@ietf.org;=20 > > john.elwell@siemenscomms.co.uk;=20 > > > frank.derks@philips.com; patrick.mourot@sxb.bsf.alcatel.fr; > > > olivier.rousseau@col.bsf.alcatel.fr; drage@lucent.com;=20 > > Michael Hammer=20 > > > (mhammer); jon.peterson@neustar.biz; subhodeep.sarkar@wipro.com;=20 > > > Rolf.Vautz@Tenovis.com; eric_zimmerer@yahoo.com;=20 > > > Aparna.Vemuri@Qwest.com; lyndon_ong@yahoo.com;=20 > > > mzonoun@nortelnetworks.com; sip-implementors@cs.columbia.edu > > > Betreff: [BLISS] Tunneling of Q931 messages over SIP > > >=20 > > >=20 > > > Hi experts, > > > I have a requirement where the 'ISDN Q931 messages' are to=20 > > be tunneled=20 > > > across SIP trunk. > > > RFC 3204 defines a MIME type explicitly for QSIG messages. > > > (application/qsig). > > > I have few doubts on that. > > > 1)Is there any such standard for Q931 messages ? > > > 2)As QSIG is a subtype of Q931, why RFC 3204 mentions only=20 > > about QSIG=20 > > > and not generically about Q931 messages ? > > >=20 > > >=20 > > > Thanks in Advance, > > > Jayesh > > > =20 > > > =20 > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Jun 26 17:40:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ImE-0003Og-Lh; Tue, 26 Jun 2007 17:40:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3GyH-0002ow-VO; Tue, 26 Jun 2007 15:45:06 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3GyH-00054Q-LR; Tue, 26 Jun 2007 15:45:05 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 47217175D1; Tue, 26 Jun 2007 19:44:35 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1I3Gxm-0001Ob-Sj; Tue, 26 Jun 2007 15:44:34 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 26 Jun 2007 15:44:34 -0400 X-Spam-Score: 0.6 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff X-Mailman-Approved-At: Tue, 26 Jun 2007 17:40:46 -0400 Cc: bliss@ietf.org Subject: [BLISS] WG Action: Basic Level of Interoperability for SIP Services (bliss) X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Basic Level of Interoperability for SIP Services (bliss) ========================================================= Current Status: Active Working Group Chair(s): Jason Fischl Shida Schubert Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Jonathan Rosenberg Mailing Lists: General Discussion: bliss@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/bliss Archive: http://www1.ietf.org/mail-archive/web/bliss/current/index.html Description of Working Group: The focus of the group is to facilitate effective feature interoperability for features sharing common functional primitives utilizing SIP in heterogeneous network environments as noted below. SIP's approach to supporting more advanced features and applications has been to specify a number of primitive operations, including refer, dialog replacement and joining, and event packages, and then to allow those primitives to be combined in many ways to realize different features. This approach avoids the need for standardized definitions of a feature, which can severely limit innovation and broad applicability. While this approach brings great flexibility and generality, it complicates interoperability. Without any kind of standardized definition of a particular feature, each implementation creates its own definition and corresponding set of call flows and primitives used to realize this feature. In practice, this has resulted in a poor track record for interoperability for more advanced features which make assumptions on supported SIP extensions and behaviors from other elements. The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks including non-centralized environments, and for the desire to work across domain boundaries and to interwork with the PSTN, when applicable. The focus will not be on rigorous definition of what the specific feature is and exactly how it works. Rather, the focus will be on documenting the variations that exist in the wild sharing common interop problems, figuring out a minimum baseline requirement for a UA and servers (minimum set of primitives etc.), defining minimum levels of functionality and functional primitives required to realize a broad class of related features, and on interoperating with other elements which might implement one of those features in different ways. The BLISS working group will coordinate closely with the SIP and SIPPING working groups. Like SIPPING, its role is to focus on applications of the SIP protocol and not on core extensions to SIP itself. The difference between SIPPING and BLISS, is that BLISS is focused on a particular type of SIP application - call features, and in particular, advanced call features requiring non-trivial call control. SIP applications such as configuration, presence, SIP extensions for IM, and session policy are clearly out of scope for BLISS and remain the sole province of SIPPING. Of course, any features considered by BLISS will support the full range of multimedia supported by SIP - audio, video, text, messaging, and so on. The BLISS working group will focus on resolving interpretability issues on four functional primitives as an initial milestone. Summary for each of the functional primitives are as follows. A "Problem Statement" document will also be charted as the first deliverable of this working group. This document will describe the problem this working group is trying to address, the criteria to be met for items to be accepted and a template for documenting a draft for this working group. Line Sharing Description: this covers the functionality required for multiple UA instances to be able to see and utilize sessions made to/from either one. It covers a range of features including: * multiple call appearances * call suspend/resume * retrieve * conference across appearances Parking Description: this covers functionality required to move calls from one instance to another without pre-arranged knowledge of the set of instances on which the call is to be shared. Basically a dynamic version of line sharing in a sense. It would cover features including: * park * parked retrieval * directed park * directed pickup Automated Handling Description: this covers functionality required for a user to indicate, asynchronously from the time of a call, what the handling of a future call should be. It covers the rules on who implements the processing and how it is signaled. Covers features including: * DND * CFU * CFNA Call Queuing Description: this covers functionality required to queue a call when the callee is not available, handling of a queue and notifying when callee is ready to receive a call. Covers features including: * CCBS * CCNR Guiding principles for this working group work will include: - Identify functional primitives with interoperability issues, based on an analysis of variations of features sharing same or similar functional primitives within heterogeneous network(s). Provide a clear description of any interoperability problems that are identified by documenting the variations that exist in the wild for features that is already implemented. - Document minimum baseline requirements relevant to the functional requirements for addressing the interoperability issue. Criteria to consider: * who is responsible for invoking? * who is responsible for implementing? * how does the functional primitive interact with multiple media types? * how does the functional primitive work between administrative domains? - Initiate analysis of the pros and cons of key approaches to addressing the requirements. - Where the requirements can be satisfied within the capabilities of the current standards, produce BCPs [and appropriate call-flows] to document the best approach. - Where normal event packages or SIP uri parameter is all what's needed to prevent interoperability issues, appropriate extensions and its usage would be defined and documented. - Where extensions to standards are required beyond what's mentioned above, bring the analysis, requirements and need for new extensions to the appropriate working group (SIP, SIPPING or SIMPLE). - As in the SIPPING charter, the security of all the deliverables will be of special importance. *Deliverable may attempt to... 1. Define a single approach to solve the problem. 2. Allow variations but mandate support for more than one mechanism. 3. Demonstrate that interoperability is possible even when entities provide the feature with the functional primitive differently. Goals and Milestones: Aug 2007 Submit Problem Statement to the IESG as Informational RFC Dec 2007 Submit Line Sharing to the IESG as BCP Apr 2008 Submit Parking to the IESG as BCP Apr 2008 Submit Automated Handling to the IESG as BCP Aug 2008 Submit Call Queing to the IESG as BCP _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss