I'd like to get feedback on a crazy proposal I've been batting around. Many
times an XMPP client or other JID is in a context where it has some access
to PSTN (either because the client is on a cell phone, or it has access to a
VoiP bridge, or it *is* a VoiP gateway of some kind). Jingle could be used
to initiate a voice session whose peer-to-peer component is routed entirely
over PSTN in these cases. For example, [email protected] wants to talk to
[email protected] and indicates that one option for contact is to call
+15557254545
<iq from='[email protected]/orchard'
id='ph37a419'
to='[email protected]/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='[email protected]/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:pstn:1' />
<transport xmlns='urn:xmpp:jingle:transports:pstn:1'>
<candidate id='el0747fg11'
tel='+15557254545' />
</transport>
</content>
</jingle>
</iq>
ACK:
<iq from='[email protected]/balcony'
id='ph37a419'
to='[email protected]/orchard'
type='result'/>
[email protected] accepts the session, and indicates that other options
include calling +15557253232 with callerid set to +15557772222 or calling
+15558881234 and then adding the DTMF string *714:
<iq from='[email protected]/balcony'
id='jd82f517'
to='[email protected]/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
responder='[email protected]/balcony'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:pstn:1' media='audio' />
<transport xmlns='urn:xmpp:jingle:transports:pstn:1'>
<candidate id='el0747fg11'
tel='+15557253232'
callerid='+15557772222' />
<candidate id='el0747fg11'
tel='+15558881234'
dtmf='*714' />
</transport>
</content>
</jingle>
</iq>
ACK:
<iq from='[email protected]/orchard'
id='jd82f517'
to='[email protected]/balcony'
type='result'/>
[email protected] selects a mechanism (this part is maybe tricky in some
cases: since some selections will cost one party more money and others the
other party more money -- I guess still just using priority numbers? I
mean, if you offered a candidate clearly you're ok with it being used.) and
lets [email protected] know:
<iq from='[email protected]/orchard'
id='pd81b49s'
to='[email protected]/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-info'
initiator='[email protected]/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='audio'>
<transport xmlns='urn:xmpp:jingle:transports:pstn:1'>
<candidate id='el0747fg11'
tel='+15558881234'
dtmf='*714' />
</transport>
</content>
</jingle>
</iq>
ACK:
<iq from='[email protected]/balcony'
id='pd81b49s'
to='[email protected]/orchard'
type='result'/>
And then [email protected] uses whatever PSTN connection it has available
to call +15558881234,*714. Once the PSTN session has ended (because Juliet
hung up, or similar) the session is over:
<iq to='[email protected]/orchard'
id='bv81gs75'
from='[email protected]/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-terminate'
sid='a73sjjvkla37jfea'>
<reason>
<success/>
</reason>
</jingle>
</iq>
ACK:
<iq to='[email protected]/balcony'
id='bv81gs75'
from='[email protected]/orchard'
type='result'/>
Hopefully the above is clear enough to discuss. My main use case is a PSTN
Gateway which could, on receiving an inbound call, be told by the XMPP
client to forward the call over PSTN to a receiving number (either with
upstream caller id or rewriting caller id, depending on application).
However, I could see something like this being used to enable XMPP contacts
to call each other over PSTN directly (without advertising a permanent
telephone number in vCard, but instead giving out numbers on a case-by-case
call-establishment basis), or many other cases.
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
