[Asterisk-Dev] FYI - ITU notices Dunny

[Conroy, Lawrence (SMTP)]

Hi Folks,
  FYI - on yet another list (RIPE-enumwg) posted by my esteemed  
colleague Richard Stastny:


Big brother is watching you ;-)
http://www.itu.int/osg/spu/newslog/categories/voip/2004/10/20.html#a730
Distributed Universal Number Discovery = DUNDi  


The Distributed Universal Number Discovery (DUNDi  
 ), from Digium  , is a  
peer to peer system for locating Internet gateways to telephony  
services. Unlike traditional hierarchical services such as ENUM  
 , DUNDi    
is a distributed sysem with no centralized authority. An implementation  
of DUNDi   exists in Asterisk  
 , an Open Source PBX. For further  
information, see:

*   DUNDi Core Members 
*   DUNDi Whitepaper 
*   General Peering Agreement 
*   DUNDi Internet Draft 
*   DUNDi Best Practices 
*   DUNDi Press Release 
*   DUNDi Mailing List 
More information can be found in a related article  
  from  
the people at Voxilla  . Also worth reading are the  
VoIP peering discussions on this mailing list  
 .


--
Visit our website at www.roke.co.uk
Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] UK Caller ID patch and new CVS

[Conroy, Lawrence (SMTP)]

Hi again, Andrew, folks,
 Yup - the X100P (or clone) is a PSTN card for use with single lines.
Fine device, and WAY cheaper than a TDM4xx with a single populated
FXO module (TDM01B), at least in the UK.
I assumed that you weren't seriously suggesting a TDM01B for a
single analogue line (if they weren't back-ordered). Hence I
guessed that the use case is "a few lines".
AFAICT, the TDM4xx modules don't do busy detection or call
supervision or CLI or have settings for correct impedance
right now for use in the UK - all we have is the *potential*
to get these working sometime in the *future*.
If one does need a couple of lines, then one may have a choice
- PSTN access or ISDN access.
In civilised countries (i.e. not here) it's cheaper to get a
BRI than it is to get two analogue lines. Thus, if one needs
more than one analogue line, it may be cheaper to go for a
BRI from your Comms Provider.
If you DO go for a BRI (or a pair of BRIs) the card(s) WILL
be cheaper (and, most important, it works, out of the box).
No grief with whether or not CLI works - it does now.
Likewise, no grief about progress/call supervision - it
works over here right now.
To sum up, if the use case is more than one line and you don't live
in the U.S of A., then don't forget ISDN - it has several advantages
(not least of which is that we don't do SPIDs over here).
If the use case is a single analogue line, then the price of an
under-populated TDM4xx puts it outside the budget for most people
- it's just too expensive at current UK reseller prices.
all the best,
  Lawrence
On 23 Jul 2004, at 15:50, Andrew Kohlsmith wrote:
On Friday 23 July 2004 10:29, Conroy, Lawrence (SMTP) wrote:
Frankly though, I don't think ANYONE should buy these cards, clone or
no -- Get
the TDMxx series.

Why?
Does progress tone/call supervision/CLI work in the UK for the TDM4xx?
(at least now CLI works with the X100P :).
The TDM card is a true Digium product, not an OEM card resold by 
Digium.  IIRC
the FXO module is far higher quality too.

In my experience, ISDN works very well with Junghanns's excellent
chan_capi
(and the AVM passive cards are cheaper) so if a couple of lines is all
you need, ...
The X101P doesn't support ISDN.  I thought we were talking PSTN here 
not ISDN?

-A.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Visit our website at www.roke.co.uk
Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] UK Caller ID patch and new CVS

[Conroy, Lawrence (SMTP)]

Hi folks,
  First, many thanks to the good people who developed this patch set.
I now get Caller ID on my home line, so I do have a use for the
Pissy that was keeping my door open (and one of its PCI slots).
I have an X100P and S100U and that's it for zaptel devices so
this hack is fine by me. Progress tone/Busy Detection/Call Cleardown
supervision is a "bridge too far", but at least I can process based
on who's calling at last; A GOOD THING. Mother-in-Law processing is Go.
As I understand it, the patch includes a low-level hack to the kernel
driver to add the ring buffer. Look at the bugnotes - the concern seems
to be that this may lead to fragility in the core code and make it 
harder
to maintain for other zaptel devices. Fair enough - I don't use any of 
the
other kinds of zaptel devices, so I'm unfamiliar with the code.

However, this one's going to be in my standard "download, patch, build"
cycle from now one unless someone goes out of their way to break it.
We have contribs in Asterisk, so is it time to get contribs in Zaptel 
as well?

all the best,
  Lawrence
On 23 Jul 2004, at 14:12, Andrew Kohlsmith wrote:

It's just Good Karma to support Digium.
Frankly though, I don't think ANYONE should buy these cards, clone or 
no -- Get
the TDMxx series.
Why?
Does progress tone/call supervision/CLI work in the UK for the TDM4xx?
(at least now CLI works with the X100P :).
In my experience, ISDN works very well with Junghanns's excellent 
chan_capi
(and the AVM passive cards are cheaper) so if a couple of lines is all 
you need, ...

--
Visit our website at www.roke.co.uk
Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Regional Options

[Conroy, Lawrence (SMTP)]

Hi Dave, Fran, folks,
Quick clarification - "Caller Display" is actually BT caller ID.
It's defined in a pair of SINs (i.e. BT specifications).
It's NOT used by a *few* parts of NTL (a/the Cable Company in the UK).
Thus "UK" caller ID will not work as such for a few folk in the UK.
I suspect that NTL are going to scrap the remaining old switches that
they still have doing Bell standard CLI, so it doesn't really matter.
If you can capture CDS data with the Digium X100P or the TDM400P/FXO,
then you definitely get the free beer!
all the best,
  Lawrence
On 23 May 2004, at 9:04 am, Fran Boon wrote:
Dave Harvey wrote:
I'm a UK user, relatively new to Asterisk, but keen to add a few 
features
(like UK-style Caller ID, which looks likeit should be feasible on 
the new
hardware).
Great, you'll make many people happy with that :)
However, in order to enable this appropriately, I would need to
"know" what region a articular channel is supposed to be operating 
in, and I
can't find options to set this.yes, there are LANGUAGE options, 
but this
is no use in trying to decide if CallerID should be US, UK, South 
Africa
etc.!  Am I missing something, and if there isn't alrerady such a 
system,
should it be added - might then be useful for other things such as:
ringing cadences
conventional codes for caller ID suppresion etc. (e.g. we uses 141 in 
the
UK)
and propably a few more I haven't thought of.
http://voip-info.org/wiki-Asterisk+config+indications.conf
country=uk
internal callerID suppression would need to be dealt with in the 
dialplan.
Sounds like a nice option to give users.

external callerID suppression could be accessed as-normal, as long as 
the dialplan supported it...having this as a variable & then making it 
accessible  through an alternative code would be simple dialplan 
'magic' if you wanted it.

Idealy, there would be both a country (ISO 3166 2 letter code?) and an
optional  system identifier, as some countries (including technically 
the
UK) have only supplier specific oddities ("UK" caller ID is actually 
a BT
standard).
My suggestion would be that it be "per channel" so that a mixed bag of
equipment from diffeent zones could be used, but there may be a better
way.ideas anyone?
Both sound like potentially useful enhancements...
F
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Visit our website at www.roke.co.uk
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] libsrtp

