Vodia PBX
-
Posts
11,111 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
Check out http://wiki.pbxnsip.com/index.php/Installi...oftware_updates. After updating to 2084, you should update to 2115 (see http://www.pbxnsip.com/software).
-
You can manually edit the pbx.xml file and remove the password there (which should be a long hexnumber). After a service restart the password is empty.
-
Hmm. The attachment from the NOTIFY would be interesting. It is "human readable" and shows what the PBX opinion on the message count is. Also, see RFC 3842.
-
Well, that is a complicated topic. DTMF depends not only on the connection between the PBX and Exchange, is also depends on the DTMF that has been negotiated on the other side. In the end, a Wireshark trace will show what is the problem.
Plus it is still a mystery to me how Exchange can be made to detect inband DTMF. They are able to recognize voice, so they should also be able to detect inband DTMF IMHO. I saw it working in one place, but in other places it did not work and I have no idea why.
-
You had mentioned not having the same issue with your UM server; please let me know if there is any other Trunk debugging that I could do that would be helpful to get this fixed up.
Well, regarding the UM trunk there are two settings: The redirect flag and the "Assume that call comes from user". The last one is important if you want to accept trunk-in-trunk-out calls (which Microsoft Exchange does) - then you need to charge an account for that. Someone needs to pay the bill, even in a IP-PBX.
-
Yes...
-
Hmm. The only differernce that I can see is the missing tag on the GS. In SIP 2.0, requests must be tagged on the From header. Maybe they are using the old SIP RFC?
-
Okay, we made the 2.1 version publically available.
The release notes can be found at http://wiki.pbxnsip.com/index.php/Release_Notes_2.1.0. IMHO there are a lot of good fixes and also some interesting new features and 2.1 will be a great release!
As stated there, there is not reason to upgrade running systems unless there is a good reason in the release notes. If you just want to try the new version, please ask for a demo key and run the trial on a seperate test machine.
-
Agent groups and hunt groups do not respect redirection settings. Otherwise your office will end up with a lot of redirected calls (and loops). The only way to "redirect" hunt group calls is to use the hot seating to another extension.
-
Well, with pbxnsip you can. OCS and other products also don't do magic.
But you must be aware that the audio quality will suffer and the maximum number of calls on a 4 port FXO will be 2.
-
Well, what you can do is run a PCAP trace on the phone and see if it is really sending REGISTER packets. Or if you can have Wireshark in the network you will get a "objective" view on where it is failing. If you filter by IP address the actual PCAP trace will not become too big, so that you can run it for several hours.
If you are running the phones behind NAT, it would also be very interesting if the packets arrive at the PBX unmodified. There is some equipment out there that tries to behave smart and patches SIP packets in a bad way or randomly changes ports. Just want to make sure we are not burning time on such bad equipment!
-
This odd behavior is RFC compliant but highly non-standard and breaks symmetric NAT traversal workarounds commonly deployed by VOIP providers.
I remember that the older versions had a flag that you can switch off in the user interface. But it seems that this flag is not available in the version 8 any more?! I check my phone here, but even the unlocking does not work for me any more...
Maybe there are too many Cisco engineers in the IETF working groups and this is their way of making everyone upgrading to IPv6.
-
If the phone does not register any more, I would recommend to set the transport layer to UDP and use IP addresses (no DNS addresses). If that is not stable, there is something really strange going on. If the DNS does the trick, check out the availability of the DNS server. If the UDP does make a difference, there msut be something with the stability of the TCP connections in this setup.
-
flopping that shouldn't need a service restart, should it?
You don't have to restart the service for that.
-
Well, whenever an IP interface becomes unavailable the PBX has a problem because the internal routing tables don't fit any more. Is there any way you can stabilize that VPN connection on the PBX? For example, have another server doing the VPN and just send the traffic there (in a different IP segment)? Then the PBX IP config never changes and the PBX does not get confused.
-
The *90xxx works on my system too. I was just trying the Unicast SIP paging account and could not get any audio to play. The Aastra phones only show the caller ID on the display.
Then it is not a Aastra-specific problem... Must be something else, maybe a permission problem. Or just move to the latest and greatest 2.1.
Also, is it possible to somehow enable the *90xx inbetween two PBXnSIP installations? I have one in the US and one in Mexico both have different extension number spaces and are connected via a SIP Gateway Trunk and a dial plan entry. Would that work if I add a dial plan entry that gets the *90 & EXT over to the other system?If you register a trunk then that should be possible (maybe you just create another trunk for this purpose). The incoming call from PBX1 will be treated like a regular extension call on PBX2 - then you can call whatever you like there.
-
I verified it here and it worked fine:
[5] 2007/10/08 13:36:47: SIP Tx udp:192.168.0.155:5060:
INVITE sip:44@192.168.0.155 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.154:5060;branch=z9hG4bK-574d8fa8e8ff00be15c9d675fed0d3d5;rport
From: "41" <sip:41@test.pbxnsip.com>;tag=24656
To: "*9044" <sip:*9044@test.pbxnsip.com>
Call-ID: f259c65d@pbx
CSeq: 10040 INVITE
Max-Forwards: 70
Contact: <sip:44@192.168.0.154: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.0.2115
Call-Info: <sip:41@test.pbxnsip.com>;answer-after=0
Content-Type: application/sdp
Content-Length: 244
v=0
o=- 56981 56981 IN IP4 192.168.0.154
s=-
c=IN IP4 192.168.0.154
t=0 0
m=audio 60508 RTP/AVP 0 8 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
[5] 2007/10/08 13:36:47: SIP Rx udp:192.168.0.155:5060:
SIP/2.0 200 OK
Call-ID: f259c65d@pbx
CSeq: 10040 INVITE
From: "41" <sip:41@test.pbxnsip.com>;tag=24656
To: "*9044" <sip:*9044@test.pbxnsip.com>;tag=596481733029d22
Via: SIP/2.0/UDP 192.168.0.154:5060;branch=z9hG4bK-574d8fa8e8ff00be15c9d675fed0d3d5;rport
Content-Length: 255
Call-Info: <sip:192.168.0.154>;appearance-index=1
Allow-Events: talk,hold,conference
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Content-Type: application/sdp
Supported: replaces
Contact: "*9044" <sip:44@192.168.0.155>
User-Agent: Aastra 57i/2.0.1.2000 Brcm-Callctrl/v1.7.2.2 MxSF/v3.6.2.5
v=0
o=MxSIP 0 1562308524 IN IP4 192.168.0.155
s=SIP Call
c=IN IP4 192.168.0.155
t=0 0
m=audio 3000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
-
The problem here is that the Cisco phone sends UDP packets from a different port than it is listening on. This is extremly NAT unfriendly, and such a phone will never work behind NAT (FYI).
There is a setting on the phone called "NAT friendly UDP ports" or so that turns this off. If you toggle this flag the Cisco phone will use the port 5060 for sending and receiving.
Cisco is one of the few phones that do this. Practically all other phones use the same port for sending and receiving.
-
When we upgrade our systems, all of ithe personal announcements on the mailboxes disappear. I tried changing the mailbox setting to Name Announcement and then back to Personal and it didn't make a difference. Any ideas?
2.1 has more than one personal greeting... Unfortunately it is not so easy to migrate the old prompts to the new prompt style.
I guess manual explainations are more complicated than just doing it automatically. so check out http://www.pbxnsip.com/download/pbxctrl-2.1.0.2115.exe - it should migrate those files.
-
I would suggest to use the logging feature in the PBX. You can set per extension on what log level registration events should be logged. For example, if you set it to log level 1 and set the general log level to 2, you should be able to see when the phone looses it's registration and when it comes back.
This feature helped in other situations to figure out what was wrong. In that case there was a router that was changing the NAT binding from time to time and during that switch-over the registration got lost. A replacement of the router solved the problem.
-
When you do Intercom (*90xx) it should work. Paging as in Multicast paging will be a problem. What does the SIP INVITE packet say that goes to the Aastra phone?
-
In analog FXO, you cannot signal a transfer. All you can do it establish another connection using another FXO and then loop the calls through the SIP PBX.
I would not recommend to do this on a regular basis. Keep in mind that the audio path in such situations will become bad (at least two additional A/D conversions involved) and that you will quickly use up your FXO lines.
-
You can log into your mailbox from a trunk, then dial the star code from there (terminate it with the pound key).
-
This is a known issue. It is a little bit "magic" because in the tests it works fine, but users are reporting these issues. We need to get this situation reproduced in the lab then we can fix it.
Interconnecting two PBXnSIP
in Trunk Setup
Posted
So it works now?