Call forward fails to external number

[Jeff Pyle]

Hello,

What must one do in 4.6 to allow a local user to forward a call to an
external number?

Here is what I have now: User A can dial a 10-digit outside number and it
routes out the gateway correctly. User A can include the outside number in
his call forwarding configuration, and if User B calls User A, the call
forward works correctly. But if User A receives a call from the outside,
the outside caller hits User A's voicemail instead of forwarding to the
outside number.

All other inbound and outbound calling through the gateway seems to work
okay.

As far as I can tell all my permissions and dial-plans are configured and
enabled correctly. sipXproxy.log isn't helping much. What might I check
next?



- Jeff

[Tony Graziano]

It will depend entirely upon the itsp or telco provider.

Some itsp's do not actually support "hair pinned" calls.

I ran into an instance recently where the outbound call (forward) was a
local call but we had to use a 10 digit number instead of 7 "only" for the
forward.

A siptrace would be helpful.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hello,
What must one do in 4.6 to allow a local user to forward a call to an
external number?
Here is what I have now: User A can dial a 10-digit outside number and it
routes out the gateway correctly. User A can include the outside number in
his call forwarding configuration, and if User B calls User A, the call
forward works correctly. But if User A receives a call from the outside,
the outside caller hits User A's voicemail instead of forwarding to the
outside number.
All other inbound and outbound calling through the gateway seems to work
okay.
As far as I can tell all my permissions and dial-plans are configured and
enabled correctly. sipXproxy.log isn't helping much. What might I check
next?
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Jeff Pyle]

Hi Tony,

For this testing, no ITSP, just a local PRI gateway. Although we're not
that far yet - sipX never sends the INVITE to gateway for the outbound leg
of the forward, so no SIP trace.

This is day 3 a new install atop Centos 6.3 (not the ISO). Very little
fiddling so far.


- Jeff

Post by Tony Graziano
It will depend entirely upon the itsp or telco provider.
Some itsp's do not actually support "hair pinned" calls.
I ran into an instance recently where the outbound call (forward) was a
local call but we had to use a 10 digit number instead of 7 "only" for the
forward.
A siptrace would be helpful.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hello,
What must one do in 4.6 to allow a local user to forward a call to an
external number?
Here is what I have now: User A can dial a 10-digit outside number and
it routes out the gateway correctly. User A can include the outside number
in his call forwarding configuration, and if User B calls User A, the call
forward works correctly. But if User A receives a call from the outside,
the outside caller hits User A's voicemail instead of forwarding to the
outside number.
All other inbound and outbound calling through the gateway seems to work
okay.
As far as I can tell all my permissions and dial-plans are configured and
enabled correctly. sipXproxy.log isn't helping much. What might I check
next?
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

what kind of gateway/who is the telco?
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hi Tony,
For this testing, no ITSP, just a local PRI gateway. Although we're not
that far yet - sipX never sends the INVITE to gateway for the outbound leg
of the forward, so no SIP trace.
This is day 3 a new install atop Centos 6.3 (not the ISO). Very little
fiddling so far.
- Jeff
On Wed, Sep 19, 2012 at 2:46 AM, Tony Graziano <

Post by Tony Graziano
It will depend entirely upon the itsp or telco provider.
Some itsp's do not actually support "hair pinned" calls.
I ran into an instance recently where the outbound call (forward) was a
local call but we had to use a 10 digit number instead of 7 "only" for the
forward.
A siptrace would be helpful.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hello,
What must one do in 4.6 to allow a local user to forward a call to an
external number?
Here is what I have now: User A can dial a 10-digit outside number and
it routes out the gateway correctly. User A can include the outside number
in his call forwarding configuration, and if User B calls User A, the call
forward works correctly. But if User A receives a call from the outside,
the outside caller hits User A's voicemail instead of forwarding to the
outside number.
All other inbound and outbound calling through the gateway seems to work
okay.
As far as I can tell all my permissions and dial-plans are configured
and enabled correctly. sipXproxy.log isn't helping much. What might I
check next?
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Jeff Pyle]

Adtran TA908e. I manage it. CLEC (network) PRI behind it.

The user's extension is set to ring first for 4 seconds, then forward to a
10-digit PSTN number. The PRI on the gateway will accept 7 or 10-digit
local number and the gateway is set to pass through whatever it receives.
I can dial a 7 or 10-digit local number just fine from a local user,
including the one I'm using to test this forwarding. If I call this local
user from another local user, the forward works correctly. Just not if an
outside user calls in.

Here is the tshark outbound of the entire call flow from the perspective of
that gateway, starting with the inbound call from the PRI sent to sipX.
192.168.53.11 is the gateway; 192.168.54.46 is the sipX system.
2160000000 is not the real DID.

0.000000 192.168.53.11 -> 192.168.54.46 SIP/SDP Request: INVITE
sip:***@sipx46.dtcle.fvd.local:5060, with session description
0.002137 192.168.54.46 -> 192.168.53.11 SIP Status: 100 Trying
0.141508 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.181202 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.205498 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.300094 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
4.154583 192.168.54.46 -> 192.168.53.11 SIP/SDP Status: 200 OK, with
session description
4.171045 192.168.53.11 -> 192.168.54.46 SIP Request: ACK
sip:***@192.168.54.46:15060;transport=udp

-{ caller hears VM system }-

7.896108 192.168.53.11 -> 192.168.54.46 SIP Request: BYE
sip:***@192.168.54.46:15060;transport=udp
7.909495 192.168.54.46 -> 192.168.53.11 SIP Status: 200 OK

There are 4 registered devices on the called user, hence the 4x 180 Ringing
messages.

I would expect to see an INVITE or REFER sent to the gateway at
call-forward time instead of the 200 OK of the VM system. It seems like
something is preventing the system from even trying to send the call.


- Jeff

Post by Tony Graziano
what kind of gateway/who is the telco?
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hi Tony,
For this testing, no ITSP, just a local PRI gateway. Although we're not
that far yet - sipX never sends the INVITE to gateway for the outbound leg
of the forward, so no SIP trace.
This is day 3 a new install atop Centos 6.3 (not the ISO). Very little
fiddling so far.
- Jeff
On Wed, Sep 19, 2012 at 2:46 AM, Tony Graziano <

