Jump to content

sean

Members
  • Posts

    17
  • Joined

  • Last visited

Everything posted by sean

  1. The Huawei is located at our VOIP-Provider QSC, so we don't have any influence either Right now, we are testing an upgrade to our Firewall/NAT-GW, and first tests look promising. Though I have no clue, why this component should make any difference, since it was involved in the successfull scenario as well. Using https to fax sounds interesting. I will look into it. Cheers, sean
  2. First of all: Thank you for your continuing effort to help me solve this problem. As you suggested, I set <support_update> to false. Unfortunateley this did not solve the problem jet. Find attached a little graphic that further illustrates our environment. Option A (green): This is our preferred setup, but the switch to t38 does not seem to work. Find attached two new traffic-captures taken on the pbx itself: A.1: as illustrated the traffic between the ATA and the PBX A.2: Traffic between PBX and the SIP-GW at our provider QSC. Option B (blue): This is the setup not involving the pbx This is the only Setup that works with t38, so far. One capture ( directly at the ATA (through port-mirroring at the switch). I am not really experienced in interpreting SIP-communication, but two things cought my attention, when comparing the working option B with the failing option A: 1) In Frame B.576 an invitation to t38 is issued by the SIP-GW (upstream), and in Frame B.580 it is accepted by the ATA (downstream). The same happens in capture A1 (Frame A1.651 and A1.661) and Capture A2 (Frame A2.59 and A2.70) only here in the opposite direction, i.e. the downstream component (A1=ATA; A2=PBX) is inviting the Upstream componen (A1=PBX; A2=SIP-GW). 2) The Session- and MediaAttributes in the SDP-Frames differ between Option A and B. I do not expect the NAT-GW to be the problem, as the working option B is also going through the NAT-GW. I hope the provided information will help in isolating the problem. Cheers, s. Captures_fax_out.zip
  3. Changing the provider is not really possible here. But since faxing works perfectly, as long as I change only one of the involved parameters (excluding pbx), I don't expect changing the provider would yield any new insight. The same applies to the public IP-address. All our telephony with pbx and SIP-Trunk work perfectly through our NAT-GW. Also faxing works with t38 through our NAT-GW, as long as PBX is not involved. I will try to test with a public IP, but this could not be the final solution. So the captures and logfiles do not offer any clue as to where the problem is? Would additional information help in anyway to solve the problem? Cheers, s.
  4. Thanx for your feedback, and sorry for my late reply. Extended vacation The attached archive contains two capture-files, one with pbxnsip being involved, one without. All packets in the file ixto_fax_out_pbxnsip.cap contain the pbxnsip (192.168.0.210) either as source or as destination. The files ixto_fax_out_QSC.cap does not contain PBX. This was a test to ensure the general ability of our VOIP-Provider and the ATA to send faxes via T38. When sending through pbxnsip, the ATA has the outbound proxy set to 192.168.0.210(PBX). Maybe I should clearify our setup a little bit: All our phones and the pbxnsip are in the privat network 192.168.0.0/24 The pbxnsip does not have a public address. There are no forwarding rules in the Firewall/NAT-GW for incoming VOIP-Traffic. (could this be the problem? does the externel SIP-GW try to establish a new incoming connection for t38 which is then blocked at our firewall/NAT-GW) The pbxnsip has IP 192.168.0.210 The ATA has IP 192.168.0.209 The Standard-Gateway is 192.168.0.1 The SIP-GW of our Provider (QSC) has the IP 213.148.136.2 I just confirmed that the capture-files do reflect this setup. Is there anything wrong with this setup? Could you please reevaluate your analysis of the capture-files? Do you need the files in another format or any additional information to help me solve this problem? Cheers, s.
  5. I appreciate your help, but unfortunatly this did not solve the problem I changed the parameter "support_update" to false, and verfied it's value in pbx.xml This did not change anything, so I upgraded to pbxnsip v. 3.4.0.3201 by swapping the executable and restarting the service. Still same behaviour. My knowledge is not sufficient to analyze the corresponding network/SIP-traffic, but maybe you can find some hints. Find attached two traffic-capture files (Microsoft Network-Monitor), I hope they are compatible to display with other sniffers as well. They are both recorded on our NAT-router/Firewall. IP 192.168.0.209 is the ATA of the fax IP 192.168.0.210 is the pbxnsip IP 213.148.136.2 is the SIP-Gateway of our provider QSC The file ixto_fax_out_qsc.cap is capture of a successfull fax with the ATA registered directly at the SIP-Gateway of our Provider QSC. A capture-filter was applied for IP 192.168.0.209. The file ixto_fax_out_pbxnsip.cap is a capture of a failed attempt to send a fax through pbxnsip. A capture-filter was applied for IP 192.168.0.210. Any help would be greatly appreciated! Cheers, s. ixto_fax_out_capture.zip
  6. I need some help in sending fax through pbxnsip. (We'll deal with receiving a fax later Our setup: Internetprovider with SIP-GateWay (QSC), supports t38 pbxnsip v 3.3.1.3177 ATA (SPA2102), supports t38 Faxmaschine Our problem: We have enabled the speaker on the fax to listen in. When we register the ATA directly at the SIP-gateway of our provider, everything is perfect. When we register the ATA in pbxnsip (with identical settings), the following problem occurs: Fax is dialing, remoteparty is ringing, remoteparty picks up, our fax is sending CNG, and that's it! No CED from remote party is recieved. After a timeout the connection is terminated. The pbxnsip log and the statusinfo on the ATA show, that first the G711 codec is used and then it switches over to t38. It seems the remote fax is not recieving our CNG and therefor is not sending the CED. Find attached an example logfile and a screenshot of the configuration of our ATA. Any help would be greatly appreciated Cheers, sean pbixto_fax_log2.txt
  7. All in all I have to say, this thread was a very disappointing experience. pbxnsip A says, the feature is already working in version 3 pbxnsip B says, the feature is not working at all, though I have proof, that this statement is wrong. After I point out this contradiction, no comments are made at all. No comments either on the second main question, wether the required fearture will work in future versions. As a paying customer, I would have expected a little more enthusiasm. We were about to programm an RCC-Server (which we gladly would have made publicly available), to make it possible to controll calls remotely through Office communicator and OCS. But since the TAPI-interface is not working reliably, and the support here seems to stall, we stopped the project. Cheers, s.
  8. I thought we already established, that hotdeking at a remote location (cell phone) works. For some reason it does not work, when the extension is registered, but that would be ok in our case, as our users never register. The initial question was: Why doesn't the invocation of a call through TAPI work, when hotdesking remote, and will it work in version 4. Btw, when initiating a call through TAPI, call Forking, as you suggest, doesn't work either. It is realy disappointing, that you are stuck with registered SIP-phones, when it comes to TAPI or CtD. Cheers, s.
  9. ok I tried this with the following results. I am mainly interested in TAPI so I did not test CtD. Weired behavior: Extension 53 is registered. Extension 53 is hotdesking at extension 214. As expected, if I call extension 115 from another phone (extension 118) the extension 214 rings. Everything is fine. Now extension 53 is hotdesking at the cellphone, i.e. 00491791234567. If I call 53 from extension 118, the extension 53 rings . Hotdesking-setting is ignored. Remember: I did not even use TAPI jet. Then I remembered, that you were so kind as to implement a much desired feature, as described in this thread http://forum.pbxnsip.com/index.php?showtopic=1051&hl= To test, if this feature had any impact on the matter at hand, I set multiple_hot_destking to false (restarted the service),... to no avail. Same behaviour. It seems that the situation got even worse with the registered extension, since hotdesking at the cellphone does not work at all, not even when the extension is called localy whithout TAPI (which did work, when the extension was not registered). Unconditional call-diversion to the cell phone does however work (not with TAPI). If you need more information about our setup and configuration, to resolve this issue, please let me know. I hope I am not to confusing. I appreciate your help, as this is a much desired feature for our road warriers. Cheers, s.
  10. This issue is still not resolved, and I am not shure, if we meen the same thing. I have a roadwarrier user. He has extension 53 in our pbxnsip. He is not registered at the pbxnsip, but is hotdesking at his cellphone at the number 0049 179 1234567. this is configured through his personal webpage on the pbxnsip. If his internal extension is called (53), his cellphone will ring, and the call is connected when he picks up. If he tries to initiate a call vie TAPI, nothing happens. Silence! The pbxnsip-log does not show ANY SIP-Traffic at all. This behaviour contradicts the statements in your last post. Could someone please confirm and test, this is actually working in version 3.3? Cheers, sean
  11. Your ARE getting the point:) But I can not get this to work. No matter how I redirect calls to my cellphone, it does not ring, when I initiate a call vie TAPI/CtD. I tried hotdesking with my cell number. When my extension gets called directly, my cell rings as expected. When I initiate a call vie TAPI/CtD it does not. Same with unconditional forwarding and "call this number, when not registered" I am relieved, that this should already be working, but I am also concerned, because I can not find the error in my configuration. Any ideas? Cheerio, s.
  12. So, just to make it clear: At the moment it is not possible for a user that is hotdesking at a remote location (cell phone) to initiate calls via TAPI or Click To dial? But this will be possible with pbxnsip version 4? When would that be? Cheerio, s.
  13. Hi, our users recieve eMail-status-notifications twice. If I acivate or deactivate hotdesking forexample, I am notified by email. I recieve exactly the same email twice. While other eMails, about missed calls for example, are sent once. Any ideas, where to look for a solution? Cheers, s.
  14. We use hotdesking a lot. Since noone has his own desk/phone at our office, all the phones have some neutral SIP-Registration, belonging to the phone. The employee takes ownership of a phone, by activating hotdesking. (This is much easier then registering with the individual SIP-account). Some peaple sometimes forget to change the hotdesking, when they change the office. It would be great, if PAC would show the extension I am currently hotdesking at. Cheerio, s.
  15. Thanx for you reply and sorry for my tone. I was quite frustrated at that time :/ I did try to just exchange the executable before, but the admin-website seemed to have been messed up by this. Since I reverted back to the old version after my fruitless attempts to upgrade, i tried to upgrade by exchanging the executable again today. This time it did work. I guess I forgot to hit reload at my first attempt. Calling out works now, after setting the Rewrite global numbers to "european with 00" (Previously "Depending on configured countrycode). Cheers, and happy easter, sean [edit 2009.04.13] New Problem: The CallerID that ist presented to the external callee is incomplete and missing the areacode. We would like to present an external number (not related to the internal or external Sip-accounts) to the callee. In the domain-Settings I entered the folowing info (deleted all other info on the trunks): countrycode: 49 areacode: 30 ANI: 2787xxxx On the trunk the CLIP-Standard is set to RFC 3325 P-Asserted-Identity) On the trunk, the option "always interpret SIP-URI as telephonenumber" is activated. The number shown to the calle is +492787xxxx, so the areacode is missing between countrycode and ani. Also, if i change the ani to the full number, i.e. +49302787xxxx, the areacode is stipped from it with the same result as before. Any ideas? [/Edit]
  16. man I am so pi****, I spend a whole day, trying to figure out what happened. As mentioned in the manual, I installed the new version on top of the old one. The installer did NOT recognise the previously installed version. Is this a problem? did some config- Files not get converted? Here's the problem: We have set up some SIP-Registrations (trunks) with our provider. Everythig works fine on incoming calls, and on internal calls. When I try to make an external call, the called number is not passed to our provider in the sip-invite. and the call obviously fails. At some point it seemed to work, right after i configured the sip-Registration (Trunk) to NOT be global, and then back to global. Only, after I've done this, the sip-Registration was gone from the list of Trunks. It did not reapear after restarting the service or restarting the machine, though the xml-file was still in der /trunks directory, and the trunk was still successfully used in externel calls. Since I did not feel to comfortable with this state, I reset the machine, and started over. Same story when installung new version. Only now i could not get the trunk to work again, no matter what i did. Could someone please explain, why an easy update is such a hassel, and what to do about the disfunctioning SIP invites on the trunks? Cheers, s.
×
×
  • Create New...