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

Simon Guindon simon.guindon at tomahawk.ca
Thu Jan 5 14:33:56 UTC 2006

Jingle INFO message sounds good to me. This way the gateway can take
this INFO message and whether it's a SIP, IAX or any other gateway it
can do its specific DTMF method based on the INFO.

Now on the subject of switching sessions assuming your client might have
3 calls on the go. Let's just think of the secretary model etc.

I'm not sure if we want to entirely put the logic on the clients
shoulders. I think this is a good idea for Jingle clients which will not
be hooking up to PBX's who will be getting multiple Jingle calls. But in
the case of someone hooking up to Asterisk, Asterisk has to be signaled
to put someone on hold, or transfer etc between lines as far as I
understand how Asterisk works and I may be wrong, but I believe Asterisk
is doing all the switching.

Could a Jingle INFO message be sent to the gateway to signal the PBX of
different call management features?

I like the idea of clients being able to switch themselves etc but
perhaps if the gateway supports a namespace indicating it has PBX
support the client must also signal to the gateway its call changes?


Simon Guindon
simon.guindon at tomahawk.ca

-----Original Message-----
From: standards-jig-bounces at jabber.org
[mailto:standards-jig-bounces at jabber.org] On Behalf Of Scott Ludwig
Sent: Thursday, January 05, 2006 2:03 AM
To: Jabber protocol discussion list
Subject: Re: [Standards-JIG] FW: Jingle - P2P and PBX calls

> So your client could let you talk to has many people as you want. I
> would imagine that the RTP socket would go silent as you switched
> between people. I'd have to check to see if Jingle specifies a hold
> Looking at Jingle, there doesn't seem to be an explicit hold/suspend
> state. Could someone mention why there isn't one? Tearing down a
> session and starting a new one seems rather dirty to me, or was the
> to transfer to some music playing service?

You can choose to listen / send to any jingle-audio session your
client is participating in. Switching is a client concept - you just
switch to another session. When you switch from A to B for example,
you're not sending audio to A any more (instead to B) - however the
session to A is still live and active, you are just listening /
sending RTP to B. You can switch back and forth this way.

However nothing prevents A from sending to you, since the session is
still active. Even though you aren't processing the RTP from A it
would still eat some bandwidth. Is that what you are suggesting, that
hold / suspending signaling could help save incoming RTP bandwidth?
That would be useful. It would be done with a jingle-audio INFO

The other comments about DTMF floating in this thread - it will get
added to jingle-audio. We're planning to add it as a jingle INFO
message. By sending it this way, it is associated with the right
session context.


More information about the Standards mailing list