Packetizer Forums

SIP is not an emerging protocol

2010-03-14T02:01:09Z

Why is it that after 14 years since the first publication of the SIP Internet Draft is it that people continue to refer to SIP as an "emerging" protocol? 14 years!?!?!

I herewith declare that SIP is NOT am emerging protocol.

ITU Initiates Focus Group on Cloud Computing

2010-02-25T16:20:56Z

The ITU is establishing a Focus Group to look at standardization issues related to Cloud Computing. For the Terms of Reference, refer to this document:

http://ftp3.itu.int/av-arch/avc-site/20 ... D-3853.zip

Paul

Welcome!

2010-02-12T22:38:45Z

Folks,

Welcome to the H.323 Global Network discussion area. These forums are open to anybody who wishes to ask questions about how to get involved in the project, configure equipment, etc.

Cheers!
Paul E. Jones
Rapporteur, ITU-T Q2/16

Google's phone has arrived

2010-01-06T05:35:03Z

Folks,

Some might have been hiding under a rock and missed the announcement earlier:
http://www.dailypayload.com/content/3371

This looks like a very impressive device. If you've not had a chance to play with other Android devices, you really ought to visit your local wireless store and do that. I think Google is setting the stage for a significant shift step forward in terms of what we can do with mobile devices.

Apple has had a good run and, quite frankly, I think they're going to be forced to make some changes in order to compete against the forthcoming Android devices. Knowing Apple, I'm sure they've got something planned.

In any case, this device really looks cool.

Paul

(Still using an old Windows Mobile device...)

Re: t38FaxMaxDatagram (H.245)

2009-12-18T19:56:44Z

This parameter represents the largest size of the datagram that can be accepted by the receiving device. This does not count RTP headers, for example. There is debate as to whether this counts redundancy, but I think the general consensus is that it does not consider redundancy. So, if a device that advertises 72 octets also supports redundancy can actually receive larger UDP packets (containing the primary and redundant data), but the intent is that the primary fax data would not consume more than 72 octets.

This and many of the T.38-related parameters have been a source of confusion and, for that reason, there are currently three efforts underway to work to clarify how T.38 is supposed to work. It is expected that a new revision of T.38 will be made available next year with better definitions. And, you're definitely encouraged to contribute. Part of the work is going on in the SIP Forum (where I'm engaged). Some of the work is going on in the ITU (in which I am indirectly involved). I just recently learned that i3 Forum is also doing work in this area.

t38FaxMaxDatagram (H.245)

2009-12-18T07:02:18Z

Paul, please help me to understand the correct meaning of t38FaxMaxDatagram. When using UDP TL does this parameter define the maximum UDP data size which receiver CAN process? If receiver sets t38FaxMaxDatagram = 72 should sender transmit UDP packets with no more than 72 bytes of data?

Re: Help parsing OLC info in H225 messages

2009-12-07T01:52:17Z

Yes the change I made does apparently trick the compiler into thinking it is a different type. When I decode a message with debug printing enabled it calls it an OpenType and then I can decode that as an OpenLogicalChannel_PDU. Without that change it just considers it a sequence of octet stream but then I can't decode it because I have no way of decoding OpenLogicalChannel types. There are a very small (14) number of messages types that are defined as decodable PDUs and that is not one of them. Once it is defined as a new type my compiler also adds the ability to decode OpenLogicalChannel_PDU types.
Again, I'm constrained by the tools we currently use and have to rely on what the compiler will generate from the asn files and then subsequently what it deems as decodable types. I'm not in a position at this time to upgrade our tools although as time goes on that may become necessary.
If this does the trick for now (which it appears it will) I'll probably just got with it. BTW I found that little change to the asn somewhere in my random downloads trying to get around this issue so somebody else must have been having a similar issue. There was another change having to do with h245 tunneling that I didn't grab but may need ultimately.

Diana

Re: Help parsing OLC info in H225 messages

2009-12-05T20:55:27Z

I am sure there is a reason why it was defined that way at the beginning, but I can't say why now. Perhaps it was just to avoid importing types from H.245. Indeed, we did not import types from H.245 until H.323v3.