Post by Tony Graziano
It will depend entirely upon the itsp or telco provider.
Some itsp's do not actually support "hair pinned" calls.
I ran into an instance recently where the outbound call (forward) was a
local call but we had to use a 10 digit number instead of 7 "only" for the
forward.
A siptrace would be helpful.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hello,
What must one do in 4.6 to allow a local user to forward a call to an
external number?
Here is what I have now: User A can dial a 10-digit outside number and
it routes out the gateway correctly. User A can include the outside number
in his call forwarding configuration, and if User B calls User A, the call
forward works correctly. But if User A receives a call from the outside,
the outside caller hits User A's voicemail instead of forwarding to the
outside number.
All other inbound and outbound calling through the gateway seems to
work okay.
As far as I can tell all my permissions and dial-plans are configured
and enabled correctly. sipXproxy.log isn't helping much. What might I
check next?
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Todd Hodgen]

Have you tried removing all the phones but one on that called user to ensure
its not a bad behaving endpoint?



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Jeff Pyle
Sent: Wednesday, September 19, 2012 7:16 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Call forward fails to external number



Adtran TA908e. I manage it. CLEC (network) PRI behind it.



The user's extension is set to ring first for 4 seconds, then forward to a
10-digit PSTN number. The PRI on the gateway will accept 7 or 10-digit
local number and the gateway is set to pass through whatever it receives. I
can dial a 7 or 10-digit local number just fine from a local user, including
the one I'm using to test this forwarding. If I call this local user from
another local user, the forward works correctly. Just not if an outside
user calls in.



Here is the tshark outbound of the entire call flow from the perspective of
that gateway, starting with the inbound call from the PRI sent to sipX.
192.168.53.11 is the gateway; 192.168.54.46 is the sipX system. 2160000000
is not the real DID.



0.000000 192.168.53.11 -> 192.168.54.46 SIP/SDP Request: INVITE
sip:***@sipx46.dtcle.fvd.local:5060, with session description

0.002137 192.168.54.46 -> 192.168.53.11 SIP Status: 100 Trying

0.141508 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing

0.181202 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing

0.205498 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing

0.300094 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing

4.154583 192.168.54.46 -> 192.168.53.11 SIP/SDP Status: 200 OK, with
session description

4.171045 192.168.53.11 -> 192.168.54.46 SIP Request: ACK
sip:***@192.168.54.46:15060;transport=udp



-{ caller hears VM system }-



7.896108 192.168.53.11 -> 192.168.54.46 SIP Request: BYE
sip:***@192.168.54.46:15060;transport=udp

7.909495 192.168.54.46 -> 192.168.53.11 SIP Status: 200 OK



There are 4 registered devices on the called user, hence the 4x 180 Ringing
messages.



I would expect to see an INVITE or REFER sent to the gateway at call-forward
time instead of the 200 OK of the VM system. It seems like something is
preventing the system from even trying to send the call.





- Jeff





On Wed, Sep 19, 2012 at 9:56 AM, Tony Graziano
<***@myitdepartment.net> wrote:

what kind of gateway/who is the telco?
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

On Sep 19, 2012 9:50 AM, "Jeff Pyle" <***@fidelityvoice.com> wrote:

Hi Tony,



For this testing, no ITSP, just a local PRI gateway. Although we're not
that far yet - sipX never sends the INVITE to gateway for the outbound leg
of the forward, so no SIP trace.



This is day 3 a new install atop Centos 6.3 (not the ISO). Very little
fiddling so far.





- Jeff







On Wed, Sep 19, 2012 at 2:46 AM, Tony Graziano
<***@myitdepartment.net> wrote:

It will depend entirely upon the itsp or telco provider.

Some itsp's do not actually support "hair pinned" calls.

I ran into an instance recently where the outbound call (forward) was a
local call but we had to use a 10 digit number instead of 7 "only" for the
forward.

A siptrace would be helpful.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

On Sep 18, 2012 10:24 PM, "Jeff Pyle" <***@fidelityvoice.com> wrote:

Hello,



What must one do in 4.6 to allow a local user to forward a call to an
external number?



Here is what I have now: User A can dial a 10-digit outside number and it
routes out the gateway correctly. User A can include the outside number in
his call forwarding configuration, and if User B calls User A, the call
forward works correctly. But if User A receives a call from the outside,
the outside caller hits User A's voicemail instead of forwarding to the
outside number.



All other inbound and outbound calling through the gateway seems to work
okay.



As far as I can tell all my permissions and dial-plans are configured and
enabled correctly. sipXproxy.log isn't helping much. What might I check
next?







- Jeff



_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: [phone]

sip: ***@voice.myitdepartment.net



Helpdesk Customers: http://myhelp.myitdepartment.net

Blog: http://blog.myitdepartment.net


_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/



_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: [phone]

sip: ***@voice.myitdepartment.net



Helpdesk Customers: http://myhelp.myitdepartment.net

Blog: http://blog.myitdepartment.net

[Jeff Pyle]

Scenario is now one Polycom 550 registered to sipX, receiving a call from
the outside. No change in the gateway-to-sipX messaging (call still
answered by VM instead of forwarded). Gateway is .53.11, sipX is .45.46.

0.000000 192.168.53.11 -> 192.168.54.46 SIP/SDP Request: INVITE
sip:***@sipx46.dtcle.fvd.local:5060, with session description
0.001530 192.168.54.46 -> 192.168.53.11 SIP Status: 100 Trying
0.269556 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
4.136557 192.168.54.46 -> 192.168.53.11 SIP/SDP Status: 200 OK, with
session description
4.152206 192.168.53.11 -> 192.168.54.46 SIP Request: ACK
sip:***@192.168.54.46:15060;transport=udp
6.856499 192.168.53.11 -> 192.168.54.46 SIP Request: BYE
sip:***@192.168.54.46:15060;transport=udp
6.864558 192.168.54.46 -> 192.168.53.11 SIP Status: 200 OK

