Speaking of Standards

Upon the completion of SDP negotiation, the media server essentially gets a media pipe to the client, represented as the NetworkConnection. Now, to have some fun, we need to connect that pipe to a multimedia studio that can play, record, and recognize different sound.

MediaGroup

This multimedia studio is called MediaGroup in Java Media Control API.  MediaGroup contains four Resources — Player, Recorder, SignalDetector, and SignalGenerator. Once a MediaGroup is connected to a NetworkConnection, you can use these Resources to, e.g. play music to the client.

MediaGroup can be created from a MediaSession based on a Configuration and, optionally, Parameters.

MediaSession.createMediaGroup(Configuration);

The Configuration indicates to the media server what Resources that the application might be using (or not using). Thus the media server can allocate appropriate resources for this MediaGroup. Typically you will use one of the pre-defined Configurations

• PLAYER: Use this when the application will only use Player in this MediaGroup.
• PLAYER_SIGNALDETECTOR: Use this when the application will only use Player and SignalDetector in this MediaGroup.
• PLAYER_RECORDER_SIGNALDETECTOR: Use this when the application will use all Resources but SignalGenerator in this MediaGroup.
• PLAYER_RECORDER_SIGNALDETECTOR_SIGNALGENERATOR: Use this when the application will use all Resources in this MediaGroup.

To use the MediaGroup, simply joining the NetworkConnection with the MediaGroup. (See Media Object Composition about join concept.) Now you can provide multimedia functions for the client by using different Resource in the MediaGroup.

NetworkConnection nc = ...
MediaGroup mg = session.createMediaGroup(MediaGroup.PLAYER_RECORDER_SIGNALDETECTOR);
nc.join(mg);
mg.getPlayer().play(URI.create("http://myserver.com/mysong.wav"), RTC.NO_RTC, Parameters.NO_PARAMETER);

Let’s take a look what you can do with each Resource in the MediaGroup.

Player

Player can be used to play media streams from a URI (or a set of URIs). For example, the following code snippet shows how to play a song from a Web server.

mg.getPlayer().play(URI.create("http://myserver.com/mysong.wav"), RTC.NO_RTC, Parameters.NO_PARAMETER);

If the media server supports text-to-speech, you can use SSML to render text into synthesized speech. For example,

final static String HELLO_WORLD_SSML = URLEncoder.encode("application/ssml+xml, <?xml version=\"1.0\"?><speak><voice>Hello World!</voice></speak>", "UTF-8");
mg.getPlayer().play(URI.create("data:" + HELLO_WORLD_SSML), RTC.NO_RTC, Parameters.NO_PARAMETER);

You can ask the Player to play multiple items at once by giving an array of URIs.

To stop playing, simply call stop operation to stop either the current item being played or all the items in the queue.

You can also pause and resume the play, as well as adjusting speed and volume.

Recorder

Recorder can be used to record media to URI. For example, the following code snippet shows how to record your voice into a file on a Web server.

mg.getRecorder().record(URI.create("http://myserver.com/mysong.wav"), RTC.NO_RTC, Parameters.NO_PARAMETER);

To stop recording, simply call stop operation.

You can also pause and resume the recording.

SignalDetector

SignalDetector can be used to collect user input based on a set of patterns. For example, the following code snippet tries to receive one DTMF input from the user.

mg.getSignalDetector().receiveSignals(1, SignalDetector.NO_PATTERN, RTC.NO_RTC, Parameters.NO_PARAMETER);

The use of Parameter and pattern label in Java Media Control API is a bit akward. I will explain more in the future blog.

Similarly, you can call stop() to stop the receiveSignal operation.

SignalGenerator

SignalGenerator can be used to generate signal into the media server. This is typically used when the DTMF input are received via SIP INFO.

Sample Application

Here is a sample application that will announce “Hello World” after you dial into it. Then it will ask you to input “1″ for replay. Any other key input will determinate the call.

