Jump to content
Vodia PBX forum

nebbin

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About nebbin

  • Rank
    Member

Profile Information

  • Gender
    Male
  1. 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
  2. On PCAP I See this: : Ignoring the SDP due to the trunk setting That does that mean?
  3. 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
  4. 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?
  5. 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
  6. 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
  7. I've have a customer asking about Skype for Business and Vodia integration now that we don't have Lynx... Can anybody shed some light on what possible here and the approaches available? Wants to use it's local IPBX/numbers (non -MS calls) Thanks
  8. Gosh, I was hoping for a more meaningful response?
  9. We currently using Vodia PBX with our client's middle software that is voice automation + a bit of AI in the transportation business. For a current call, what API can we use to call an external number to dial and external number and connect this external to a current call to of an agent? The business scenario in this case is to connect a incoming call to the number (cell phone) of a transport driver, without any human intervention. The middleware developed will queue it's own database to determine the appropriate number to dial. However, with this information what Vodia commands (API)/code do we need use to achieve this and are there any examples of such code. Thanks, NE
  10. When is that to be released? I now understand the deadline is moved to May 6th...
  11. ? Clients are not going to buy that?
  12. This suppose to be in place by April 26, 2018. We have registered and transferred our account... Is there anything else we need to do? What about download parameter from snom RDS Service - Moving to SRAPS? Newbie and need to know before deadline. Thanks, NE
  13. Seems like there is NO combined BLF for monitor, pick up and speed dial. Client has SNOM 320's and only has 10 free buttons? In Future how can we get around this... We don't have any documentation on new buttons set up, so does this mean 30 buttons will be needed,, when previously on 10 were required to do three function for one extension (button)?
  14. No joy...but next upgrade seemed to resolve this issue. 60.0.2 :-)
×
×
  • Create New...