The change you made I suppose tricks the compiler into thinking the type is a different type, but I've never found that to be necessary with the tools I used. I would decode the message and then pass a pointer to the buffer to the decode() routine. As a parameter to the deocde() function, I could explicitly tell it that it was an OpenLogicalChannel type. All ASN.1 decoders must do that, since it must be told what kind of PDU it is decoding. I've never found it necessary to modify the ASN.1 to accomplish what you want to do.

Paul

Re: Help parsing OLC info in H225 messages

2009-12-04T23:22:51Z

I agree decoding/reencoding is a better way to go but I'm somewhat constrained by the tools at hand.
Regardless I did figure out a change to the h225 asn file that when compiled would generate a .c and .h file that allowed me to decode the fastStart elements:

< fastStart SEQUENCE OF OCTET STRING OPTIONAL,
---
> fastStart SEQUENCE OF TYPE-IDENTIFIER.&Type(OpenLogicalChannel) OPTIONAL,

Once I decode each element I can access/modify the fields of the element without stepping through the bytes.

Wonder why the h225 asn files still have it defined as in my original.

Oh well problem solved. Now on to the real problem at hand - setting up proper tcp/udp sockets for a fastStart call.

Thanks.

Re: Help parsing OLC info in H225 messages

2009-12-04T00:33:34Z

You are correct that they're fairly easy to parse. The options you have are to just step through the OLC with hand-written code or to use an ASN.1 encoder/decoder. Parsing it by hand is doable, but one has to be careful to watch each bit to ensure that the proper address and port fields are identified.

Personally, I'd prefer to run it through an ASN.1 decoder and then re-encode them. For most ASN.1 decoders, this is nothing more than calling a decode function, dereferencing the C structure containing the address and port and changing it, then calling encode() to re-encode it.

Obviously, one can save clock cycles by parsing the PER message by hand, but is it worth it? That's hard to say. But, if you want to understand more about the intricacies of ASN.1 PER encoding, there are folks on the board with this skill (or I'll invite them over for a discussion) and/or you could post questions to the ASN.1 mailing list: http://www.asn1.org/discuss/mailing/index.htm

Paul

Help parsing OLC info in H225 messages

2009-12-03T22:12:03Z

In the H225 messages Setup, Connect, ... the fastStart items are parsed as a sequence of octet streams. Each of these is actually an OLC but can't seem to parse those. The few formats that I have definitions for seem easy enough to parse but I'd like definitions for all of them.
The ones I found are in the implementation notes of this http://lists.packetizer.com/pipermail/i ... chment.doc
I need to extract all addresses and ports from the OLCs.
Does anybody have a thought/suggestion?

SIP Forum T.38 Problem Statement

2009-11-22T07:27:58Z

Folks,

You might find this interesting:
http://tools.ietf.org/id/draft-jones-si ... ent-00.txt

If fax is of interest to you, perhaps you might want to get involved in the SIP Forum's fax-related work.

Paul

Google Phone is real...

2009-11-19T20:01:14Z

http://www.dailypayload.com/permalink/3329

Asterisk h323 with Nortel GK

2009-11-12T00:08:07Z

I am having trouble getting a stable working Asterisk H323 to work with a Nortel GK.

I had version 1.4 and the NuPhone Stack with openh323 1.18.0 and pwlib 1.10.3 working reasonably stable but due to other issues was forced to go to now 1.6.2rc4. I have not been able to get the system stable since with versions of openh323 or H323plus. I get core dumps that always have openh323 and ptlib as culprits of crashes of asterisk.

I have now downloaded and installed h323plus v 1.21.0 and ptlib 2.4.5 and have successfully compiled the Asterisk H.323 but now I am getting an error when trying to restart asterisk with "amportal restart" that an openh323 library cannot be found.

Where did I go wrong?

H.323 version 7 approved

2009-11-06T14:25:35Z

Folks,

The ITU approved H.323 version 7 today, along with new NAT/FW traversal procedures that allow media to flow directly between endpoints, even when endpoints are behind different NAT/FW devices.

For more details about what's in v7 and related documents, see:
http://www.packetizer.com/ipmc/h323/whatsnew_v7.html

Paul

G.711.0 - Compressed G.711

2009-10-13T20:40:10Z

Folks,

The ITU formally approved a new Recommendation for audio coding that is sure to grab some attention. It's a lossless compression algorithm for G.711, supporting both a-law and mu-law.

