From iptel-bounces@ietf.org Wed Jan 11 11:05:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiTw-00073o-GB; Wed, 11 Jan 2006 11:05:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiTu-00073X-PM for iptel@megatron.ietf.org; Wed, 11 Jan 2006 11:05:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22529 for ; Wed, 11 Jan 2006 11:04:31 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewiaq-0007Of-Pw for iptel@ietf.org; Wed, 11 Jan 2006 11:13:01 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp8.clb.oleane.net with ESMTP id k0BG5KGj015053 for ; Wed, 11 Jan 2006 17:05:36 +0100 Message-Id: <200601111605.k0BG5KGj015053@smtp8.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 11 Jan 2006 17:04:34 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYWyLbIy7TFo+9pSDWgYCTzFLydKg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [Iptel] International SIP Conference / WiMAX Summit 2006 - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0658176258==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0658176258== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0319_01C616D1.18E9CFB0" This is a multi-part message in MIME format. ------=_NextPart_000_0319_01C616D1.18E9CFB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The International SIP conference and the WiMAX Summit will start next February 21st in Paris. The two events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access. The early registration 10% discount will end in one week. Get all details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get all details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0319_01C616D1.18E9CFB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = International SIP conference and the WiMAX Summit will start next February 21st in = Paris. The two = events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access.

The early registration 10% discount will end = in one week.

Get all details on International SIP = at:

http://www.upp= erside.fr/sip2006/sip2006intro.htm

Get all details on the WiMAX Summit = at:

http://www= .upperside.fr/wimax2006/wimax2006intro.htm