[Conroy, Lawrence (SMTP)]

Hi Folks,
  libsrtp for * is a GOOD idea, IMHO. Go for it!
However, I'm a little puzzled with these comments.
Yes, I am subscribed to MMUSIC, AVP & SIP/SIPPING Mailing Lists; I 
don't get enough junk email.

No, 802.1X is not an IETF protocol - it's an IEEE link layer protocol.
Yes, SIP does use S/MIME - it's specified in RFC 3261 (for example, see 
section 23 on page 201 et seq).
BTW, the S/MIME RFCs are listed in the references section at the end of 
3261.

No, TCP doesn't really add latency, as this is used only for the SIP 
exchanges (i.e. the signalling),
NOT the (s)RTP used to carry the media. In practice, you often get 
retransmits in SIP using UDP
transport unless you're "close", so the extra syn/ack traffic to 
set up TCP is insignificant.
Remember also that the TCP connections can be re-used, so for 
inter-PBX trunking it makes no odds.

The SIP INVITE/200 exchange carries the SDP anyway, so a secured 
exchange (via SIPS - i.e. TLS)
should be OK to carry the keys, hence SDPdescriptions. You have the 
problem of mutual authentication
and encryption with TLS anyway; once that's dealt with, passing a 
message key (or keys) is OK,
as it's done over a secured signalling channel.

