Carl Johnson

Any advice on the Country code response and logging question?

can you please produce a debian 4.0 x86 binary?

Additional issue .. in the RC for some reason VM messages are not recording (that is why is need the logging working) and it seems related to this situation and not "normal" extenstions. Caller comes into AA then presses 6 which transfers them to an extenstion with NO registrations, when the caller is connected the VM (goes right to VM as it is unregisterd .. lets call this a VM only ext) the prompts and recordings are playing and the user is leaving a VM but for some odd reason unless the caller presses # or a digit it will NOT leave the VM which is very odd as usually a call disconnect works just as well and is certanly not expected! PLEASE check this out.

Can you help me with the logic in only allowing 3 trunks on the CS425 as this is an outstanding solution for places with multiple offices, in our case 1 with a 100 user PRO version and then smaller offices with CS425 solutions and for site to site dialing it really does not make sense to limit to three trunks for that .. can you maybe add a S2S trunk that is unlimited or at least could be licensed for more than 3?

I did have 1 as the CC before the upgrade and yes it was a bit bumpy .. any feedback on the logging issue?

Okay on the transformations .. we have the dialplan set as NAPNA 3 digit and when entering an extension as: ** Inbound DNIS ** In v3.0 we had setup extensions as 123 with a tel:40612345678 alias and after conversion to 3.1 it added the 011 to all of these so in the ext it showed 123 011 40 61234567 or something similar? v3.1 - when we have an extension same as the areacode it tried adding +1 to it? v3.1 - 123 4061234567 it changes to 123 (406)123-4567 on the screus-en and then in the user alias db entry it stores 445.xml:<row><display>(406)123-4567</display><domain>2</domain><name>+140612345678</name><user>35</user></row> We took care of the issue with the inbound by adding that to the incoming number as it was coming in as 10 digits so we prepended in the inbound trunk +1 to those .. should that be required just to a version upgrade? Before: !([0-9]{10})!\1!t!500 .. for 2.x 3.0 After: !([0-9]{10})!+1\1!t!500 for 3.1 ** Logging ** Also, we are trying enable logging which full debug and it just ignores me and does not do so, no file no log entries in the status->log ** Outbound ** Why does it still transform the OUTBOUND ANI to a full number

More issues .. On the trunk settings, the NAPNA 10 digit, it totally ignores that as it is still sending +[CC][AC][NUMBER] Also, when it saves the aliases, it stores them as +[CC][AC][NUMBER] even when entered as [AC][NUMBER] so on inbound the rule from 2.x, 3.0 does not work?

Couple issues on test to this version. All tel (10 digit) aliases had 011 appeneded to them, that is a lot of work to fix! Inbound calls on trunk, unchanged from 3.0.1 to 3.1 will not hit extension based on tel alias (account) as before .. for example we get a 10 digit DNIS and have the account set with that 10 digit as an account alias but it does not match as expected and goes to default (AA)? Outbound issue with forcing ANI on redirections from outside is still exisitng.

Can you post a debian 4.0 x86 version?

Anyone?

That is the setting I am using .. what I would like to know is if a call comes in how can I FORCE the outgoing ANI to be the extenstions ANI vs the incoming caller-id?

On this, I have been testing build 3033 and have a few questions so on these scenarios: 1) I dial out on my extension that has an ANI set, it properly passes that ANI 40612345678 in the FROM header as set on the extension and using the NAPNA 10 trunk setting From: "Carl Johnson" <sip:40612345678@192.168.40.218;user=phone>;tag=574149672 2) I dial into the PBX with a header of: From: <sip:4067890000@rcp.local:5060>;tag=3184c2f731d55ce then that extension is set with a proper ANI and is setup to redirect calls outside via the same trunk as used above the system isists on sending the users inbound caller-id, which is not what is hoped for can we resolve this somehow our our circuits lock us into to providing out caller-id that is valid and known as a good DID on that circuit? From: <sip:4067890000@rcp.local:5060;user=phone>;tag=1529366861 instead of the .. I think expected from header of From: "Carl Johnson" <sip:40612345678@192.168.40.218;user=phone>;tag=574149672

That is why the product is so great, it is all about the customer and our needs! Debian 4.0 x86

This seems to be the same issue as indicated in: http://forum.pbxnsip.com/index.php?showtopic=1254 PBXNSIP, any ETA?

Can this be put in the next incremental release, maybe 3.0.2 then as this completly breaks our ability to use forwarding, etc starting a few versions ago and we would really appreciate the change. Thanks!

That is definetly and interesting spin .. so is this something that we are just stuck with as it seems incorrect if I specifiy a ANI it should just use that and not try to outsmart the input .. right?

That would affect the ability to properly PNP, wouldn't it?

Ok, I guess that doesn't seem the expected result. So just remove that CC and it should work as expected then?

Any ideas?

3.0.0.2998 (Linux)

I am trying to set a codec preference on an extension and when the submit is hit the preference disappears? BUG? IE: 0 8 9

If I set an ANI in v3, the PBX transforms the given ANI and add the Country code .. this is fully unexpected? What is wrong? Set ANI to: 4061234567 Trunk sends: 14061234567 From: "Carl Johnson" <sip:14061234567@192.168.40.218;user=phone>;tag=2047478008

Here is the story .. The phone registers and shows its inside IP behind NAT, but the SIP packets are addressing it properly via the real-world address .. when sending RTP to the phone it will send it to the inside IP that is behind NAT which is obviously unroutable .. any ideas .. would a packet trace help?

v2.2.2

We all know about NAT and its unfreindly nature concerning VOIP .. that said I am having a bit of an odd issue that just does not make sense as the SBC should resolve this, I think? Polycom (not the greatest for external applications) .. will establish the SIP session and register as well as initiate a call but the audio (RTP) coming back from the PBX is always addressed to the wrong IP? Any thoughts on this does not seem to be an issue with a softphone and other hardphones in the same external network .. just the Polycom?