Allstate Computers

The way I got this to work on version 62.0.3 is in the trunk settings, scroll down to Number/Call Identification. Set the SIP caller-ID presentation to Custom Headers, then set Remote-Party-ID to other and use the custom header {rpi}. Your mileage may vary. This is an old pbx that we're slowly upgrading to 68 (current as of this writing) and we'll be going to 63 tomorrow, so it could break by then ¯\_(ツ)_/¯. This is a huge headache every time we upgrade a system. I like the Vodia PBX as a whole, but support could be much better in cases like this. We as users and providers shouldn't have to do trial and error to solve these problems. I understand that different carriers have different settings and criteria, but with the user base this software has, support should be keeping results of theses support cases in a KB that they make available to us. Hope this helps someone. Brian

Does Vodia PBX have a text to speech function or is there a solution out there that provides text to speech in cooperation with IVR nodes? Thanks, Brian

Nevermind, I figured it out. For those looking for this: http://wiki.snomone.com/index.php?title=Dial_Plan_Time_Restrictions

Is there a way to disable outgoing calls on a specific extension or even the extension altogether on a schedule? I have a client who is a drug rehab center, and they have 2 public phones for the patients. They want to disable those phones from say 9pm to 7am. Can this be done? Maybe with a service flag? We're using version 5.1.2 at this location. Thanks, Brian

I've never tried to forward a call to a park orbit, but to solve your particular problem, I'd use an agent group. I would have the incoming call ring a hunt group with the receptionist in it say 20 - 30 seconds with the final stage set to go to the agent group.

We're running into an issue with several clients where they get no audio on an incoming call until they place it on hold and pick it back up. This is spanning 3 snomone servers; a 4.3, 4.5, and 5.0.10a. IPTables is disabled on all of them, SELinux is disabled on all of them. All of the clients have either a Sonicwall or Mikrotik router/firewall in place running QOS over Comcast either 16/2 Mbps or 20/5 Mbps connections. Phones are 320's, 720's, and 821's. Some have no audio on outgoing calls until they hang up and place the call again. Oh and its intermittent just to make it fun. Thanks, Brian

