Jingle Call Addresses

Ok so now that I am back from Mexico I have come back to some of these issues a bit fresher, I think I was getting a bit too consumed by thinking and rethinking this process that I lost a bit of what I was trying to achieve in the first place.

So in my original post I spoke about Call Addresses so lets focus on just this part first.

After speaking to Peter Saint-Andre, the Reachability JEP was introduced to me. This JEP seems quite useful for our problem, but now raises a few more questions.

Here is my question to the community:
If a client supports IAX directly, and you need to discover what extension to call him on whether its "555" and you are logged into a PBX (Asterisk) do you:

1. Query for reachability, which might respond with an extension of "555" and you simply dial this extension.
2. You use Jingle IAX which the extension is added in the candidates. (Jingle currently only supports IPs)

#2 is where I was focusing on prior to learning of Reachability. So which way is proper? Part of me wants to say Jingle from my previous thoughts, and extending Jingle to support more than IP end points.

Jingle Discussions

I've been doing a lot of discussions lately with many people around the community in various different sections. Some being XMPP, some being VoIP, Asterisk, Freeswitch etc. Also had a great talk with Jean-Louis Seguineau this morning (he beat me to blogging it but thats ok ;).

Much of what we talked about was rehashing some of the things I've mentioned in the past that needs to be addressed but I would like to take it further in the forefront now that these issues are becoming more important to others when at first it seemed I was the only one interested.

So firstly, before getting into the nitty gritty, lets assume a world where Jingle clients actually connect to a VoIP PBX such as Asterisk or Freeswitch. Let's not think of a closed box where its purely client to client VoIP such as what Jingle is currently.

The immediate outstanding issues are:

1. Call Addresses


2. Service Discovery


3. PSTN Access

1. Call Addresses
Currently Jingle candidate stanzas use IP addresses. Perhaps we need to change this to something more generic, such as a URI. For example. If I am a XMPP client also logged into the PBX via SIP or IAX I may want to send candidates stating:

• I can be reached at LAN IP 192.168.1.11


• I can be reached at my remote IP 216.52.22.11


• I can be reached at my IAX extension on Asterisk (server.com/555)


• I can be reached at my PSTN phone number 16135555555

From these candidates, the client can do a try approach. PBX would be tried first as it would be the most proper place to call. PSTN would be tried last as that would be the last resort I think as that is where costs incur.

Please read Jean-Louis's post here for more details about call uri's that we discussed.

These URI's are great but put a burden on the user to configure their client to know to send these URI's out. Obviously the client could detect its lan ip / internet ip seamless through some other means, but it cannot currently find a way to ask the PBX for its IAX/SIP URI or to query the gateway for a PSTN number they can be reached at.

2. Service Discovery
In my opinion we need some sort of manner to be able to query the server requesting additional contact details for a JID, this allows other clients to discover where they can contact you, and also allows you to discover where you yourself can be contacted from. Since Jingle is a client negotiation, we need the client to be able to discover its own surrounding so it can respond accordingly.

On second thought as well I think the contact details need to respond with what type the contact is. It could be a simple messaging contact. It could be a jingle contact.

I'm not sure if there is a JEP yet we could utilize for this but I'll throw in the worlds first pseudo-xmpp ;)

[juliet@server.com] - Queries server.com asking for contact details for juliet@server.com
[server.com] - Responds with items:
    - URI = juliet@msn.server.com
        - Basic Messaging Features
        - Jingle Support (In the future gateways may gateway to other IM audio)
    - URI = server.com/555
        - Jingle IAX (this is an IAX uri)

So now that the client can discover its available contact means, it can now populate its candidate fields for a Jingle request, and the other end can attempt a connection.

One could say this isn't needed if the user registers willingly with a gateway, such the same way msn etc does. In my next blog I think I will discuss how we can make gateways seamless. This I believe is important as well because some deployments may wish when a jabber account is created, the PBX automatically creates an IAX/SIP account and also voicemail, extensions etc.

You could do this manually backend, but think of this situation:

You are running a client that doesn't support Jingle IAX but you support Jingle RTP. But you use an IAX capable hard phone on your desk. pbx.server.com the gateway to Asterisk knows you have a phone on your desk. Your client if it could discover this, now in its Jingle candidates could send off an IAX response even though it doesn't support IAX itself. Now calls seamlessly go to your hard phone.

3. PSTN Access
With all this in place. Our client still doesn't know if we dial 5555555 how to call that phone number. I think we need some sort of PSTN identifier when we query a Jingle capable server/gateway to find out what supports PSTN. We need some way to identify this. I'm not sure exactly how to approach this yet.

Jingle and the phone world just seems to get more blurry for me and clearer at the same time the more I think ;) With XMPP there is so many ways to do the same thing. I would really appreciate some feedback on these things. Hopefully we can start hashing real solutions for these problems.

I believe we must solve #1 first, we need a way to better identify call addresses.

I think if servers and clients can get smarter this way we really have something going here.

Jingle & the outside world

I've been thinking again about Jingle. Spoke to some Asterisk guys, also met some great guys in the Freeswitch project. Discussed some ideas etc.

I really like Jingle and where this is taking us but I'm left a bit confused about some solutions I need to solve. Currently Jingle is mostly a client to client protocol. But what if we want more. What if the Jabber server has a PBX behind it. I envision something like:

jingle.server.com (supports Jingle Audio/Jingle IAX perhaps)
This allows us to map services such as voicemail@jingle.server.com etc.

