Hi Christoph, folks, Re. two points - I have a certain nostalgia for the old days when folk thought that H.323 was the answer to a maiden's prayer and people still voted Tory in the UK. I still have an old Pentium 166 in our lab that must be about the same era, so I DO understand the concept of using whatever old kit is hanging around. Re. 3761/3762 forbidding anything - yup. Strictly, it's RFC3762 that forbids this, as that slim document is what registers the h323 Enumservice. 3762 does not mention any sub-sub-type, so the :voice bit is invalid. Talk to Orit if you think it should be changed. AFAIK, Asterisk is one of the two widest used ENUM-enabled systems, the other being SER. Hence whilst the * enum.c does meet RFCs 3761, 3762, 3764 (and also supports the ETSI 102172 spec), as well as the earlier RFC2915 and RFC2916, (i.e. it's pretty flexible), it breaks with the syntax chosen by your ?hoster?. So it goes. all the best, Lawrence On 8 Oct 2004, at 13:25, Christoph Künkel wrote:

Lawrence,

You still manage to ignore my 2 points ;-)

Nevertheless, regarding the service spec. This is done by our trial enum NAPTR hoster. See http://www.enum-trial.de/newsletter/newsletter02.htm (at the end) for details [ sorry, I am not aware of an English translation ].

Do you think either RFC 3761 or 3762 forbids this? or is enum.c the normative reference?

:-) Christoph

-----Ursprüngliche Nachricht----- Von: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] [ ... ]

I haven't seen before: E2U+h323:voice

Looking at the code, I suspect that this will successfully break

Asterisk's

enum.c processing.