As most people know, using codecs like G.729 results in reduced audio quality. Compressing, decompressing, mixing in a conference bridge, re-compressing, and then decompressing results in an even more degraded audio performance. An these steps are not uncommon when calls pass through different carrier networks.

G.711.0 suffers absolutely no loss whatsoever and the compression is very good. It can be compressed and decompressed any number of times and no reduction of quality occurs, because the compression algorithm is a lossless algorithm. When there is silence, the codec consumes virtually no bandwidth at all. When there is speech activity, then the bandwidth it consumes varies, with as much as 50% reduction in bandwidth.

This is significant. G.711.0 has been the standard for telephone systems for years and virtually everything is designed for its use, including conference bridges, modems, fax devices, etc. While it is unlikely that any real compression would be seen if a modem is employed, it can significantly reduce the bandwidth required for most voice calls. Rather than consuming 80Kbps (G.711 with IP packet overhead using 20ms per packet), it will be possible to see bandwidth consumption below 64Kbps for most calls. The reason that is significant, of course, is that existing T1/E1 infrastructure can more easily be replaced with IP without sacrificing any audio quality whatsoever and without reducing the number of simultaneous calls that can be placed over that existing infrastructure.

The document has not yet been posted, but when it has undergone final edits, it will be posted here:
http://www.itu.int/rec/T-REC-G.711.0/en

Paul

Re: Open Source Projects

2009-10-05T23:11:22Z

I did not get an overwhelming response to the poll to create groups related to open source, but the majority did express a desire to have such a sub-group. Further, I continue to see a lot of questions asking questions on open source projects. So, I think there is a need. As such, I created the sub-category. We will see how it goes, but I hope that people will find it useful. Can you direct people directly to the sub-category with this URL: viewforum.php?f=45

By all means, feel free to suggest groups that are not listed. I did not list Asterisk, because there is already a vibrant discussion forum for that at http://forums.digium.com/. Should I include a note about that somewhere in that section?

Cisco to Acquire TANDBERG

2009-10-01T19:33:17Z

This is the big news story of the day:
http://www.dailypayload.com/3288

I think this is great news, as I believe we are about to see videoconferencing truly leave the niche market it has been in for 20 years and finally go mainstream.

Paul

Re: Avaya, Nortel, and Skype

2009-09-28T15:44:51Z

My personal opinion that the Avaya/Nortel merger is a bad idea. There are some good products and engineers on both sides, but the fact is that they compete directly with each other. How can two companies struggling to make a profit bring together overlapping product portfolios and then expect to do better? The only rationale that makes sense to me is that they're removing a major competitor from the market.

The Skype element is really interesting. They would not necessarily have to merge the Skype technology with the Avaya/Nortel products, but work to ensure that the SIP trunk offered by Skype works flawlessly with their equipment. They would also need to have extremely favorable pricing. In that way, every customer can be offered an option to bypass the incumbent carrier with some very attractive prices.

Perhaps the days when an enterprise is charged a high monthly "line charge" for every incoming line are over?

Re: Avaya, Nortel, and Skype

2009-09-25T15:25:11Z

The path of least resistance says that it only appears interesting on the surface, and that the investment firm is simply broadening its industry portfolio. I'm inclined to believe that, given the amount of effort it would take to coordinate those three disparate companies.

That said, it seems like it could be a conscious effort to get an early position into the Google Voice competitive space. I'm not exactly sure what the play would be, but I'm thinking something like selling hard phones which integrate deeply with Skype and are supported by call centers?

Spam and idiotic spam prevention

2009-09-25T02:03:38Z

Folks,

Earlier today, I tried sending a message to the H.323 Announce list to let everybody know about the potential new work in the H.323 Forum on "Open Community Specifications" (or whatever this might be called). I sent out the message and, little did I know, but our server was blacklisted on UCE PROTECT's mail server (full details).

Sadly, about 20 subscribers got kicked off the H.323 Announce list, because of this blacklisting problem.

If your employer or service provider is using UCE PROTECT, may I suggest you encourage them to stop. I've made every effort to try to reason with those folks, but it appears they're not willing to change their policies.

I can only apologize to those who got kicked off the list, but there was absolutely nothing I could do about it.

H.323 Forum Open Community Specifications

2009-09-25T01:58:08Z

