[Standards-JIG] FW: Jingle - P2P and PBX calls
scottlu at google.com
Thu Jan 5 22:43:21 UTC 2006
> > 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.
> 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.
There is a message for this, called "modify" (it might be written as
"replace" in the jep). It is up to the session type to handle modify
since it's meaning is session type specific (modify could just as
easily be an info message). The concept behind it is to re-negotiate
the session, within the same session context. This currently isn't
discussed in jingle-audio, but will need to be.
For hold, it is easiest to signal it as a specific action, through a
jingle-audio info message. Modify / replace would be if you want to
re-negotiate something about the session media, like format, or number
of streams, etc.
More information about the Standards