[Standards-JIG] FW: Jingle - P2P and PBX calls

Simon Guindon simon.guindon at tomahawk.ca
Fri Jan 6 15:30:15 UTC 2006


I agree that it should use INFO but as I don't have as much knowledge in
the VOIP arena of things I wanted some more feedback.

 

It also opens it up to alternate protocols besides IAX/SIP etc to having
the control even though they may or may not have DTMF support
themselves.

 

Thanks,

Simon

 

-------------------------------------------------------

Simon Guindon

Tomahawk Technologies Inc.

simon.guindon at tomahawk.ca

www.tomahawk.ca

-------------------------------------------------------

________________________________

From: standards-jig-bounces at jabber.org
[mailto:standards-jig-bounces at jabber.org] On Behalf Of Thomas Charron
Sent: Thursday, January 05, 2006 4:51 PM
To: Jabber protocol discussion list
Subject: Re: [Standards-JIG] FW: Jingle - P2P and PBX calls

 

On 1/5/06, Simon Guindon <simon.guindon at tomahawk.ca> wrote: 

Yes Steve also mentioned to me on IRC that RTP can send DTMF. Is there
any cases where there is a benefit to sending this via XMPP perhaps in a
Jingle INFO or any other similar manner? I'm not sure which is the
better solution. In the future will some audio methods implement Jingle
that may not have DTMF support but may support putting people on hold,
transferring calls etc? 

  Personally, I'd use info.  This makes the RTP implementation simpler.
I can think of no logical reason NOT to do it over XMPP.

 

	Also about the putting people on hold and how SIP manages it. I
still believe we need this support in XMPP if Jingle is to connect to a
PBX. Reason being, it's the PBX that handles the call management, not
the client. If I understand Asterisk correctly, it is the one putting
people on "music on hold" or allowing a client to do call transfers etc.


	This means we must send commands to the Jingle-Asterisk gateway
to tell it what to do on a specific call 

	Or am I misunderstanding something?

 

  This sort of call control is always handled by using a (re)INVITE.
After thinking about it, this is a problem with the correct
specification.  There really IS no direct mapping for an INVITE or
reINVITE.  INVITE can also be used to renegotiate, and really, this
isn't addressed at all. 

 

  This sort of functionality would be, I suspect part of 'replace',
which, I'd like to point out, isn't defined.  The above conversation can
perhaps help solidify the usage of the replace action within jingle.
Hypothetically, with replace, you'd send a replace to place a user on
hold, or send one when you wanted to call to be on hold. 

 

  Thomas


 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060106/cffb3f79/attachment.html>


More information about the Standards mailing list