The sipX-to-Poly messaging, Poly is .201.60. TCP ACKs removed for clarity.

0.000021 192.168.54.46 -> 172.21.201.60 SIP/SDP Request: INVITE
sip:***@172.21.201.60;x-sipX-nonat, with session description
0.064324 172.21.201.60 -> 192.168.54.46 SIP Status: 100 Trying
0.230543 172.21.201.60 -> 192.168.54.46 SIP Status: 180 Ringing
3.993589 192.168.54.46 -> 172.21.201.60 SIP Request: CANCEL
sip:***@172.21.201.60;x-sipX-nonat
4.045358 172.21.201.60 -> 192.168.54.46 SIP Status: 200 OK
4.079853 172.21.201.60 -> 192.168.54.46 SIP Status: 487 Request Cancelled
4.080990 192.168.54.46 -> 172.21.201.60 SIP Request: ACK
sip:***@172.21.201.60;x-sipX-nonat

I'm new to sipX, but not to SIP. All this messaging looks appropriate to
me.

The only call forward scenario that doesn't work for me is when an external
caller hits a user set to forward to an external number - the call goes to
the user's VM instead. Every other internal/external caller/callee
combination works as expected.


- Jeff

Post by Todd Hodgen
Have you tried removing all the phones but one on that called user to
ensure its not a bad behaving endpoint?****
** **
*Sent:* Wednesday, September 19, 2012 7:16 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Call forward fails to external number****
** **
Adtran TA908e. I manage it. CLEC (network) PRI behind it.****
** **
The user's extension is set to ring first for 4 seconds, then forward to a
10-digit PSTN number. The PRI on the gateway will accept 7 or 10-digit
local number and the gateway is set to pass through whatever it receives.
I can dial a 7 or 10-digit local number just fine from a local user,
including the one I'm using to test this forwarding. If I call this local
user from another local user, the forward works correctly. Just not if an
outside user calls in.****
** **
Here is the tshark outbound of the entire call flow from the perspective
of that gateway, starting with the inbound call from the PRI sent to sipX.
192.168.53.11 is the gateway; 192.168.54.46 is the sipX system.
2160000000 is not the real DID.****
** **
0.000000 192.168.53.11 -> 192.168.54.46 SIP/SDP Request: INVITE
0.002137 192.168.54.46 -> 192.168.53.11 SIP Status: 100 Trying****
0.141508 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing****
0.181202 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing****
0.205498 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing****
0.300094 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing****
4.154583 192.168.54.46 -> 192.168.53.11 SIP/SDP Status: 200 OK, with
session description****
4.171045 192.168.53.11 -> 192.168.54.46 SIP Request: ACK
** **
-{ caller hears VM system }-****
** **
7.896108 192.168.53.11 -> 192.168.54.46 SIP Request: BYE
7.909495 192.168.54.46 -> 192.168.53.11 SIP Status: 200 OK****
** **
There are 4 registered devices on the called user, hence the 4x 180
Ringing messages.****
** **
I would expect to see an INVITE or REFER sent to the gateway at
call-forward time instead of the 200 OK of the VM system. It seems like
something is preventing the system from even trying to send the call.****
** **
** **
- Jeff****
** **
** **
On Wed, Sep 19, 2012 at 9:56 AM, Tony Graziano <
what kind of gateway/who is the telco?****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~****
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!****
Hi Tony,****
** **
For this testing, no ITSP, just a local PRI gateway. Although we're not
that far yet - sipX never sends the INVITE to gateway for the outbound leg
of the forward, so no SIP trace.****
** **
This is day 3 a new install atop Centos 6.3 (not the ISO). Very little
fiddling so far.****
** **
** **
- Jeff****
** **
** **
** **
On Wed, Sep 19, 2012 at 2:46 AM, Tony Graziano <
It will depend entirely upon the itsp or telco provider.****
Some itsp's do not actually support "hair pinned" calls.****
I ran into an instance recently where the outbound call (forward) was a
local call but we had to use a 10 digit number instead of 7 "only" for the
forward.****
A siptrace would be helpful.****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~****
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!****
Hello, ****
** **
What must one do in 4.6 to allow a local user to forward a call to an
external number?****
** **
Here is what I have now: User A can dial a 10-digit outside number and it
routes out the gateway correctly. User A can include the outside number in
his call forwarding configuration, and if User B calls User A, the call
forward works correctly. But if User A receives a call from the outside,
the outside caller hits User A's voicemail instead of forwarding to the
outside number.****
** **
All other inbound and outbound calling through the gateway seems to work
okay.****
** **
As far as I can tell all my permissions and dial-plans are configured and
enabled correctly. sipXproxy.log isn't helping much. What might I check
next?****
** **
** **
** **
- Jeff****
** **
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: [phone]****
** **
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: [phone]****
** **
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

It is more likely a provider issue. I have seen this also but in my case
the provided wanted 10 digits instead of 7 even though 7 was valid.

I'd call the telco and troubleshoot with them. They are getting the digits
but they need to tell you what is wrong with the digits. really. Call the
telco.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Adtran TA908e. I manage it. CLEC (network) PRI behind it.
The user's extension is set to ring first for 4 seconds, then forward to a
10-digit PSTN number. The PRI on the gateway will accept 7 or 10-digit
local number and the gateway is set to pass through whatever it receives.
I can dial a 7 or 10-digit local number just fine from a local user,
including the one I'm using to test this forwarding. If I call this local
user from another local user, the forward works correctly. Just not if an
outside user calls in.
Here is the tshark outbound of the entire call flow from the perspective
of that gateway, starting with the inbound call from the PRI sent to sipX.
192.168.53.11 is the gateway; 192.168.54.46 is the sipX system.
2160000000 is not the real DID.
0.000000 192.168.53.11 -> 192.168.54.46 SIP/SDP Request: INVITE
0.002137 192.168.54.46 -> 192.168.53.11 SIP Status: 100 Trying
0.141508 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.181202 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.205498 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.300094 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
4.154583 192.168.54.46 -> 192.168.53.11 SIP/SDP Status: 200 OK, with
session description
4.171045 192.168.53.11 -> 192.168.54.46 SIP Request: ACK
-{ caller hears VM system }-
7.896108 192.168.53.11 -> 192.168.54.46 SIP Request: BYE
7.909495 192.168.54.46 -> 192.168.53.11 SIP Status: 200 OK
There are 4 registered devices on the called user, hence the 4x 180
Ringing messages.
I would expect to see an INVITE or REFER sent to the gateway at
call-forward time instead of the 200 OK of the VM system. It seems like
something is preventing the system from even trying to send the call.
- Jeff
On Wed, Sep 19, 2012 at 9:56 AM, Tony Graziano <

