Dialing an Extension in another domain in the PBX

[nebbin]

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

[Vodia PBX]

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.

[nebbin]

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

[nebbin]

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?

[nebbin]

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

 

[Support]

Hey Norris,

 

Can you give us a call about this?

[nebbin]

On PCAP I See this: 

: Ignoring the SDP due to the trunk setting   That does that mean?

 

 

[Support]

Hi,

The doc we were referring to on the call: https://doc.vodia.com/trunk_branches

[nebbin]

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

[Vodia PBX]

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