What if we just wish to dial 555-5555 and call that real phone number?

I see a world where msn.server.com may gateway Jingle Audio, to MSN audio technology. So how will the client know where to call 5555555?

I think the client should be able to figure this out via Discovery. I don't think all Jingle destinations will be user JID's per say. I may want to dial 5555555@jingle.server.com, but how do I assume this?

Perhaps this is where Discovery comes in. Along with the jingle.server.com service responding to Discovery queries saying it supports jingle, perhaps there needs to be an identifier that says it supports anonymous alphanumeric calls.

This means the client can basically query and figure out "where can I call PSTN?" jingle.server.com replies "with me" then when I want to dial 5555555 I just dial 5555555@jingle.server.com.

That way even if I am on jabber.org, if I am registered with jingle.server.com when I discovery my gateways asking which supports PSTN I can dynamically find one and dial out of it.

A whole other problem though is, what if I have multiple gateways supporting PSTN, how do I give priority to one, or how do I say, well this gateway gives me cheap north american rates, so dial out for these numbers there, but if I dial a China country code go out another gateway because its cheaper.

Jingle seems clear to me client to client, but beyond that I get a bit foggy.

Thanks go out to Tony from Freeswitch for his time discussing ideas.

Please comment :)

I just got news that Peter Millard, long time Jabber client developer has recently passed away. I want to send my respects out to his family, friends and coworkers. I haven't spoken to Peter in several years but every time I did he was very friendly. A link to stpeter's blog says it best.

Nexxia in action

I've been meaning to do this for a week or so but just haven't been able to find the time. It's a grind at work lately but I decided to make time.

I've recorded a screen capture video of Nexxia Messenger's current build running on a week old build of Mono. Basically just displays System.Windows.Forms on Linux in general usage of Nexxia such as logging in, the UI, chatting etc.

Hoping to display some of the VoIP UI next time. I'm really looking for feedback of the main window and phone plugin as I'm finding the UI pretty crowded. But I would imagine 99% of the time the phone plugin would be minimized.

If anyone would like me to convert this video to another format please let me know. Also any comments/ideas would be great!

Video (Windows Media 9)
Video (Flash Player)

Poker time

I've always been a big poker fan but haven't been able to play as often as I would like. I don't think I've played for a few months now. We used to have a weekly game here at the office but I haven't been able to get enough people worth while to do it lately.

I decided to play a bit online. Nothing serious. It was a 20 person tournament. I decided I was going to play a tight aggressive style. I was pretty quiet most of the first half of game. I was still hovering about the initial chip count for most of it.

I got a couple good hands, bet very aggressive and it started to work out for me. After not very long I was 2nd in chip count for the tournament with 11k. They merged the taples into a final table and I started off pretty aggressive and jumped to 22k, still in 2nd as the first place guy had 60k so I was quite far behind.

I was happy with my play so far. I really like tournament play as people play more honest. Non-tournament play seems to be more all over the place and hard to read people etc.

Anyways shortly after I got pocket kings, which I decided were going to be good enough and I went head to head with the chip leader. Not so long later I got exposed to what always beats pocket kings. Yes. If you've played poker you've been there before. Doh!

VoIP call quality

So we did a bit of testing last week. Spoke with Sean over VoIP with my ATCOM-320 SIP/IAX2 phone calling his home PSTN phone. Voice quality seemed pretty good using the 711a codec (8KB/s I believe) but there was some real stuttering going on. Most of the time it was smooth but there was enough stuttering to get a bit annoying. I think once I can figure out what is causing that, we will have good call quality. Unfortunately I'm not a network guru so where the problem lies should be interesting to find out.

What we know of the network is:
- Server end currently is 3Mbit DSL on a Linksys WRT54G
- My home is 4Mbit DSL on a Linksys WRT54G

Placing one call between these two via the 711a codec @ 8KB/s shouldn't be a problem. Especially since the two are on the same ISP which via a ping to the PSTN provider is 35ms. Is this acceptable for VoIP? I don't know but it doesn't sound like a bad ping response to me.

Testing the ATCOM-320 and our Softphone software built into Nexxia, results in the same kind of stuttery/packet missing kind of sound. So it can't be the phone nor the software.

Will have to devise a way to do some network analysis.

More to come soon!

Digging into VoIP

Well I've recently started to ramp up the testing of VoIP technologies. I decided my immediate goals are:

1. Buy a SIP/IAX capable phone to test our servers and communication to Nexxia's soft phone software.
2. Buy an account from a PSTN provider (so we can dial out to real world phones).
3. Buy a DID (incoming phone #) so the real world can dial into Nexxia and the SIP/IAX hard phone.
4. Test between all those to evaluate reliability of the server, the software and the quality of the call audio.

I've basically now have all that in place except #3 as I'm having a bit of difficulty with Globotech's instructions.

I'm pretty happy with the reliability so far. Calls seem to go through every time. So far I'm a bit dissapointed with the call quality though. I need to do further testing of audio codecs though.

Latency doesn't seem to be too much of an issue but the audio does get choppy at times so I'm not sure whats causing that. Be it the connection between me and our provider, or if its the codecs used on the SIP/IAX hard phone, or the codecs used in Nexxia.

I hope to setup some tests so Sean and myself can evaluate it further. Perhaps get some others involved for further feedback.

Thanks go out to Matt O'Gorman for helping out with the Asterisk configuration.