Post by Tony Graziano
what kind of gateway/who is the telco?
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hi Tony,
For this testing, no ITSP, just a local PRI gateway. Although we're not
that far yet - sipX never sends the INVITE to gateway for the outbound leg
of the forward, so no SIP trace.
This is day 3 a new install atop Centos 6.3 (not the ISO). Very little
fiddling so far.
- Jeff
On Wed, Sep 19, 2012 at 2:46 AM, Tony Graziano <

Post by Tony Graziano
It will depend entirely upon the itsp or telco provider.
Some itsp's do not actually support "hair pinned" calls.
I ran into an instance recently where the outbound call (forward) was a
local call but we had to use a 10 digit number instead of 7 "only" for the
forward.
A siptrace would be helpful.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about
sipX-CoLab 2013!

Post by Jeff Pyle
Hello,
What must one do in 4.6 to allow a local user to forward a call to an
external number?
Here is what I have now: User A can dial a 10-digit outside number
and it routes out the gateway correctly. User A can include the outside
number in his call forwarding configuration, and if User B calls User A,
the call forward works correctly. But if User A receives a call from the
outside, the outside caller hits User A's voicemail instead of forwarding
to the outside number.
All other inbound and outbound calling through the gateway seems to
work okay.
As far as I can tell all my permissions and dial-plans are configured
and enabled correctly. sipXproxy.log isn't helping much. What might I
check next?
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Jeff Pyle]

Hi Tony,

In the case of an internal caller, all is well. The called-user's call
forward definitions work as one would expect. SipX sends the 7 or 10 digit
INVITE to the gateway when it should, and the telco handles the call. I
happen to be using 10 at the moment.

In the case of an external caller, sipX does not send the INVITE to the
gateway. Instead, that step in the call forward seems to be skipped and
the call goes to the user's VM. That's not telco's fault.

SipX does not send the INVITE for the outbound leg of the call forward to
the gateway if the caller is external. Any thoughts on what might cause
that behavior within sipX? The Forwarding and Transferring Wiki
page<http://wiki.sipfoundry.org/display/sipXecs/Forwarding+and+Transferring>
mentions,
"If you can call [an external] number from your SIP phone, you should be
able to forward or transfer to it ... enter the forwarding number in
exactly the same way in the forwarding target box." I can indeed call the
number (with 7 or 10 digits) but the forward doesn't seem to be working.
No on-phone forwarding is used (signaling verified in a previous post).
Something else seems to be going on.

The How to configure User Call Forwarding
page<http://wiki.sipfoundry.org/display/sipXecs/How+to+configure+User+Call+Forwarding>mentions
a user and group permission named "Forward Calls External" that
needs to be enabled. But this seems to be old info, as XX-422 (redirected
from XECS-200) removed this requirement in 2007 (ver 3.10.0).

So by all indications this should just work. But it doesn't. Hmm. Time
to find a bigger hammer.


- Jeff

Post by Tony Graziano
It is more likely a provider issue. I have seen this also but in my case
the provided wanted 10 digits instead of 7 even though 7 was valid.
I'd call the telco and troubleshoot with them. They are getting the digits
but they need to tell you what is wrong with the digits. really. Call the
telco.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Adtran TA908e. I manage it. CLEC (network) PRI behind it.
The user's extension is set to ring first for 4 seconds, then forward to
a 10-digit PSTN number. The PRI on the gateway will accept 7 or 10-digit
local number and the gateway is set to pass through whatever it receives.
I can dial a 7 or 10-digit local number just fine from a local user,
including the one I'm using to test this forwarding. If I call this local
user from another local user, the forward works correctly. Just not if an
outside user calls in.
Here is the tshark outbound of the entire call flow from the perspective
of that gateway, starting with the inbound call from the PRI sent to sipX.
192.168.53.11 is the gateway; 192.168.54.46 is the sipX system.
2160000000 is not the real DID.
0.000000 192.168.53.11 -> 192.168.54.46 SIP/SDP Request: INVITE
0.002137 192.168.54.46 -> 192.168.53.11 SIP Status: 100 Trying
0.141508 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.181202 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.205498 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
0.300094 192.168.54.46 -> 192.168.53.11 SIP Status: 180 Ringing
4.154583 192.168.54.46 -> 192.168.53.11 SIP/SDP Status: 200 OK, with
session description
4.171045 192.168.53.11 -> 192.168.54.46 SIP Request: ACK
-{ caller hears VM system }-
7.896108 192.168.53.11 -> 192.168.54.46 SIP Request: BYE
7.909495 192.168.54.46 -> 192.168.53.11 SIP Status: 200 OK
There are 4 registered devices on the called user, hence the 4x 180
Ringing messages.
I would expect to see an INVITE or REFER sent to the gateway at
call-forward time instead of the 200 OK of the VM system. It seems like
something is preventing the system from even trying to send the call.
- Jeff
On Wed, Sep 19, 2012 at 9:56 AM, Tony Graziano <

Post by Tony Graziano
what kind of gateway/who is the telco?
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by Jeff Pyle
Hi Tony,
For this testing, no ITSP, just a local PRI gateway. Although we're
not that far yet - sipX never sends the INVITE to gateway for the outbound
leg of the forward, so no SIP trace.
This is day 3 a new install atop Centos 6.3 (not the ISO). Very little
fiddling so far.
- Jeff
On Wed, Sep 19, 2012 at 2:46 AM, Tony Graziano <