------=_NextPart_000_0319_01C616D1.18E9CFB0-- --===============0658176258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0658176258==-- From iptel-bounces@ietf.org Tue Jan 17 04:01:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eymif-0003Zn-G8; Tue, 17 Jan 2006 04:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eymid-0003Za-VK for iptel@megatron.ietf.org; Tue, 17 Jan 2006 04:01:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28547 for ; Tue, 17 Jan 2006 04:00:10 -0500 (EST) Received: from uproxy.gmail.com ([66.249.92.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eymqi-0005Sv-UJ for iptel@ietf.org; Tue, 17 Jan 2006 04:09:58 -0500 Received: by uproxy.gmail.com with SMTP id o2so176391uge for ; Tue, 17 Jan 2006 01:01:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ufw2rDpBoKd5IetTpkHTMfVUXDuPwsVqiAqLLp0+/nI9EJLhh6Z6I3bqwuRVLRN7FCSaiBX7JxesYoTIBJuTCYd5dRzuqhfpZrv9FwjTyo1/BiyODciyYRkDf91jRdIWELHNWrKTlfUXE+qnSN9DOtEVUJPEOh7ySzXV/ZVz4qc= Received: by 10.49.56.5 with SMTP id i5mr297530nfk; Tue, 17 Jan 2006 01:01:31 -0800 (PST) Received: by 10.48.243.11 with HTTP; Tue, 17 Jan 2006 01:01:31 -0800 (PST) Message-ID: <876aa5be0601170101m5ed5e216j@mail.gmail.com> Date: Tue, 17 Jan 2006 14:31:31 +0530 From: parveen jain To: iptel@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.7 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Iptel] Questions regarding tel URI X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1018714420==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org --===============1018714420== Content-Type: multipart/alternative; boundary="----=_Part_8461_8471438.1137488491769" ------=_Part_8461_8471438.1137488491769 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I have some question regarding the role of proxy/Registrar in case they receives a request containing URI . Is it possible to get the URI in messages other then INVITE and REGISTER or in responses of any type? 1. From RFC 3261 it has been mentioned that URI could be present in REQUEST URI , FROM and TO header, and only for REGISTER metho= d it could be in CONTACT header. Is it possible to get it in any other header except from these? 2. Is it alright from implementation point of view to register the URI's just like sip URI . 3. if the answer of previous question is yes, then if we are storing only URI of a sip-phone/ PSTN-gateway , how is it possible to map URI to sip uri if the proxy have no prior information about sip U= RI of that endpoint . in my opinion the sip-phone/PSTN-gateway must have to register there sip URI's with DNS by any other mean and proxy can contact that DNS for any mapping using ENUM, please correct me if I am wrong ? any help regarding the same will be highly appreciated .Please excuse if I had not formed my question's well. Thanks & Regards, Parveen ------=_Part_8461_8471438.1137488491769 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,

= I have some question regarding the role of proxy/= Registrar in case they receives a request containing <tel:> URI .

= Is it possible = to get the <tel:> URI in messages other then INVITE and REGISTER or in responses of any type?

From RFC 3261 it h= as been mentioned that <tel:> URI could be present in REQUEST URI , FROM= and TO header, and only for REGISTER method it could be in CONTACT header.= Is it possible to get it in any other header except from these?

Is it alright from implementation point of view to register the <tel:> URI's just l= ike sip URI .

if the answer of previous question is yes, then if we are storing only <tel:> URI of a sip-phone/ P= STN-gateway , how is it possible to map <tel:> URI to sip uri if the proxy h= ave no prior information about sip URI of that endpoint .

in my opinion the sip-phone/PSTN-gateway must have to register there sip URI's with DNS by any other mean and proxy can contact t= hat DNS for any mapping using ENUM, please correct me if I am wrong ?

any help regarding the same will be highly appreciated .Please excuse if I had not formed my question's well.

Thanks & Regards,

Parveen

------=_Part_8461_8471438.1137488491769-- --===============1018714420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1018714420==-- From iptel-bounces@ietf.org Fri Jan 20 04:00:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezs8D-0007oh-00; Fri, 20 Jan 2006 04:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezs8A-0007nT-BS for iptel@megatron.ietf.org; Fri, 20 Jan 2006 04:00:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23232 for ; Fri, 20 Jan 2006 03:58:59 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzsGr-00043N-8S for iptel@ietf.org; Fri, 20 Jan 2006 04:09:26 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2006 01:00:16 -0800 X-IronPort-AV: i="4.01,203,1136188800"; d="scan'208"; a="1768449461:sNHT31183536" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0K8xec1019292; Fri, 20 Jan 2006 01:00:15 -0800 (PST) Received: from 10.21.148.18 ([10.21.148.18]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 08:59:04 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 00:59:04 -0800 From: Cullen Jennings To: Cullen Jennings , Richard Shockey , Stastny Richard , Lawrence Conroy Message-ID: Thread-Topic: iptel-tel-enumdi-03 Thread-Index: AcYAXi94bh5KnWxREdq0TwARJEEJ/AdQZPR1 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" Subject: [Iptel] iptel-tel-enumdi-03 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Thanks for making the changes from the NITS review. I think there is still some problems with the boiler plate. I get draft-ietf-iptel-tel-enumdi-03.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.4 Copyright Line -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. Can you see if this is a mistake in the checking or just submit a version that fixes it. There is no significant changes in this draft since the version that WGLC so I see no need for another WGLC. If you call me on my mobile at tel:+14084219990;enumdi I will deal with this draft the same day you submit it. Thanks, Cullen _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Jan 20 04:00:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezs8Q-0007sE-Ef; Fri, 20 Jan 2006 04:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezs8O-0007rQ-ES for iptel@megatron.ietf.org; Fri, 20 Jan 2006 04:00:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23249 for ; Fri, 20 Jan 2006 03:59:13 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzsH6-00043o-AE for iptel@ietf.org; Fri, 20 Jan 2006 04:09:40 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2006 01:00:31 -0800 X-IronPort-AV: i="4.01,203,1136188800"; d="scan'208"; a="1768449534:sNHT30991016" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0K8xec3019292; Fri, 20 Jan 2006 01:00:31 -0800 (PST) Received: from 10.21.148.18 ([10.21.148.18]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 08:59:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 00:59:16 -0800 Subject: Re: [Iptel] Sending draft-ietf-iptel-tel-np to IESG From: Cullen Jennings To: James Yu Message-ID: Thread-Topic: [Iptel] Sending draft-ietf-iptel-tel-np to IESG Thread-Index: AcYAUIxtywBEx2xDEdqNnQARJEEJ/AFZGAuwBfq3dU8= In-Reply-To: <165FCC93A820D240A62F98E028CEFED005DF2076@stntexch01.cis.neustar.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Hi James, Thanks for getting all the SHALL -> MUST changes done. There seem to be some problem with the boiler plates and some strange characters left over from word. idnits 1.73 (17 Jun 2005) draft-ietf-iptel-tel-np-08.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.4 Copyright Line -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? * There are 15 instances of lines with non-ascii characters in the document. Can you submit a version that fixes these up. There has been no significant change to the draft since the issues that came up during WGLC so I see no reason to do another WGLC. Thanks, Cullen On 12/20/05 2:35 PM, "Yu, James" wrote: > Cullen, > > I just submitted -08 version. > > This is to inform the list that the title of the I-D has changed. Any > future reference to this document should reflect the new title in > addition to the new version # and new date. > > James > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, December 13, 2005 8:49 PM > To: Alexander Mayrhofer; iptel@ietf.org; Yu, James > Cc: Rich Shockey > Subject: Re: [Iptel] Sending draft-ietf-iptel-tel-np to IESG > > > Alex thanks for the detail review. > > James, any idea when we could have a rev that addressed these and > Vijay's > comments? I would really really like to have this sent to the AD before > the > holidays. > > Thanks, Cullen. > > > PS - I agree that SHALL or MUST is left to your discretion - I'm happy > either way. I will note that the MAY/SHOULD/MUST are used the most and > many > people seem more familiar with those. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Jan 20 06:56:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezusy-0007hj-87; Fri, 20 Jan 2006 06:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezusw-0007hY-6h for iptel@megatron.ietf.org; Fri, 20 Jan 2006 06:56:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05109 for ; Fri, 20 Jan 2006 06:55:25 -0500 (EST) Received: from smtp4.clb.oleane.net ([213.56.31.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezv1e-00010D-72 for iptel@ietf.org; Fri, 20 Jan 2006 07:05:55 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp4.clb.oleane.net with ESMTP id k0KBubsO024030 for ; Fri, 20 Jan 2006 12:56:37 +0100 Message-Id: <200601201156.k0KBubsO024030@smtp4.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 20 Jan 2006 12:55:26 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYduGbF8xhSVLz7Sj6zqUl8bXqwxQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [Iptel] WiMAX Summit - International SIP conference - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0185022505==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0185022505== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0129_01C61DC0.C91B1740" This is a multi-part message in MIME format. ------=_NextPart_000_0129_01C61DC0.C91B1740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WiMAX Summit and the International SIP conference will jointly open their doors in one month, on February 21st, in Paris. Everything you must know about broadband wireless access, VoIP and convergence will be delivered by operators and key technical players. An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their solutions. Get details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0129_01C61DC0.C91B1740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WiMAX Summit and the International SIP = conference will jointly open their doors in one month, on February 21st, in = Paris.

Everything you must know about broadband = wireless access, VoIP and convergence will be delivered by operators and key = technical players.

An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their = solutions.

Get details on International SIP = at:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

Get details on the WiMAX Summit = at:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

Hi,

Currently, my application is adapted to RFC 2806. = Since there are a few conflicts between the two RFCs, I was hoping that = someone else has attempted to support both RFCs. If so, can you give me a few = suggestions as how you solved the conflicts.

Thanks,

Nadav = Golombick

Software Engineer

Tel: &n= bsp; +972 3 7666421

Fax: = +972 3 6474681

Email: = nadavg@radcom.com

www.radcom.com<= /a>

www.protocols.com

Come see us at 3GSM, = Barcelona.

13–16 February 2006, Booth = C45.

"The 3G = future is already visible."

------_=_NextPart_002_01C62183.7197C63A-- ------_=_NextPart_001_01C62183.7197C63A Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif Content-Transfer-Encoding: base64 R0lGODlhjgA2AHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAX AAAAC21zT1BNU09GRklDRTkuMEI8pPUALAAAAACOADYAhxQTEyYnKDU2OBwcHHAsJm1vcFZXWUZF RpEuJrYuKrExKcguKdUsJtk2KMc4LLBEMddIMqByZ9ZoUqyFed6JdaeutLGYkeOrmbW6wL/Ey8TL 09bc49zi5+To7O3w8vL09v////3+/vr7+/f4+Prs5u7OwszT2ouMjwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAj/AEEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmy5EMRJEqoXMmy pcuXMFuSEGGypsQRJShQkMCzp86fQIMK1dmzqNGeF0bYXLqQxE4HC6IuSEC1KlWpDLIyaMAVgtev XBtozSrV6oMHEkgwXVtwBAUIDKROtVoV69iwX8GKHSuXbgIHFJSyZVtCAtmyfhPY1Yo3b9ixcRHT dVCC5mCmFMRKzcv564K7DYqC7cxZwWTAHiwTDNHBRAYMGj4oHOEaQwYOIQyK2MB7gwnVAz301tDh owjDkReUIMG8uXMSyLOGJjFiBHSvDZY/d17YqgMHEkx8/8g9cMMJAwICBBBg4ETxthkKHEgf4EAB DeQFisBgYH4B4AJt0N8BBnDw0QjISUXBBbl50FJuJXwmHYOpgfAWVxRYIJuDK2lgIAkPUPWdAw9g 0IFlIWRggHoGFFCAAAMMcEAF74HwwQkHyOjiigMIUEF+IHAgAAAAGBACkCCYMCQABRyJJEYIJreA Ag+I4IEBBCCgJQIMlpCAdNmBcEEJIJTgAFcLIKBWBFlqScADJIQwgWkjPlDBBiPkpoEBAxhgggcd cGDCCTAOUIFAIxDqYweAbhDfAAH8OJCQMQYQm2ohnBDAAEx28IEIT1oUZV8SiGBClgqYlgAFIpSg gHQSKP8VAQUhcHCmWA3M9ICqqSpwAQhzjkhiBbGF4EEBfXLQWgbMZlBBfRyAmsEBAWAgnAbNYlAA AAJsQB6lBwBwAgeC2bhiuAZosMF4HI0aFVWlmoDAVVGV6upWDdD6AVojHLdXriI8IBkFwCowIgR2 auBBCBikl4GjtmWgAbYFVGBCBx0g615tEmNbwZAn5BkkjMgeIB55GwhAYJ8YnNyuBH0lEO+8itXb 6qtc/ZoBAhCQOQFjug5c8HdeJZwasgZA7CGjgb4GWwYOm2DbxR40um23NFFKaLULgxCCBQGcgHTL 5WqEYMwz07uAvThDoNYED0DA4AUSAizwXFQRHKwDRRP/C6gB4moAWwd5Hmmla4PWt4Ft64Iagggj ZLBpBQtrzee4NH1QQLVjm1B2Rme/Cy9KDwgrdwgXKMBVrCOUDkGsZkoXNN6rDs03wn4raaht5OZ3 pAfKIntfy10PxFq4446g9Ql9ijfyARt0/jmUMIsuM03btTpvziGUwLNX1D0ge8B+6W3wV0ZLHils xRsP+ZUDnGDbiQaNAHgB4mn9bAAZLPzsCSbgkwHI1pHQWaVUIOCQSpRSGHyRiQQW+IlSkGO38g0N fX7DgHoqgAE8HeRIHUAe+54kAqRlIFAwkt/lOKC5aqmIZZ4rYPUOCLkCbAkBEVCLmRrgNoTQbSu6 suCc//JiNA1G6oQAIkgIxUVA3ZiQA1rLwAmKtAEOzMdR0pOh9a5HAgSY5l1dUh2rytSs5ZTpS3ZT VVXMR0S/qa8CJwyVQD5wvw5Oz0bC62AUJScADTwLf48aYAxfRjsuIiAqWqGVqxrAoIDdcAKkY4AD dKXGvAErbhhUmAY2dQKFydFr2xrgBpIIghDGr4Mpi18GTJAjsRmKYjC8o6hgRpdSdRGRWVGkAnpW JgR8JypuCwHMJhmwStYObm1UWAeGdJ/2HYR5AuggKVPJQROk8gS3YZ58BOAaDWTxZX6x5SHHosse WmCXXMmKWiywAGLuii6/msDtINAAo4VgWwfo35P+JP8QDcToBB4sSAielU9UpvA2/tyUn1b5zY0g qHwoGWciu/eAMUbgVnshUwniFqcIVDItIbgoWOxZgX/SbzUnCJm5ijRIJV4OAxiA4kGVFa74YSt6 sSwgBOAZp1uSMwQfMOMHfJnOXB5pOblJCUvitAFffoUB9rwStzIAnBAEMH5HwsA/nXmj+gjuhFEk 17ZcSJyGakQEO7VKCTDmKgnl8jkWQMBjstIzjNn1rnYtQQS+R0+o+i2rAQDAAawVghF0gD89qkCe NAep5AHVPOppGfHCuh/BwlQ8ZtWIBOjygC29ijEIO8tZtrcXsoz2hqhFQJYcs4AI/BWoHwNAAFpU APT/DAB/VfwUB5ClIxflKJoceA2eKNuBsMFRrDntyAXo0isFuBVfDvjLiOaqlSk117O9SoBjGKAA C/wVBCLoQAVetCkW0chRxBHBBwZFrfIKAH8dEJzCEiWA98YUcifgYP/2pDKLydIi0ElVXXDJGB5y pqh82WJVDuaYBLiWWOx6rLMqwEHiLGtwIgiv4Ch8XOB9tXcePi6oPCA18XygNZf9b0VCsAGPqmox +DKwY0p7GAWLiGhfcYACHtwydnmNxK/pGLZgSpzCadg2E5tYkNeVm8JygHc0EQEHPKQU1gjOZRwB qgYmEAHRevnLYA6zmMf8gAhMgMP3JYh6p+w0JG+A/3DkKWwHNjBkmK6ShXFW3sToZyxG0YQ1rmGy R6Q8YQsY+tCITrSiF83oRHOYwsRDUmGB1xtlfQpIjzsxB3rjZ99ZCWOf8hrkQOU1w3baIxJ+tKpX zepWu5rVLTupQB8HuX4dCSGGq06Gn2Q4xwnESb+m9a0/AlRBtRmmyE62spfN7GYnW2IbSM0nLzOS TAdq073Jtra3ze1uaxuKHigctS9D6wyb+9zoTre6163uYY/73fCOt7wxDRKgesDHDqG3vDFSAe+m VAO/rs4I8F1YcRdc4Aj5QAX6Y4AKoEjg/TpIBrxrgfwGPE+Qi3OtI44QD1TAPWoWeJ4h7pHarmeA Af8SW23fo3AXORwEiXJRAU7wwY9VLEcZyA0HVF4AAxnEAuiZLc1tdAILDPQEltmtzDeA649FiiDe dJEFECXzmX/EA2HTdQg2mVIMjIdh7+Wg4TCgKQvgx1jYko0I+vOByAXgP1YVQH4JS5vbGE8+urZS i7RlpNxsIGz57Vp88UP18xyA1CD42McDkBsRjNdQOZ+2RFjzdt54SnIHgF7bWYye90qbYQFYV7+g xk2vocea/yOcCdZzAA1Ux4py/3UJoVfFqs2HWgbY9d8JFJs8EeoAKHsvnzLArpL6x9YDHcC9bb2R Wr0d2h7IwG3FdrERaAtH0JO2Bh/Ggc876VnsqS//8TaJSmUVzkmFRQ+z/hRC98gHY6aafifhjP5M +UhTBaDfs1Y/LmmX1JrdR0oUwRretUqEwwEVJzZFxgEfJz8XAyqDwizRBiofUDUZFh/tYQKuAUVw NDFvlicjUDUg+HESw0IeRywfpy4fgIAphU1wpl7Lx0EeoAEpxWQmYDEp9TDjEYEPUyEcIWXqIjK7 IYHSpmcT0zvGYgLp9TjCwUJWcoTLgifKA30UuGkVAmguY2VK5jwjgF4TKGcf6GRKRhxH0oXNwmRJ uIQdEV4mEC36MWXq8oKt4YEi04V/0ngnFm6PNTFKeDGPIyjRVjghqIc/Zk0R1hrWZIgwB4dh+GnS jPYBvqGBHgIqdqiBblhYvuFMGmEsAagfwlFFL0hpE6gfoBZnwGYlkdiIwCNtwTZsxUY4v5aHJ0Y/ qAiK54d+pgYoygIqVqIsnciEniJ5E/E4zCdqA9d2jgM5yKhxu4ZrA3dvpFZu0zZqGtcv5tZk6vUB m2cQ0lhY0WhuxUiMwrhv5FiO5niO6JiOGxEQADs= ------_=_NextPart_001_01C62183.7197C63A-- --===============1444023793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1444023793==-- From iptel-bounces@ietf.org Wed Jan 25 20:19:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1vll-0000LU-F2; Wed, 25 Jan 2006 20:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1vli-0000Ks-K3 for iptel@megatron.ietf.org; Wed, 25 Jan 2006 20:17:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20182 for ; Wed, 25 Jan 2006 20:16:15 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1vvY-0004Tu-Vj for iptel@ietf.org; Wed, 25 Jan 2006 20:27:58 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id B0F507A2B5; Thu, 26 Jan 2006 01:17:05 +0000 (GMT) In-Reply-To: <72E31CBDD28B29418986A01998EAC72D1CFEAA@rad-w2ksrv11.radcom.co.il> References: <72E31CBDD28B29418986A01998EAC72D1CFEAA@rad-w2ksrv11.radcom.co.il> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CE9C09C-32E6-41F2-A3E0-A72B4E502C20@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Iptel] Adapting to RFC 3966 Date: Thu, 26 Jan 2006 01:17:04 +0000 To: Nadav Golombick X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Hi there, It is hard to give a specific answer without you spelling out exactly what you see as the problems in your program with 3966 support. In general, don't try to support 2806. It is a bad idea. The update was to fix some features that did not interwork well, as everyone interpreted them differently. From experience, "pure" 2806 support is a road to pain during integration/interworking tests. Of course, if you're after fax: or data:, you're out of luck, but on the tel: side, 3966 is MUCH clearer, IMHO. atb, L On 25 Jan 2006, at 07:46, Nadav Golombick wrote: > Hi, > > > > Currently, my application is adapted to RFC 2806. Since there are a > few > conflicts between the two RFCs, I was hoping that someone else has > attempted to support both RFCs. If so, can you give me a few > suggestions > as how you solved the conflicts. > > > > Thanks, > > > > Nadav Golombick > > Software Engineer > > Tel: +972 3 7666421 > > Fax: +972 3 6474681 > > Email: nadavg@radcom.com > > www.radcom.com > > www.protocols.com > > > > > > Come see us at 3GSM, Barcelona. > > 13-16 February 2006, Booth C45. > > "The 3G future is already visible." > > > > > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Jan 26 01:44:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F20sK-0000bR-HQ; Thu, 26 Jan 2006 01:44:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F20sJ-0000bM-O3 for iptel@megatron.ietf.org; Thu, 26 Jan 2006 01:44:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16122 for ; Thu, 26 Jan 2006 01:43:23 -0500 (EST) Received: from mail.radcom.com ([80.74.109.3] helo=rad-w2ksrv11.radcom.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F212B-0007jl-Pm for iptel@ietf.org; Thu, 26 Jan 2006 01:55:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Adapting to RFC 3966 Date: Thu, 26 Jan 2006 08:42:42 +0200 Message-ID: <72E31CBDD28B29418986A01998EAC72D1CFEB2@rad-w2ksrv11.radcom.co.il> Thread-Topic: [Iptel] Adapting to RFC 3966 Thread-Index: AcYiFgNIuWkLAxc6SjGa+FrR+ElvtQALRt9A From: "Nadav Golombick" To: "lconroy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Hi, The issue regarding 2806 is that I have an application that already supports 2806 and would like to add the support for 3966 without affecting backwards compatibility. Some of the issues that I have encountered are as follows: 1) In 2806 the context parameter as well as other parameters can appear a number of times. In 3966, those parameters can only appear once. 2) The phone-context in 2806 can contain alphanumeric characters as well as a number of other characters mentioned. In 3966, only alphanumeric characters, period and dashes (-) can appear.=20 As for modem and fax, I don't have to support them, so that issue is not a problem. Thanks, Nadav -----Original Message----- From: lconroy [mailto:lconroy@insensate.co.uk]=20 Sent: Thursday, January 26, 2006 3:17 AM To: Nadav Golombick Cc: iptel@ietf.org Subject: Re: [Iptel] Adapting to RFC 3966 Hi there, It is hard to give a specific answer without you spelling out exactly what you see as the problems in your program with 3966 support. In general, don't try to support 2806. It is a bad idea. The update was to fix some features that did not interwork well, as everyone interpreted them differently. From experience, "pure" 2806 support is a road to pain during integration/interworking tests. Of course, if you're after fax: or data:, you're out of luck, but on the tel: side, 3966 is MUCH clearer, IMHO. atb, L On 25 Jan 2006, at 07:46, Nadav Golombick wrote: > Hi, > > > > Currently, my application is adapted to RFC 2806. Since there are a =20 > few > conflicts between the two RFCs, I was hoping that someone else has > attempted to support both RFCs. If so, can you give me a few =20 > suggestions > as how you solved the conflicts. > > > > Thanks, > > > > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Jan 26 03:43:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F22jX-00046K-8O; Thu, 26 Jan 2006 03:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F22jU-00045v-Ui for iptel@megatron.ietf.org; Thu, 26 Jan 2006 03:43:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23573 for ; Thu, 26 Jan 2006 03:42:24 -0500 (EST) Received: from mail.radcom.com ([80.74.109.3] helo=rad-w2ksrv11.radcom.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F22tO-0002jr-GP for iptel@ietf.org; Thu, 26 Jan 2006 03:54:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Iptel] Adapting to RFC 3966 Date: Thu, 26 Jan 2006 10:41:54 +0200 Message-ID: <72E31CBDD28B29418986A01998EAC72D1CFEB4@rad-w2ksrv11.radcom.co.il> Thread-Topic: [Iptel] Adapting to RFC 3966 Thread-Index: AcYiFgNIuWkLAxc6SjGa+FrR+ElvtQALRt9AAARXU6A= From: "Nadav Golombick" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Hi, The issue regarding 2806 is that I have an application that already supports 2806 and would like to add the support for 3966 without affecting backwards compatibility. Some of the issues that I have encountered are as follows: 1) In 2806 the context parameter as well as other parameters can appear a number of times. In 3966, those parameters can only appear once. 2) The phone-context in 2806 can contain alphanumeric characters as well as a number of other characters mentioned. In 3966, only alphanumeric characters, period and dashes (-) can appear.=20 As for modem and fax, I don't have to support them, so that issue is not a problem. Thanks, Nadav -----Original Message----- From: lconroy [mailto:lconroy@insensate.co.uk]=20 Sent: Thursday, January 26, 2006 3:17 AM To: Nadav Golombick Cc: iptel@ietf.org Subject: Re: [Iptel] Adapting to RFC 3966 Hi there, It is hard to give a specific answer without you spelling out exactly what you see as the problems in your program with 3966 support. In general, don't try to support 2806. It is a bad idea. The update was to fix some features that did not interwork well, as everyone interpreted them differently. From experience, "pure" 2806 support is a road to pain during integration/interworking tests. Of course, if you're after fax: or data:, you're out of luck, but on the tel: side, 3966 is MUCH clearer, IMHO. atb, L On 25 Jan 2006, at 07:46, Nadav Golombick wrote: > Hi, > > > > Currently, my application is adapted to RFC 2806. Since there are a =20 > few > conflicts between the two RFCs, I was hoping that someone else has > attempted to support both RFCs. If so, can you give me a few =20 > suggestions > as how you solved the conflicts. > > > > Thanks, > > > > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Jan 26 12:42:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2B8o-0003UK-TE; Thu, 26 Jan 2006 12:42:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2B8l-0003S9-HY for iptel@megatron.ietf.org; Thu, 26 Jan 2006 12:42:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07719 for ; Thu, 26 Jan 2006 12:41:02 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BHs-0006nu-GD for iptel@ietf.org; Thu, 26 Jan 2006 12:52:01 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2006 09:41:24 -0800 X-IronPort-AV: i="4.01,221,1136188800"; d="scan'208"; a="251615909:sNHT36542648" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0QHfKQJ001048; Thu, 26 Jan 2006 09:41:20 -0800 (PST) Received: from 10.21.145.12 ([10.21.145.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Jan 2006 17:41:19 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 26 Jan 2006 09:41:35 -0800 Subject: Re: [Iptel] Adapting to RFC 3966 From: Cullen Jennings To: Nadav Golombick , Lawrence Conroy Message-ID: Thread-Topic: [Iptel] Adapting to RFC 3966 Thread-Index: AcYiFgNIuWkLAxc6SjGa+FrR+ElvtQALRt9AABcoaRs= In-Reply-To: <72E31CBDD28B29418986A01998EAC72D1CFEB2@rad-w2ksrv11.radcom.co.il> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Could you make it so that you will only send 3966 compliant things and receive either 3966 or 2806 things? In general the things removed from 2806 were things that were not used or undefined. For example, it is not clear what multiple contexts would mean and it in doing the drafts, no one told us about any applications that actually sent multiple contexts. I know this is not all that helpful but be strict in what you send and liberal in what you receive. On 1/25/06 10:42 PM, "Nadav Golombick" wrote: > Hi, > > The issue regarding 2806 is that I have an application that already > supports 2806 and would like to add the support for 3966 without > affecting backwards compatibility. > Some of the issues that I have encountered are as follows: > 1) In 2806 the context parameter as well as other parameters can appear > a number of times. In 3966, those parameters can only appear once. > 2) The phone-context in 2806 can contain alphanumeric characters as well > as a number of other characters mentioned. In 3966, only alphanumeric > characters, period and dashes (-) can appear. > > As for modem and fax, I don't have to support them, so that issue is not > a problem. > > Thanks, > > Nadav > > > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Thursday, January 26, 2006 3:17 AM > To: Nadav Golombick > Cc: iptel@ietf.org > Subject: Re: [Iptel] Adapting to RFC 3966 > > Hi there, > It is hard to give a specific answer without you spelling out exactly > what you see as the problems in your program with 3966 support. > > In general, don't try to support 2806. It is a bad idea. > The update was to fix some features that did not interwork well, > as everyone interpreted them differently. From experience, "pure" > 2806 support is a road to pain during integration/interworking tests. > > Of course, if you're after fax: or data:, you're out of luck, but on > the tel: side, 3966 is MUCH clearer, IMHO. > > atb, > L > > On 25 Jan 2006, at 07:46, Nadav Golombick wrote: >> Hi, >> >> >> >> Currently, my application is adapted to RFC 2806. Since there are a >> few >> conflicts between the two RFCs, I was hoping that someone else has >> attempted to support both RFCs. If so, can you give me a few >> suggestions >> as how you solved the conflicts. >> >> >> >> Thanks, >> >> >> >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Jan 26 23:01:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2KnY-0003ZU-6s; Thu, 26 Jan 2006 23:01:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2KnW-0003Vo-1B for iptel@megatron.ietf.org; Thu, 26 Jan 2006 23:01:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03704 for ; Thu, 26 Jan 2006 22:59:45 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Kxa-000666-EY for iptel@ietf.org; Thu, 26 Jan 2006 23:11:43 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2006 20:01:07 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0R417jt017890; Thu, 26 Jan 2006 20:01:07 -0800 (PST) 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.211); Thu, 26 Jan 2006 23:01:06 -0500 Received: from [192.168.1.102] ([10.86.240.83]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 23:01:06 -0500 Message-ID: <43D99B01.7080900@cisco.com> Date: Thu, 26 Jan 2006 23:01:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" Subject: Re: [Iptel] The 'npdi' parameter References: <165FCC93A820D240A62F98E028CEFED007261B0C@stntexch01.cis.neustar.com> In-Reply-To: <165FCC93A820D240A62F98E028CEFED007261B0C@stntexch01.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2006 04:01:06.0518 (UTC) FILETIME=[4C5E3760:01C622F6] X-Spam-Score: 2.0 (++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Miguel's example, though, talks about user=dialstring. I don't think the npdi actually makes much sense for dialstrings. -Jonathan R. Yu, James wrote: > Paul's answer is correct. If a sip URI does not carry the phone number > (e.g., sip:jacksmith@spA.com), npdi is meaningless in the sip URI. If > the sip URI carries the phone numbers (e.g., with user=phone), then all > the tel URI parameters including the npdi, rn and other could be > included in the user part of that sip URI. > > James > > -----Original Message----- > From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, January 24, 2006 10:28 AM > To: Miguel Garcia > Cc: iptel@ietf.org > Subject: Re: [Iptel] The 'npdi' parameter > > Miguel, > > Doesn't all the syntax that applies to tel URIs also apply to sip/sips > URIs with user=phone? Does that have to be restated for each new > extension to tel? > > Paul > > Miguel Garcia wrote: > >>Hi: >> >>I was reading the Number Portability parameters for the Tel URI, >>draft-ietf-iptel-tel-np-08.txt, and I have no problem with the draft >>itself. But I was wondering if the 'npdi' parameter should be also >>defined for SIP URIs that carry telephone numbers. >> >>Let's assume I have a SIP UA that encodes E.164 numbers as SIP URIs, >>perhaps with the "user=dialstring" defined in >>draft-rosen-iptel-dialstring-02.txt. If a node does an NP translation, > > >>we don't have the means to indicate that the query to the NPDB has > > taken > >>place. But if the E.164 number is encoded as a tel URI there is. >> >>In my opinion this claims for the npdi parameter to be applicable to > > SIP > >>URIs as well. Any thoughts? >> >>/Miguel >> > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Jan 27 09:57:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2V24-0007cO-Hh; Fri, 27 Jan 2006 09:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EymHI-0002J7-9e for iptel@megatron.ietf.org; Tue, 17 Jan 2006 03:33:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26780 for ; Tue, 17 Jan 2006 03:31:54 -0500 (EST) Received: from uproxy.gmail.com ([66.249.92.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EymPK-0004Ik-SV for iptel@ietf.org; Tue, 17 Jan 2006 03:41:42 -0500 Received: by uproxy.gmail.com with SMTP id j3so333152ugf for ; Tue, 17 Jan 2006 00:33:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XGWucubgujwaL46Iv5475gEYbs/VlsqTgUdGfNlUd6vGDvP09pxmSooDIRRQHjoHp8LNa+QYJeSDJ8TlnAC5ag0ALBtM2nkkQT2zKKTNP6LfTwElDUHClEU8qPdmwqz1LP3ro8YOAS060fqJYGGJ7gcm7DuS2Db6Bsm+fMVmXjI= Received: by 10.49.11.2 with SMTP id o2mr296525nfi; Tue, 17 Jan 2006 00:33:15 -0800 (PST) Received: by 10.48.243.11 with HTTP; Tue, 17 Jan 2006 00:33:15 -0800 (PST) Message-ID: <876aa5be0601170033ka6943b3w@mail.gmail.com> Date: Tue, 17 Jan 2006 14:03:15 +0530 From: parveen jain To: iptel@ietf.org In-Reply-To: <876aa5be0601162106w4ba6ddf5o@mail.gmail.com> MIME-Version: 1.0 References: <876aa5be0601162106w4ba6ddf5o@mail.gmail.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-Mailman-Approved-At: Fri, 27 Jan 2006 09:56:54 -0500 Subject: [Iptel] Fwd: Questions regarding tel: URI X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0790535085==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org --===============0790535085== Content-Type: multipart/alternative; boundary="----=_Part_8257_17586294.1137486795135" ------=_Part_8257_17586294.1137486795135 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I have some question regarding the role of proxy/Registrar in case they receives a request containing URI . Is it possible to get the URI in messages other then INVITE and REGISTER or in responses of any type? 1. From RFC 3261 it has been mentioned that URI could be present in REQUEST URI , FROM and TO header, and only for REGISTER metho= d it could be in CONTACT header. Is it possible to get it in any other header except from these? 2. Is it alright from implementation point of view to register the URI's just like sip URI . 3. if the answer of previous question is yes, then if we are storing only URI of a sip-phone/ PSTN-gateway , how is it possible to map URI to sip uri if the proxy have no prior information about sip U= RI of that endpoint . in my opinion the sip-phone/PSTN-gateway must have to register there sip URI's with DNS by any other mean and proxy can contact that DNS for any mapping using ENUM, please correct me if I am wrong ? any help regarding the same will be highly appreciated .Please excuse if I had not formed my question's well. Thanks & Regards, Parveen ------=_Part_8257_17586294.1137486795135 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,

= I have some question regarding the role of proxy/= Registrar in case they receives a request containing <tel:> URI .

= Is it possible = to get the <tel:> URI in messages other then INVITE and REGISTER or in responses of any type?

From RFC 3261 it h= as been mentioned that <tel:> URI could be present in REQUEST URI , FROM= and TO header, and only for REGISTER method it could be in CONTACT header.= Is it possible to get it in any other header except from these?

Is it alright from implementation point of view to register the <tel:> URI's just l= ike sip URI .

if the answer of previous question is yes, then if we are storing only <tel:> URI of a sip-phone/ P= STN-gateway , how is it possible to map <tel:> URI to sip uri if the proxy h= ave no prior information about sip URI of that endpoint .

any help regarding the same will be highly appreciated .Please excuse if I had not formed my question's well.

Thanks & Regards,

Parveen

------=_Part_8257_17586294.1137486795135-- --===============0790535085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0790535085==-- From iptel-bounces@ietf.org Fri Jan 27 10:15:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VJa-0008K0-46; Fri, 27 Jan 2006 10:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VJW-0008JJ-K8 for iptel@megatron.ietf.org; Fri, 27 Jan 2006 10:15:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18028 for ; Fri, 27 Jan 2006 10:13:29 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VTg-0002aW-SP for iptel@ietf.org; Fri, 27 Jan 2006 10:25:34 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 Jan 2006 07:14:52 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0RFEeWn023693; Fri, 27 Jan 2006 07:14:51 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 10:14:46 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 10:14:46 -0500 Message-ID: <43DA38E5.4070809@cisco.com> Date: Fri, 27 Jan 2006 10:14:45 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Iptel] The 'npdi' parameter References: <165FCC93A820D240A62F98E028CEFED007261B0C@stntexch01.cis.neustar.com> <43D99B01.7080900@cisco.com> In-Reply-To: <43D99B01.7080900@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2006 15:14:46.0473 (UTC) FILETIME=[6889E390:01C62354] X-Spam-Score: 2.0 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, "Yu, James" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Jonathan Rosenberg wrote: > Miguel's example, though, talks about user=dialstring. I don't think the > npdi actually makes much sense for dialstrings. I agree it doesn't make too much sense for user=dialstring. But it does make sense for user=phone. Paul > -Jonathan R. > > Yu, James wrote: > >> Paul's answer is correct. If a sip URI does not carry the phone number >> (e.g., sip:jacksmith@spA.com), npdi is meaningless in the sip URI. If >> the sip URI carries the phone numbers (e.g., with user=phone), then all >> the tel URI parameters including the npdi, rn and other could be >> included in the user part of that sip URI. >> >> James >> >> -----Original Message----- >> From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, January 24, 2006 10:28 AM >> To: Miguel Garcia >> Cc: iptel@ietf.org >> Subject: Re: [Iptel] The 'npdi' parameter >> >> Miguel, >> >> Doesn't all the syntax that applies to tel URIs also apply to sip/sips >> URIs with user=phone? Does that have to be restated for each new >> extension to tel? >> >> Paul >> >> Miguel Garcia wrote: >> >>> Hi: >>> >>> I was reading the Number Portability parameters for the Tel URI, >>> draft-ietf-iptel-tel-np-08.txt, and I have no problem with the draft >>> itself. But I was wondering if the 'npdi' parameter should be also >>> defined for SIP URIs that carry telephone numbers. >>> >>> Let's assume I have a SIP UA that encodes E.164 numbers as SIP URIs, >>> perhaps with the "user=dialstring" defined in >>> draft-rosen-iptel-dialstring-02.txt. If a node does an NP translation, >> >> >> >>> we don't have the means to indicate that the query to the NPDB has >> >> >> taken >> >>> place. But if the E.164 number is encoded as a tel URI there is. >>> >>> In my opinion this claims for the npdi parameter to be applicable to >> >> >> SIP >> >>> URIs as well. Any thoughts? >>> >>> /Miguel >>> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Jan 31 06:37:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tpI-0007aP-OV; Tue, 31 Jan 2006 06:37:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tpG-0007Wu-3q for iptel@megatron.ietf.org; Tue, 31 Jan 2006 06:37:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07746 for ; Tue, 31 Jan 2006 06:35:50 -0500 (EST) Received: from smtp11.clb.oleane.net ([213.56.31.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3u05-0007pT-LZ for iptel@ietf.org; Tue, 31 Jan 2006 06:48:46 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp11.clb.oleane.net with ESMTP id k0VBb7Aa019108 for ; Tue, 31 Jan 2006 12:37:14 +0100 Message-Id: <200601311137.k0VBb7Aa019108@smtp11.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 31 Jan 2006 12:37:06 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYmWqm4hcI1BTR+SdaLOV2xX0QIUA== X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Iptel] International SIP/WiMAX Summit - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621621562==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============1621621562== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01C62663.0BCD9CC0" This is a multi-part message in MIME format. ------=_NextPart_000_00AC_01C62663.0BCD9CC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit More than 500 participants will attend International SIP and the WiMAX Summit next February 21st to 24th in Paris. Registration is still open for both events. The 7th edition of the International SIP conference program is mainly dedicated to IMS architectures and Peer-to-Peer communications: http://www.upperside.fr/sip2006/sip2006intro.htm The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant operators: http://www.upperside.fr/wimax2006/wimax2006intro.htm Close to the conference rooms an exhibition welcomes industrials involved in VoIP and wireless broadband access. ------=_NextPart_000_00AC_01C62663.0BCD9CC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

More than 500 participants will attend = International = SIP and the WiMAX Summit next February 21st to 24th in = Paris.

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

Registration is still open for both = events.

The 7th edition of the International SIP = conference program is mainly dedicated to IMS architectures = and Peer-to-Peer communications:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant = operators:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

Close to the conference rooms an exhibition = welcomes industrials involved in VoIP and wireless broadband = access.

------=_NextPart_000_00AC_01C62663.0BCD9CC0-- --===============1621621562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1621621562==--