To run this sample, assuming you have Voxeo Prism downloaded and installed, simply drop the Tutorial.3.war to <prism>/apps directory. Once you have Voxeo Prism (both Application Server and Media Server) started, simply dial “sip:user@localhost” from your SIP phone such as SJPhone or XLite.

Source code is included in the sample .

Are you attending SIPNOC next week in Herndon, Virginia? If so, are you interested in talking with others about real-time communication over IPv6?

SIPNOC organizer Marc Robins spread the word today that a number of BOFs (“Birds-Of-a-Feather” sessions… loose, informal gatherings) would be held at SIPNOC, including a 2-part BOF on “IPv6 Readiness“. Time has been allocated on the agenda for the IPv6 BOF on Tuesday, April 26, 2011, at:

3:00-3:45pm

5:45-6:30pm

In both cases the IPv6 BOF will meet in the “Luray E” room.

I’ll be there at SIPNOC speaking about lessons we’ve learned at Voxeo in large-scale SIP interoperability and also on the topic of SIP security. Naturally, you can expect that I’ll be at both of these IPv6 sessions, too!

To continue my Java Media Control blogs, before we can talk about media operations, we need first talk about media object composition concept. Media objects are composed together for media processing and functions. E.g. a NetworkConnection, which represents the client, connects to a MediaMixer to join a conference.

Join

A composable media object is called Joinable in Java Media Control API. When a joiner joins with a joinee, the media streams are connected between them. You can even specify the directions of the media streams when joining.

• DUPLEX means the media streams can flow both ways.
• RECV means the media streams can flow from joinee to joiner only.
• SEND means the media streams can flow from joiner to joinee only.

Here is code sinppet that shows how to join a NetworkConnection and a MediaGroup.

      NetworkConnection nc = ....
      MediaGroup mg = ....
      nc.join(Joinable.Direction.DUPLEX, mg));

To decompose, you simply unjoin the joinee from the joiner.

Asynchronous Join

join won’t return until the composition is completed. If you don’t want to wait for the the completion, you can use the asynchronous joinInitiate method, which simply initiates the composition. A Joinable object that supports asynchronous join must be a JoinEventNotifiers so it can send the composition result back as a JoinEvent. This is very similar to media event model, as illustrated in the following digram.

Similarly, you can also use asynchronous unjoinInitiate method to start the decomposition and get notified by the event for the decomposition result.

Re-Join

A pair of joined Joinables can be re-joined, potentially change the existing media stream directions.

E.g. the following code snippet shows how to change a fully connected NetworkConnection to listen-only mode.

     nc.join(Joinable.Direction.DUPLEX, mg));
     ...
     nc.join(Joinable.Direction.RECV, mg));

Multiple Joins

A media object can be joined to more than one media object to form a graph of composition. However, one important rule here is any media object, except MediaMixer, can talk to many other media objects but only listen to one media object.

A simple use case of this is illustrated by the following diagram from Java Media Control API spec.

In this diagram, the Fred’s NetworkConnection NC2 joins to both Mark’s NetworkConnection NC1 and a MediaGroup. Please note, in this case, you can not use the Player of the MediaGroup since it violates the talk-to-many/listen-to-one rule as Fred can only listen to Mark right now.

Join Degradation

Please note in the above example, NC2 is explicitly joined with SEND direction with the MediaGroup. What happens if NC2 joins the MediaGroup with DUPLEX? I.e.

      NC1.join(DUPLEX, NC2);
      NC2.join(DUPLEX, MGASR);

This will cause so called Join Degradation — the join between NC1 and NC2 will be degraded from DUPLEX to RECV only. I.e. Fred can speak to Mark but not heard from him. Rather Fred will hear from whatever plays in the MediaGroup. The Join Degradation basically means the last joined DUPLEX pair wins and all the previous joined pairs will change according to the talk-to-many/listen-to-one rule.

Last Friday, April 8, 2011, the US National Telecommunications and Information Administration (NTIA) announced the release of what they called an “IPv6 Readiness Tool”. The “tool” is available for public usage at:

http://www.ntia.doc.gov/advisory/IPv6/index.html