Post by Tony Graziano
It will depend entirely upon the itsp or telco provider.
Some itsp's do not actually support "hair pinned" calls.
I ran into an instance recently where the outbound call (forward) was
a local call but we had to use a 10 digit number instead of 7 "only" for
the forward.
A siptrace would be helpful.
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about
sipX-CoLab 2013!

Post by Jeff Pyle
Hello,
What must one do in 4.6 to allow a local user to forward a call to an
external number?
Here is what I have now: User A can dial a 10-digit outside number
and it routes out the gateway correctly. User A can include the outside
number in his call forwarding configuration, and if User B calls User A,
the call forward works correctly. But if User A receives a call from the
outside, the outside caller hits User A's voicemail instead of forwarding
to the outside number.
All other inbound and outbound calling through the gateway seems to
work okay.
As far as I can tell all my permissions and dial-plans are configured
and enabled correctly. sipXproxy.log isn't helping much. What might I
check next?
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Mark A. Smith]

Hi Jeff,
Just to ensure I understand the scenario:
• Calling party originates via PRI
• Calling party is routed to called party.
• Called party is unavailable, rule is set to forward to
10 digit destination number via PRI
• Calling party actually arrives at Free Switch VM box for
called party.
• The ISDN-PRI gateway is an ADTRAN 908e
First, could you please share what version of AOS your TA is
running?
Second, how many PRIs are actually terminating on the 908e?

Best,
Mark

[Jeff Pyle]

Hi Mark,

Your understand is spot on. A4.11. One PRI to a Lucent 5ESS CO. It's a
lab setup so there is next to no traffic. Not that it's related to this
case but the 908e does handle REFERs correctly from sipX when necessary.
That got crossed off the list yesterday.

Back to the sipX box. Capturing traffic on localhost 5060 I found the
INVITE that represented the outbound leg of the call. It gets shot down
with a "403 Requires" by "Server: sipXecs/4.6.0 sipXecs/sipXproxy (Linux)",
never making it to the gateway.


- Jeff

Post by Mark A. Smith
Hi Jeff,
• Calling party originates via PRI
• Calling party is routed to called party.
• Called party is unavailable, rule is set to forward to
10 digit destination number via PRI
• Calling party actually arrives at Free Switch VM box for
called party.
• The ISDN-PRI gateway is an ADTRAN 908e
First, could you please share what version of AOS your TA is
running?
Second, how many PRIs are actually terminating on the 908e?
Best,
Mark
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Mark A. Smith]

Hi Jeff,
Thanks for the reply.
My knee jerk reaction when I first saw your post is that you
may have had multiple PRIs across multiple TDM groups. I'm
glad you've dug into this a bit.
By default, inter B-channel transfer (hair pinning) is not
allowed via AOS switchboard. However, I was running on a
number of assumptions.
Best,
Mark

[George Niculae]

Post by Mark A. Smith
Hi Jeff,
Thanks for the reply.
My knee jerk reaction when I first saw your post is that you
may have had multiple PRIs across multiple TDM groups. I'm
glad you've dug into this a bit.
By default, inter B-channel transfer (hair pinning) is not
allowed via AOS switchboard. However, I was running on a
number of assumptions.
Best,
Mark

Looks like time to recreate it with proxy and registrar on debug and
take log snapshot (Diagnostics > Snapshot)

George

[Jeff Pyle]

Mark, thanks anyway. I appreciate the replies. We haven't gotten far
enough to try TBCT yet! I like you're thinking, though.

George, I think I'm onto something. I've recreated this scenario with two
local users, 1821 and 4821. 1821 is set to forward to 2169311212 after 4
seconds. 4821 calls 1821. 1821 doesn't answer, and the call forwards as
expected.

But, if I remove 4821's "Local Dialing" privilege, 1821 is no longer able
to forward 4821 to the PSTN. Straight to voicemail - just like my external
testing.

It appears sipXproxy is using the privileges of the original caller rather
than those of the one doing the forwarding. There is some discussion about
this in XX-422.

I'm new enough to sipX this is the first time I've attempted a snapshot.
Seems simple enough. Is it just as simple to tail the last 1000 lines of
sipXproxy.log and sipregistrar.log? Regardless of the approach, do I reply
with them as an attachment, or is there another preference?


- Jeff

Post by George Niculae

Post by Mark A. Smith
Hi Jeff,
Thanks for the reply.
My knee jerk reaction when I first saw your post is that you
may have had multiple PRIs across multiple TDM groups. I'm
glad you've dug into this a bit.
By default, inter B-channel transfer (hair pinning) is not
allowed via AOS switchboard. However, I was running on a
number of assumptions.
Best,
Mark

Looks like time to recreate it with proxy and registrar on debug and
take log snapshot (Diagnostics > Snapshot)
George

[George Niculae]

Post by Jeff Pyle
Mark, thanks anyway. I appreciate the replies. We haven't gotten far
enough to try TBCT yet! I like you're thinking, though.
George, I think I'm onto something. I've recreated this scenario with two
local users, 1821 and 4821. 1821 is set to forward to 2169311212 after 4
seconds. 4821 calls 1821. 1821 doesn't answer, and the call forwards as
expected.
But, if I remove 4821's "Local Dialing" privilege, 1821 is no longer able to
forward 4821 to the PSTN. Straight to voicemail - just like my external
testing.
It appears sipXproxy is using the privileges of the original caller rather
than those of the one doing the forwarding. There is some discussion about
this in XX-422.
I'm new enough to sipX this is the first time I've attempted a snapshot.
Seems simple enough. Is it just as simple to tail the last 1000 lines of
sipXproxy.log and sipregistrar.log? Regardless of the approach, do I reply
with them as an attachment, or is there another preference?

It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.

George

[Jeff Pyle]

Post by George Niculae
It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.

The proxy and registrar logs are attached.

User 1821 is set to ring for 4 seconds, then forward to 2169311212. User
1821 can call 2169311212 with no problem (has Local permission).

