Dial And Bridge

Home » Asterisk Users » Dial And Bridge
Asterisk Users 11 Comments

Hi all, I need some advice – I have been working on originating multiple calls using AMI and then joining them. What I want to do is:
– dial call 1 (where the caller is in a “channel” format, like SIp/1234 or Local/1234@ext) and “park” it somehow
– dial call 2 (where again the caller is in channel format) and join it to the previous call.

As a requirement, I cannot use the dialplan as an end-point (as I cannot change it) but need to use the AMI only.

I tried doing something like:

Action: Originate Channel: Local/300@from-internal Async: 1
Application: Wait Data: 1973

So that the call goes to 300 and then basically stays there forever, and then I dial again:

Action: Originate Channel: Local/500@from-internal Async: 1
Application: Wait Data: 1973

And then try to bridge the results, but it does not seem to work. What I would like to do would be more on the lines of:

Originate call 1 and park it (using a park or waiting)
Originate call 2 and bridge it immediately to call1 (using the Application part)

But maybe I am missing something? is there anybody who has better suggestions?

Thanks l.

11 thoughts on - Dial And Bridge

  • Dial first call and put it into a conference, then dial second call and put him into same conference to bridge both.

    However dial plan way is much more simpler.

    Mitul

  • Why not just originate from one extension to the other? Something like this (not tested):

    Action: Originate Channel: Local/300@from-internal Context: from-internal Exten: 500
    Timeout: 30

    Should dial extension 500 in the from-internal context after the call to
    300@from-internal is answered. Meaning, the person at
    300@from-internalwould have their phone ring, they’d pick it up, and then they’d hear ringing on the line as asterisk then dialed extension 500@from-internal.

  • Dial first call and put it into a conference, then dial second call and put him into same conference to bridge both.

    However dial plan way is much more simpler.

    Mitul

  • Hi Mitul, I agree that the dialplan way is easier, but it’s a client requirement to avoid using it. I was wondering if there was a way to send a call directly to a parking slot right from the originate, because that is cheaper than running conferences, and then joining the second call right to the parked call, so that all we have to do is two originates. l.

    2013/5/14 Mitul Limbani

  • Hi Warren, the problem is that all I have is two channels, so the specs might be “join SIP/123 and SIP/345” not “join SIP/123 to 456@from-internal”. They might be Local channels, but this should be able handle the general case. The reason why I have channels and not ext@ctxt is that I read them live from the AMI
    itself. any idea on how to do this?
    Thanks l.

    2013/5/14 Warren Selby

  • The dial n bridge might work, but there ain’t indefinite wait in that scenario. Direct calls to parking you might try Local(70X@from-internal) but I m not sure if this method works reliably.

    The method I mentioned is used by vicidial and it works flawlessly, yes it comes with some computing load, however you can try the newer ConfBridge app to see if its cheaper.

    Mitul

  • I never actually used parking, but should it work if I call the Park application as the second leg of the Originate (w/o going through the dialplan)? I dont seem to be able to make it work. l.

    2013/5/15 Mitul Limbani

  • BTW – what was exactly the problem when trying to bridge the two channels that you have sent to the wait application?

  • WW91IGNvdWxkIHVzZSBBc3luY0FHSSB0byBhY2hpZXZlIHRoaXMuDQoNCiANCg0KT3JpZ2luYXRl IHRoZSBmaXJzdCBjYWxsIChwYXNzaW5nIGluIHNvbWUgdW5pcXVlIGlkZW50aWZpZXIgYXMgYSB2
    YXJpYWJsZSksIHRoZW4gdXNpbmcgQU1JIHlvdSB3aWxsIHNlZSB0aGUgY2hhbm5lbCBkYXRhLiAg V2hlbiB5b3Ugc2VlIGFuIEV2ZW50OiBBeXNuY0FHSSBmb3IgdGhhdCBjaGFubmVsICh3aXRoIHRo YXQgaWQsIHlvdSBoYXZlIGNvbnRyb2wgb2YgdGhlIGNhbGwpLiAgU2VuZCBhIERpYWwgQWN0aW9u IHRlbGxpbmcgaXQgdG8gZGlhbCB0aGUgY2FsbCBhbmQgYnJpZGdlIHRoZW0gdG9nZXRoZXIgaWYg dGhlIHBlcnNvbiBhbnN3ZXJzLiAgSWYgdGhleSBkb27igJl0IGFuc3dlciwgeW91IHdpbGwgYmUg bm90aWZpZWQgYW5kIGNhbiBkbyBzb21ldGhpbmcgd2l0aCB0aGUgb3JpZ2luYWwgY2FsbCAocGxh eSBhIG1lc3NhZ2UsIGhhbmd1cCwgZXRjKS4gIElmIHRoZXkgYXJlIGJyaWRnZWQsIHlvdSBjYW4g c2VlIGhvdyBsb25nLCBldGMuDQoNCiANCg0KU2V0dXAgYW4gZXh0ZW5zaW9uLCBuYW1pbmcgaXQg c29tZXRoaW5nIGxpa2UgcGF0Y2hpbmcNCg0KIA0KDQpleHRlbiA9PiBwYXRjaGluZywxLEFHSShh Z2k6YXN5bmMpDQoNCiANCg0KQWN0aW9uOiBPcmlnaW5hdGUNCkNoYW5uZWw6IExvY2FsLzMwMEBm cm9tLWludGVybmFsDQoNCkFzeW5jOiAxIA0KRXh0ZW46IDENCg0KQ29udGV4dDogcGF0Y2hpbmcN
    CkRhdGE6IDE5NzMNCg0KVmFyaWFibGU6IFlvdXJVbmlxdWVQYXRjaElEPTEyMzQNCg0KIA0KDQog DQoNClVzaW5nIEFzeW5jQUdJIGFuZCBBTUksIHlvdSBjYW4gaGF2ZSBmdWxsIGNvbnRyb2wgb2Yg dGhlIGNhbGwuICBZb3UgZG8gaGF2ZSB0byBzZXR1cCBhIHZlcnkgc2ltcGxlIGRpYWwgcGxhbiBz byBBc3RlcmlzayBrbm93cyB5b3UgYXJlIHVzaW5nIEFzeW5jQUdJIHRvIGNvbnRyb2wgdGhlIGNh bGwuDQoNCiANCg0KSGF2ZSBhIGdyZWF0IGRheSENCg0KRGFuDQoNCiANCg0KIA0KDQogDQoNCkZy b206IGFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbSBbbWFpbHRvOmFzdGVy aXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbV0gT24gQmVoYWxmIE9mIExlbnogRW1p bGl0cmkNClNlbnQ6IFR1ZXNkYXksIE1heSAxNCwgMjAxMyAxMToxNiBBTQ0KVG86IEFzdGVyaXNr IFVzZXJzIE1haWxpbmcgTGlzdCAtIE5vbi1Db21tZXJjaWFsIERpc2N1c3Npb24NClN1YmplY3Q6
    IFthc3Rlcmlzay11c2Vyc10gZGlhbCBhbmQgYnJpZGdlDQoNCiANCg0KDQoNCg0KSGkgYWxsLA0K
    DQpJIG5lZWQgc29tZSBhZHZpY2UgLSBJIGhhdmUgYmVlbiB3b3JraW5nIG9uIG9yaWdpbmF0aW5n IG11bHRpcGxlIGNhbGxzIHVzaW5nIEFNSSBhbmQgdGhlbiBqb2luaW5nIHRoZW0uIA0KDQpXaGF0
    IEkgd2FudCB0byBkbyBpczoNCg0KLSBkaWFsIGNhbGwgMSAod2hlcmUgdGhlIGNhbGxlciBpcyBp biBhICJjaGFubmVsIiBmb3JtYXQsIGxpa2UgU0lwLzEyMzQgb3IgTG9jYWwvMTIzNEBleHQpIGFu ZCAicGFyayIgaXQgc29tZWhvdw0KDQotIGRpYWwgY2FsbCAyICh3aGVyZSBhZ2FpbiB0aGUgY2Fs bGVyIGlzIGluIGNoYW5uZWwgZm9ybWF0KSBhbmQgam9pbiBpdCB0byB0aGUgcHJldmlvdXMgY2Fs bC4NCg0KIA0KDQpBcyBhIHJlcXVpcmVtZW50LCBJIGNhbm5vdCB1c2UgdGhlIGRpYWxwbGFuIGFz IGFuIGVuZC1wb2ludCAoYXMgSSBjYW5ub3QgY2hhbmdlIGl0KSBidXQgbmVlZCB0byB1c2UgdGhl IEFNSSBvbmx5Lg0KDQogDQoNCkkgdHJpZWQgZG9pbmcgc29tZXRoaW5nIGxpa2U6DQoNCiANCg0K
    QWN0aW9uOiBPcmlnaW5hdGUNCkNoYW5uZWw6IExvY2FsLzMwMEBmcm9tLWludGVybmFsDQoNCkFz eW5jOiAxIA0KQXBwbGljYXRpb246IFdhaXQNCkRhdGE6IDE5NzMNCg0KIA0KDQpTbyB0aGF0IHRo ZSBjYWxsIGdvZXMgdG8gMzAwIGFuZCB0aGVuIGJhc2ljYWxseSBzdGF5cyB0aGVyZSBmb3JldmVy LCBhbmQgdGhlbiBJIGRpYWwgYWdhaW46DQoNCiANCg0KQWN0aW9uOiBPcmlnaW5hdGUNCkNoYW5u ZWw6IExvY2FsLzUwMEBmcm9tLWludGVybmFsDQoNCkFzeW5jOiAxIA0KQXBwbGljYXRpb246IFdh aXQNCkRhdGE6IDE5NzMNCg0KICANCg0KQW5kIHRoZW4gdHJ5IHRvIGJyaWRnZSB0aGUgcmVzdWx0
    cywgYnV0IGl0IGRvZXMgbm90IHNlZW0gdG8gd29yay4NCg0KV2hhdCBJIHdvdWxkIGxpa2UgdG8g ZG8gd291bGQgYmUgbW9yZSBvbiB0aGUgbGluZXMgb2Y6DQoNCiANCg0KT3JpZ2luYXRlIGNhbGwg MSBhbmQgcGFyayBpdCAodXNpbmcgYSBwYXJrIG9yIHdhaXRpbmcpDQoNCk9yaWdpbmF0ZSBjYWxs IDIgYW5kIGJyaWRnZSBpdCBpbW1lZGlhdGVseSB0byBjYWxsMSAodXNpbmcgdGhlIEFwcGxpY2F0
    aW9uIHBhcnQpDQoNCiANCg0KQnV0IG1heWJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmc/IGlzIHRo ZXJlIGFueWJvZHkgd2hvIGhhcyBiZXR0ZXIgc3VnZ2VzdGlvbnM/DQoNCiANCg0KVGhhbmtzDQoN
    CmwuDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCi0tIA0KDQpMb3dheSAtIGhvbWUg b2YgUXVldWVNZXRyaWNzIC0gaHR0cDovL3F1ZXVlbWV0cmljcy5jb20NCg0KVGVzdC1kcml2ZSBX
    b21iYXREaWFsZXIgYmV0YSBAIGh0dHA6Ly93b21iYXRkaWFsZXIuY29tIA0KDQo

  • Thanks all for your help, in the end I was able to do something like:

    Action: Originate Channel: Local/300@from-internal/n Application: MusicOnHold Async: 1

    As soon as this connects, the callee hears MOH. I get the channel out via AMI events and start another call:

    Action: Originate Channel: Local/301@from-internal/n Application: Bridge Data: Local/300@from-internal-aa8c;1
    Async: 1

    when this connects, it is immediately bridged to the first callee. I just have to keep track of errors and hang up the first call if the seconds does not go through.

    Thanks a lot!
    l.

    2013/5/15 Dan Cropp