Jump to content
Vodia PBX forum

Krom

Members
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Krom

  • Rank
    Member
  1. I have a question along the same vein. Is there a way to mangle the from header to force the from domain to be a specific domain instead of the PBX IP address? The URI and To header can be done via the dial-plan. But how does one change the domain of the From header? EX: (numbers and IP's have been changed for protection) INVITE sip:15554443333@mycompany.com SIP/2.0. Via: SIP/2.0/UDP 10.1.1.55:5060;branch=z9hG4bK-baa1c6f86a3c3f8526a3bd6f7a7ed3bf;rport. From: "Test Two" <sip:5552221111@10.1.1.55;user=phone>;tag=1887596257. To: <sip:15554443333@mycompany.com>. Call-ID: 100287b5@pbx.
  2. Well you guys are getting much further than I have been able to at this time. Running 3.3.1.3177 (Linux), alias set on hunt group 113 in B.domain.com to 5554443333 Dial Plan in A.domain.com has one entry Try Loopback match * with null replacement. Debug going and the log tells be the following. [9] 20090706153623: Dialplan: Evaluating !^(\+?[0-9]*)@.*!sip:\1@\r;user=phone!i against 5554443333@A.domain.com [8] 20090706153623: Dialplan TEST: 5554443333@A.domain.com not found in the local system I read this and say to my self - of course 5554443333@A.domain.com is not found in the local system, because it is 5554443333@B.domain.com. These types of changes is what keeps us running 3.1.0.3031 (Linux). If it's not broken, why fix it...? I think it is going to be easier to figure out how to get my sofswitch vendor to change their code than to make changes on every server and domain dial plan whenever or if ever we figure out this 'new' method for inter-domain dialing. Right now - leaving it setup the old way on this version the log file just states - [5] 20090706162813: Received loopback request without tag. If I could figure out what this highly detailed debug message means - I could probably get the softswitch vendors help. Any ideas on which tag this message talks about? Could if be the ftag in the Record-Route header? Does this need to have a different tag id? Or does the the tag of the from header need to change when coming back to the PBX? Thoughts?
  3. Thank you. I am hitting myself for not thinking of the ole ulimit command. Dust on the old Unix brain. Will do - we assume that support would want to review any core dump created in "normal" operational conditions to assist in ongoing development. Thanks again. -Krom
  4. We are running RH here and when the PBX application crashes we are not able to locate a core dump file to submit to support for review. Nothing is posted in the logs prior to the crash of 2.1.12.2489 (Linux) and if we increase the logging level is seems to increase the occurrence of the crash and doesn't provide any information of what caused the crash. Any way to add the memory/process dump to a core file when the application crashes within Linux? This would allow us to submit the core file to a support ticket to assist in determining what was going at the time of the crash and assist in preventing it in the future. At this time we can determine that 15 calls were going on as normal with 5 call legs in voicemail at the time of the crash, other than that we can't determine what was going on to cause the crash. RH forums are telling us to look at the core dump file created by the crashed application - but we can't seem to locate the core dump file. -Krom
  5. Not really an option. Each SNOM is remote from the PBXnSIP server and their local cable modem doesn't support option 66. What is needed is similar to how the SNOM's work on *. Every phone monitoring a CO line will be called via a broadcast hunt group. The person answering the phone places the call on hold and pages or IM's the the proper party telling them they have a call on Line 1 which in turn is flashing on their SNOM phone. We have tried to work with them on Parking a call, but they don't like the number of key strokes, so we made the key strokes a softkey where the transfer blind and press the softkey. Still to many key strokes for them, they want the KTS feature. Answer and then press hold and every phone flashes. Like I mentioned, I have the indication working perfectly, but when a terminal that is not the terminal that places the call on hold presses the flashing line, nothing happens, not a message from the phone (RE-INVITE) nothing. Would creating the buttons file provide me with the parameters when looking at the file with the needed parameters that I need to program the Function Keys with to get this to work? I guess I will try that. Also, does what I am describing work with using the plug-n-play buttons, or is that just a guess? Trying not to waste cycles if the solution is to direct them to a provider using another type of Feature Server that appears in the SNOM list of servers.
  6. Et al, Looking for some direction/guidance. We have a customer requiring KTS feature and functionality, the primary being shared line. You know, one phone places a CO line on hold, it flashes on all of the phones that are monitoring that CO line and anyone on any phone can pickup that CO line from the hold state and continue the call. Well, I have scrubbed the wiki, documentation and SNOM site up and down and can’t find a configuration for the SNOM function keys that work. I have the indication working fine, but can’t pickup the call on another SNOM extension. Can someone direct me to a link that can show me step-by-step how both PBXnSIP needs to be configured and the SNOM phones need to be configured to accomplish this setup. The following link provided me the information to get me to the indication state, but I am still not able to pickup the call on another extension and continue the call. http://wiki.pbxnsip.com/index.php/Snom Anything would be great – even a can’t do that right know would allow me to move on to something else. -Krom
  7. This question is within the thread topic but nothing to do with file location, etc... How does one turn off the "beep" tone that is heard when initiating the call recording feature?
  8. We have also given up on Windows server and need to migrate to Linux do to the cost of supporting a Windows server for one application - PBXnSIP. Redhat trimmed down to just the kernel, network and hardware devs is much more manageable. I can swing a stick and find a Linux sys admin that doesn't ask for my firstborn in payment. But we need the dongle support ASAP or we are back to the MAC string with no quick way to swap servers if the customer box has hardware problems. Any way to get this into 2.1.10?
  9. I would like to add something here, that does fall into trunk failover, but not directly related to priority level within the dial-plan for failing over to another trunk. My request is for the trunk registration to utilize the NAPTR-->SRV information more efficiently. Let me explain. We utilize the NAPTR-->SRV-->A records lookup that PBXnSIP supports (yeah!!) to connect to our upstream PSTN provider. They require it since they load balance and do maintenance and we work 24x7. In our trunk configuration under the outbound proxy we set it to bfp.example.domain. PBXnSIP works great with this but lacks what I think (IMHO) is the next step. When looking at the network captures when initially registering the trunk we see the following. PBX: DNS NAPTR query for bfp.example.com DNS response with: _sip._udp.int.example.com type SRV Class IN priority 0 weight 0 port 5060 target sftsw-1.example.com _sip._udp.int.example.com type SRV Class IN priority 1 weight 0 port 5060 target sftsw-2.example.com PBX: DNS SRV query for _sip._udp.int.example.com DNS response with: _sip._udp.int.example.com type SRV Class IN priority 0 weight 0 port 5060 target sftsw-1.example.com _sip._udp.int.example.com type SRV Class IN priority 1 weight 0 port 5060 target sftsw-2.example.com PBX: DNS A query for sftsw-1.example.com And then registration occurs. What I have noticed and it would be great to have "enhanced" would be when registration fails during a re-registration for any reason, the PBX attempt to re-resolve the Outbound Proxy entry by running the DNS query process again to see if the records have changed. This is not happening at this time. Standard re-registration attempts a 60s continues to hit the IP address in the A record query. I have to restart the PBXnSIP service to initialize the DNS query process so that registration can attempt to the first priority SRV record and after failing moving on to the next SRV record. It would be great to have this done without having to restart the service.
  10. Observing what could be considered a strange anomaly when making changes to the Outbound Proxy field on a SIP Registration trunk. Created the trunk with account 5554443333 and defined the Outbound Proxy field to 10.0.0.10 and saved. Trunk registered properly. Went back into the configuration and changed the Outbound Proxy field to 10.0.0.11 making no other changes - saved and Ethereal shows the trunk registering to the original 10.0.0.10 address instead of the new 10.0.0.11 address. Clicked on Register on the Trunk List screen to "force" the trunk to re-register and Ethereal again shows the trunk registering to the original 10.0.0.10 address instead of the new 10.0.0.11 address. Looked into the trunk xml file and <reg_registrar>10.0.0.11</reg_registrar> is properly stored. Stopped and restarted the service and the Trunk registered to 10.0.0.11. Also deleting the trunk and re-creating the trunk with the new registrar IP address allows it to register to the proper IP address. It appears that after making IP changes for the Outbound Proxy, that the information is changed and stored properly in the trunk xml file but not in memory. Is anyone else observing this?
  11. Thank you and understood. Parameter 2 is empty as this time. My strategy is to lower the number of SIP Registration Trunks by utilizing SIP Gateway Trunks. I have a SIP Gateway Trunk created that as user that has a DID that that when dialing out needs to be presented in the From Header. When extension 269 Dials a PSTN call the dial-plan associated with that extension is used utilizing the SIP Gateway trunks for outbound PSTN dialing. When the INVITE is placed on the wire it has the extension number in the From header field. The call is rejected because my ITSP reads that as an invalid TN. i.e. a billable TN of record within their switch. INVITE sip:15552223333@10.10.10.10;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.11.11.11:5060;branch=z9hG4bK-2fc13508d3a9552ec8655cc241a737f0;rport From: "269" <sip:269@10.11.11.11>;tag=1849938551 To: <sip:15552223333@10.10.10.10;user=phone> Call-ID: 198e9ff2@pbx CSeq: 21466 INVITE Max-Forwards: 70 ... no relevent P-Asserted-Identity: <sip:5554448888@15552223333@10.10.10.10> With that said - when extension 269 blind transfers an incoming call to the PSTN, it too is rejected because in this release the From field is replaced with the inbound calling party number. Again - another number that is invalid to the ITSP in the From field. I am trying to figure out how to get the same functionality in the SIP Gateway trunk as I have in 2.0. When I place that in the Trunk DID section it doesn't do what I expect. From field being SIP Gateway account number and the P-Asserted field being used. Any suggestions?
  12. OK - getting back to this after a break from testing. Agree with moving towards the hardened standard and support the effort. Working with 2.1.6.2450 in preparation for upgrading I have a question about the documentation and configuration of my Outbound SIP Gateway trunks. http://wiki.pbxnsip.com/index.php/Outbound..._2.1_and_higher Bullet one works great and my PTSN ITSP accepts RPID while the LD ITSP only accepts P-Asserted so setting up two Gateways trunks work for defining in the dial-plan which trunk to use based on the digits dialed. The question I have is the second bullet. "If the parameter of the calling extension is set, the PBX uses that parameter as the Caller-ID. Having this as the first option makes it always possible to override the following steps. However, usually using this parameter is not necessary." Can someone provide a clearer explanation? Where is this parameter set. It is apparent that it is set since my extension has a tel: alias set with my DID, but when I dial out my three digit extension is put in the From field. I am needing the tel: alias in the From field or the SIP Gateway Account in the From field. The call is being rejected since the number in the From field is not a NANP 10-digit number. What am I doing wrong?
  13. Query regarding syntax. Wishing to match 1+10-digit or just 10-digit in a single statement. The following works for matching NANP possible digits dialed: (1[0-9]{10})@.*|([0-9]{10})@.* Why doesn't the following work: (1?[0-9]{10}@.* Thanks for any hints or tips for a REGEXP match for NANP. -Krom
  14. Not exactly. The Gateway Trunk uses the configured information for authenticating with the outbound proxy when challenged. The P-Asserted-Identity: header field is for passing the number that you wish to have presented to the called party. And per the wiki documentation and how it is working in previous version, this is not working properly. $f "will insert the caller-ID of the other side of the call, if it is not coming from an extension. This way, redirected calls can present the original caller ID for incoming calls." Read the wiki on outbound call trunks - http://wiki.pbxnsip.com/index.php/Outbound_Calls_on_Trunk So we should be seeing the 2225555555 number in that header field.
  15. [7] 20071211162440: SIP Rx udp:10.1.1.21:5060: REFER sip:269@10.1.1.245:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.1.1.21:5060;branch=z9hG4bKc71e850a9CDD4873 From: "Jan Doe" <sip:269@10.1.1.254>;tag=B2AC285D-D30FAAB4 To: <sip:+12225555555@10.4.1.144:5060>;tag=3483 CSeq: 2 REFER Call-ID: a13bf5be@pbx Contact: <sip:269@10.1.1.21:5060> User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.0.3.0127 Refer-To: sip:003335555555@10.1.1.254 Referred-By: <sip:269@10.1.1.254> Max-Forwards: 70 Content-Length: 0 [7] 20071211162440: SIP Tx udp:10.1.1.21:5060: SIP/2.0 202 Accepted Via: SIP/2.0/UDP 10.1.1.21:5060;branch=z9hG4bKc71e850a9CDD4873 From: "Jan Doe" <sip:269@10.1.1.254>;tag=B2AC285D-D30FAAB4 To: <sip:+12225555555@10.4.1.144:5060>;tag=3483 Call-ID: a13bf5be@pbx CSeq: 2 REFER Contact: <sip:269@10.1.1.245:5060;transport=udp> User-Agent: pbxnsip-PBX/2.1.2.2292 Content-Length: 0 [5] 20071211162440: Redirecting call to 003335555555 [7] 20071211162440: SIP Tx udp:10.1.1.21:5060: BYE sip:269@10.1.1.21:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1.1.245:5060;branch=z9hG4bK-75a2025cbb9f149ef6b5676473710cf1;rport From: <sip:+12225555555@10.4.1.144:5060>;tag=3483 To: "Jan Doe" <sip:269@10.1.1.254>;tag=B2AC285D-D30FAAB4 Call-ID: a13bf5be@pbx CSeq: 10506 BYE Max-Forwards: 70 Contact: <sip:269@10.1.1.245:5060;transport=udp> RTP-RxStat: Dur=22,Pkt=194,Oct=33368,Underun=0 RTP-TxStat: Dur=18,Pkt=198,Oct=33048 Content-Length: 0 [7] 20071211162440: fcd68b7c291ae13f1a211d4983a97584#608b460159: RTP pass-through mode [5] 20071211162440: Dialplan: Match 003335555555@10.1.1.254 to <sip:+13335555555@10.2.1.28> on trunk TEST EXT FORWARD [5] 20071211162440: Using <sip:+12225555555@10.4.1.144:5060>;tag=35ba1245 as redirect from [8] 20071211162440: Play audio_moh/noise.wav [7] 20071211162440: UDP: Opening socket on port 50750 [7] 20071211162440: UDP: Opening socket on port 50751 [7] 20071211162440: SIP Tx udp:10.2.1.28:5060: INVITE sip:+13335555555@10.2.1.28 SIP/2.0 Via: SIP/2.0/UDP 10.3.1.130:5060;branch=z9hG4bK-bcf48998571afdb4b6269e7c5fc9760f;rport From: <sip:+12225555555@10.4.1.144:5060>;tag=11350 To: <sip:+13335555555@10.2.1.28> Call-ID: cca65755@pbx CSeq: 29182 INVITE Max-Forwards: 70 Contact: <sip:4445555555@10.3.1.130:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: pbxnsip-PBX/2.1.2.2292 P-Asserted-Identity: "Jan Doe" <sip:269@10.1.1.254> Content-Type: application/sdp Content-Length: 270 v=0 o=- 12637 12637 IN IP4 10.3.1.130 s=- c=IN IP4 10.3.1.130 t=0 0 m=audio 50750 RTP/AVP 0 8 2 3 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv
×
×
  • Create New...