In this test, User 4821 called user 1821, but since User 4821 does not have
the Local permission, the call went to 1821's VM box instead of to
2169311212. If I re-enable Local permission for 4821, the call forward on
1821 succeeds.


- Jeff

[Joegen Baclor]

This is a long standing issue and is all about 302 redirects not able to
grant permissions of the called number to the caller. On top of this,
branches will also be enforced if you have set one. The caller will not
inherent the branch where the callee is located.

Post by George Niculae
It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.
The proxy and registrar logs are attached.
User 1821 is set to ring for 4 seconds, then forward to 2169311212.
User 1821 can call 2169311212 with no problem (has Local permission).
In this test, User 4821 called user 1821, but since User 4821 does not
have the Local permission, the call went to 1821's VM box instead of
to 2169311212. If I re-enable Local permission for 4821, the call
forward on 1821 succeeds.
- Jeff
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Jeff Pyle]

Is there a workaround to allow a user to forward externally sourced calls
to external numbers? Perhaps by disabling a permission requirement somehow?


- Jeff

Post by Joegen Baclor
This is a long standing issue and is all about 302 redirects not able to
grant permissions of the called number to the caller. On top of this,
branches will also be enforced if you have set one. The caller will not
inherent the branch where the callee is located.

Post by George Niculae
It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.

The proxy and registrar logs are attached.
User 1821 is set to ring for 4 seconds, then forward to 2169311212.
User 1821 can call 2169311212 with no problem (has Local permission).
In this test, User 4821 called user 1821, but since User 4821 does not
have the Local permission, the call went to 1821's VM box instead of to
2169311212. If I re-enable Local permission for 4821, the call forward on
1821 succeeds.
- Jeff
_______________________________________________
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Todd Hodgen]

That feature works today, as AFAIK, has worked for years. Incoming calls
to an extension, can have forwarding set to ring at the same time, or at the
end of a timed period. There is no magic to that, the feature just works.



Something in your particular setup is keeping that from working.



Don't want to sound like a broken record, but try using another group of
trunks - for example, order some VOIP.ms trunks, which are very low cost,
and get them working. It will give you a known working scenario to test
from, and give you some call details to do stare and compare with to see
what might be your issue.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Jeff Pyle
Sent: Thursday, September 20, 2012 5:50 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Call forward fails to external number



Is there a workaround to allow a user to forward externally sourced calls to
external numbers? Perhaps by disabling a permission requirement somehow?





- Jeff





On Wed, Sep 19, 2012 at 11:53 PM, Joegen Baclor <***@ezuce.com> wrote:

This is a long standing issue and is all about 302 redirects not able to
grant permissions of the called number to the caller. On top of this,
branches will also be enforced if you have set one. The caller will not
inherent the branch where the callee is located.



On 09/20/2012 10:04 AM, Jeff Pyle wrote:

On Wed, Sep 19, 2012 at 5:56 PM, George Niculae <***@ezuce.com> wrote:



It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.





The proxy and registrar logs are attached.



User 1821 is set to ring for 4 seconds, then forward to 2169311212. User
1821 can call 2169311212 with no problem (has Local permission).



In this test, User 4821 called user 1821, but since User 4821 does not have
the Local permission, the call went to 1821's VM box instead of to
2169311212. If I re-enable Local permission for 4821, the call forward on
1821 succeeds.





- Jeff

[Michael Picher]

Well, those adtrans are known to have some SIP issues in working with our
platform...

Josh can speak up but we've tested them every so often and from what I know
from about 4 months ago they still hadn't ironed out all of the signalling
issues they have.

Mike

Post by Todd Hodgen
That feature works today, as AFAIK, has worked for years. Incoming calls
to an extension, can have forwarding set to ring at the same time, or at
the end of a timed period. There is no magic to that, the feature just
works.****
** **
Something in your particular setup is keeping that from working. ****
** **
Don’t want to sound like a broken record, but try using another group of
trunks – for example, order some VOIP.ms trunks, which are very low cost,
and get them working. It will give you a known working scenario to test
from, and give you some call details to do stare and compare with to see
what might be your issue.****
** **
*Sent:* Thursday, September 20, 2012 5:50 AM
*To:* Joegen Baclor
*Cc:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Call forward fails to external number****
** **
Is there a workaround to allow a user to forward externally sourced calls
to external numbers? Perhaps by disabling a permission requirement somehow?
****
** **
** **
- Jeff****
** **
** **
****
This is a long standing issue and is all about 302 redirects not able to
grant permissions of the called number to the caller. On top of this,
branches will also be enforced if you have set one. The caller will not
inherent the branch where the callee is located.****
On 09/20/2012 10:04 AM, Jeff Pyle wrote:****
****
** **
It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.****
** **
** **
The proxy and registrar logs are attached.****
** **
User 1821 is set to ring for 4 seconds, then forward to 2169311212. User
1821 can call 2169311212 with no problem (has Local permission).****
** **
In this test, User 4821 called user 1821, but since User 4821 does not
have the Local permission, the call went to 1821's VM box instead of to
2169311212. If I re-enable Local permission for 4821, the call forward
on 1821 succeeds.****
** **
** **
- Jeff****
** **
** **
_______________________________________________****
sipx-users mailing list****
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
** **
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary and
those who don't.

[Jeff Pyle]

Michael,

I have a number of TA900-series Adtrans on my network, and I'm familiar
with most of the ins and outs of their configuration. You're right,
they're not perfect, but I've become quite satisfied with them. I'm
curious what issues you've encountered.

In this particular sipX test scenario, I have a single Adtran gateway
configured in sipX as an "Unmanaged gateway". All the signaling everywhere
in the system is private; no NAT or public traffic exists. This is not a
"SIP Trunking" issue as sipX defines it because I don't have a "SIP Trunk"
defined with sipXbridge.

