Jump to content
Vodia PBX forum
nebbin

Dialing an Extension in another domain in the PBX

Recommended Posts

We're offering video conferencing to customers importantly with local dial in number capability. Is it possible to send a conference dial in number to the extension our of conference facility PBX domain from an extension in a customer domain or from their auto attendant (DID). We could place a DID on the our extension in the conference facility domain connected to the video conference facility, but I think we want the conference facility extension to dial out to avoid carrier concurrent call restrictions on DID.

Any ideas on how we could approach this?

Thanks,

NE

Share this post


Link to post
Share on other sites

You can assign as many DID as you want to an extension. For example, you could assign one just for conferencing purposes. Depending where you are coming from, this "DID" can also contain also alphanumeric characters. So for example, you could use the alias name "conf-5434634564" as DID/alias name for the extension and then call in from a trunk that goes directly to the conference server, so that there are no carriers involved. The PBX will then take care about ringing the user up, including desktop phones, cell phones and apps.

Share this post


Link to post
Share on other sites

So in Domain A, I can put the DID Alias; and it would reach the extension in the domain I'm using for connection to the PBX that has been given this alias?

NE

Share this post


Link to post
Share on other sites

Note: in this case, the conference is tied first in FreePBX (where the IVR integration takes place because we don't know how to do integration to conference App in Vodia). So we're forwarding the calls to FreePBX? Should we then not be using and extension DID in Vodia, but a trunk with a DID reference. Currently, we set up the DID in the conference domain, to be forward to a number which is identified as Trunk A in a dial plan? Are suggesting we can skip this and send directly to trunk identified as conference DID?

 

Also, we seem to have gotten Vodia to forward call into this conference (via FreePBX). Calling from a number set up as DID on our system seems to works. But calling from an external number (mobile); it would appear there is no sound for 40 seconds before FreePBX IVR can be heard. What would cause this?

Share this post


Link to post
Share on other sites

Here's the log from the calls the delay (up to 40 seconds) media. It is because if trying to find where to place call:

In this case I'm call from a cell phone (4415362338)  to the conference room number via 1 441 400 7000 and then extension 4000:

[8] 11:13:26.917 TRUN: Trying to match number 14412362095 with ERE (.*)
[8] 11:13:26.917 TRUN: Send call to extension ERE returned 14412362095
[8] 11:13:26.919 TRUN: Trying to match number 14412362095 with ERE (.*)
[8] 11:13:26.919 TRUN: Send call to extension ERE returned 14412362095
[8] 11:13:26.919 TRUN: Trying to match number 14412362095 with ERE (.*)
[8] 11:13:26.919 TRUN: Send call to extension ERE returned 14412362095
[8] 11:13:26.919 TRUN: Trying to match number 14412362095 with ERE (.*)
[8] 11:13:26.919 TRUN: Send call to extension ERE returned 14412362095
[8] 11:13:26.920 TRUN: Trying to match number 14412362095 with ERE (.*)
[8] 11:13:26.920 TRUN: Send call to extension ERE returned 14412362095
[9] 11:13:47.367 TRUN: Generating hf header using <sip:{ext-ani}@{domain}>
[9] 11:13:47.367 TRUN: Generating ht header using {to}
[9] 11:13:47.367 TRUN: Generating hpai header using <sip:{ext-ani}@{domain}>
[9] 11:13:47.367 TRUN: Generating hrpi header using {from}
[9] 11:13:48.048 TRUN: Generating hf header using <sip:{ext-ani}@{domain}>
[9] 11:13:48.048 TRUN: Generating ht header using {to}
[9] 11:13:48.048 TRUN: Generating hpai header using <sip:{ext-ani}@{domain}>
[9] 11:13:48.048 TRUN: Generating hrpi header using {from}
[8] 11:13:56.107 TRUN: Trying to match number 14414055308 with ERE (.*)
[8] 11:13:56.107 TRUN: Send call to extension ERE returned 14414055308
[8] 11:13:56.108 TRUN: Trying to match number 14414055308 with ERE (.*)
[8] 11:13:56.108 TRUN: Send call to extension ERE returned 14414055308
[8] 11:13:56.109 TRUN: Trying to match number 14414055308 with ERE (.*)
[8] 11:13:56.109 TRUN: Send call to extension ERE returned 14414055308
[8] 11:13:56.109 TRUN: Trying to match number 14414055308 with ERE (.*)
[8] 11:13:56.109 TRUN: Send call to extension ERE returned 14414055308
[8] 11:13:56.109 TRUN: Trying to match number 14414055308 with ERE (.*)
[8] 11:13:56.109 TRUN: Send call to extension ERE returned 14414055308
[9] 11:14:01.342 TRUN: Generating hf header using <sip:{ext-ani}@{domain}>
[9] 11:14:01.343 TRUN: Generating ht header using {to}
[9] 11:14:01.343 TRUN: Generating hpai header using <sip:{ext-ani}@{domain}>
[9] 11:14:01.343 TRUN: Generating hrpi header using {from}
[9] 11:14:02.198 TRUN: Generating hf header using <sip:{ext-ani}@{domain}>
[9] 11:14:02.198 TRUN: Generating ht header using {to}
[9] 11:14:02.198 TRUN: Generating hpai header using <sip:{ext-ani}@{domain}>
[9] 11:14:02.198 TRUN: Generating hrpi header using {from}
[5] 11:14:10.416 PACK: SIP Rx 76.8.40.106:5060:
BYE sip:14414007000@172.24.16.181:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 76.8.40.106:5060;branch=z9hG4bK-524287-1---2aec38613f440f6ee40ff213f9227b6e;rport
Via: SIP/2.0/UDP 76.8.40.108:5070;rport=5070;branch=z9hG4bK-e2lwqbk6uo5yvqna
Max-Forwards: 69
Contact: sip:76.8.40.108:5070
To: <sip:14414007000@172.24.16.181>;tag=9a1a289d78
From: <sip:14415362338@76.8.40.106>;tag=CQFRGNYRWBOVWOCPGJMA____.o
Call-ID: 0gQAAC8WAAACBAAALxYAABrTWpr/c1LmFESM7HBU77DJ/8mO4EoN/uALHlILOlZV@69.17.214.94
CSeq: 854 BYE
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
User-Agent: PortaSIP
cisco-GUID: 3753021899-3943194721-784679244-1290984961
h323-conf-id: 3753021899-3943194721-784679244-1290984961
Content-Length: 0

[5] 11:14:10.417 PACK: SIP Tx 76.8.40.106:5060:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 76.8.40.106:5060;branch=z9hG4bK-524287-1---2aec38613f440f6ee40ff213f9227b6e;rport=5060
Via: SIP/2.0/UDP 76.8.40.108:5070;rport=5070;branch=z9hG4bK-e2lwqbk6uo5yvqna
From: <sip:14415362338@76.8.40.106>;tag=CQFRGNYRWBOVWOCPGJMA____.o
To: <sip:14414007000@172.24.16.181>;tag=9a1a289d78
Call-ID: 0gQAAC8WAAACBAAALxYAABrTWpr/c1LmFESM7HBU77DJ/8mO4EoN/uALHlILOlZV@69.17.214.94
CSeq: 854 BYE
Contact: <sip:14414007000@204.232.169.181:5060;transport=udp>
User-Agent: Vodia-PBX/65.0.6
Content-Length: 0

[5] 11:14:10.426 PACK: SIP Tx 155.138.208.200:5060:
BYE sip:8990@155.138.208.200:5060 SIP/2.0
Via: SIP/2.0/UDP 204.232.169.181:5060;branch=z9hG4bK-edfcf87d38e9c0536007dbc7f4d126af;rport
From: <sip:14414007000@pbx.gombay.bm>;tag=939817284
To: "Gombay Main Auto attendant" <sip:8990@pbx.gombay.bm;user=phone>;tag=as6dfb3053
Call-ID: 8f7da753@pbx
CSeq: 20696 BYE
Max-Forwards: 70
Contact: <sip:4000@204.232.169.181:5060;transport=udp>
P-Asserted-Identity: "YAK BM" <sip:4000@pbx.gombay.bm>
P-Preferred-Identity: "YAK BM" <sip:4000@pbx.gombay.bm>
Remote-Party-ID: "YAK BM" <sip:14414007000@>
Content-Length: 0

[5] 11:14:10.439 PACK: SIP Rx 155.138.208.200:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.24.16.181:5060;branch=z9hG4bK-edfcf87d38e9c0536007dbc7f4d126af;received=172.24.16.181;rport=5060
From: <sip:14414007000@pbx.gombay.bm>;tag=939817284
To: "Gombay Main Auto attendant" <sip:8990@pbx.gombay.bm;user=phone>;tag=as6dfb3053
Call-ID: 8f7da753@pbx
CSeq: 20696 BYE
Server: FPBX-15.0.16.53(16.9.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

[7] 11:14:10.439 SIP: Port 949: Clear last request
[5] 11:14:10.439 SIP: BYE Response: Terminate 8f7da753@pbx

 

Share this post


Link to post
Share on other sites

Seemed to figured it out. The auto attendant number to select extension was being sent out directly on trunk to FreePBX, but putting pound sign after the number on the auto attendant, this behavior stopped, i.e. isn't set out as DMTF input over trunk. Trunk was expecting a PIN number...so if waited for the initial entry period to expire (i.e. incomplete input), then second as for input - hence initial delay for external calls.

NE

Share this post


Link to post
Share on other sites

Thanks. We actually fixed a similar problem recently with initial DTMF coming in after a transfer from another system. 

Share this post


Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...