While I was admittedly thinking the “tool” would be some type of script or other program to help scan your network infrastructure, the “IPv6 Readiness Tool” is in fact an Excel spreadsheet that provides a solid checklist for businesses to consider when assessing the readiness of their organization.

The meat of the spreadsheet template is a tab “Assessing State of Readiness” that looks not only at technical issues, but also questions related to the wider organization including internal developers, product management, purchasing, sales and more. There are also additional tabs for “Costs“, “Risks” and “Contingencies & Exposures“.

NTIA has also provided an Executive Summary with their description of the tool.

All in all the spreadsheet does provide a rather comprehensive list of things to think about when assessing the readiness of your company or organization for IPv6 usage. Kudos to the NTIA for putting it together and hopefully it will be helpful to many agencies, companies and other organizations as they look at how ready they are for IPv6.

P.S. There was also a post on the White House blog about this tool from U.S. CTO Aneesh Chopra.

For those of you following the ongoing “RTCWEB” work to bring about standards for real-time communications from within web browsers, there are now two new public mailing lists that you can join – and are where all the RTCWEB activity is now intended to happen.

On the IETF side, as part of the new charter for the RTCWEB work, there is now a mailing list at:

https://www.ietf.org/mailman/listinfo/rtcweb

You can subscribe and also view the archive from that page.

On the W3C side, a working group is still forming there, but the mailing list is now up for subscription at:

http://lists.w3.org/Archives/Public/public-webrtc/

The W3C list was literally created today, so there has not yet been any activity on that list.

The work of the RTCWEB initiative is now moving into the standards bodies… and so if you want to monitor or participate in the work, you’ll need to join those mailing lists.

Today the folks organizing the Canadian IPv6 Summit (mentioned previously on this blog) on Friday, April 29, 2011, in Ottawa, announced the tentative schedule at:

http://ipv6summit.ca/index.php/v6/2011/schedConf/schedule

and the list of presenters and their abstracts at:

http://ipv6summit.ca/index.php/v6/2011/schedConf/presentations

It looks like a great agenda with a good mixture of business and technical sessions. Sadly, I won’t personally be able to attend, but it looks to be a great session for those interested in learning more about IPv6 in general – and how to make the move to IPv6.

Kudos to the IPv6summit.ca team and I wish them all the best for their event!

Looking for a softphone that lets you easily make VoIP calls over IPv6 using the SIP protocol? I was looking to do this and after trying several of the common SIP softphones I knew of, several people pointed me over to Linphone which turns out to work like a charm! I knew of Linphone from a number of years back, but I mistakenly thought it was Linux-only… nope! It truly is cross-platform with binary versions for Windows and Mac OS X, and source available for Linux distros – plus versions for iPhone, Android and Blackberry.

With really just one configuration change, here is what it looked like to make a SIP call using IPv6 addresses (well, almost what it looked like since I did mask the actual addresses, being as security-paranoid as I am):

In the top address field I simply entered the SIP address using the standard format:

sip:user@ipddress

with the exception that because it is an IPv6 address I enclosed the address in square brackets (per RFC 3986). That’s it. I was off and making my call.

The One Configuration Step (and the caveat)

All I had to do to make this work was go into the settings (which you get by going to the “Windows” menu and choosing “Preferences” on Mac OS X) and checking off the box that says to use IPv6:

After checking that box and pressing “Done”, Linphone changed my identity to show my local IPv6 address and let me start making calls to IPv6 addresses.

The caveat

Now whether this “just works” does depend upon how you are connected via IPv6.

In my case, I use Tunnelbroker.net to have IPv6 in my home office (which I explained previously how to configure for Apple devices and for generic devices). The effect of doing this is that…

I am directly connected to the IPv6 side of the Internet.

So for me, the screen above with the radio button next to “Direct connection to the Internet” works fine. If you are behind a IPv6 NAT or gateway device, you may need to adjust the settings here.

Indeed, when I used Linphone for testing with IPv4, I did need to change the options myself, because for IPv4, my home network is behind a NAT / firewall. In my case I went for the second of the three options and provided my external IP address:

So you may need to adjust these settings in order to have Linphone work with IPv6.

Now, Linphone is a pretty bare-bones SIP client… it doesn’t have all the features and frills of many of the other clients out there… but that’s okay… all I wanted to do was test out the ability to make calls using SIP over IPv6. And for that it worked great!

As a bonus, it does not require you to set up a SIP account and register with a SIP registrar. You can just use it for direct computer-to-computer calling… which again is exactly what I needed in this case.

I’ll be writing more about making SIP calls over IPv6 in the weeks and months ahead… but in the meantime I thought I’d pass along this info.

I’ve tried Jitsi, the rebranded “SIP Communicator”, but it seemed to require me to set up a SIP account before I could make calls… and I don’t have an IPv6-compliant SIP system to which I can register.

In any event, I’m greatly impressed with Linphone… kudos to the team there for making it work so well over IPv6!

P.S. Thanks to some Voxeo colleagues for the recommendation of Linphone and also to someone in the #ipv6 IRC channel on Freenode (mentioned in this post).

As I’ve continued to work with IPv6 on my home network (which I set up using these instructions), one question was whether I could use IRC natively over IPv6. Turns out that this is incredibly trivial if you use Freenode as a IRC network, as I do. From the Freenode FAQ all you need to do is open a connection from your IRC client to:

irc.ipv6.freenode.net

That’s it. Once connected you simply join IRC rooms as you would through the normal IPv4 connection. (A good one, naturally, would be the “#ipv6″ room if you are interested in the topic.)

I connected in without any problem and it’s been working fine. (The client I use on my Mac is Colloquy, pictured above.) I’ll note that Freenode has somewhat conflicting instructions elsewhere on their site, where they say that IPv6 access can just happen over the regular addresses… but the “irc.ipv6.freenode.net” address worked great.

If you don’t use Freenode for IRC, there is a longer list of IRC servers at:

http://en.linuxreviews.org/IPv6_supported_IRC_servers

P.S. While you are on IRC on Freenode, why not join “#tropo” and hang out with our Voxeo Labs team talking about our Tropo cloud communications service?

Carrying on a fine tradition, the IETF today released RFC 6214, which adapts the venerable RFC 1149 (from 1990) for IPv6.

If you are not aware, RFC 1149 defines, of course, IP-over-carrier-pigeon.

RFC 6214 does outline some of the challenges with IPv6 with regard to avian carriers:

As noted in RFC 1149, the MTU is variable, and generally increases with increased carrier age. Since the minimum link MTU allowed by RFC 2460 is 1280 octets, this means that older carriers MUST be used for IPv6. RFC 1149 does not provide exact conversion factors between age and milligrams, or between milligrams and octets. These conversion factors are implementation dependent, but as an illustrative example, we assume that the 256 milligram MTU suggested in RFC 1149 corresponds to an MTU of 576 octets. In that case, the typical MTU for the present specification will be at least 256*1280/576, which is approximately 569 milligrams. Again as an illustrative example, this is likely to require a carrier age of at least 365 days.

Furthermore, the MTU issues are non-linear with carrier age. That is, a young carrier can only carry small payloads, an adult carrier can carry jumbograms [RFC2675], and an elderly carrier can again carry only smaller payloads. There is also an effect on transit time depending on carrier age, affecting bandwidth-delay product and hence the performance of TCP.

I did very much enjoy this part of section 5:

Routing carriers through the territory of similar carriers, without peering agreements, will sometimes cause abrupt route changes, looping packets, and out-of-order delivery. Similarly, routing carriers through the territory of predatory carriers may potentially cause severe packet loss. It is strongly recommended that these factors be considered in the routing algorithm used to create carrier routing tables. Implementers should consider policy-based routing to ensure reliable packet delivery by routing around areas where territorial and predatory carriers are prevalent.

There is evidence that some carriers have a propensity to eat other carriers and then carry the eaten payloads. Perhaps this provides a new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa. However, the decapsulation mechanism is unclear at the time of this writing.

All in all a fun bit of work… enjoy!