Regardless, the signaling for the outbound leg of the call doesn't make it
out of sipXproxy towards the Adtran in the failing scenarios. Captures
have shown sipXproxy denies it with a "403 Requires" rejection. Joegen has
said this is because of a long-standing 302 bug where permissions are not
inherited correctly. The provider/gateway is irrelevant because the call
is dropped within sipX before it even tries to contact the
provider/gateway. Even if I were to light up a trunk with voip.ms as Todd
suggests and configure it with sipXbridge, in this scenario sipXproxy would
reject the call before it got to sipXbridge (tested), and certainly before
it got to voip.ms.

Summarizing Joegen's explanation, the call is denied because of a
permissions problem. What if I were to edit the Local dial plan to change
the permission requirement from the default "Local Dialing" to "None"?
That way an unauthenticated user (with no permissions), including an
external gateway, should be able to send a call through the matching dial
plan.

And it worked! I could call the user with the call forward from a user
without the Local permission, and the forward executed correctly. Same
thing from an external call routing in through the PRI. Good stuff.

Clearly there's a security issue leaving it like this. I look forward to
the day when the 302/permissions problem is resolved. Thanks to everyone
for your thoughts and suggestions. And if anyone has other thoughts about
how to work around the 302 problem in a more secure way, I'd love to hear
it.


- Jeff

Post by Michael Picher
Well, those adtrans are known to have some SIP issues in working with our
platform...
Josh can speak up but we've tested them every so often and from what I
know from about 4 months ago they still hadn't ironed out all of the
signalling issues they have.
Mike

Post by Todd Hodgen
That feature works today, as AFAIK, has worked for years. Incoming
calls to an extension, can have forwarding set to ring at the same time, or
at the end of a timed period. There is no magic to that, the feature just
works.****
** **
Something in your particular setup is keeping that from working. ****
** **
Don’t want to sound like a broken record, but try using another group of
trunks – for example, order some VOIP.ms trunks, which are very low cost,
and get them working. It will give you a known working scenario to test
from, and give you some call details to do stare and compare with to see
what might be your issue.****
** **
*Sent:* Thursday, September 20, 2012 5:50 AM
*To:* Joegen Baclor
*Cc:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Call forward fails to external number****
** **
Is there a workaround to allow a user to forward externally sourced calls
to external numbers? Perhaps by disabling a permission requirement somehow?
****
** **
** **
- Jeff****
** **
** **
wrote:****
This is a long standing issue and is all about 302 redirects not able to
grant permissions of the called number to the caller. On top of this,
branches will also be enforced if you have set one. The caller will not
inherent the branch where the callee is located.****
On 09/20/2012 10:04 AM, Jeff Pyle wrote:****
wrote: ****
** **
It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.****
** **
** **
The proxy and registrar logs are attached.****
** **
User 1821 is set to ring for 4 seconds, then forward to 2169311212.
User 1821 can call 2169311212 with no problem (has Local permission).***
*
** **
In this test, User 4821 called user 1821, but since User 4821 does not
have the Local permission, the call went to 1821's VM box instead of to
2169311212. If I re-enable Local permission for 4821, the call forward
on 1821 succeeds.****
** **
** **
- Jeff****
** **
** **
_______________________________________________****
sipx-users mailing list****
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
** **
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Michael Picher, Director of Technical Services
eZuce, Inc.
300 Brickstone Square****
Suite 201****
Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com
------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary and
those who don't.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

Some might argue it "should" work this way too (as in how it works now),
since the first user does not have the security to send the call where the
second user does...

You might be sure to test attended transfers and directed call pickups.
That's where they failed before. They have gotten better since they
finally added REFER support, but you might also want to test park retrieve
and park call return too. Post back on what they choke on if you would be
so kind.

Post by Jeff Pyle
Michael,
I have a number of TA900-series Adtrans on my network, and I'm familiar
with most of the ins and outs of their configuration. You're right,
they're not perfect, but I've become quite satisfied with them. I'm
curious what issues you've encountered.
In this particular sipX test scenario, I have a single Adtran gateway
configured in sipX as an "Unmanaged gateway". All the signaling everywhere
in the system is private; no NAT or public traffic exists. This is not a
"SIP Trunking" issue as sipX defines it because I don't have a "SIP Trunk"
defined with sipXbridge.
Regardless, the signaling for the outbound leg of the call doesn't make it
out of sipXproxy towards the Adtran in the failing scenarios. Captures
have shown sipXproxy denies it with a "403 Requires" rejection. Joegen has
said this is because of a long-standing 302 bug where permissions are not
inherited correctly. The provider/gateway is irrelevant because the call
is dropped within sipX before it even tries to contact the
provider/gateway. Even if I were to light up a trunk with voip.ms as
Todd suggests and configure it with sipXbridge, in this scenario sipXproxy
would reject the call before it got to sipXbridge (tested), and certainly
before it got to voip.ms.
Summarizing Joegen's explanation, the call is denied because of a
permissions problem. What if I were to edit the Local dial plan to change
the permission requirement from the default "Local Dialing" to "None"?
That way an unauthenticated user (with no permissions), including an
external gateway, should be able to send a call through the matching dial
plan.
And it worked! I could call the user with the call forward from a user
without the Local permission, and the forward executed correctly. Same
thing from an external call routing in through the PRI. Good stuff.
Clearly there's a security issue leaving it like this. I look forward to
the day when the 302/permissions problem is resolved. Thanks to everyone
for your thoughts and suggestions. And if anyone has other thoughts about
how to work around the 302 problem in a more secure way, I'd love to hear
it.
- Jeff

Post by Michael Picher
Well, those adtrans are known to have some SIP issues in working with our
platform...
Josh can speak up but we've tested them every so often and from what I
know from about 4 months ago they still hadn't ironed out all of the
signalling issues they have.
Mike

Post by Todd Hodgen
That feature works today, as AFAIK, has worked for years. Incoming
calls to an extension, can have forwarding set to ring at the same time, or
at the end of a timed period. There is no magic to that, the feature just
works.****
** **
Something in your particular setup is keeping that from working. ****
** **
Don’t want to sound like a broken record, but try using another group of
trunks – for example, order some VOIP.ms trunks, which are very low cost,
and get them working. It will give you a known working scenario to test
from, and give you some call details to do stare and compare with to see
what might be your issue.****
** **
*Sent:* Thursday, September 20, 2012 5:50 AM
*To:* Joegen Baclor
*Cc:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Call forward fails to external number****
** **
Is there a workaround to allow a user to forward externally sourced
calls to external numbers? Perhaps by disabling a permission requirement
somehow?****
** **
** **
- Jeff****
** **
** **
wrote:****
This is a long standing issue and is all about 302 redirects not able to
grant permissions of the called number to the caller. On top of this,
branches will also be enforced if you have set one. The caller will not
inherent the branch where the callee is located.****
On 09/20/2012 10:04 AM, Jeff Pyle wrote:****
wrote: ****
** **
It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.****
** **
** **
The proxy and registrar logs are attached.****
** **
User 1821 is set to ring for 4 seconds, then forward to 2169311212.
User 1821 can call 2169311212 with no problem (has Local permission).**
**
** **
In this test, User 4821 called user 1821, but since User 4821 does not
have the Local permission, the call went to 1821's VM box instead of to
2169311212. If I re-enable Local permission for 4821, the call forward
on 1821 succeeds.****
** **
** **
- Jeff****
** **
** **
_______________________________________________****
sipx-users mailing list****
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
** **
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Michael Picher, Director of Technical Services
eZuce, Inc.
300 Brickstone Square****
Suite 201****
Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com
------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary
and those who don't.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

[Jeff Pyle]

Tony,

Yikes, seems like you've had a rough go. Thanks for the tips. I'll test
through those over the coming days and report back.


- Jeff

Post by Tony Graziano
Some might argue it "should" work this way too (as in how it works now),
since the first user does not have the security to send the call where the
second user does...
You might be sure to test attended transfers and directed call pickups.
That's where they failed before. They have gotten better since they
finally added REFER support, but you might also want to test park retrieve
and park call return too. Post back on what they choke on if you would be
so kind.

Post by Jeff Pyle
Michael,
I have a number of TA900-series Adtrans on my network, and I'm familiar
with most of the ins and outs of their configuration. You're right,
they're not perfect, but I've become quite satisfied with them. I'm
curious what issues you've encountered.
In this particular sipX test scenario, I have a single Adtran gateway
configured in sipX as an "Unmanaged gateway". All the signaling everywhere
in the system is private; no NAT or public traffic exists. This is not a
"SIP Trunking" issue as sipX defines it because I don't have a "SIP Trunk"
defined with sipXbridge.
Regardless, the signaling for the outbound leg of the call doesn't make
it out of sipXproxy towards the Adtran in the failing scenarios. Captures
have shown sipXproxy denies it with a "403 Requires" rejection. Joegen has
said this is because of a long-standing 302 bug where permissions are not
inherited correctly. The provider/gateway is irrelevant because the call
is dropped within sipX before it even tries to contact the
provider/gateway. Even if I were to light up a trunk with voip.ms as
Todd suggests and configure it with sipXbridge, in this scenario sipXproxy
would reject the call before it got to sipXbridge (tested), and certainly
before it got to voip.ms.
Summarizing Joegen's explanation, the call is denied because of a
permissions problem. What if I were to edit the Local dial plan to change
the permission requirement from the default "Local Dialing" to "None"?
That way an unauthenticated user (with no permissions), including an
external gateway, should be able to send a call through the matching dial
plan.
And it worked! I could call the user with the call forward from a user
without the Local permission, and the forward executed correctly. Same
thing from an external call routing in through the PRI. Good stuff.
Clearly there's a security issue leaving it like this. I look forward to
the day when the 302/permissions problem is resolved. Thanks to everyone
for your thoughts and suggestions. And if anyone has other thoughts about
how to work around the 302 problem in a more secure way, I'd love to hear
it.
- Jeff

Post by Michael Picher
Well, those adtrans are known to have some SIP issues in working with
our platform...
Josh can speak up but we've tested them every so often and from what I
know from about 4 months ago they still hadn't ironed out all of the
signalling issues they have.
Mike

Post by Todd Hodgen
That feature works today, as AFAIK, has worked for years. Incoming
calls to an extension, can have forwarding set to ring at the same time, or
at the end of a timed period. There is no magic to that, the feature just
works.****
** **
Something in your particular setup is keeping that from working. ****
** **
Don’t want to sound like a broken record, but try using another group
of trunks – for example, order some VOIP.ms trunks, which are very low
cost, and get them working. It will give you a known working scenario to
test from, and give you some call details to do stare and compare with to
see what might be your issue.****
** **
*Sent:* Thursday, September 20, 2012 5:50 AM
*To:* Joegen Baclor
*Cc:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Call forward fails to external number****
** **
Is there a workaround to allow a user to forward externally sourced
calls to external numbers? Perhaps by disabling a permission requirement
somehow?****
** **
** **
- Jeff****
** **
** **
wrote:****
This is a long standing issue and is all about 302 redirects not able
to grant permissions of the called number to the caller. On top of this,
branches will also be enforced if you have set one. The caller will not
inherent the branch where the callee is located.****
On 09/20/2012 10:04 AM, Jeff Pyle wrote:****
wrote: ****
** **
It's not about tailing logs only but it also captures other config
from your system. However in your case tailing proxy and reg logsand
post them back here would suffice.****
** **
** **
The proxy and registrar logs are attached.****
** **
User 1821 is set to ring for 4 seconds, then forward to 2169311212.
User 1821 can call 2169311212 with no problem (has Local permission).*
***
** **
In this test, User 4821 called user 1821, but since User 4821 does not
have the Local permission, the call went to 1821's VM box instead of to
2169311212. If I re-enable Local permission for 4821, the call
forward on 1821 succeeds.****
** **
** **
- Jeff****
** **
** **
_______________________________________________****
sipx-users mailing list****
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
** **
** **
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Michael Picher, Director of Technical Services
eZuce, Inc.
300 Brickstone Square****
Suite 201****
Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com
------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary
and those who don't.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: [phone]
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/