Discussion:
Calls dropping
Geoff Musgrave
2012-09-11 15:17:01 UTC
Permalink
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
Tony Graziano
2012-09-11 15:33:32 UTC
Permalink
Where is the original post?

On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <
Post by Geoff Musgrave
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.
I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.
thanks again.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-11 16:57:33 UTC
Permalink
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Tony Graziano
2012-09-11 17:02:48 UTC
Permalink
Explain who the ITSP is and how you have trunking setup. Typically calls
from providers come to your system on port 5080. I would assume this is
working because the call DOES transfer to the AA (and audio is heard,
correct)? If not it is likely the call is not coming to the system on port
5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA
and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can
elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <
Good question. I’m not sure. I was on the forums looking for an answer
to another question when I added this.****
** **
I added the text below:****
** **
First post so bare with me. I've been searching off and on all day today
with nothing to show for it. So now I'm posting for some help.
For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd
space.
Now down to the problem at hand. Incoming calls hit a dummy "ring user" to
supply the ringing to the caller (per client request) for 7 seconds. I
can't find another way of getting this accomplished - open to suggestions.
From there, the call is transferred to an auto attendant that acknowledges
the caller and gives them some direction. If they don't chose an option
they are then transferred to openACD queue and the call then drops. I
watched in the openACD dashboard and the calls drop at 20 seconds - no
more, no less.
I've also called from an internal extension without any problems at all
and no drops. I have also set up a direct DID to the queue line and called
from an external phone and that too works flawlessly. This leads me away
from a RE-INVITE possible issue from my ITSP.
Please point me in the direction or help me in any way possible. This is
the only hangup I have had with this installation so far.
Thank you in advance.****
** **
*Sent:* Tuesday, September 11, 2012 10:34 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping ****
** **
Where is the original post?****
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.
I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.
thanks again.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
** **
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~****
** **
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
[image: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
** **
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
** **
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-11 17:21:05 UTC
Permalink
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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://www.ezuce.com/image/image_gallery?uuid=61c95dd3-a26d-4363-95b1-131231e1edf0&groupId=284283&t=1340112036507%22+style=%22width:+310px;+height:+310px;]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Tony Graziano
2012-09-11 17:35:27 UTC
Permalink
It is more likely the ACK is not being OK'd by the ITSP. I would try to
simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the
call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being ACK'ed
by the ITSP and they are sending a BYE. A call trace or pcap will also bear
this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <
Post by Geoff Musgrave
Tony, thank you for your response and your questions. I hope I answer
them with enough detail.****
** **
** **
My ITSP is TouchTone and they are signaling on 5080.****
Yes, the call will connect to the AA and will transfer to the queue and
the caller will hear the MOH for a couple seconds and then the call is
dropped so I have no way to confirm that audio is passing both ways because
the drop occurs so quickly..****
** **
When calling directly to the queue the call works properly and audio is
heard both ways, but the caller loses their options presented to them in
the AA.****
** **
Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is behind
a watchguard firewall (to an extent) but in the dmz, no alg in use all
custom rules allowing full access to and from the ITSP and internal
phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in
place and when I run DNS advisor everything but the NAPTR records are
working (windows DNS).****
** **
The dummy ringing is a request by the client. They want their callers to
hear actual “ringing” when they are calling in. I can’t seem to find
another way of making that sound occur rather than tying the DID to an
extension and adding it to a softphone on another computer and forwarding
the calls after X amount of time to the actual AA. When the DID was direct
to the AA there was no “ringing” sound and they didn’t like it. Thus is
life.****
** **
Anything else you need to know? I’m open to suggestions. ****
Thank you!****
** **
*Sent:* Tuesday, September 11, 2012 12:03 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject****
** **
Explain who the ITSP is and how you have trunking setup. Typically calls
from providers come to your system on port 5080. I would assume this is
working because the call DOES transfer to the AA (and audio is heard,
correct)? If not it is likely the call is not coming to the system on port
5080, which means the system is not properly anchoring the call. ****
** **
Explain your trunking and firewall. Explain if the transfer goes to the AA
and audio is heard. ****
** **
Don't understand the use case to provide dummy ringing, so perhaps you can
elaborate.****
** **
On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <
Good question. I’m not sure. I was on the forums looking for an answer to
another question when I added this.****
****
I added the text below:****
****
First post so bare with me. I've been searching off and on all day today
with nothing to show for it. So now I'm posting for some help.
For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd
space.
Now down to the problem at hand. Incoming calls hit a dummy "ring user" to
supply the ringing to the caller (per client request) for 7 seconds. I
can't find another way of getting this accomplished - open to suggestions.
From there, the call is transferred to an auto attendant that acknowledges
the caller and gives them some direction. If they don't chose an option
they are then transferred to openACD queue and the call then drops. I
watched in the openACD dashboard and the calls drop at 20 seconds - no
more, no less.
I've also called from an internal extension without any problems at all
and no drops. I have also set up a direct DID to the queue line and called
from an external phone and that too works flawlessly. This leads me away
from a RE-INVITE possible issue from my ITSP.
Please point me in the direction or help me in any way possible. This is
the only hangup I have had with this installation so far.
Thank you in advance.****
****
*Sent:* Tuesday, September 11, 2012 10:34 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping ****
****
Where is the original post?****
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.
I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.
thanks again.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>****
[image: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
** **
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>****
** **
** **
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
** **
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-11 17:44:42 UTC
Permalink
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Tony Graziano
2012-09-11 17:47:13 UTC
Permalink
Ugh. Go daddy. i only use them for a registrar but cant even stomach their
DNS and moved everything. Good to know I missed that headache yesterday too!

On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <
Post by Geoff Musgrave
Thanks Tony. I was thinking that yesterday when I requested the
troubleshooting with the ITSP but I had other godaddy related fires to put
out yesterday. We will be doing some captures and go from there this
afternoon and I’ll report back. I’ll also try going direct to the AA and
we’ll see how that goes.****
** **
Thanks again.****
** **
*Sent:* Tuesday, September 11, 2012 12:35 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject****
** **
It is more likely the ACK is not being OK'd by the ITSP. I would try to
simplify the call inbound to see if this applies to all calls or not.****
** **
In other words, send the call to the AA (dont ring) and then see if the
call will stay up for longer than 20 seconds.****
** **
Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being ACK'ed
by the ITSP and they are sending a BYE. A call trace or pcap will also bear
this out.****
** **
On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <
Tony, thank you for your response and your questions. I hope I answer them
with enough detail.****
****
****
My ITSP is TouchTone and they are signaling on 5080.****
Yes, the call will connect to the AA and will transfer to the queue and
the caller will hear the MOH for a couple seconds and then the call is
dropped so I have no way to confirm that audio is passing both ways because
the drop occurs so quickly..****
****
When calling directly to the queue the call works properly and audio is
heard both ways, but the caller loses their options presented to them in
the AA.****
****
Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is behind
a watchguard firewall (to an extent) but in the dmz, no alg in use all
custom rules allowing full access to and from the ITSP and internal
phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in
place and when I run DNS advisor everything but the NAPTR records are
working (windows DNS).****
****
The dummy ringing is a request by the client. They want their callers to
hear actual “ringing” when they are calling in. I can’t seem to find
another way of making that sound occur rather than tying the DID to an
extension and adding it to a softphone on another computer and forwarding
the calls after X amount of time to the actual AA. When the DID was direct
to the AA there was no “ringing” sound and they didn’t like it. Thus is
life.****
****
Anything else you need to know? I’m open to suggestions. ****
Thank you!****
****
*Sent:* Tuesday, September 11, 2012 12:03 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject****
****
Explain who the ITSP is and how you have trunking setup. Typically calls
from providers come to your system on port 5080. I would assume this is
working because the call DOES transfer to the AA (and audio is heard,
correct)? If not it is likely the call is not coming to the system on port
5080, which means the system is not properly anchoring the call. ****
****
Explain your trunking and firewall. Explain if the transfer goes to the AA
and audio is heard. ****
****
Don't understand the use case to provide dummy ringing, so perhaps you can
elaborate.****
****
On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <
Good question. I’m not sure. I was on the forums looking for an answer to
another question when I added this.****
****
I added the text below:****
****
First post so bare with me. I've been searching off and on all day today
with nothing to show for it. So now I'm posting for some help.
For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd
space.
Now down to the problem at hand. Incoming calls hit a dummy "ring user" to
supply the ringing to the caller (per client request) for 7 seconds. I
can't find another way of getting this accomplished - open to suggestions.
From there, the call is transferred to an auto attendant that acknowledges
the caller and gives them some direction. If they don't chose an option
they are then transferred to openACD queue and the call then drops. I
watched in the openACD dashboard and the calls drop at 20 seconds - no
more, no less.
I've also called from an internal extension without any problems at all
and no drops. I have also set up a direct DID to the queue line and called
from an external phone and that too works flawlessly. This leads me away
from a RE-INVITE possible issue from my ITSP.
Please point me in the direction or help me in any way possible. This is
the only hangup I have had with this installation so far.
Thank you in advance.****
****
*Sent:* Tuesday, September 11, 2012 10:34 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping ****
****
Where is the original post?****
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.
I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.
thanks again.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>****
[image: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
*Error! Filename not specified.*<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
** **
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[image: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
** **
** **
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
** **
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-11 22:47:52 UTC
Permalink
I eliminated the dummy ring piece and still the same result. I was able to verify that I'm getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it's more because I wasn't available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I'll see what I come up with from here but if you have any further suggestions that I can try I'm open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with - suggestions?) because it was never "answered" so they never saw a 200. Sorry, there wasn't an agent logged in so that's my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back - I don't know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy - I'm not a fan at all. I don't even use them for a registrar anymore (personally) but it's what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Tony Graziano
2012-09-11 23:37:30 UTC
Permalink
"whatever" answers the call, if/when configured properly is going to ACK
it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest
simply having the calls route to the AA (it shows answered this way), then
let it transfer to the hunt group or openacd queue. you probably need to
ask questions about the best way to handle openacd when there is no agent
logged in. It would be important to make sure the reinvite is being honored
by the itsp by testing it with a logged in agent or to an AA and
transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step
thing a year ago, because it kept coming up:
http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <
Post by Geoff Musgrave
I eliminated the dummy ring piece and still the same result. I was able
to verify that I’m getting 2 way audio before the call drops though. My
ITSP is being difficult, but I think it’s more because I wasn’t available
to respond to their response soon enough to further explain the situation
and clear up the obvious confusion they were having. ****
** **
I’ll see what I come up with from here but if you have any further
suggestions that I can try I’m open to them. They were getting 183 when
dialing directly to the queue and telling me that was an abandoned call
(another issue I have to deal with – suggestions?) because it was never
“answered” so they never saw a 200. Sorry, there wasn’t an agent logged in
so that’s my assumption as to the 183 but I would have thought that when
the MOH kicked in on the queue sipXecs would have sent the 200 back – I
don’t know. They determined the call through the AA was ok because they
were transferred and all the SIP messages came back properly. So now I
continue the battle. ****
** **
As for godaddy – I’m not a fan at all. I don’t even use them for a
registrar anymore (personally) but it’s what was in place here. I need to
take the 10 minutes and find a reliable host to move our DNS to or spend
the time to bring it in house. ****
** **
Again, thanks for all your help.****
** **
*Sent:* Tuesday, September 11, 2012 12:47 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject****
** **
Ugh. Go daddy. i only use them for a registrar but cant even stomach their
DNS and moved everything. Good to know I missed that headache yesterday too!
****
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <
Thanks Tony. I was thinking that yesterday when I requested the
troubleshooting with the ITSP but I had other godaddy related fires to put
out yesterday. We will be doing some captures and go from there this
afternoon and I’ll report back. I’ll also try going direct to the AA and
we’ll see how that goes.****
****
Thanks again.****
****
*Sent:* Tuesday, September 11, 2012 12:35 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject****
****
It is more likely the ACK is not being OK'd by the ITSP. I would try to
simplify the call inbound to see if this applies to all calls or not.****
****
In other words, send the call to the AA (dont ring) and then see if the
call will stay up for longer than 20 seconds.****
****
Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being ACK'ed
by the ITSP and they are sending a BYE. A call trace or pcap will also bear
this out.****
****
On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <
Tony, thank you for your response and your questions. I hope I answer them
with enough detail.****
****
****
My ITSP is TouchTone and they are signaling on 5080.****
Yes, the call will connect to the AA and will transfer to the queue and
the caller will hear the MOH for a couple seconds and then the call is
dropped so I have no way to confirm that audio is passing both ways because
the drop occurs so quickly..****
****
When calling directly to the queue the call works properly and audio is
heard both ways, but the caller loses their options presented to them in
the AA.****
****
Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is behind
a watchguard firewall (to an extent) but in the dmz, no alg in use all
custom rules allowing full access to and from the ITSP and internal
phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in
place and when I run DNS advisor everything but the NAPTR records are
working (windows DNS).****
****
The dummy ringing is a request by the client. They want their callers to
hear actual “ringing” when they are calling in. I can’t seem to find
another way of making that sound occur rather than tying the DID to an
extension and adding it to a softphone on another computer and forwarding
the calls after X amount of time to the actual AA. When the DID was direct
to the AA there was no “ringing” sound and they didn’t like it. Thus is
life.****
****
Anything else you need to know? I’m open to suggestions. ****
Thank you!****
****
*Sent:* Tuesday, September 11, 2012 12:03 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject****
****
Explain who the ITSP is and how you have trunking setup. Typically calls
from providers come to your system on port 5080. I would assume this is
working because the call DOES transfer to the AA (and audio is heard,
correct)? If not it is likely the call is not coming to the system on port
5080, which means the system is not properly anchoring the call. ****
****
Explain your trunking and firewall. Explain if the transfer goes to the AA
and audio is heard. ****
****
Don't understand the use case to provide dummy ringing, so perhaps you can
elaborate.****
****
On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <
Good question. I’m not sure. I was on the forums looking for an answer to
another question when I added this.****
****
I added the text below:****
****
First post so bare with me. I've been searching off and on all day today
with nothing to show for it. So now I'm posting for some help.
For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd
space.
Now down to the problem at hand. Incoming calls hit a dummy "ring user" to
supply the ringing to the caller (per client request) for 7 seconds. I
can't find another way of getting this accomplished - open to suggestions.
From there, the call is transferred to an auto attendant that acknowledges
the caller and gives them some direction. If they don't chose an option
they are then transferred to openACD queue and the call then drops. I
watched in the openACD dashboard and the calls drop at 20 seconds - no
more, no less.
I've also called from an internal extension without any problems at all
and no drops. I have also set up a direct DID to the queue line and called
from an external phone and that too works flawlessly. This leads me away
from a RE-INVITE possible issue from my ITSP.
Please point me in the direction or help me in any way possible. This is
the only hangup I have had with this installation so far.
Thank you in advance.****
****
*Sent:* Tuesday, September 11, 2012 10:34 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping ****
****
Where is the original post?****
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.
I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.
thanks again.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>****
[image: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
*Error! Filename not specified.*<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[image: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
** **
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[image: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
** **
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
** **
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-13 16:49:58 UTC
Permalink
My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I'll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) "We're getting the first REINVITE-without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. " Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They've never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I'm getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it's more because I wasn't available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I'll see what I come up with from here but if you have any further suggestions that I can try I'm open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with - suggestions?) because it was never "answered" so they never saw a 200. Sorry, there wasn't an agent logged in so that's my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back - I don't know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy - I'm not a fan at all. I don't even use them for a registrar anymore (personally) but it's what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-14 16:01:02 UTC
Permalink
Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered "slow start", as the SDP is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because we still haven't sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I'll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) "We're getting the first REINVITE-without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. " Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They've never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I'm getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it's more because I wasn't available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I'll see what I come up with from here but if you have any further suggestions that I can try I'm open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with - suggestions?) because it was never "answered" so they never saw a 200. Sorry, there wasn't an agent logged in so that's my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back - I don't know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy - I'm not a fan at all. I don't even use them for a registrar anymore (personally) but it's what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Todd Hodgen
2012-09-14 16:39:21 UTC
Permalink
The invite with no SDP is a valid response, and the RFC does require a
response from the ITSP. As I understand it, it is affectively allowing the
ITSP to offer up what they have.



One ITSP that has issues with an invite without SDP has created what they
refer to a Mitel patch, as Mitel operates this way as well. Ask how they
work with MITEL, and you might find they have a solution in their bag of
tricks already.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



Ok. Still no headway and below is the latest from my provider. Any ideas or
suggestions will be greatly appreciated. Where can I make these adjustments
or what do I need to ask them to do?



When XXXX transfers the call they send us a RE-INVITE as part of the process
(typical of transfers). However, this INVITE contains no SDP, offering no
information as to what parameters of the media stream should be. While
abnormal, this is allowed by SIP RFC for RE-INVITES. These types of
RE-INVITES, or INVITES are considered "slow start", as the SDP is provided
later in the setup instead of up-front.



The problem is that we are handling the RE-INVITE without SDP differently
that one with SDP:

XXXX sends the reinvite without SDP

We send XXXX a 100 trying and send the reinvite on to our carrier without
SDP

Carrier sends us a 100 trying, then a 200 OK.

We send a 200 OK to XXXX

XXXX sends an ACK, but this time with SDP

We do not send that ACK to our carrier right away (symptom of slow start)



XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH
SDP.

We send the invite on to our carrier, also with SDP

They send back a 100 Trying, then an immediate Request Pending, because we
still haven't sent an ACK to them for the previous reinvite

We send that on to XXXX

XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in
rapid manner, all of them get the same Request Pending response.

This cycle continues 3 times until XXXX gives up and ends the call.



Thanks for all your help.





From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



My ITSP has asked if I can turn off REINVITES and possibly increase the
session timers.



They want to disable reinvites strictly for testing purposes. They do
support them and have never asked to disable before and have assured me that
I'll be able to enable them after we test. Is this possible? If so where
would I do that?



The increase in the session timers is because (and I quote) "We're getting
the first REINVITE-without SDP-- less than 30 seconds after the call starts.
After the first reinvite we get one every 60 seconds or so and those have
SDP. " Where would I increase those? Or does any of what they are asking
make any sense.



My ITSP and I are in agreement that the issue is between sipXecs and them
but we have to find where. And I am fairly confident that they will make the
adjustment on their end to make it work if we can find the cause. They've
never done me wrong thus far.



Again, I appreciate you help.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



"whatever" answers the call, if/when configured properly is going to ACK it.
Assuming the ITSP is competent they will see the call as answered.



I simply don't know enough about your environment, but I would suggest
simply having the calls route to the AA (it shows answered this way), then
let it transfer to the hunt group or openacd queue. you probably need to ask
questions about the best way to handle openacd when there is no agent logged
in. It would be important to make sure the reinvite is being honored by the
itsp by testing it with a logged in agent or to an AA and transferred to a
ua that is registered.



you might also double-check the sonicwall config. I wrote a little 3 step
thing a year ago, because it kept coming up:
http://wiki.sipfoundry.org/display/sipXecs/Sonicwall











On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave
<***@cacionline.net> wrote:

I eliminated the dummy ring piece and still the same result. I was able to
verify that I'm getting 2 way audio before the call drops though. My ITSP is
being difficult, but I think it's more because I wasn't available to respond
to their response soon enough to further explain the situation and clear up
the obvious confusion they were having.



I'll see what I come up with from here but if you have any further
suggestions that I can try I'm open to them. They were getting 183 when
dialing directly to the queue and telling me that was an abandoned call
(another issue I have to deal with - suggestions?) because it was never
"answered" so they never saw a 200. Sorry, there wasn't an agent logged in
so that's my assumption as to the 183 but I would have thought that when the
MOH kicked in on the queue sipXecs would have sent the 200 back - I don't
know. They determined the call through the AA was ok because they were
transferred and all the SIP messages came back properly. So now I continue
the battle.



As for godaddy - I'm not a fan at all. I don't even use them for a registrar
anymore (personally) but it's what was in place here. I need to take the 10
minutes and find a reliable host to move our DNS to or spend the time to
bring it in house.



Again, thanks for all your help.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



Ugh. Go daddy. i only use them for a registrar but cant even stomach their
DNS and moved everything. Good to know I missed that headache yesterday too!

On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave
<***@cacionline.net> wrote:

Thanks Tony. I was thinking that yesterday when I requested the
troubleshooting with the ITSP but I had other godaddy related fires to put
out yesterday. We will be doing some captures and go from there this
afternoon and I'll report back. I'll also try going direct to the AA and
we'll see how that goes.



Thanks again.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject



It is more likely the ACK is not being OK'd by the ITSP. I would try to
simplify the call inbound to see if this applies to all calls or not.



In other words, send the call to the AA (dont ring) and then see if the call
will stay up for longer than 20 seconds.



Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being ACK'ed by
the ITSP and they are sending a BYE. A call trace or pcap will also bear
this out.



On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave
<***@cacionline.net> wrote:

Tony, thank you for your response and your questions. I hope I answer them
with enough detail.





My ITSP is TouchTone and they are signaling on 5080.

Yes, the call will connect to the AA and will transfer to the queue and the
caller will hear the MOH for a couple seconds and then the call is dropped
so I have no way to confirm that audio is passing both ways because the drop
occurs so quickly..



When calling directly to the queue the call works properly and audio is
heard both ways, but the caller loses their options presented to them in the
AA.



Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a
watchguard firewall (to an extent) but in the dmz, no alg in use all custom
rules allowing full access to and from the ITSP and internal
phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in
place and when I run DNS advisor everything but the NAPTR records are
working (windows DNS).



The dummy ringing is a request by the client. They want their callers to
hear actual "ringing" when they are calling in. I can't seem to find another
way of making that sound occur rather than tying the DID to an extension and
adding it to a softphone on another computer and forwarding the calls after
X amount of time to the actual AA. When the DID was direct to the AA there
was no "ringing" sound and they didn't like it. Thus is life.



Anything else you need to know? I'm open to suggestions.


Thank you!



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject



Explain who the ITSP is and how you have trunking setup. Typically calls
from providers come to your system on port 5080. I would assume this is
working because the call DOES transfer to the AA (and audio is heard,
correct)? If not it is likely the call is not coming to the system on port
5080, which means the system is not properly anchoring the call.



Explain your trunking and firewall. Explain if the transfer goes to the AA
and audio is heard.



Don't understand the use case to provide dummy ringing, so perhaps you can
elaborate.



On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave
<***@cacionline.net> wrote:

Good question. I'm not sure. I was on the forums looking for an answer to
another question when I added this.



I added the text below:



First post so bare with me. I've been searching off and on all day today
with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd
space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to
supply the ringing to the caller (per client request) for 7 seconds. I can't
find another way of getting this accomplished - open to suggestions. From
there, the call is transferred to an auto attendant that acknowledges the
caller and gives them some direction. If they don't chose an option they are
then transferred to openACD queue and the call then drops. I watched in the
openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and
no drops. I have also set up a direct DID to the queue line and called from
an external phone and that too works flawlessly. This leads me away from a
RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the
only hangup I have had with this installation so far.

Thank you in advance.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Where is the original post?

On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave
<***@cacionline.net> wrote:



I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>


<http://sipxcolab2013.eventbrite.com/?discount=tony2013> Description:
Description: Description: Description: Image removed by sender.



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Description: Description: Image removed by sender.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Description: Image removed by sender.



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Image removed by sender.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

sip: ***@voice.myitdepartment.net



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

Blog: http://blog.myitdepartment.net
Joegen Baclor
2012-09-19 11:55:52 UTC
Permalink
The first reInvite without SDP is the result of a REFER coming from the
AA. You cannot disable this. You can set session timer interval in
/etc/sipxpbx/sipxbridge.xml by setting
"sip-session-timer-interval-seconds" parameter. From what I know, the
default session timer value is 1800 not 60 seconds.
Post by Geoff Musgrave
My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.
They want to disable reinvites strictly for testing purposes. They do
support them and have never asked to disable before and have assured
me that I'll be able to enable them after we test. Is this possible?
If so where would I do that?
The increase in the session timers is because (and I quote) "We're
getting the first REINVITE---without SDP-- less than 30 seconds after
the call starts. After the first reinvite we get one every 60 seconds
or so and those have SDP. " Where would I increase those? Or does any
of what they are asking make any sense.
My ITSP and I are in agreement that the issue is between sipXecs and
them but we have to find where. And I am fairly confident that they
will make the adjustment on their end to make it work if we can find
the cause. They've never done me wrong thus far.
Again, I appreciate you help.
Graziano
*Sent:* Tuesday, September 11, 2012 6:38 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject
"whatever" answers the call, if/when configured properly is going to
ACK it. Assuming the ITSP is competent they will see the call as answered.
I simply don't know enough about your environment, but I would suggest
simply having the calls route to the AA (it shows answered this way),
then let it transfer to the hunt group or openacd queue. you probably
need to ask questions about the best way to handle openacd when there
is no agent logged in. It would be important to make sure the reinvite
is being honored by the itsp by testing it with a logged in agent or
to an AA and transferred to a ua that is registered.
you might also double-check the sonicwall config. I wrote a little 3
http://wiki.sipfoundry.org/display/sipXecs/Sonicwall
On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave
I eliminated the dummy ring piece and still the same result. I was
able to verify that I'm getting 2 way audio before the call drops
though. My ITSP is being difficult, but I think it's more because I
wasn't available to respond to their response soon enough to further
explain the situation and clear up the obvious confusion they were
having.
I'll see what I come up with from here but if you have any further
suggestions that I can try I'm open to them. They were getting 183
when dialing directly to the queue and telling me that was an
abandoned call (another issue I have to deal with -- suggestions?)
because it was never "answered" so they never saw a 200. Sorry, there
wasn't an agent logged in so that's my assumption as to the 183 but I
would have thought that when the MOH kicked in on the queue sipXecs
would have sent the 200 back -- I don't know. They determined the call
through the AA was ok because they were transferred and all the SIP
messages came back properly. So now I continue the battle.
As for godaddy -- I'm not a fan at all. I don't even use them for a
registrar anymore (personally) but it's what was in place here. I need
to take the 10 minutes and find a reliable host to move our DNS to or
spend the time to bring it in house.
Again, thanks for all your help.
Graziano
*Sent:* Tuesday, September 11, 2012 12:47 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject
Ugh. Go daddy. i only use them for a registrar but cant even stomach
their DNS and moved everything. Good to know I missed that headache
yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave
Thanks Tony. I was thinking that yesterday when I requested the
troubleshooting with the ITSP but I had other godaddy related fires to
put out yesterday. We will be doing some captures and go from there
this afternoon and I'll report back. I'll also try going direct to the
AA and we'll see how that goes.
Thanks again.
Graziano
*Sent:* Tuesday, September 11, 2012 12:35 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject
It is more likely the ACK is not being OK'd by the ITSP. I would try
to simplify the call inbound to see if this applies to all calls or not.
In other words, send the call to the AA (dont ring) and then see if
the call will stay up for longer than 20 seconds.
Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being
ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap
will also bear this out.
On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave
Tony, thank you for your response and your questions. I hope I answer
them with enough detail.
My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue
and the caller will hear the MOH for a couple seconds and then the
call is dropped so I have no way to confirm that audio is passing both
ways because the drop occurs so quickly..
When calling directly to the queue the call works properly and audio
is heard both ways, but the caller loses their options presented to
them in the AA.
Trunking is a SIP trunk to IP over 5080 -- nothing fancy. sipXecs is
behind a watchguard firewall (to an extent) but in the dmz, no alg in
use all custom rules allowing full access to and from the ITSP and
internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV
records are in place and when I run DNS advisor everything but the
NAPTR records are working (windows DNS).
The dummy ringing is a request by the client. They want their callers
to hear actual "ringing" when they are calling in. I can't seem to
find another way of making that sound occur rather than tying the DID
to an extension and adding it to a softphone on another computer and
forwarding the calls after X amount of time to the actual AA. When the
DID was direct to the AA there was no "ringing" sound and they didn't
like it. Thus is life.
Anything else you need to know? I'm open to suggestions.
Thank you!
Graziano
*Sent:* Tuesday, September 11, 2012 12:03 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject
Explain who the ITSP is and how you have trunking setup. Typically
calls from providers come to your system on port 5080. I would assume
this is working because the call DOES transfer to the AA (and audio is
heard, correct)? If not it is likely the call is not coming to the
system on port 5080, which means the system is not properly anchoring
the call.
Explain your trunking and firewall. Explain if the transfer goes to
the AA and audio is heard.
Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.
On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave
Good question. I'm not sure. I was on the forums looking for an answer
to another question when I added this.
First post so bare with me. I've been searching off and on all day
today with nothing to show for it. So now I'm posting for some help.
For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12)
via iso. yum update ran earlier. 2x quad processors | 16gb RAM |
plenty of hdd space.
Now down to the problem at hand. Incoming calls hit a dummy "ring
user" to supply the ringing to the caller (per client request) for 7
seconds. I can't find another way of getting this accomplished - open
to suggestions. From there, the call is transferred to an auto
attendant that acknowledges the caller and gives them some direction.
If they don't chose an option they are then transferred to openACD
queue and the call then drops. I watched in the openACD dashboard and
the calls drop at 20 seconds - no more, no less.
I've also called from an internal extension without any problems at
all and no drops. I have also set up a direct DID to the queue line
and called from an external phone and that too works flawlessly. This
leads me away from a RE-INVITE possible issue from my ITSP.
Please point me in the direction or help me in any way possible. This
is the only hangup I have had with this installation so far.
Thank you in advance.
Graziano
*Sent:* Tuesday, September 11, 2012 10:34 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping
Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.
I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.
thanks again.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Description: Description: Description: Image removed by
sender. <http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
*Error! Filename not specified.*
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Description: Description: Description: Image removed by sender.
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
<http://list.sipfoundry.org/archive/sipx-users/>
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Description: Description: Image removed by sender.
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
<http://list.sipfoundry.org/archive/sipx-users/>
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Description: Image removed by sender.
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.net
<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net <http://blog.myitdepartment.net>
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
Geoff Musgrave
2012-09-14 17:51:53 UTC
Permalink
Todd, thanks for the response - I've asked my ITSP about Mitel but have not gotten a response yet; I'll post back when I do.

In the interim and in an effort of just getting this working is there anything you can think of that I can do or try from my side to possibly force sdp in the re-invites or something to get this working?

Any and all help/suggestions/ideas/etc will be appreciated. If you need anything else to help me with this let me know and I'll see what I can do.



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

The invite with no SDP is a valid response, and the RFC does require a response from the ITSP. As I understand it, it is affectively allowing the ITSP to offer up what they have.

One ITSP that has issues with an invite without SDP has created what they refer to a Mitel patch, as Mitel operates this way as well. Ask how they work with MITEL, and you might find they have a solution in their bag of tricks already.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered "slow start", as the SDP is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because we still haven't sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I'll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) "We're getting the first REINVITE-without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. " Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They've never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I'm getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it's more because I wasn't available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I'll see what I come up with from here but if you have any further suggestions that I can try I'm open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with - suggestions?) because it was never "answered" so they never saw a 200. Sorry, there wasn't an agent logged in so that's my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back - I don't know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy - I'm not a fan at all. I don't even use them for a registrar anymore (personally) but it's what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-14 18:08:14 UTC
Permalink
Todd, thanks again. My ITSP was already aware of the "fix" for how Mitel operates and have begun planning a software release to address just this but it has not been put in place yet and may not be for a couple weeks due. So now I must find a way around it myself or with the help of the community until then.

Any ideas on how to include SDP in a re-invite?

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks for the response - I've asked my ITSP about Mitel but have not gotten a response yet; I'll post back when I do.

In the interim and in an effort of just getting this working is there anything you can think of that I can do or try from my side to possibly force sdp in the re-invites or something to get this working?

Any and all help/suggestions/ideas/etc will be appreciated. If you need anything else to help me with this let me know and I'll see what I can do.



From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

The invite with no SDP is a valid response, and the RFC does require a response from the ITSP. As I understand it, it is affectively allowing the ITSP to offer up what they have.

One ITSP that has issues with an invite without SDP has created what they refer to a Mitel patch, as Mitel operates this way as well. Ask how they work with MITEL, and you might find they have a solution in their bag of tricks already.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered "slow start", as the SDP is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because we still haven't sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I'll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) "We're getting the first REINVITE-without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. " Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They've never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I'm getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it's more because I wasn't available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I'll see what I come up with from here but if you have any further suggestions that I can try I'm open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with - suggestions?) because it was never "answered" so they never saw a 200. Sorry, there wasn't an agent logged in so that's my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back - I don't know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy - I'm not a fan at all. I don't even use them for a registrar anymore (personally) but it's what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Matt White
2012-09-14 18:32:18 UTC
Permalink
Just a wild guess, but maybe karoo bridge can force the sdp? I know you
can force it with an ingate.