I just wanted to make everyone aware of a proposal that was made to do some work in the H.323 Forum on a set of specifications tentatively called H.323 Forum Open Community Specifications. The intent is to make it easier for people to collaborate in the development of both informational documents and protocol extensions for H.323. The latter class of documents would allow the H.323 community to bring forth new capabilities that might include such things as text messaging to file transfer.

I would encourage you to visit this page:
http://www.h323forum.org/specifications/

Re: H.323-SIP SBC with T.38 pass-through support

2009-09-17T15:34:08Z

To be entirely honest, I've never seen an open source SBC product that performed H.323/SIP interworking. There are several commercial products, including ones from Cisco and Acme Packet.

I would be interested to know if there are any, though.

Paul

H.323-SIP SBC with T.38 pass-through support

2009-09-17T05:26:46Z

Does anyone know any OPEN-SOURCE SBC which provide H.323-SIP interworking WITH T.38 PASS-THROUGH support? Or am I asking for too much ?

Avaya, Nortel, and Skype

2009-09-16T03:22:33Z

Folks,

For those of us in the industry, it is hard to ignore the fact that Avaya, Nortel's enterprise telephony business, and Skype will all be controlled (directly or indirectly) by the investment firm Silver Lake. See this:
http://www.dailypayload.com/content/3274

Do you think they plan to play strongly both as an equipment provider and as a carrier, or are these really disjoint efforts that just look really interesting on the surface?

Paul

Open Source Projects

2009-09-01T03:38:53Z

I am curious: would people benefit from a sub-forum under the "Product Development and Deployment" section that covers the various open source projects? For example, have a forum that reads "Open Source Projects" and then when you click on that, it would lead you to a set of additional forums, one for each of the various projects folks suggest to add, which might be for things like OpenMCU, H323Plus, GnuGK, Kamailio (formerly OpenSER), etc.

Take the poll and/or feel free to post a comment.

Paul

Re: CISCO GK Opinions

2009-08-28T02:30:07Z

Guy,

It's certainly doable, but I suppose the opinion of good or bad depends on the kinds of features or functionality you want to get out of the Gatekeeper.

Here's an old presentation, but perhaps still somewhat useful:
http://www.vide.net/conferences/spr2002 ... /kirby.ppt

If you dig around looking for documentation on the GK, you might also find documentation on the "MCM Proxy". I believe that functionality is still in the Cisco IOS Gatekeeper, but I do not believe it is supported any longer. Regardless, there is a newer product that replaced that called the Cisco Unified Border Element (CUBE). As the name suggests, it is a border element that can be used to route call signaling and media.

As shown in the presentation, the Gatekeepers are designed to resolve addressed across the entire network by sending LRQ messages (as defined in H.225.0) to other Gatekeepers. This is all done through static provisioning, but it's highly scalable and designed for carriers -- and it's used by a number of carriers. Nice thing is the functionality is available in smaller enterprise class routers.

The Cisco Gatekeeper has the ability to register terminals, but its strength is in managing Gateways, ensuring that the proper gateway is selected, calls are load balanced across a set of Gateways, etc. It lacks the ability to use H.323 URLs, for example, as a part of address resolution. That said, I'm not sure if an commercial devices use H.323 URLs, anyway. (I know some of the open source products do, but commercial products tend to stick with phone numbers.)

I hope that help.

Paul

Re: IM Federators or aggregators

2009-08-27T20:41:53Z

I am not personally familiar with their product, but it looks like one of the several "all-in-one" clients that connect to a multiplicty of networks simultaneously. I don't think there is any real magic in that, though there's certainly work required to interface with all of those various networks.

IM Federators or aggregators

2009-08-27T08:48:51Z

Could some one point the implementation of federators/aggregatros such as nimbuzz .

When inter working with google it act as a federator .
But if you give your yahoo user name or password , whether nimbuzz server is acting as a client for you .

Or operators like nimbuzzz is having special agreement with yahoo, MSN and uses some polling or watcher mechanism to get mmy buddy's status for me?

Re: Vendor Opinions - LifeSize

2009-08-27T04:07:52Z

I don't really have an opinion, just a comment. I was at Polycom when the CTO left to form what would become LifeSize. I heard that he couldn't get the board (or company?) to approve funding to develop a new camera lens, so he left. That's about all I know.