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
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:
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.
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:
- Call Addresses
- Service Discovery
- 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.
posted by Simon at
11:58 AM
|
0 comments