-M
Todd, thanks again. My ITSP was already aware of the “fix” for
how Mitel operates and have begun planning a software release to address
just this but it has not been put in place yet and may not be for a
couple weeks due. So now I must find a way around it myself or with the
help of the community until then.

Any ideas on how to include SDP in a re-invite?

From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff
Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Todd, thanks for the response - I’ve asked my ITSP about Mitel but have
not gotten a response yet; I’ll post back when I do.

In the interim and in an effort of just getting this working is there
anything you can think of that I can do or try from my side to possibly
force sdp in the re-invites or something to get this working?

Any and all help/suggestions/ideas/etc will be appreciated. If you need
anything else to help me with this let me know and I’ll see what I can
do.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject



The invite with no SDP is a valid response, and the RFC does require a
response from the ITSP. As I understand it, it is affectively allowing
the ITSP to offer up what they have.

One ITSP that has issues with an invite without SDP has created what
they refer to a Mitel patch, as Mitel operates this way as well. Ask
how they work with MITEL, and you might find they have a solution in
their bag of tricks already.

From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff
Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject



Ok. Still no headway and below is the latest from my provider. Any
ideas or suggestions will be greatly appreciated. Where can I make these
adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the
process (typical of transfers). However, this INVITE contains no SDP,
offering no information as to what parameters of the media stream should
be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These
types of RE-INVITES, or INVITES are considered “slow start”, as the SDP
is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP
differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier
without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow
start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time
WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because
we still haven’t sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites
in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff
Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject



My ITSP has asked if I can turn off REINVITES and possibly increase the
session timers.

They want to disable reinvites strictly for testing purposes. They do
support them and have never asked to disable before and have assured me
that I’ll be able to enable them after we test. Is this possible? If so
where would I do that?

The increase in the session timers is because (and I quote) “We’re
getting the first REINVITE—without SDP-- less than 30 seconds after the
call starts. After the first reinvite we get one every 60 seconds or so
and those have SDP. “ Where would I increase those? Or does any of what
they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and
them but we have to find where. And I am fairly confident that they will
make the adjustment on their end to make it work if we can find the
cause. They’ve never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony
Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to
ACK it. Assuming the ITSP is competent they will see the call as
answered.


I simply don't know enough about your environment, but I would suggest
simply having the calls route to the AA (it shows answered this way),
then let it transfer to the hunt group or openacd queue. you probably
need to ask questions about the best way to handle openacd when there
is no agent logged in. It would be important to make sure the reinvite
is being honored by the itsp by testing it with a logged in agent or to
an AA and transferred to a ua that is registered.



you might also double-check the sonicwall config. I wrote a little 3
step thing a year ago, because it kept coming up:
http://wiki.sipfoundry.org/display/sipXecs/Sonicwall










On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave
<***@cacionline.net> wrote:
I eliminated the dummy ring piece and still the same result. I was
able to verify that I’m getting 2 way audio before the call drops
though. My ITSP is being difficult, but I think it’s more because I
wasn’t available to respond to their response soon enough to further
explain the situation and clear up the obvious confusion they were
having.

