edwardforgacs
-
Posts
29 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by edwardforgacs
-
-
I can confirm that setting "Lock codec during conversation" to true on the trunk fixed it, no transcoding messages.
I would just like to understand why that is necessary to avoid transcoding when the codecs match anyway.
A word of warning to others with regards to that setting though, if you force it to a codec which the other end doesn't support, and set "Lock codec during conversation" to yes, I have seen the situation where calls ring but refuse to connect due to incompatible codecs.
-
As you mentioned, when the packet size is different and/or negotiated codecs on either side of the call is different, then PBX will do the transcoding.
You can control this behaviour by setting the "Lock codec during conversation" under Admin->Settings->Ports page and the trunk page.
If you did not have this set, then the PBX pass the RTP using codec type that is negotiated on the outgoing call leg. Maybe PBX spits out the below log message in this case too, which may be confusing. We are cleaning up the log in the 4.0 version.
This doesn't make any sense. Are you saying that the log says "falling back to transcoding" when it isn't actually transcoding? If it is transcoding, *why* is it transcoding? We're in agreement that it isn't because of the packet size or codec, so what is the cause?
The "lock codec during conversation" wasn't set on this trunk, I have tried setting to see if it makes any difference. My understanding was that that setting influenced whether it would be able to negotiate a codec in the first place which isn't the problem here. The SIP packets clearly show that the same two codecs are accepted by both (PCMA and PCMU in that order), and both are using a packet size of 20ms.
I was wondering if the problem could be that PBXnSIP shows the codecs as e.g. a=rtpmap:8 PCMA/8000 whereas the gateway shows them as a=rtpmap:8 PCMA/8000/1 - i.. the extra /1. Is there possibly a bug where it thinks the codecs are different because of the different packet format?
-
Can someone please explain what the following log messages actually mean, and what the problem is caused by?
I have seen the packet size mismatch and different codec issues, but not this "cannot pass through" error. The device it is trying to pass through is a Quintum gateway and the codecs and packet sizes do match as indicated by the SIP messages.
[7] 2009/09/16 19:13:09: 7ef0d3f3@pbx#624788665: RTP pass-through mode
[7] 2009/09/16 19:13:09: 3c269b549362-jhbdc5ainorw#90c6c3ebc6: RTP pass-through mode
[7] 2009/09/16 19:13:11: Cannot pass through on 7ef0d3f3@pbx#624788665, falling back to transcoding
AND
[7] 2009/09/16 20:37:08: 8b981f0f-180a-464e-95ea-76835e173d40@192.168.0.2#43bfd52868: RTP pass-through mode
[7] 2009/09/16 20:37:08: 97e9242f@pbx#1291898535: RTP pass-through mode
[7] 2009/09/16 20:37:08: Cannot pass through on 8b981f0f-180a-464e-95ea-76835e173d40@192.168.0.2#43bfd52868, falling back to transcoding
[7] 2009/09/16 20:37:08: Cannot pass through on 97e9242f@pbx#1291898535, falling back to transcoding
-
After installing this upgrade I was unable to place ANY calls via the PSTN gateway - I got a lot of hissing followed by a request timeout.
I have now reverted to version 7.27.
-
Did anyone ever get a phone behind a Microsoft ISA server connect to a PBXnSIP server on the public internet.
I tried following http://stewedprunes.com/blogs/stewed_prune.../08/29/502.aspx written for Vonage and changing the RTP port range, and also forwarding ports 5060-5080 tcp and udp it did not work.
If I set transport=tcp, then I get http://wiki.pbxnsip.com/index.php/One-way_Audio.
As far as I know, this is completely impossible - it just can't work. Unfortunately, ISA Server 2006 (and older versions) do not support SIP at all. Because of this, you can publish the SIP ports, but the RTP ports will never open properly (because they are created dynamically, creating the one-way audio problem). We experienced this ourselves a long time ago trying to connect to our SIP trunk provider via ISA (before we used PBXnSIP) and the word from Microsoft was that it simply isn't compatible.
What I would try to do is set up a VPN into the PBXnSIP server, which will get around the issue by bypassing ISA. Other options would be to use another firewall which is compatible with SIP and can open the right ports - most Cisco devices will do that fine for example. A lot of low-end devices also let you create a DMZ which would get around the issue too. In this case, you could put these in front of the ISA server, but the phones would have to be connected in such a way that they never cross ISA because it completely breaks SIP.
-
We are trying to send faxes over SIP lines (not via the FXO gateway) and I have used this with the same provider on a different device so I know it should work - not via the FXO lines so that shouldn't be the issue.
Can you drop me an email so I can send you the full log please? I'm not sure really what bit you're after and the log is huge when it's set up to show anything meaningful for fax calls.
-
Can you post the actual request that PBX receives?
We've got it dialling out now with an amazing amount of hassle with the special Fax dial plan, but the fax calls always drop after about 40 seconds with "send error, no answer".
I suspect a codec problem as the speed is reported as 300bps (although I'm not sure this is 100% accurate either).
Firstly, does the CS410 support T.38 passthrough? What needs to be configured to enable it in terms of codecs (the system is set up currently to only use G.711a and G.711u in that order)?
-
Is PBXnSIP also supported, or has anyone got it working, with the free VOIP plugin for Windows Fax that FaxBack offer (which appears to have an *identical* architecture from the SIP end)? We have got it working fine for inbound faxes, but nomatter what configuration we try, it is unable to send faxes outbound.
PBXnSIP seems to get confused by the sip: prefix that FaxBack uses in the SIP messages, but we got around that with a special dial plan for the fax extension.
All the fax calls now start dialling, but fail immediately "bad address" in the fax software and the following 400 bad request error:
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK1005
From: IPFax <sip:108@192.168.0.2>;tag=IPF_PORT_0001_1003
To: <sip:88888888>;tag=01d725d3ce
Call-ID: d32d6fff-77bf-41db-bdc7-4143ba5e8638@192.168.0.2
CSeq: 2 INVITE
Contact: <sip:108@192.168.0.10:5060>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: pbxnsip-PBX/3.4.0.3201
Content-Length: 0
(please note the 88888888 above is the correct destination fax number)
-
I can confirm we've experienced this exact same scenario, and we actually have a support case open about it.
In our case the AA was Exchange 2007, but like you mention the line stayed off hook for over 14 minutes, despite the caller hanging up, until the cable was physically disconnected from the CS410 to reset the line.
We are also using the version 3.4 firmware.
I wonder if this is an issue with the Australian tone settings? The only PSTN settings on this version for the CS410 seem to be FX Impedance and CPC Duration (Complex and 400 respectively in our setup), so I presume the others are set automatically for Australia based on the regional settings on the device?
-
Yes, I understand what you're saying here, but:
* I would really be surprised if it's that hard for the processor to add VLAN tagging to the SIP/RTP packets. Other devices (like cheap consumer telephone adapters) manage to do that, if the CS410/425 can't then it's really not up to scratch. Also as I mentioned our Snom phones also support it, I would imagine they have much less processing power.
* If "small" IT shops don't know what a VLAN is, they should steer clear of VOIP solutions because they will end up with a lot of very angry customers - it frankly doesn't work, the whole network needs to be properly designed to support it or it is a recipe for disaster. We are one of those shops and we are not willing to recommend a solution to customers that has no QoS because we have seen those setups fall over.
* If we're trying to avoid confusing these guys, it would make sense to support the many "voice-enabled" switches which are designed to work with VLAN tagging, so the web console still works without setting up inter-VLAN routing on another device. The layer 3 devices which support inter-VLAN routing are likely beyond the budget of a lot of the target market of the CS410/425 but lots of layer 2 "voice-enabled" ones aren't. At the moment it doesn't work with the cheaper ones as far as I'm concerned because to make it usable (to access the web console on the PBX), you need inter-VLAN routing.
At the end of the day, we are going to set up inter-VLAN routing in our own setup so I'm not too fussed, just amazed that this feature has been overlooked.
-
Hi All -
On a new cs410 installation trunk 1 simply busys out (short circuits or is seized) after a few hours and there is no log entry. Outgoing calls no longer use that trunk and no calls show in progress. A hard restart and all is well for now. I will see what it's like tomorrow but it's feeling like a hardware issue. Has anyone else experienced this one?
This is on an AT&T 5ESS and I am getting CPC signals from the phone company. Thoughts?
AK
I had the exact same issue today and I have a support request open about it. What seemed to happen here was that a call was answered, but when the user hung up, the line didn't go back to the on-hook state - the line was just jammed.
-
Unfortunately, we can't do what you described because our router does NAT with DMZ, so we have to have the WAN port plugged into the router. We could possibly configure the web console to be accessible via the router but it seems like it is reducing security.
>we've yet to see any reason to deploy VLANs in smaller installations.
I could not disagree more. We have had call drop outs on internal calls as a result of QoS problems.
Quite simply, it seems like a sloppy, half-baked solution to be not using VLANs on any IP-PBX solution. Almost every other commercian IP-PBX I know of supports this. If PBXnSIP is to be a professional solution then it has to work reliably, and having voice traffic on a separate VLAN is a fundamental requirement of having the network set up properly.
-
RESOLVED: I upgraded one of the Snom 360 phones to 7.3.23 firmware (latest public release), and this issue went away. Perhaps that will help someone else should they have the same problem.
I have not yet experienced any new/unique issues due to the new firmware. This is still a lab/testing setup and not a live/production setup (yet), but are there any known concerns/issues with using this new Snom firmware with pbxnsip/cs410 version 3.3.2.3181?
As always, THANKS!
Unfortunately that didn't resolve it for me, I've got the exact same issue with that model of firmware, and I'm also using a PBXnSIP CS410, though it's version 3.4.0.3201.
-
Unfortunately that is not a option for us as we have just purchased some expensive 3Com gear for this purpose, which doesn't support L3 routing like the DLink product but is specifically designed for voice.
It seems very odd that an IP-PBX product wouldn't support VLAN tagging when all other products do, including the IP phones we're using and the Exchange server being used for voicemail.
Are there any plans to fix this on the CS410?
-
Cisco consider it secure enough in their CallManager product.
Assuming the MWI is going to be provided by a third party product though, can you allow PBXnSIP to accept these messages with some form of authentication?
-
Yes, I can see that is an issue, and I'm not sure how Exchange handles the installation.
It is frustrating though that other PBXs allow you to basically turn off the security on this though to get the MWIs to work, and PBXnSIP doesn't - having a slight internal security risk is better than no MWIs at all.
-
I am not very clear about the SIP NOTIFY plans at this moment.
If I understand the requirements correctly from your message, when someone leaves a voicemail, Exchange 2010 will send a NOTIFY to the PBX and PBX should send the MWI to the corresponding phone. Is that correct?
This is the SIP NOTIFY that I have constructed from reading some SIP docs and packet sniffing what some of the third-party Exchange 2007 MWI tools send (where 192.168.0.3 is the Exchange server and 192.168.0.10 is PBXnSIP):
NOTIFY sip:101@192.168.0.10 SIP/2.0
Via: SIP/2.0/TCP 192.168.0.3:5060;branch=z9hG4bK.37ace54681;rport;alias
From: <sip:101@192.168.0.3>
To: <sip:101@localhost>
Contact: <sip:101@192.168.0.3>
Call-ID: 54681@192.168.0.3
CSeq: 54681 NOTIFY
Event: message-summary
Subscription-State: active
Content-Type: application/simple-message-summary
Content-Length: 49
Messages-Waiting: yes
Voice-Message: 1/0 (0/0)
I would imagine that Exchange 2010 will do something very similar to this, and that it may also require the PBX to support these sort of NOTIFY messages without having a subscription (unsolicited NOTIFY).
Currently these messages are rejected by PBXnSIP with 404 not accepted.
-
Thanks for the reply. I did try the vconfig command on the CS410 and unfortunately it doesn't appear to be supported.
The issue with setting it on the switch is as follows. The switch can be set so that all traffic on that particular port defaults to the Voice VLAN if it is untagged, however this means that the web console becomes part of the voice VLAN and is inaccessible without a device capable of doing inter-VLAN routing.
The WAN port is not an issue in my setup as it is connected directly to the DMZ port of a NAT router which is SIP-aware and that port gives traffic a higher priority.
-
Is it possible to configure VLAN tagging on the CS410 device? We would like to be able to use the QoS features of our switch without having to use a higher-end layer 3 switch which supports inter-vlan routing.
-
I am unable to get BLF buttons to work satisfactorily with Snom 370 phones. I have tried both the "BLF" and "Extension" settings. I'm running the latest firmware (PBXNSIP 3.4.0.3201 and Snom 7.3.23) both on the CS410 and the phones.
Basically, it seems that the BLF keys work as expected, except on the extension that the call is initiated from???? This is incredibly weird.
From, say, extension 101 dialling, say, extension 104, if you dial the numbers 104, the BLF key for 101 comes on solid, but the BLF key for 104 never comes on at all. If you press the 104 BLF to dial instead of entering the actual numbers, then the BLF light for 104 & 101 come on, but 104 is on solid even when it is ringing.
If I watch the lines on 101 from 106, it works as it should (flashing when ringing and solid when off hook).
The extensions are configured with a star (*) for "Watch the calls of the following extensions (* for all):" and "Watch the presence of the following extensions (* for all):" in the account setup.
Any thoughts?
-
Well the caller-ID is transmitted between the first and the second ring. That's why analog phones with Caller-ID support first start ringing and then after that start showing the Caller-ID.
Unfortunately, the genius that specified SIP did not envision that and wrote that the caller-ID cannot be changed after call setup (though there is a new RFC that now starts supporting that, but procatically all SIP phones not support that yet). That is why the CS410 FXO gateway waits for the second ring before it sends the call to the SIP phone.
Sorry to re-open an old thread, but we are using this device in an Australian setup and have the same problem. As we don't even have caller ID enabled on the PSTN line as you have to pay for it (we use PSTN only to retain an old number and for emergency calls), can we disable the caller ID functionality in pbxnsip for that line to avoid the delay?
-
Sorry to re-open an old thread but thanks for the tip!
The latest version (3.4.0.3201) still has this issue but I can confirm that deleting those files fixed the problem.
-
Currently, we have "SetExtensionParameterRequest" SOAP api, which can be used to set the voice mail indicator on the extension. But MWI is not sent to the phones on this change in the versions that are available for the public. But we have already added this on a beta version.
Thanks for the info. Can you let us know what version number will have this feature?
Also, are there any plans to support the SIP notify approach for Exchange 2010 compatibility?
-
Yea, it is amazing that the Exchange (a great product) had a blackout on MWI. The way you are supposed to get the MWI is to poll the Exchange server through SOAP messages. IMHO that is a joke.
Then if you actually know that there is a SIP account that has a MWI, then the next step is to tell the PBX about it. Here we go with the next SOAP message. Because pbxnsip also supports SOAP! But of course the two SOAP messages are totally unrelated.
I really don't know... If someone can give me an example on how the SOAP messages to Exchange look like it is probably easier to do the SOAP natively in pbxnsip than to use 3rd party software (which is sometimes even more expensive than the IP-PBX!).
The Exchange team would everyone do a favor by using the well-established RFC for MWI.
Yeah, it is amazing that Exchange 2007 just "forgot" about this feature. Fortunately it is sorted in Exchange 2010.
If pbxnsip can turn on the MWI lights via a SOAP message, then I'm sure we can hack up something to get it working as we are a .NET software company.
Can you provide a link to any docs about the SOAP APIs for PBXnSIP, and a sample SOAP message that turns on the MWI light? This approach did cross my mind before but I was unable to find any docs on it, so I started exploring SIP solutions as mentioned above.
Exchange 2010 RTM Support
in Microsoft Exchange
Posted
Exchange 2010 RTM has been out since October 2009. Are there any plans for PBXnSIP to support Exchange 2010?
I notice that PBXnSIP version 2.0 was on the official list of Microsoft-supported IP-PBX platforms, but 3.0 and 4.0 are not, not even for Exchange 2007. Are there any plans for current versions of PBXnSIP to be re-certified with Microsoft as supported telephony platforms?