I know there is a way to provision Yealink phones using multicast, but in a hosted scenario we cannot do that. Is there a way to auto-provision Yealink phones using HTTP like with the Snom phones (ie. http://server.com/prov/snom720.htm)?

Hmm... So how would I go about changing the caller ID for a specific extensions? I have a multi-path trunk that contains multiple DID's. Their main number is the username for the trunk and the other DID's are aliased to that trunk. I need certain extensions to send a different caller-ID from the main number when diailing.

How would I modify the contact field in the trunk setup? I can get the p-asserted and p-preferred identities to match the ANI but I cannot get the Contact to match the ANI field. The username for the trunk account is different than the number I need to come up on the CID. The provider doesn't like it if I change the from, so I believe my only option is to change the contact.

We need the number to be a redirection from an extension because if she doesn't answer her cell phone or she's out of range, the call needs to fall back to the office phone's voicemail and not go through to her cellphone's voicemail.

We have a customer who is in and out of her office on a daily basis. We programmed an 'Out of Office' service flag. We have the hunt group set so that when the 'Out of Office' service flag is set it directs all calls to her extension. If I set the 'Specify time when system calls the cell phone: No specific time excluded', then it will call her cell phone. If I set it to 'Out of Office' then it won't call her cell phone. The problem is we only want it to call her cellphone when the 'Out of Office' flag is set. So I need it to work the opposite way it's currently working. Is there a way to make it work where the system will only call her cell phone if the 'Out of Office' flag is set. It is important that it call the cellphone through extension redirection so that if she doesn't pick up it falls back to her office phone voicemail and doesn't go to her cell phone voicemail. I did see this post: http://forum.snomone.com/index.php?/topic/5799-service-flag-for-cell-phone-times/ which seems he is having a similar issue to us. Perhaps if there is currently no way to do this the Snom dev team should add it. Seems like a simple logic addition - maybe a include/exclude radio button next to the Specify time option. Thanks, Brian

I know this is an older thread, but I figured I'd put in my $0.02 anyways. We're successfully running snomONE on a Microsoft Hyper-V cluster. The failover time is very fast. We haven't tested to see if calls or ACD instances stay up, but most of the time when someone gets a dropped call they just re-initiate the call. They don't start freaking out unless they can't place the call again. We've seen mostly 20-30 second migrations. I'm trying to figure out how to setup a distributed redundant configuration where one PBX is in one datacenter and the other PBX is an another datacenter. Anyone got any ideas on this one? ::cough ::cough snom?

That worked, thanks very much . Brian

Ok, now it's coming up - I had SIP events set to 9, sorry. [9] 2012/04/05 17:04:06: Incoming: formatted To is = <sip:+15555555555@{customersIP}:5060;user=phone> So how do you deal with a +1?

There is no line in the log like that. I did a search for 'Incoming' which only came up once for the first line I already mentioned, and I did a search for 'formatted' which yielded no results.

I tried the 1 just for grins and it made no difference. The number in the To: field is just the 10 digit number, there is no 1 prepended to it. Here is the actual message from the log: [8] 2012/04/04 09:54:49: Incoming call: Request URI sip:1111111111@{customersIP}:5060, To is <sip:5555555555@{customersIP}:5060> [8] 2012/04/04 09:54:49: Set the To domain based on To user 300@{customersDomain} What is driving me in circles is if you look at the call log it says that the call went to that extension, but it doesn't it goes to the hunt group.

We're running into an issue with a client's system - running snomONE Blue 4.3.0. We have 6 numbers for the domain and they are assigned as follows: To protect the innocent I've changed the names and numbers (111)111-1111 - Hunt Group 300 - Main Number (222)222-2222 - Hunt Group 301 - Back Line (333)333-3333 - Hunt Group 302 - Service Department (444)444-4444 - Hunt Group 303 - Shipping Department (555)555-5555 - Extension 202 - Service Manager (666)666-6666 - Extension 203 - Bookkeeper For the trunk I have the 'send to extension' field set to: !([0-9]*)!\1!t!300 No matter what I do all of the calls go to Hunt Group 300, but it's really weird because if I call (555)555-5555 it says 'Service Manager (202)' in the Call Log but it routes the call to the Hunt Group instead. The main number (111)111-1111 is the username for the trunk and the other numbers are aliases. My proxy server is set to make the alias the To: field in the SIP header. If I call (555)555-5555 from my cell phone (999)999-9999 the INVITE looks like this: INVITE sip:1111111111@{customersIP}:5060 SIP/2.0 Via: SIP/2.0/UDP {myProxyIP}:5060;rport;branch=z9hG4bK0dd8e0b61501b567ea47-dbf76dba-f7dfd81f Via: SIP/2.0/UDP {sipProviderIP}:5060;branch=z9hG4bK1e4b27fe;rport=5060 From: "9999999999" {sip:9999999999@sipProviderIP}>;tag=as1addfed2 To: <sip:5555555555@{myProxyIP}:5060> Contact: {sip:9999999999@208.115.60.141:5060} Call-ID: 49293b426af17c514b75865947d2976f@{sipProviderIP} CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 69 Date: Wed, 04 Apr 2012 01:42:56 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Record-Route: <sip:{myProxyIP}:5060;lr> Content-Type: application/sdp Content-Length: 332 I'm at a loss, any assistance would be greatly appreciated. Thanks, Brian

We ran into the same issue. Actually after the upgrade we couldn't make outgoing calls at all. After about 20 mins of playing with it we figured it out. We're using custom headers, which is a pretty cool feature because it allows you to set the caller-id to whatever want. The settings will need to be modified to match your SIP provider's requirements - since we are our own sip provider it was pretty easy. The problem more than likely lies in the Remote-Party-ID: portion. We set ours to "Based on incoming call" that way when a call comes in and the system reroutes it to a cell phone, we get the caller id of the incoming call rather than our office number. That way you can determine if you want to accept the call or not... uh I mean if you don't answer it in time, you can call them back . Hope that helps! Brian

We're using hosted snom ONE ver 4.0.1.3499 (Linux). We're running into an intermittent issue where when you dial a number and hit the check mark it grabs a shared line you'll hear the comfort noise and then the light goes out and the call goes dead. Now the call does still go through to the other side but the callee gets dead air. We've tried 3 different providers, and 2 different Internet connections (Comcast and Windstream T1), as well as 3 different routers (Linksys WRT54GL, PFSense, SonicWall TZ180). The phones are Ssnom 320s and 370s. I've only seen it happen when we dial the number with the receiver on the hook, hit the check mark, and then pick up the phone before it starts to ring. However, I've had clients call with this problem that state they weren't using speakerphone. Sometimes if you hit the redial button, it'll do it again, and sometimes it'll go right through. Here is the call flow in the logfile: x's are the last 4 of callee's phone number [7] 2011/08/17 10:55:36: SIP Rx tls:64.139.77.137:54696: INVITE sip:xxxxxxx@pbx.allstatecomputers.com;user=phone SIP/2.0 Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-5sw0ts03k0wc;rport From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone> Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:405@192.168.100.120:1402;transport=tls;line=5z91mad1>;reg-id=1 X-Serialnumber: 00041326601A P-Key-Flags: resolution="31x13", keys="4" User-Agent: snom370/8.2.29 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600;refresher=uas Min-SE: 90 Proxy-Require: buttons Content-Type: application/sdp Content-Length: 530 [7] 2011/08/17 10:55:36: SIP Tx tls:64.139.77.137:54696: SIP/2.0 100 Trying Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-5sw0ts03k0wc;rport=54696;received=64.139.77.137 From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone>;tag=aa112c7956 Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 1 INVITE Content-Length: 0 [7] 2011/08/17 10:55:36: Set packet length to 20 [6] 2011/08/17 10:55:36: Sending RTP for 3c4b75252475-v0yf8yotze2n#aa112c7956 to 192.168.100.120:59716 [7] 2011/08/17 10:55:36: SIP Tx udp:208.115.60.142:5060: INVITE sip:1561427xxx@208.115.60.142;user=phone SIP/2.0 Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-3e3e98944e760e7f42026e1128561203;rport From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone> Call-ID: a086938b@pbx CSeq: 14029 INVITE Max-Forwards: 70 Contact: <sip:5617431521@208.115.60.136:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: AllstateTelecom-PBX/4.0.1.3499 Content-Type: application/sdp Content-Length: 290 v=0 o=- 1066957623 1066957623 IN IP4 208.115.60.136 s=- c=IN IP4 208.115.60.136 t=0 0 m=audio 61400 RTP/AVP 18 0 101 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [7] 2011/08/17 10:55:36: Set packet length to 20 [6] 2011/08/17 10:55:36: Send codec pcmu/8000 [7] 2011/08/17 10:55:36: SIP Tx tls:64.139.77.137:54696: SIP/2.0 183 Session Progress Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-5sw0ts03k0wc;rport=54696;received=64.139.77.137 From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone>;tag=aa112c7956 Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 1 INVITE Contact: <sip:405@208.115.60.136:5061;transport=tls> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: AllstateTelecom-PBX/4.0.1.3499 Require: 100rel RSeq: 1 Content-Type: application/sdp Content-Length: 484 v=0 o=- 1439637230 1439637230 IN IP4 208.115.60.136 s=- c=IN IP4 208.115.60.136 t=0 0 m=audio 54918 RTP/AVP 0 8 9 18 2 3 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:kdbRvVLTrWAjCHLIafsjJnz9s8mbK+JTtKFDOscV a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [7] 2011/08/17 10:55:36: SIP Rx udp:208.115.60.142:5060: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-3e3e98944e760e7f42026e1128561203;rport=5060 From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone>;tag=7696ca4181be7f5787517527c78a3092.7f39 Call-ID: a086938b@pbx CSeq: 14029 INVITE Proxy-Authenticate: Digest realm="208.115.60.142", nonce="4e4bd777000004bf7965b8ab80081eb702aeab3b0d6c916b" Server: OpenSIPS (1.6.4-2-tls (i386/linux)) Content-Length: 0 [7] 2011/08/17 10:55:36: SIP Tx udp:208.115.60.142:5060: ACK sip:1561427xxxx@208.115.60.142;user=phone SIP/2.0 Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-3e3e98944e760e7f42026e1128561203;rport From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone>;tag=7696ca4181be7f5787517527c78a3092.7f39 Call-ID: a086938b@pbx CSeq: 14029 ACK Max-Forwards: 70 Content-Length: 0 [7] 2011/08/17 10:55:36: SIP Tx udp:208.115.60.142:5060: INVITE sip:1561427xxxx@208.115.60.142;user=phone SIP/2.0 Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-5e0d32504503372356c54f08ea6ef395;rport From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone> Call-ID: a086938b@pbx CSeq: 14030 INVITE Max-Forwards: 70 Contact: <sip:5617431521@208.115.60.136:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: AllstateTelecom-PBX/4.0.1.3499 Proxy-Authorization: Digest realm="208.115.60.142",nonce="4e4bd777000004bf7965b8ab80081eb702aeab3b0d6c916b",response="643e10a3e747539004c22ef2b9175779",username="5617431521",uri="sip:1561427xxxx@208.115.60.142;user=phone",algorithm=MD5 Content-Type: application/sdp Content-Length: 290 v=0 o=- 1066957623 1066957623 IN IP4 208.115.60.136 s=- c=IN IP4 208.115.60.136 t=0 0 m=audio 61400 RTP/AVP 18 0 101 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [7] 2011/08/17 10:55:36: SIP Tr udp:208.115.60.142:5060: INVITE sip:1561427xxxx@208.115.60.142;user=phone SIP/2.0 Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-5e0d32504503372356c54f08ea6ef395;rport From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone> Call-ID: a086938b@pbx CSeq: 14030 INVITE Max-Forwards: 70 Contact: <sip:5617431521@208.115.60.136:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: AllstateTelecom-PBX/4.0.1.3499 Proxy-Authorization: Digest realm="208.115.60.142",nonce="4e4bd777000004bf7965b8ab80081eb702aeab3b0d6c916b",response="643e10a3e747539004c22ef2b9175779",username="5617431521",uri="sip:1561427xxxx@208.115.60.142;user=phone",algorithm=MD5 Content-Type: application/sdp Content-Length: 290 v=0 o=- 1066957623 1066957623 IN IP4 208.115.60.136 s=- c=IN IP4 208.115.60.136 t=0 0 m=audio 61400 RTP/AVP 18 0 101 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [7] 2011/08/17 10:55:37: SIP Rx tls:64.139.77.137:54696: PRACK sip:405@208.115.60.136:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-s7rdxl5fra9l;rport From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone>;tag=aa112c7956 Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 2 PRACK Max-Forwards: 70 Contact: <sip:405@192.168.100.120:1402;transport=tls;line=5z91mad1>;reg-id=1 RAck: 1 1 INVITE Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Proxy-Require: buttons Content-Length: 0 [7] 2011/08/17 10:55:37: SIP Tx tls:64.139.77.137:54696: SIP/2.0 200 Ok Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-s7rdxl5fra9l;rport=54696;received=64.139.77.137 From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone>;tag=aa112c7956 Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 2 PRACK Contact: <sip:405@208.115.60.136:5061;transport=tls> User-Agent: AllstateTelecom-PBX/4.0.1.3499 Content-Length: 0 [7] 2011/08/17 10:55:37: Discard SRTCP packet from 64.139.77.137:3725 with wrong MAC [6] 2011/08/17 10:55:37: Sending RTP for 3c4b75252475-v0yf8yotze2n#aa112c7956 to 64.139.77.137:3724 [7] 2011/08/17 10:55:37: SIP Rx udp:208.115.60.142:5060: SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-5e0d32504503372356c54f08ea6ef395;rport=5060 From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone> Call-ID: a086938b@pbx CSeq: 14030 INVITE Server: OpenSIPS (1.6.4-2-tls (i386/linux)) Content-Length: 0 [7] 2011/08/17 10:55:37: SIP Rx udp:208.115.60.142:5060: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-5e0d32504503372356c54f08ea6ef395;rport=5060 From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone>;tag=7696ca4181be7f5787517527c78a3092.0d2d Call-ID: a086938b@pbx CSeq: 14030 INVITE Proxy-Authenticate: Digest realm="208.115.60.142", nonce="4e4bd779000004c0e6af14460e0b7de18ace196d8577917f", stale=true Server: OpenSIPS (1.6.4-2-tls (i386/linux)) Content-Length: 0 [7] 2011/08/17 10:55:37: Call a086938b@pbx#174310263: Clear last INVITE [7] 2011/08/17 10:55:37: SIP Tx udp:208.115.60.142:5060: ACK sip:1561427xxxx@208.115.60.142;user=phone SIP/2.0 Via: SIP/2.0/UDP 208.115.60.136:5060;branch=z9hG4bK-5e0d32504503372356c54f08ea6ef395;rport From: <sip:5617431521@208.115.60.142>;tag=174310263 To: <sip:1561427xxxx@208.115.60.142;user=phone>;tag=7696ca4181be7f5787517527c78a3092.0d2d Call-ID: a086938b@pbx CSeq: 14030 ACK Max-Forwards: 70 Contact: <sip:5617431521@208.115.60.136:5060;transport=udp> Content-Length: 0 [5] 2011/08/17 10:55:37: INVITE Response 407 Proxy Authentication Required: Terminate a086938b@pbx [7] 2011/08/17 10:55:37: SIP Tx tls:64.139.77.137:54696: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-5sw0ts03k0wc;rport=54696;received=64.139.77.137 From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone>;tag=aa112c7956 Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 1 INVITE Contact: <sip:405@208.115.60.136:5061;transport=tls> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: AllstateTelecom-PBX/4.0.1.3499 Content-Length: 0 [7] 2011/08/17 10:55:38: SIP Rx tls:64.139.77.137:54696: ACK sip:427xxxx@pbx.allstatecomputers.com;user=phone SIP/2.0 Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-5sw0ts03k0wc;rport From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone>;tag=aa112c7956 Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 1 ACK Max-Forwards: 70 Contact: <sip:405@192.168.100.120:1402;transport=tls;line=5z91mad1>;reg-id=1 Proxy-Require: buttons Content-Length: 0 [7] 2011/08/17 10:55:39: SIP Rx udp:208.115.60.142:5060: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 208.115.60.136:5060;received=208.115.60.136;branch=z9hG4bK-5e0d32504503372356c54f08ea6ef395;rport=5060 Record-Route: <sip:sansay527215264rdb19609@64.136.174.30:5060;lr;transport=udp> Record-Route: <sip:208.115.60.142;lr=on> To: <sip:1561427xxxx@208.115.60.142;user=phone>;tag=sansay527215264rdb19609 From: <sip:5617431521@208.115.60.142>;tag=174310263 Call-ID: a086938b@pbx CSeq: 14030 INVITE Contact: <sip:1561427xxxx@64.136.174.30:5060> Content-Type: application/sdp Content-Length: 214 v=0 o=Sansay-VSXi 188 1 IN IP4 64.136.174.30 s=Session Controller c=IN IP4 74.120.93.70 t=0 0 m=audio 21672 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 [7] 2011/08/17 10:55:41: SIP Rx tls:64.139.77.137:54696: CANCEL sip:427xxxx@pbx.allstatecomputers.com;user=phone SIP/2.0 Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-5sw0ts03k0wc;rport From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone> Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 1 CANCEL Max-Forwards: 70 Reason: SIP;cause=487;text="Request terminated by user" Proxy-Require: buttons Content-Length: 0 [7] 2011/08/17 10:55:41: SIP Tx tls:64.139.77.137:54696: SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/TLS 192.168.100.120:1402;branch=z9hG4bK-5sw0ts03k0wc;rport=54696;received=64.139.77.137 From: "Brian Artigas" <sip:405@pbx.allstatecomputers.com>;tag=9aa6p7ailg To: <sip:427xxxx@pbx.allstatecomputers.com;user=phone> Call-ID: 3c4b75252475-v0yf8yotze2n CSeq: 1 CANCEL Content-Length: 0 Any input would be greatly appreciated. Thanks, Brian

Are you saying that I can't get an m3 to work with SnomONE?

How might one auto provision a Snom M3 in SnomONE. I would normally go to www.pbxnsipsupport.com and consult the knowledgebase, but I cannot seem to find it. Any advice would be greatly appreciated. Thanks, Brian

We're trying to figure out the best practice for this situation. We have a client with two locations, both locations have their own DIDs. We'd like to have 5 lines total - so if location 1 is using 3 lines then there are one 2 lines available for location 2. We figured we'd do this by combining two DID's into one trunk and then assigning co1 - co5 to that trunk. This way if a call comes into location 1 and the person that needs to receive the call happens to be at location 2 that day, the receptionist in location 1 can just put the call on hold and notify location 2 of which line the caller is holding on. We know we need two hunt groups, one for location 1 and one for location 2. How do you set it up so that the trunk will send the call to the proper hunt group based on the DID rather than account number? Thanks, Brian

We figured out what the issue was. In the trunk settings try changing the "Remote Party/Privacy Indication" field to "No Indication". The default is "RFC3325 (P-Asserted-Identity). An explanation of that section can be found at the link below. http://www.pbxnsipsupport.com/index.php?_m...v=0,142,233,248 Brian

Hello, We have been unable to place an outbound call from a cellphone. We just get a message from the system saying "The call could not be established." We can't find anything in the logs showing what may be causing the call to fail. Any ideas? Thanks, Brian

Yep, we're running Centos with PBXnSIP on a Hyper-V Cluster. Works great, the only problem we've had is a Centos/Hyper-V issue with the system clock. You have to modify the grub file and configure ntpd. Otherwise it works great.