Jump to content

Recommended Posts

Posted

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

Posted
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

 

 

Any ideas?

Posted
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

 

That happens when you select that your domain is in the NANPA region.

  • 3 weeks later...
Posted
That would affect the ability to properly PNP, wouldn't it?

 

Well, only the dialplan part... As VoIP becomes more mainstream and people have cell phones, hitting the "call" button on a SIP phone also becomes more popular these days.

Posted
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?

 

Well, what we need at a certian point is a transformation rule for the trunk. Because different service providers have different ways of presenting a phone number we might need a setting for that. For example, one provider would like to see <sip:+19787562777@...>, the next one <sip:19787562777@...>, and the next one <sip:9787562777@...>, and the next one <sip:0019787562777@...>. Internally we decided to use only the + form, as this is the only global common denominator.

  • 2 weeks later...
Posted

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!

 

Well, what we need at a certian point is a transformation rule for the trunk. Because different service providers have different ways of presenting a phone number we might need a setting for that. For example, one provider would like to see <sip:+19787562777@...>, the next one <sip:19787562777@...>, and the next one <sip:9787562777@...>, and the next one <sip:0019787562777@...>. Internally we decided to use only the + form, as this is the only global common denominator.
  • 4 weeks later...
Posted

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

Posted
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

 

We have introduced a new setting for the trunk that tells the PBX hoe to represent a international telephone number (+ sign in the beginning, 011, 00, and so on). It is still not 100 % stable. Not sure if you want to try that one out.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...