-----Original Message-----
From:Rolf Taylor Sent:2006-03-08 18:05:11
To:radio-tech@broadcast.net
Subject:[RT] ISDN over IP (was: IP Audio and Wireless ISP?)
Kevin krider at ix.netcom.com writes:

Why can't someone make an ISDN emulator for IP? How about a box with and ISDN connection on one side and an Network connection on the other? The network provides 64k (or 128k) of bandwidth and the box provides everything >else to make it look like an ISDN circuit to our old ISDN codecs. I need this device...

Kevin, very good question.

This is NOT a trivial task, but the answer is: this exists, and their ISDN implementation has been tested with Zephyr and Zephyr Xstream. See:

http://www.patapsco.co.uk/applications/
isdn_over_ip/isdn_ip.htm

and

http://www.patapsco.co.uk/pdfs/ISDN%20Codec%20
over%20IP%20 Application%20Note%20V1.02.pdf

However, this does not address the need for quality of service on the IP link. This is becoming more available, but is still the exception, not the rule. If you are using this equipment on an MPLS network (see Mike Tosch's recent thread) that offers sufficient QoS, it is likely to work very well. I met recently with this vendor, and they have been doing a lot of testing with various products, not just codecs.

Our biggest area of concern was the basic compatibility of the ISDN signaling as we've seen compatibility problems with some PBXs. I am happy to report there were no compatibility problems at all.

Their experience with IP services without QoS mechanisms is that if you use the same ISP on both ends, reliability tends to be decent since in that case it does not actually hit the public internet. But in this case, there is no performance guarantees like there would be with IP offering that guarantee QoS. Operation over the public internet is possible, but obviously the reliability under those conditions is the lowest. And if you do have problems, there is almost nothing you can do to get them remedied.

The real key for the case where there is no guaranteed QoS is to use coding schemes that are inherently robust to errors (such as G.722 or ADPCM) or to use one of the more efficient codecs combined various techniques to conceal lost or corrupted packets. Zephyr Xstream's AAC has error concealment which is why we recommend using Layer 2 or Layer 3 when testing suspect lines.