I’ll see what I come up with from here but if you have any further
suggestions that I can try I’m open to them. They were getting 183 when
dialing directly to the queue and telling me that was an abandoned call
(another issue I have to deal with – suggestions?) because it was never
“answered” so they never saw a 200. Sorry, there wasn’t an agent
logged in so that’s my assumption as to the 183 but I would have
thought that when the MOH kicked in on the queue sipXecs would have sent
the 200 back – I don’t know. They determined the call through the AA was
ok because they were transferred and all the SIP messages came back
properly. So now I continue the battle.

As for godaddy – I’m not a fan at all. I don’t even use them for a
registrar anymore (personally) but it’s what was in place here. I need
to take the 10 minutes and find a reliable host to move our DNS to or
spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony
Graziano
Sent: To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach
their DNS and moved everything. Good to know I missed that headache
yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave
<***@cacionline.net> wrote:
Thanks Tony. I was thinking that yesterday when I requested the
troubleshooting with the ITSP but I had other godaddy related fires to
put out yesterday. We will be doing some captures and go from there this
afternoon and I’ll report back. I’ll also try going direct to the AA and
we’ll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony
Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to
simplify the call inbound to see if this applies to all calls or not.


In other words, send the call to the AA (dont ring) and then see if
the call will stay up for longer than 20 seconds.



Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being
ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap
will also bear this out.


On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave
<***@cacionline.net> wrote:
Tony, thank you for your response and your questions. I hope I answer
them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and
the caller will hear the MOH for a couple seconds and then the call is
dropped so I have no way to confirm that audio is passing both ways
because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is
heard both ways, but the caller loses their options presented to them
in the AA.

Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is
behind a watchguard firewall (to an extent) but in the dmz, no alg in
use all custom rules allowing full access to and from the ITSP and
internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV
records are in place and when I run DNS advisor everything but the NAPTR
records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers
to hear actual “ringing” when they are calling in. I can’t seem to find
another way of making that sound occur rather than tying the DID to an
extension and adding it to a softphone on another computer and
forwarding the calls after X amount of time to the actual AA. When the
DID was direct to the AA there was no “ringing” sound and they didn’t
like it. Thus is life.

Anything else you need to know? I’m open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony
Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically
calls from providers come to your system on port 5080. I would assume
this is working because the call DOES transfer to the AA (and audio is
heard, correct)? If not it is likely the call is not coming to the
system on port 5080, which means the system is not properly anchoring
the call.


Explain your trunking and firewall. Explain if the transfer goes to
the AA and audio is heard.



Don't understand the use case to provide dummy ringing, so perhaps you
can elaborate.


On Tue, Sep 11, 2012 at 12:57 PM, Good question. I’m not sure. I was on the forums looking for an
answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day
today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of
hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user"
to supply the ringing to the caller (per client request) for 7 seconds.
I can't find another way of getting this accomplished - open to
suggestions. From there, the call is transferred to an auto attendant
that acknowledges the caller and gives them some direction. If they
don't chose an option they are then transferred to openACD queue and the
call then drops. I watched in the openACD dashboard and the calls drop
at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all
and no drops. I have also set up a direct DID to the queue line and
called from an external phone and that too works flawlessly. This leads
me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This
is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony
Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave
<***@cacionline.net> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

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






--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!






LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/






--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.




LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

sip: ***@voice.myitdepartment.net



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

Blog: http://blog.myitdepartment.net




_______________________________________________
sipx ~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/






--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/






--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

sip: ***@voice.myitdepartment.net



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

Blog: http://blog.myitdepartment.net
Todd Hodgen
2012-09-14 21:44:48 UTC
Permalink
Since its is not adhering to standards you may want to consider another. Or find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.
Post by Geoff Musgrave
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
Geoff Musgrave
2012-09-14 22:28:43 UTC
Permalink
Todd, thanks again for the reply.
I’ll take a look at Karoo. Would that be in conjunction with sipxbridge or instead of? I’m already reading through what is on the wiki now but anything additional you could direct me to would be appreciated.

I would look for another ITSP but it’s late in the game for me to be finding this out. All of our DIDs/TFs are with them and the client wants to go live Monday. I may have to build up an asterisk server and configure it until the ITSP gets things straightened out to work with sipXecs. We have another project working via freepbx with this ITSP and do not have any issues so I may have to go that route – at least for a brief period until they make the necessary changes on their end.

Thank you

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 4:45 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Since its is not adhering to standards you may want to consider another. Or find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.

Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Todd, thanks again. My ITSP was already aware of the “fix” for how Mitel operates and have begun planning a software release to address just this but it has not been put in place yet and may not be for a couple weeks due. So now I must find a way around it myself or with the help of the community until then.

Any ideas on how to include SDP in a re-invite?

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks for the response - I’ve asked my ITSP about Mitel but have not gotten a response yet; I’ll post back when I do.

In the interim and in an effort of just getting this working is there anything you can think of that I can do or try from my side to possibly force sdp in the re-invites or something to get this working?

Any and all help/suggestions/ideas/etc will be appreciated. If you need anything else to help me with this let me know and I’ll see what I can do.



From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

The invite with no SDP is a valid response, and the RFC does require a response from the ITSP. As I understand it, it is affectively allowing the ITSP to offer up what they have.

One ITSP that has issues with an invite without SDP has created what they refer to a Mitel patch, as Mitel operates this way as well. Ask how they work with MITEL, and you might find they have a solution in their bag of tricks already.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered “slow start”, as the SDP is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because we still haven’t sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I’ll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) “We’re getting the first REINVITE—without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. “ Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They’ve never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I’m getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it’s more because I wasn’t available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I’ll see what I come up with from here but if you have any further suggestions that I can try I’m open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with – suggestions?) because it was never “answered” so they never saw a 200. Sorry, there wasn’t an agent logged in so that’s my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back – I don’t know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy – I’m not a fan at all. I don’t even use them for a registrar anymore (personally) but it’s what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I’ll report back. I’ll also try going direct to the AA and we’ll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual “ringing” when they are calling in. I can’t seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no “ringing” sound and they didn’t like it. Thus is life.

Anything else you need to know? I’m open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I’m not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Todd Hodgen
2012-09-15 03:33:23 UTC
Permalink
Geoff, I’m not an expert on Karoo, or anything else really, but My understanding is you can have Karoo for your Session Border Controller and not need to use sipxbridge. There is a limit to the number of concurrent calls – I believe 20, and then you have to license it. Maybe Joegen will chime in here. Recently it was announced it was going open source, so I don’t know how that affects the pricing on it.



I believe a few people on the list are using it currently, so maybe they will chip in their expertise from implementation of it.



Best of luck with the project.



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 3:29 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Todd, thanks again for the reply.

I’ll take a look at Karoo. Would that be in conjunction with sipxbridge or instead of? I’m already reading through what is on the wiki now but anything additional you could direct me to would be appreciated.

I would look for another ITSP but it’s late in the game for me to be finding this out. All of our DIDs/TFs are with them and the client wants to go live Monday. I may have to build up an asterisk server and configure it until the ITSP gets things straightened out to work with sipXecs. We have another project working via freepbx with this ITSP and do not have any issues so I may have to go that route – at least for a brief period until they make the necessary changes on their end.



Thank you



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 4:45 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Since its is not adhering to standards you may want to consider another. Or find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.

Geoff Musgrave <***@cacionline.net> wrote:

Todd, thanks again. My ITSP was already aware of the “fix” for how Mitel operates and have begun planning a software release to address just this but it has not been put in place yet and may not be for a couple weeks due. So now I must find a way around it myself or with the help of the community until then.



Any ideas on how to include SDP in a re-invite?



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Todd, thanks for the response - I’ve asked my ITSP about Mitel but have not gotten a response yet; I’ll post back when I do.



In the interim and in an effort of just getting this working is there anything you can think of that I can do or try from my side to possibly force sdp in the re-invites or something to get this working?



Any and all help/suggestions/ideas/etc will be appreciated. If you need anything else to help me with this let me know and I’ll see what I can do.







From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject



The invite with no SDP is a valid response, and the RFC does require a response from the ITSP. As I understand it, it is affectively allowing the ITSP to offer up what they have.



One ITSP that has issues with an invite without SDP has created what they refer to a Mitel patch, as Mitel operates this way as well. Ask how they work with MITEL, and you might find they have a solution in their bag of tricks already.



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject



Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?



When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered “slow start”, as the SDP is provided later in the setup instead of up-front.



The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:

XXXX sends the reinvite without SDP

We send XXXX a 100 trying and send the reinvite on to our carrier without SDP

Carrier sends us a 100 trying, then a 200 OK.

We send a 200 OK to XXXX

XXXX sends an ACK, but this time with SDP

We do not send that ACK to our carrier right away (symptom of slow start)



XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.

We send the invite on to our carrier, also with SDP

They send back a 100 Trying, then an immediate Request Pending, because we still haven’t sent an ACK to them for the previous reinvite

We send that on to XXXX

XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.

This cycle continues 3 times until XXXX gives up and ends the call.



Thanks for all your help.





From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject



My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.



They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I’ll be able to enable them after we test. Is this possible? If so where would I do that?



The increase in the session timers is because (and I quote) “We’re getting the first REINVITE—without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. “ Where would I increase those? Or does any of what they are asking make any sense.



My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They’ve never done me wrong thus far.



Again, I appreciate you help.



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject



"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.



I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.



you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall











On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net> wrote:

I eliminated the dummy ring piece and still the same result. I was able to verify that I’m getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it’s more because I wasn’t available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.



I’ll see what I come up with from here but if you have any further suggestions that I can try I’m open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with – suggestions?) because it was never “answered” so they never saw a 200. Sorry, there wasn’t an agent logged in so that’s my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back – I don’t know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.



As for godaddy – I’m not a fan at all. I don’t even use them for a registrar anymore (personally) but it’s what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.



Again, thanks for all your help.



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject



Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!

On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net> wrote:

Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I’ll report back. I’ll also try going direct to the AA and we’ll see how that goes.



Thanks again.



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject



It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.



In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.



Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.



On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net> wrote:

Tony, thank you for your response and your questions. I hope I answer them with enough detail.





My ITSP is TouchTone and they are signaling on 5080.

Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..



When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.



Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).



The dummy ringing is a request by the client. They want their callers to hear actual “ringing” when they are calling in. I can’t seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no “ringing” sound and they didn’t like it. Thus is life.



Anything else you need to know? I’m open to suggestions.


Thank you!



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject



Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.



Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.



Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.



On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net> wrote:

Good question. I’m not sure. I was on the forums looking for an answer to another question when I added this.



I added the text below:



First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.



From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Where is the original post?

On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net> wrote:



I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>


<http://sipxcolab2013.eventbrite.com/?discount=tony2013> Description: Description: Description: Description: Image removed by sender.



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Description: Description: Image removed by sender.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Description: Image removed by sender.



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Image removed by sender.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

sip: ***@voice.myitdepartment.net



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

Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-17 16:49:42 UTC
Permalink
Can someone tell me what I’m overlooking when I’m trying to edit /etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profiles.xml to prevent it from reverting back after I restart everything?

I’m trying everything I can think of to get this going with my ITSP – I simply don’t have the luxury of changing providers at this moment.

Thanks in advance.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 10:33 PM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping

Geoff, I’m not an expert on Karoo, or anything else really, but My understanding is you can have Karoo for your Session Border Controller and not need to use sipxbridge. There is a limit to the number of concurrent calls – I believe 20, and then you have to license it. Maybe Joegen will chime in here. Recently it was announced it was going open source, so I don’t know how that affects the pricing on it.

I believe a few people on the list are using it currently, so maybe they will chip in their expertise from implementation of it.

Best of luck with the project.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 3:29 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks again for the reply.
I’ll take a look at Karoo. Would that be in conjunction with sipxbridge or instead of? I’m already reading through what is on the wiki now but anything additional you could direct me to would be appreciated.

I would look for another ITSP but it’s late in the game for me to be finding this out. All of our DIDs/TFs are with them and the client wants to go live Monday. I may have to build up an asterisk server and configure it until the ITSP gets things straightened out to work with sipXecs. We have another project working via freepbx with this ITSP and do not have any issues so I may have to go that route – at least for a brief period until they make the necessary changes on their end.

Thank you

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 4:45 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Since its is not adhering to standards you may want to consider another. Or find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.

Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Todd, thanks again. My ITSP was already aware of the “fix” for how Mitel operates and have begun planning a software release to address just this but it has not been put in place yet and may not be for a couple weeks due. So now I must find a way around it myself or with the help of the community until then.

Any ideas on how to include SDP in a re-invite?

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks for the response - I’ve asked my ITSP about Mitel but have not gotten a response yet; I’ll post back when I do.

In the interim and in an effort of just getting this working is there anything you can think of that I can do or try from my side to possibly force sdp in the re-invites or something to get this working?

Any and all help/suggestions/ideas/etc will be appreciated. If you need anything else to help me with this let me know and I’ll see what I can do.



From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

The invite with no SDP is a valid response, and the RFC does require a response from the ITSP. As I understand it, it is affectively allowing the ITSP to offer up what they have.

One ITSP that has issues with an invite without SDP has created what they refer to a Mitel patch, as Mitel operates this way as well. Ask how they work with MITEL, and you might find they have a solution in their bag of tricks already.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered “slow start”, as the SDP is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because we still haven’t sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I’ll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) “We’re getting the first REINVITE—without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. “ Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They’ve never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I’m getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it’s more because I wasn’t available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I’ll see what I come up with from here but if you have any further suggestions that I can try I’m open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with – suggestions?) because it was never “answered” so they never saw a 200. Sorry, there wasn’t an agent logged in so that’s my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back – I don’t know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy – I’m not a fan at all. I don’t even use them for a registrar anymore (personally) but it’s what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I’ll report back. I’ll also try going direct to the AA and we’ll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual “ringing” when they are calling in. I can’t seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no “ringing” sound and they didn’t like it. Thus is life.

Anything else you need to know? I’m open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I’m not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
[Description: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Tony Graziano
2012-09-17 18:29:55 UTC
Permalink
you cant edit that file. it is replicated by the system.

i think your provider is not up to standards from the looks of the source
of the complaint. you would have to edit the .vm file, with care (it it's
possible). What is it you are trying to do exactly?

On Mon, Sep 17, 2012 at 12:49 PM, Geoff Musgrave <
Can someone tell me what I’m overlooking when I’m trying to edit
/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profiles.xml to prevent it
from reverting back after I restart everything?****
** **
I’m trying everything I can think of to get this going with my ITSP – I
simply don’t have the luxury of changing providers at this moment.****
** **
Thanks in advance.****
** **
*Sent:* Friday, September 14, 2012 10:33 PM
*To:* 'Discussion list for users of sipXecs software'
*Subject:* Re: [sipx-users] Calls dropping****
** **
Geoff, I’m not an expert on Karoo, or anything else really, but My
understanding is you can have Karoo for your Session Border Controller and
not need to use sipxbridge. There is a limit to the number of concurrent
calls – I believe 20, and then you have to license it. Maybe Joegen will
chime in here. Recently it was announced it was going open source, so I
don’t know how that affects the pricing on it.****
** **
I believe a few people on the list are using it currently, so maybe they
will chip in their expertise from implementation of it.****
** **
Best of luck with the project.****
** **
*Sent:* Friday, September 14, 2012 3:29 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping****
** **
Todd, thanks again for the reply.****
I’ll take a look at Karoo. Would that be in conjunction with sipxbridge or
instead of? I’m already reading through what is on the wiki now but
anything additional you could direct me to would be appreciated.
I would look for another ITSP but it’s late in the game for me to be
finding this out. All of our DIDs/TFs are with them and the client wants to
go live Monday. I may have to build up an asterisk server and configure it
until the ITSP gets things straightened out to work with sipXecs. We have
another project working via freepbx with this ITSP and do not have any
issues so I may have to go that route – at least for a brief period until
they make the necessary changes on their end. ****
** **
Thank you ****
** **
*Sent:* Friday, September 14, 2012 4:45 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping****
** **
Since its is not adhering to standards you may want to consider another.
Or find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.
Todd, thanks again. My ITSP was already aware of the “fix” for how Mitel
operates and have begun planning a software release to address just this
but it has not been put in place yet and may not be for a couple weeks due.
So now I must find a way around it myself or with the help of the community
until then.****
****
Any ideas on how to include SDP in a re-invite?****
****
Musgrave
*Sent:* Friday, September 14, 2012 12:52 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping****
****
Todd, thanks for the response - I’ve asked my ITSP about Mitel but have
not gotten a response yet; I’ll post back when I do. ****
****
In the interim and in an effort of just getting this working is there
anything you can think of that I can do or try from my side to possibly
force sdp in the re-invites or something to get this working?****
****
Any and all help/suggestions/ideas/etc will be appreciated. If you need
anything else to help me with this let me know and I’ll see what I can do.
****
****
****
****
*Sent:* Friday, September 14, 2012 11:39 AM
*To:* 'Discussion list for users of sipXecs software'
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject****
****
The invite with no SDP is a valid response, and the RFC does require a
response from the ITSP. As I understand it, it is affectively allowing the
ITSP to offer up what they have.****
****
One ITSP that has issues with an invite without SDP has created what they
refer to a Mitel patch, as Mitel operates this way as well. Ask how they
work with MITEL, and you might find they have a solution in their bag of
tricks already.****
****
Musgrave
*Sent:* Friday, September 14, 2012 9:01 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject****
****
Ok. Still no headway and below is the latest from my provider. Any ideas
or suggestions will be greatly appreciated. Where can I make these
adjustments or what do I need to ask them to do?****
****
When XXXX transfers the call they send us a RE-INVITE as part of the
process (typical of transfers). However, this INVITE contains no SDP,
offering no information as to what parameters of the media stream should
be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These
types of RE-INVITES, or INVITES are considered “slow start”, as the SDP is
provided later in the setup instead of up-front. ****
****
The problem is that we are handling the RE-INVITE without SDP differently
that one with SDP:****
XXXX sends the reinvite without SDP****
We send XXXX a 100 trying and send the reinvite on to our carrier without
SDP****
Carrier sends us a 100 trying, then a 200 OK.****
We send a 200 OK to XXXX****
XXXX sends an ACK, but this time with SDP****
We do not send that ACK to our carrier right away (symptom of slow start)*
***
****
XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH
SDP.****
We send the invite on to our carrier, also with SDP****
They send back a 100 Trying, then an immediate Request Pending, because we
still haven’t sent an ACK to them for the previous reinvite****
We send that on to XXXX****
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in
rapid manner, all of them get the same Request Pending response.****
This cycle continues 3 times until XXXX gives up and ends the call.****
****
Thanks for all your help.****
****
****
Musgrave
*Sent:* Thursday, September 13, 2012 11:50 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject****
****
My ITSP has asked if I can turn off REINVITES and possibly increase the
session timers.****
****
They want to disable reinvites strictly for testing purposes. They do
support them and have never asked to disable before and have assured me
that I’ll be able to enable them after we test. Is this possible? If so
where would I do that?****
****
The increase in the session timers is because (and I quote) “We’re
getting the first REINVITE—without SDP-- less than 30 seconds after the
call starts. After the first reinvite we get one every 60 seconds or so
and those have SDP. “ Where would I increase those? Or does any of what
they are asking make any sense. ****
****
My ITSP and I are in agreement that the issue is between sipXecs and them
but we have to find where. And I am fairly confident that they will make
the adjustment on their end to make it work if we can find the cause.
They’ve never done me wrong thus far.****
****
Again, I appreciate you help.****
****
Graziano
*Sent:* Tuesday, September 11, 2012 6:38 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject****
****
"whatever" answers the call, if/when configured properly is going to ACK
it. Assuming the ITSP is competent they will see the call as answered.****
****
I simply don't know enough about your environment, but I would suggest
simply having the calls route to the AA (it shows answered this way), then
let it transfer to the hunt group or openacd queue. you probably need to
ask questions about the best way to handle openacd when there is no agent
logged in. It would be important to make sure the reinvite is being honored
by the itsp by testing it with a logged in agent or to an AA and
transferred to a ua that is registered.****
****
you might also double-check the sonicwall config. I wrote a little 3 step
http://wiki.sipfoundry.org/display/sipXecs/Sonicwall****
****
****
****
****
****
On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <
I eliminated the dummy ring piece and still the same result. I was able to
verify that I’m getting 2 way audio before the call drops though. My ITSP
is being difficult, but I think it’s more because I wasn’t available to
respond to their response soon enough to further explain the situation and
clear up the obvious confusion they were having. ****
****
I’ll see what I come up with from here but if you have any further
suggestions that I can try I’m open to them. They were getting 183 when
dialing directly to the queue and telling me that was an abandoned call
(another issue I have to deal with – suggestions?) because it was never
“answered” so they never saw a 200. Sorry, there wasn’t an agent logged in
so that’s my assumption as to the 183 but I would have thought that when
the MOH kicked in on the queue sipXecs would have sent the 200 back – I
don’t know. They determined the call through the AA was ok because they
were transferred and all the SIP messages came back properly. So now I
continue the battle. ****
****
As for godaddy – I’m not a fan at all. I don’t even use them for a
registrar anymore (personally) but it’s what was in place here. I need to
take the 10 minutes and find a reliable host to move our DNS to or spend
the time to bring it in house. ****
****
Again, thanks for all your help.****
****
*Sent:* Tuesday, September 11, 2012 12:47 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject - Email found in subject****
****
Ugh. Go daddy. i only use them for a registrar but cant even stomach their
DNS and moved everything. Good to know I missed that headache yesterday too!
****
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <
Thanks Tony. I was thinking that yesterday when I requested the
troubleshooting with the ITSP but I had other godaddy related fires to put
out yesterday. We will be doing some captures and go from there this
afternoon and I’ll report back. I’ll also try going direct to the AA and
we’ll see how that goes.****
****
Thanks again.****
****
*Sent:* Tuesday, September 11, 2012 12:35 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject -
Email found in subject****
****
It is more likely the ACK is not being OK'd by the ITSP. I would try to
simplify the call inbound to see if this applies to all calls or not.****
****
In other words, send the call to the AA (dont ring) and then see if the
call will stay up for longer than 20 seconds.****
****
Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being ACK'ed
by the ITSP and they are sending a BYE. A call trace or pcap will also bear
this out.****
****
On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <
Tony, thank you for your response and your questions. I hope I answer them
with enough detail.****
****
****
My ITSP is TouchTone and they are signaling on 5080.****
Yes, the call will connect to the AA and will transfer to the queue and
the caller will hear the MOH for a couple seconds and then the call is
dropped so I have no way to confirm that audio is passing both ways because
the drop occurs so quickly..****
****
When calling directly to the queue the call works properly and audio is
heard both ways, but the caller loses their options presented to them in
the AA.****
****
Trunking is a SIP trunk to IP over 5080 – nothing fancy. sipXecs is behind
a watchguard firewall (to an extent) but in the dmz, no alg in use all
custom rules allowing full access to and from the ITSP and internal
phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in
place and when I run DNS advisor everything but the NAPTR records are
working (windows DNS).****
****
The dummy ringing is a request by the client. They want their callers to
hear actual “ringing” when they are calling in. I can’t seem to find
another way of making that sound occur rather than tying the DID to an
extension and adding it to a softphone on another computer and forwarding
the calls after X amount of time to the actual AA. When the DID was direct
to the AA there was no “ringing” sound and they didn’t like it. Thus is
life.****
****
Anything else you need to know? I’m open to suggestions. ****
Thank you!****
****
*Sent:* Tuesday, September 11, 2012 12:03 PM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping - Email found in subject****
****
Explain who the ITSP is and how you have trunking setup. Typically calls
from providers come to your system on port 5080. I would assume this is
working because the call DOES transfer to the AA (and audio is heard,
correct)? If not it is likely the call is not coming to the system on port
5080, which means the system is not properly anchoring the call. ****
****
Explain your trunking and firewall. Explain if the transfer goes to the AA
and audio is heard. ****
****
Don't understand the use case to provide dummy ringing, so perhaps you can
elaborate.****
****
On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <
Good question. I’m not sure. I was on the forums looking for an answer to
another question when I added this.****
****
I added the text below:****
****
First post so bare with me. I've been searching off and on all day today
with nothing to show for it. So now I'm posting for some help.
For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd
space.
Now down to the problem at hand. Incoming calls hit a dummy "ring user" to
supply the ringing to the caller (per client request) for 7 seconds. I
can't find another way of getting this accomplished - open to suggestions.
From there, the call is transferred to an auto attendant that acknowledges
the caller and gives them some direction. If they don't chose an option
they are then transferred to openACD queue and the call then drops. I
watched in the openACD dashboard and the calls drop at 20 seconds - no
more, no less.
I've also called from an internal extension without any problems at all
and no drops. I have also set up a direct DID to the queue line and called
from an external phone and that too works flawlessly. This leads me away
from a RE-INVITE possible issue from my ITSP.
Please point me in the direction or help me in any way possible. This is
the only hangup I have had with this installation so far.
Thank you in advance.****
****
*Sent:* Tuesday, September 11, 2012 10:34 AM
*To:* Discussion list for users of sipXecs software
*Subject:* Re: [sipx-users] Calls dropping ****
****
Where is the original post?****
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <
I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.
I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.
thanks again.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>****
[image: Description: Description: Description: Description: Image removed
by sender.] <http://sipxcolab2013.eventbrite.com/?discount=tony2013>****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
*Error! Filename not specified.*<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[image: Description: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[image: Description: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/****
****
****
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[image: Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
****
****
****
LAN/Telephony/Security and Control Systems Helpdesk:****
Telephone: 434.984.8426****
****
Helpdesk Customers: http://myhelp.myitdepartment.net****
Blog: http://blog.myitdepartment.net****
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-17 18:52:37 UTC
Permalink
Tony, thanks for the reply. I finally found where I needed to make the changes so that they would stick. It was actually by editing both the sipX_profile.xml and the sofia.conf.xml.vm file. Regardless it didn't produce the results I was hoping for.

Yes, both my provider and I are aware they are not up to date on handling re-invites without SDP however they've made a plan to make that change soon. So in the interim I was hoping to find a way to force SDP in the re-invites so that they can handle the calls appropriately or another way until they make the necessary changes on their end. They are the 3rd provider we've had and they have been the most accommodating to needs and their customer service has been phenomenal so I'm reluctant to stray to another. Plus we have several DIDs and TF numbers with them already - I would hate to have to wait on porting to occur.

Unless someone on here has another suggestion I suppose I'll go back to asterisk until they make their adjustments and we test it with sipx. I would just rather find a better solution to this problem aside from "get a new provider."

Thanks for all your help.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Monday, September 17, 2012 1:30 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

you cant edit that file. it is replicated by the system.

i think your provider is not up to standards from the looks of the source of the complaint. you would have to edit the .vm file, with care (it it's possible). What is it you are trying to do exactly?
On Mon, Sep 17, 2012 at 12:49 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Can someone tell me what I'm overlooking when I'm trying to edit /etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profiles.xml to prevent it from reverting back after I restart everything?

I'm trying everything I can think of to get this going with my ITSP - I simply don't have the luxury of changing providers at this moment.

Thanks in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 10:33 PM

To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping

Geoff, I'm not an expert on Karoo, or anything else really, but My understanding is you can have Karoo for your Session Border Controller and not need to use sipxbridge. There is a limit to the number of concurrent calls - I believe 20, and then you have to license it. Maybe Joegen will chime in here. Recently it was announced it was going open source, so I don't know how that affects the pricing on it.

I believe a few people on the list are using it currently, so maybe they will chip in their expertise from implementation of it.

Best of luck with the project.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 3:29 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks again for the reply.
I'll take a look at Karoo. Would that be in conjunction with sipxbridge or instead of? I'm already reading through what is on the wiki now but anything additional you could direct me to would be appreciated.

I would look for another ITSP but it's late in the game for me to be finding this out. All of our DIDs/TFs are with them and the client wants to go live Monday. I may have to build up an asterisk server and configure it until the ITSP gets things straightened out to work with sipXecs. We have another project working via freepbx with this ITSP and do not have any issues so I may have to go that route - at least for a brief period until they make the necessary changes on their end.

Thank you

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 4:45 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Since its is not adhering to standards you may want to consider another. Or find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.

Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Todd, thanks again. My ITSP was already aware of the "fix" for how Mitel operates and have begun planning a software release to address just this but it has not been put in place yet and may not be for a couple weeks due. So now I must find a way around it myself or with the help of the community until then.

Any ideas on how to include SDP in a re-invite?

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks for the response - I've asked my ITSP about Mitel but have not gotten a response yet; I'll post back when I do.

In the interim and in an effort of just getting this working is there anything you can think of that I can do or try from my side to possibly force sdp in the re-invites or something to get this working?

Any and all help/suggestions/ideas/etc will be appreciated. If you need anything else to help me with this let me know and I'll see what I can do.



From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

The invite with no SDP is a valid response, and the RFC does require a response from the ITSP. As I understand it, it is affectively allowing the ITSP to offer up what they have.

One ITSP that has issues with an invite without SDP has created what they refer to a Mitel patch, as Mitel operates this way as well. Ask how they work with MITEL, and you might find they have a solution in their bag of tricks already.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered "slow start", as the SDP is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because we still haven't sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I'll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) "We're getting the first REINVITE-without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. " Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They've never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I'm getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it's more because I wasn't available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I'll see what I come up with from here but if you have any further suggestions that I can try I'm open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with - suggestions?) because it was never "answered" so they never saw a 200. Sorry, there wasn't an agent logged in so that's my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back - I don't know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy - I'm not a fan at all. I don't even use them for a registrar anymore (personally) but it's what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Todd Hodgen
2012-09-17 19:06:59 UTC
Permalink
VOIP.ms is a quick workaround you could use - very affordable. Just forward
your existing numbers to a VOIP.ms account, configure the VOIP.ms SIP trunks
and you could be up and running in 10 minutes or less.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Monday, September 17, 2012 11:53 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Tony, thanks for the reply. I finally found where I needed to make the
changes so that they would stick. It was actually by editing both the
sipX_profile.xml and the sofia.conf.xml.vm file. Regardless it didn't
produce the results I was hoping for.



Yes, both my provider and I are aware they are not up to date on handling
re-invites without SDP however they've made a plan to make that change soon.
So in the interim I was hoping to find a way to force SDP in the re-invites
so that they can handle the calls appropriately or another way until they
make the necessary changes on their end. They are the 3rd provider we've had
and they have been the most accommodating to needs and their customer
service has been phenomenal so I'm reluctant to stray to another. Plus we
have several DIDs and TF numbers with them already - I would hate to have to
wait on porting to occur.



Unless someone on here has another suggestion I suppose I'll go back to
asterisk until they make their adjustments and we test it with sipx. I would
just rather find a better solution to this problem aside from "get a new
provider."



Thanks for all your help.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Monday, September 17, 2012 1:30 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



you cant edit that file. it is replicated by the system.



i think your provider is not up to standards from the looks of the source of
the complaint. you would have to edit the .vm file, with care (it it's
possible). What is it you are trying to do exactly?

On Mon, Sep 17, 2012 at 12:49 PM, Geoff Musgrave
<***@cacionline.net> wrote:

Can someone tell me what I'm overlooking when I'm trying to edit
/etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profiles.xml to prevent it
from reverting back after I restart everything?



I'm trying everything I can think of to get this going with my ITSP - I
simply don't have the luxury of changing providers at this moment.



Thanks in advance.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 10:33 PM


To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping



Geoff, I'm not an expert on Karoo, or anything else really, but My
understanding is you can have Karoo for your Session Border Controller and
not need to use sipxbridge. There is a limit to the number of concurrent
calls - I believe 20, and then you have to license it. Maybe Joegen will
chime in here. Recently it was announced it was going open source, so I
don't know how that affects the pricing on it.



I believe a few people on the list are using it currently, so maybe they
will chip in their expertise from implementation of it.



Best of luck with the project.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 3:29 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Todd, thanks again for the reply.

I'll take a look at Karoo. Would that be in conjunction with sipxbridge or
instead of? I'm already reading through what is on the wiki now but anything
additional you could direct me to would be appreciated.

I would look for another ITSP but it's late in the game for me to be finding
this out. All of our DIDs/TFs are with them and the client wants to go live
Monday. I may have to build up an asterisk server and configure it until the
ITSP gets things straightened out to work with sipXecs. We have another
project working via freepbx with this ITSP and do not have any issues so I
may have to go that route - at least for a brief period until they make the
necessary changes on their end.



Thank you



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 4:45 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Since its is not adhering to standards you may want to consider another. Or
find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.

Geoff Musgrave <***@cacionline.net> wrote:

Todd, thanks again. My ITSP was already aware of the "fix" for how Mitel
operates and have begun planning a software release to address just this but
it has not been put in place yet and may not be for a couple weeks due. So
now I must find a way around it myself or with the help of the community
until then.



Any ideas on how to include SDP in a re-invite?



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Todd, thanks for the response - I've asked my ITSP about Mitel but have not
gotten a response yet; I'll post back when I do.



In the interim and in an effort of just getting this working is there
anything you can think of that I can do or try from my side to possibly
force sdp in the re-invites or something to get this working?



Any and all help/suggestions/ideas/etc will be appreciated. If you need
anything else to help me with this let me know and I'll see what I can do.







From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



The invite with no SDP is a valid response, and the RFC does require a
response from the ITSP. As I understand it, it is affectively allowing the
ITSP to offer up what they have.



One ITSP that has issues with an invite without SDP has created what they
refer to a Mitel patch, as Mitel operates this way as well. Ask how they
work with MITEL, and you might find they have a solution in their bag of
tricks already.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



Ok. Still no headway and below is the latest from my provider. Any ideas or
suggestions will be greatly appreciated. Where can I make these adjustments
or what do I need to ask them to do?



When XXXX transfers the call they send us a RE-INVITE as part of the process
(typical of transfers). However, this INVITE contains no SDP, offering no
information as to what parameters of the media stream should be. While
abnormal, this is allowed by SIP RFC for RE-INVITES. These types of
RE-INVITES, or INVITES are considered "slow start", as the SDP is provided
later in the setup instead of up-front.



The problem is that we are handling the RE-INVITE without SDP differently
that one with SDP:

XXXX sends the reinvite without SDP

We send XXXX a 100 trying and send the reinvite on to our carrier without
SDP

Carrier sends us a 100 trying, then a 200 OK.

We send a 200 OK to XXXX

XXXX sends an ACK, but this time with SDP

We do not send that ACK to our carrier right away (symptom of slow start)



XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH
SDP.

We send the invite on to our carrier, also with SDP

They send back a 100 Trying, then an immediate Request Pending, because we
still haven't sent an ACK to them for the previous reinvite

We send that on to XXXX

XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in
rapid manner, all of them get the same Request Pending response.

This cycle continues 3 times until XXXX gives up and ends the call.



Thanks for all your help.





From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



My ITSP has asked if I can turn off REINVITES and possibly increase the
session timers.



They want to disable reinvites strictly for testing purposes. They do
support them and have never asked to disable before and have assured me that
I'll be able to enable them after we test. Is this possible? If so where
would I do that?



The increase in the session timers is because (and I quote) "We're getting
the first REINVITE-without SDP-- less than 30 seconds after the call starts.
After the first reinvite we get one every 60 seconds or so and those have
SDP. " Where would I increase those? Or does any of what they are asking
make any sense.



My ITSP and I are in agreement that the issue is between sipXecs and them
but we have to find where. And I am fairly confident that they will make the
adjustment on their end to make it work if we can find the cause. They've
never done me wrong thus far.



Again, I appreciate you help.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



"whatever" answers the call, if/when configured properly is going to ACK it.
Assuming the ITSP is competent they will see the call as answered.



I simply don't know enough about your environment, but I would suggest
simply having the calls route to the AA (it shows answered this way), then
let it transfer to the hunt group or openacd queue. you probably need to ask
questions about the best way to handle openacd when there is no agent logged
in. It would be important to make sure the reinvite is being honored by the
itsp by testing it with a logged in agent or to an AA and transferred to a
ua that is registered.



you might also double-check the sonicwall config. I wrote a little 3 step
thing a year ago, because it kept coming up:
http://wiki.sipfoundry.org/display/sipXecs/Sonicwall











On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave
<***@cacionline.net> wrote:

I eliminated the dummy ring piece and still the same result. I was able to
verify that I'm getting 2 way audio before the call drops though. My ITSP is
being difficult, but I think it's more because I wasn't available to respond
to their response soon enough to further explain the situation and clear up
the obvious confusion they were having.



I'll see what I come up with from here but if you have any further
suggestions that I can try I'm open to them. They were getting 183 when
dialing directly to the queue and telling me that was an abandoned call
(another issue I have to deal with - suggestions?) because it was never
"answered" so they never saw a 200. Sorry, there wasn't an agent logged in
so that's my assumption as to the 183 but I would have thought that when the
MOH kicked in on the queue sipXecs would have sent the 200 back - I don't
know. They determined the call through the AA was ok because they were
transferred and all the SIP messages came back properly. So now I continue
the battle.



As for godaddy - I'm not a fan at all. I don't even use them for a registrar
anymore (personally) but it's what was in place here. I need to take the 10
minutes and find a reliable host to move our DNS to or spend the time to
bring it in house.



Again, thanks for all your help.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject - Email found in subject



Ugh. Go daddy. i only use them for a registrar but cant even stomach their
DNS and moved everything. Good to know I missed that headache yesterday too!

On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave
<***@cacionline.net> wrote:

Thanks Tony. I was thinking that yesterday when I requested the
troubleshooting with the ITSP but I had other godaddy related fires to put
out yesterday. We will be doing some captures and go from there this
afternoon and I'll report back. I'll also try going direct to the AA and
we'll see how that goes.



Thanks again.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email
found in subject



It is more likely the ACK is not being OK'd by the ITSP. I would try to
simplify the call inbound to see if this applies to all calls or not.



In other words, send the call to the AA (dont ring) and then see if the call
will stay up for longer than 20 seconds.



Hint: If the call answers and audio flows between both ends for 20-30
seconds but ALWAYS drops, it typically means the call is not being ACK'ed by
the ITSP and they are sending a BYE. A call trace or pcap will also bear
this out.



On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave
<***@cacionline.net> wrote:

Tony, thank you for your response and your questions. I hope I answer them
with enough detail.





My ITSP is TouchTone and they are signaling on 5080.

Yes, the call will connect to the AA and will transfer to the queue and the
caller will hear the MOH for a couple seconds and then the call is dropped
so I have no way to confirm that audio is passing both ways because the drop
occurs so quickly..



When calling directly to the queue the call works properly and audio is
heard both ways, but the caller loses their options presented to them in the
AA.



Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a
watchguard firewall (to an extent) but in the dmz, no alg in use all custom
rules allowing full access to and from the ITSP and internal
phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in
place and when I run DNS advisor everything but the NAPTR records are
working (windows DNS).



The dummy ringing is a request by the client. They want their callers to
hear actual "ringing" when they are calling in. I can't seem to find another
way of making that sound occur rather than tying the DID to an extension and
adding it to a softphone on another computer and forwarding the calls after
X amount of time to the actual AA. When the DID was direct to the AA there
was no "ringing" sound and they didn't like it. Thus is life.



Anything else you need to know? I'm open to suggestions.


Thank you!



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject



Explain who the ITSP is and how you have trunking setup. Typically calls
from providers come to your system on port 5080. I would assume this is
working because the call DOES transfer to the AA (and audio is heard,
correct)? If not it is likely the call is not coming to the system on port
5080, which means the system is not properly anchoring the call.



Explain your trunking and firewall. Explain if the transfer goes to the AA
and audio is heard.



Don't understand the use case to provide dummy ringing, so perhaps you can
elaborate.



On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave
<***@cacionline.net> wrote:

Good question. I'm not sure. I was on the forums looking for an answer to
another question when I added this.



I added the text below:



First post so bare with me. I've been searching off and on all day today
with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10
ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via
iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd
space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to
supply the ringing to the caller (per client request) for 7 seconds. I can't
find another way of getting this accomplished - open to suggestions. From
there, the call is transferred to an auto attendant that acknowledges the
caller and gives them some direction. If they don't chose an option they are
then transferred to openACD queue and the call then drops. I watched in the
openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and
no drops. I have also set up a direct DID to the queue line and called from
an external phone and that too works flawlessly. This leads me away from a
RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the
only hangup I have had with this installation so far.

Thank you in advance.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping



Where is the original post?

On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave
<***@cacionline.net> wrote:



I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>


<http://sipxcolab2013.eventbrite.com/?discount=tony2013> Error! Filename
not specified.



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.



LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

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/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Description: Image removed by sender.





LAN/Telephony/Security and Control Systems Helpdesk:

Telephone: 434.984.8426

sip: ***@voice.myitdepartment.net



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

Blog: http://blog.myitdepartment.net
Geoff Musgrave
2012-09-17 19:12:32 UTC
Permalink
Thanks for the tip. I'll look into. Thank you!

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Todd Hodgen
Sent: Monday, September 17, 2012 2:07 PM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping

VOIP.ms is a quick workaround you could use - very affordable. Just forward your existing numbers to a VOIP.ms account, configure the VOIP.ms SIP trunks and you could be up and running in 10 minutes or less.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Monday, September 17, 2012 11:53 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Tony, thanks for the reply. I finally found where I needed to make the changes so that they would stick. It was actually by editing both the sipX_profile.xml and the sofia.conf.xml.vm file. Regardless it didn't produce the results I was hoping for.

Yes, both my provider and I are aware they are not up to date on handling re-invites without SDP however they've made a plan to make that change soon. So in the interim I was hoping to find a way to force SDP in the re-invites so that they can handle the calls appropriately or another way until they make the necessary changes on their end. They are the 3rd provider we've had and they have been the most accommodating to needs and their customer service has been phenomenal so I'm reluctant to stray to another. Plus we have several DIDs and TF numbers with them already - I would hate to have to wait on porting to occur.

Unless someone on here has another suggestion I suppose I'll go back to asterisk until they make their adjustments and we test it with sipx. I would just rather find a better solution to this problem aside from "get a new provider."

Thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Monday, September 17, 2012 1:30 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

you cant edit that file. it is replicated by the system.

i think your provider is not up to standards from the looks of the source of the complaint. you would have to edit the .vm file, with care (it it's possible). What is it you are trying to do exactly?
On Mon, Sep 17, 2012 at 12:49 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Can someone tell me what I'm overlooking when I'm trying to edit /etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profiles.xml to prevent it from reverting back after I restart everything?

I'm trying everything I can think of to get this going with my ITSP - I simply don't have the luxury of changing providers at this moment.

Thanks in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 10:33 PM

To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping

Geoff, I'm not an expert on Karoo, or anything else really, but My understanding is you can have Karoo for your Session Border Controller and not need to use sipxbridge. There is a limit to the number of concurrent calls - I believe 20, and then you have to license it. Maybe Joegen will chime in here. Recently it was announced it was going open source, so I don't know how that affects the pricing on it.

I believe a few people on the list are using it currently, so maybe they will chip in their expertise from implementation of it.

Best of luck with the project.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 3:29 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks again for the reply.
I'll take a look at Karoo. Would that be in conjunction with sipxbridge or instead of? I'm already reading through what is on the wiki now but anything additional you could direct me to would be appreciated.

I would look for another ITSP but it's late in the game for me to be finding this out. All of our DIDs/TFs are with them and the client wants to go live Monday. I may have to build up an asterisk server and configure it until the ITSP gets things straightened out to work with sipXecs. We have another project working via freepbx with this ITSP and do not have any issues so I may have to go that route - at least for a brief period until they make the necessary changes on their end.

Thank you

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 4:45 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Since its is not adhering to standards you may want to consider another. Or find an external session border controller. Maybe karoo would help
Sent from my twiddling thumbs.

Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Todd, thanks again. My ITSP was already aware of the "fix" for how Mitel operates and have begun planning a software release to address just this but it has not been put in place yet and may not be for a couple weeks due. So now I must find a way around it myself or with the help of the community until then.

Any ideas on how to include SDP in a re-invite?

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 12:52 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Todd, thanks for the response - I've asked my ITSP about Mitel but have not gotten a response yet; I'll post back when I do.

In the interim and in an effort of just getting this working is there anything you can think of that I can do or try from my side to possibly force sdp in the re-invites or something to get this working?

Any and all help/suggestions/ideas/etc will be appreciated. If you need anything else to help me with this let me know and I'll see what I can do.



From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Todd Hodgen
Sent: Friday, September 14, 2012 11:39 AM
To: 'Discussion list for users of sipXecs software'
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

The invite with no SDP is a valid response, and the RFC does require a response from the ITSP. As I understand it, it is affectively allowing the ITSP to offer up what they have.

One ITSP that has issues with an invite without SDP has created what they refer to a Mitel patch, as Mitel operates this way as well. Ask how they work with MITEL, and you might find they have a solution in their bag of tricks already.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Friday, September 14, 2012 9:01 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ok. Still no headway and below is the latest from my provider. Any ideas or suggestions will be greatly appreciated. Where can I make these adjustments or what do I need to ask them to do?

When XXXX transfers the call they send us a RE-INVITE as part of the process (typical of transfers). However, this INVITE contains no SDP, offering no information as to what parameters of the media stream should be. While abnormal, this is allowed by SIP RFC for RE-INVITES. These types of RE-INVITES, or INVITES are considered "slow start", as the SDP is provided later in the setup instead of up-front.

The problem is that we are handling the RE-INVITE without SDP differently that one with SDP:
XXXX sends the reinvite without SDP
We send XXXX a 100 trying and send the reinvite on to our carrier without SDP
Carrier sends us a 100 trying, then a 200 OK.
We send a 200 OK to XXXX
XXXX sends an ACK, but this time with SDP
We do not send that ACK to our carrier right away (symptom of slow start)

XXXX waits about .2 seconds and sends a new RE-INVITE, but this time WITH SDP.
We send the invite on to our carrier, also with SDP
They send back a 100 Trying, then an immediate Request Pending, because we still haven't sent an ACK to them for the previous reinvite
We send that on to XXXX
XXXX ACKs the Request Pending, waits .2 seconds and sends 4 reinvites in rapid manner, all of them get the same Request Pending response.
This cycle continues 3 times until XXXX gives up and ends the call.

Thanks for all your help.


From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Geoff Musgrave
Sent: Thursday, September 13, 2012 11:50 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

My ITSP has asked if I can turn off REINVITES and possibly increase the session timers.

They want to disable reinvites strictly for testing purposes. They do support them and have never asked to disable before and have assured me that I'll be able to enable them after we test. Is this possible? If so where would I do that?

The increase in the session timers is because (and I quote) "We're getting the first REINVITE-without SDP-- less than 30 seconds after the call starts. After the first reinvite we get one every 60 seconds or so and those have SDP. " Where would I increase those? Or does any of what they are asking make any sense.

My ITSP and I are in agreement that the issue is between sipXecs and them but we have to find where. And I am fairly confident that they will make the adjustment on their end to make it work if we can find the cause. They've never done me wrong thus far.

Again, I appreciate you help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org]<mailto:[mailto:sipx-users-***@list.sipfoundry.org]> On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 6:38 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

"whatever" answers the call, if/when configured properly is going to ACK it. Assuming the ITSP is competent they will see the call as answered.

I simply don't know enough about your environment, but I would suggest simply having the calls route to the AA (it shows answered this way), then let it transfer to the hunt group or openacd queue. you probably need to ask questions about the best way to handle openacd when there is no agent logged in. It would be important to make sure the reinvite is being honored by the itsp by testing it with a logged in agent or to an AA and transferred to a ua that is registered.

you might also double-check the sonicwall config. I wrote a little 3 step thing a year ago, because it kept coming up: http://wiki.sipfoundry.org/display/sipXecs/Sonicwall





On Tue, Sep 11, 2012 at 6:47 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
I eliminated the dummy ring piece and still the same result. I was able to verify that I'm getting 2 way audio before the call drops though. My ITSP is being difficult, but I think it's more because I wasn't available to respond to their response soon enough to further explain the situation and clear up the obvious confusion they were having.

I'll see what I come up with from here but if you have any further suggestions that I can try I'm open to them. They were getting 183 when dialing directly to the queue and telling me that was an abandoned call (another issue I have to deal with - suggestions?) because it was never "answered" so they never saw a 200. Sorry, there wasn't an agent logged in so that's my assumption as to the 183 but I would have thought that when the MOH kicked in on the queue sipXecs would have sent the 200 back - I don't know. They determined the call through the AA was ok because they were transferred and all the SIP messages came back properly. So now I continue the battle.

As for godaddy - I'm not a fan at all. I don't even use them for a registrar anymore (personally) but it's what was in place here. I need to take the 10 minutes and find a reliable host to move our DNS to or spend the time to bring it in house.

Again, thanks for all your help.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:47 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject - Email found in subject

Ugh. Go daddy. i only use them for a registrar but cant even stomach their DNS and moved everything. Good to know I missed that headache yesterday too!
On Tue, Sep 11, 2012 at 1:44 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Thanks Tony. I was thinking that yesterday when I requested the troubleshooting with the ITSP but I had other godaddy related fires to put out yesterday. We will be doing some captures and go from there this afternoon and I'll report back. I'll also try going direct to the AA and we'll see how that goes.

Thanks again.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:35 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject - Email found in subject

It is more likely the ACK is not being OK'd by the ITSP. I would try to simplify the call inbound to see if this applies to all calls or not.

In other words, send the call to the AA (dont ring) and then see if the call will stay up for longer than 20 seconds.

Hint: If the call answers and audio flows between both ends for 20-30 seconds but ALWAYS drops, it typically means the call is not being ACK'ed by the ITSP and they are sending a BYE. A call trace or pcap will also bear this out.

On Tue, Sep 11, 2012 at 1:21 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Tony, thank you for your response and your questions. I hope I answer them with enough detail.


My ITSP is TouchTone and they are signaling on 5080.
Yes, the call will connect to the AA and will transfer to the queue and the caller will hear the MOH for a couple seconds and then the call is dropped so I have no way to confirm that audio is passing both ways because the drop occurs so quickly..

When calling directly to the queue the call works properly and audio is heard both ways, but the caller loses their options presented to them in the AA.

Trunking is a SIP trunk to IP over 5080 - nothing fancy. sipXecs is behind a watchguard firewall (to an extent) but in the dmz, no alg in use all custom rules allowing full access to and from the ITSP and internal phones/softphones. sipXecs does NOT handle DNS or DHCP. SRV records are in place and when I run DNS advisor everything but the NAPTR records are working (windows DNS).

The dummy ringing is a request by the client. They want their callers to hear actual "ringing" when they are calling in. I can't seem to find another way of making that sound occur rather than tying the DID to an extension and adding it to a softphone on another computer and forwarding the calls after X amount of time to the actual AA. When the DID was direct to the AA there was no "ringing" sound and they didn't like it. Thus is life.

Anything else you need to know? I'm open to suggestions.

Thank you!

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 12:03 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping - Email found in subject

Explain who the ITSP is and how you have trunking setup. Typically calls from providers come to your system on port 5080. I would assume this is working because the call DOES transfer to the AA (and audio is heard, correct)? If not it is likely the call is not coming to the system on port 5080, which means the system is not properly anchoring the call.

Explain your trunking and firewall. Explain if the transfer goes to the AA and audio is heard.

Don't understand the use case to provide dummy ringing, so perhaps you can elaborate.

On Tue, Sep 11, 2012 at 12:57 PM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:
Good question. I'm not sure. I was on the forums looking for an answer to another question when I added this.

I added the text below:

First post so bare with me. I've been searching off and on all day today with nothing to show for it. So now I'm posting for some help.

For starters my build is sipXecs (4.6.0. 2012-09-06EDT13:09:10 ip-10-72-43-110.ec2.internal) 32bit freshly installed today (9/8/12) via iso. yum update ran earlier. 2x quad processors | 16gb RAM | plenty of hdd space.

Now down to the problem at hand. Incoming calls hit a dummy "ring user" to supply the ringing to the caller (per client request) for 7 seconds. I can't find another way of getting this accomplished - open to suggestions. From there, the call is transferred to an auto attendant that acknowledges the caller and gives them some direction. If they don't chose an option they are then transferred to openACD queue and the call then drops. I watched in the openACD dashboard and the calls drop at 20 seconds - no more, no less.

I've also called from an internal extension without any problems at all and no drops. I have also set up a direct DID to the queue line and called from an external phone and that too works flawlessly. This leads me away from a RE-INVITE possible issue from my ITSP.

Please point me in the direction or help me in any way possible. This is the only hangup I have had with this installation so far.

Thank you in advance.

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Tony Graziano
Sent: Tuesday, September 11, 2012 10:34 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] Calls dropping

Where is the original post?
On Tue, Sep 11, 2012 at 11:17 AM, Geoff Musgrave <***@cacionline.net<mailto:***@cacionline.net>> wrote:


I have contacted my ITSP and we will be doing some
troubleshooting today to see if they are causing anything or
if they are seeing any strange. I'll post back with any
significant results and especially if we find a resolution.

I'm still open to any suggestions anyone here on the forums
may have. And please let me know if you need any further
details from me.

thanks again.
_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
Error! Filename not specified.<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

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

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



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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!
[Description: Image removed by sender.]<http://sipxcolab2013.eventbrite.com/?discount=tony2013>


LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net<mailto:***@voice.myitdepartment.net>

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
Loading...