Note that the chat on the AVT list said that time-based re-keying (i.e. 
multiple keys switched
automatically based on the timestamp blah in the RTP stream) is NOT 
supported by srtp. Frankly,
I'd be surprised if anyone needed that any time soon - if encrypted 
content is that sensitive,
then we're probably talking about IPsec anyway.

One last point... srtp encrypts the content only.
The fact that there's a stream between the parties is still obvious to 
an eavesdropper, even
if the signalling that set up the session is secure (and the content is 
secure).
However, I think that the focus on content only means that the good 
news is that standard
NAT mangling should still work with srtp, as the IP/UDP headers are 
intact.

all the best,
  Lawrence

On 15 May 2004, at 4:26 pm, Duane wrote:
Olle E. Johansson wrote:
Yes, but how did you relate EAP-TLS with SIPS?
There is a reason people use UDP for telephony, by introducing TCP 
into the mix won't that introduce high amounts of latency?

EAP-TLS is handled at the mac layer not at the TCP layer, IPSec also 
uses TLS but does so over UDP because of latency associated with using 
TCP...

http://e164.org - Using Enum.164 to interconnect asterisk servers
 As Fosters is to beer, so ...
--
Visit our website at www.roke.co.uk
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Lost in Translation (DTMF Relay)

[Conroy, Lawrence (SMTP)]

Hi Sales, Folks,
  I'm confused.
The first part talks about H.323, and then the rest talks about SIP.
The peer lines look very much like H.323 (et al).
Thus, if you really DO have two Cisco phones that are both talking SIP.
then I don't see what this H.323 stuff has to do with anything.
The statement "I am using only G.729" is wrong, one way or another.
If you are transferring DTMF, this is either in RFC2833 frames, OR
it will get hopelessly scrambled by the G.729 codec.
I happily transfer DTMF using RFC2833 mode via *. It works.
Now, I'm using G.711 but this is completely irrelevant, as the DTMF
goes to * inside RFC2833-coded RTP frames, NOT inline in the audio 
codec.

Assuming that this isn't yet another Cisco-ism, I wonder if the H.323 
mung
is the problem here - it's either SIP or H.323/H.245/dadada

So - which is it, Spitz or Swallows?

all the best,
  Lawrence
On 24 Apr 2004, at 5:24 pm, [EMAIL PROTECTED] wrote:

Now that Jeremy has started, but not finished, the huge
endeavor of fixing H323, perhaps somebody else may
attempt to fix the other real issue that keeps many
people from using Asterisk in a more business-oriented
model: The DTMF Relay is useless, using either protocol
or mode. I did this experiment which failed and I had
to bypass Asterisk: The calls come from A Cisco 5300
using SIP, where the dialpeer has the usual lines
 “dial-peer voice 41 voip
 destination-pattern 5619531599
 translate-outgoing called 1
 session protocol sipv2
 session target ipv4:xx.xxx.xxx.x
 dtmf-relay cisco-rtp rtp-nte h245-signal
h245-alphanumeric
 codec g729br8 bytes 40
 fax rate 14400
 fax protocol t38 ls-redundancy 0 hs-redundancy 0
 no vad
!
The middle man is Asterisk, and the receiving end is
also another Cisco 5300, configured similarly. Whatever
I do, the dtmf gets lost using any codec except g711
and Inband, which is not exactly DTMF relay at all. It
fails with rfc2833, info, etc. The bridge kills the
dtmf. There are many business models that require this
functionality. In this case, I had to send the call
directly from Cisco to Cisco, because I could not
receive a single DTMF tone on the other end. My client
really would benefit from having Asterisk in the
middle, but to no avail. I use only G729.
Any ideas?
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
--

Visit our website at www.roke.co.uk

Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[Asterisk-Dev] Re: [Asterisk-cvs] asterisk pbx.c,1.111,1.112

[Conroy, Lawrence (SMTP)]

Hi Folks,
  Is there a particular reason why all extension matching should be 
case sensitive?
The bug seems to have come about as Mark didn't want to use a different 
letter for
Absolute and Response timeouts.

Are we so short on letters that we need all users to go through and 
check their
extensions.conf? The bugfix certainly works, but is a bit severe, IMHO.

(Of course, the log message is reversed, but documentation doesn't 
count :).

all the best,
  Lawrence
Begin forwarded message:

From: [EMAIL PROTECTED]
Date: 18 April 2004 7:47:17 am BST
To: [EMAIL PROTECTED]
Subject: [Asterisk-cvs] asterisk pbx.c,1.111,1.112
Update of /usr/cvsroot/asterisk
In directory mongoose.digium.com:/tmp/cvs-serv16996
Modified Files:
pbx.c
Log Message:
Make extension matching non case sensitive.  So 'T' and 't' are
different extensions (bug 1327)
Index: pbx.c
===
RCS file: /usr/cvsroot/asterisk/pbx.c,v
retrieving revision 1.111
retrieving revision 1.112
diff -u -d -r1.111 -r1.112
--- pbx.c   6 Apr 2004 22:17:31 -   1.111
+++ pbx.c   18 Apr 2004 05:50:55 -  1.112
@@ -3682,7 +3682,7 @@
}
e = con->root;
while(e) {
-   res= strcasecmp(e->exten, extension);
+   res= strcmp(e->exten, extension);
if (!res) {
if (!e->matchcid && !tmp->matchcid)
res = 0;
___
Asterisk-Cvs mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-cvs
--

Visit our website at www.roke.co.uk

Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Re: [Asterisk-cvs] asterisk/channels chan_sip.c,1.248,1.249

[Conroy, Lawrence (SMTP)]

Hi Folks,
  OK, I'll bite.
If one reads rfc2916bis, one notices a change - the syntax is NOT
what is proposed here. Basically, it's harris about apex from the
original (soon to be obsoleted) rfc2916. I STRONGLY recommend that
you swap the tokens around to fit with the new syntax.
Speaking as a veteran, it's not yet the right time to register an
ENUMservice, which is what you would need to do - BTW, IANA will not
register anything as an ENUMservice without passing it on to the IETF.
However, there's a get-out clause, for testing :).

The correct syntax for rfc2916 is 'E2U+', and a valid
 for testing can be 'X-IAX2'. This is NOT registered
with anyone as it's reserved for experimental use, but if your
ENUM client understands it, all is cool.
My Mobile phone ENUM client will ignore it, as all well behaved
ENUM clients are supposed to when confronted with something they
can't understand/don't support. If one barfs when it reads such
an entry (i.e. one starting 'X-'), complain.
Problem solved, and a great deal of grief avoided - you would
probably need to get the IAX2 protocol anointed by the IETF
before you could register the ENUMservice before IANA would
register it - trust me, you don't want to try that yet.
all the best,
  Lawrence
On 25 Nov 2003, at 9:02 pm, Olle E. Johansson wrote:

Jeremy McNamara wrote:

Olle E. Johansson wrote:
So if I configure ENUM for a TEL url, how do I dial out then?

I have EnumLookup working with SIP today, that's pretty straight 
forward.

How is the syntax for the DNS entry for IAX and IAX2 ?
http://www.voip-info.org/wiki-Asterisk+cmd+EnumLookup
http://www.voip-info.org/wiki-Asterisk+E164+Call+Routing
Behold the beauty of a loop :-)
These are the pages I want to add more details to.
From the later of the Wiki pages (that I added myself):

  *.4.1.5.1 IN NAPTR 100 10 "u" "IAX2+E2U" 
"!^\\+*(.*)$!iax2:mtl-gateway/\\1!" .

So I ask again, what's the full syntax? This is only one example...

I would like to document the IAX2 URL used here.

And, when ENUMbiz becomes a RFC, we should register "IAX2+E2U" with 
IANA.

/O

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev

RE: [Asterisk-Dev] SIP Phone reset from CLI

[Conroy, Lawrence (SMTP)]

At 4:59 pm -0400 29/8/03, DUSTIN WILDES wrote:
Or - we could put a small notice like "Only for phones that support 
the check-sync NOTIFY message"?
If anyone has any specs on other SIP phones on remote rebooting, 
I'll be happy to add it in.  Granted I won't be able to fully test 
it out - but I'll be willing to help.  :-)

In response to James Golovich who clarified what this was about:

I don't know if this should really be in cvs, unless its a feature that is
supported by all phones and not just the cisco phones.
To which my response is:
Hi Folks,
   There was an amusing bug a while back that caused my Siemens Optipoint 400
(behind an Intertex IX66) to remote-reboot when * attempted a native bridge,
but I don't think that this was intentional.
I have to say that I did wonder if this proposal was from Microsoft - 
it strikes
me as a *Bad Idea* to allow one's phones to be remote-rebooted by any 
WilE Hacker
who sends out a suitable Notify. If this IS to be added to *, Please 
can it be a
compile-time option that is OFF by default - it's dangerous.

all the best,
  Lawrence
--
---
Roke Manor Research: This information is provided "as is" and is not
: intended to create any contractual or legal
: relationship.
--
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ
The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev