Calls Die on Hold Pt. 2
Calls Die on Hold Pt. 2
(OP)
thread1361-1794050: Incoming Calls Die on Hold
Life got in the way, and I was unable to deal with this issue for a while.
I took firebird's advice and swapped systems, the problem stayed the same. Both systems are now exhibiting this issue.
I spoke with my provider (Flowroute) and this was their response:
Looking at the call we see it set up normally but during the re-invite to place the call on hold we see the media IP change to a private IP address: 192.168.1.90. When the 2nd re-invite comes to take the call off hold it still shows the private IP address for the media IP. Since the private IP address is not routable the media then fails. Please adjust the media IP to the Public IP address. We are also seeing the private IP address in the Contact and the Via headers which can also cause some issues. We recommend changing these to the headers as well.
I have not had the time to sit down and make any of these changes, but I did find a workaround to the problem. For now, In features, I've turned "Music" off and set MOH to "Silent", this appears to skip the re-invites and just hold the line silently. If anyone knows off the top of their head what settings I need to play with in order to avoid the issue described above, I'll happily test and report back, otherwise, it looks like I'll be digging through the manual and stabbing in the dark.
I'll dig into this more sometime this week, but wanted to give an update to the thread in case anyone else comes looking for this information sometime down the line.
Life got in the way, and I was unable to deal with this issue for a while.
I took firebird's advice and swapped systems, the problem stayed the same. Both systems are now exhibiting this issue.
I spoke with my provider (Flowroute) and this was their response:
Looking at the call we see it set up normally but during the re-invite to place the call on hold we see the media IP change to a private IP address: 192.168.1.90. When the 2nd re-invite comes to take the call off hold it still shows the private IP address for the media IP. Since the private IP address is not routable the media then fails. Please adjust the media IP to the Public IP address. We are also seeing the private IP address in the Contact and the Via headers which can also cause some issues. We recommend changing these to the headers as well.
I have not had the time to sit down and make any of these changes, but I did find a workaround to the problem. For now, In features, I've turned "Music" off and set MOH to "Silent", this appears to skip the re-invites and just hold the line silently. If anyone knows off the top of their head what settings I need to play with in order to avoid the issue described above, I'll happily test and report back, otherwise, it looks like I'll be digging through the manual and stabbing in the dark.
I'll dig into this more sometime this week, but wanted to give an update to the thread in case anyone else comes looking for this information sometime down the line.
RE: Calls Die on Hold Pt. 2
In: IP Subsystem/GeneralSettings/
Do you have your Public IP address entered there?
"we see the media IP change to a private IP address: 192.168.1.90"
-So what is the "media IP" ip address according the the carrier and what device is it on your end?
-What device is this one? 192.168.1.90
________________________________________

=----(((((((((()----=
www.curlycord.com
Toronto, Canada
Add me to LinkedIN
RE: Calls Die on Hold Pt. 2
I do have the IP entered there, yes. Due to being on a dynamic IP, STUN is turned on, with the default stun.ekiga.net -- It figures out the public IP and populates the field.
The Media address according to the carrier should be my public IP all the time, but when put on hold, it changes to 192.168.1.90, which is the IP of the BCM on my local network.
RE: Calls Die on Hold Pt. 2
What about "Tones" on hold? What were using for a music source?
Marv ccna
RE: Calls Die on Hold Pt. 2
I do not actually use stun any longer, I have 5 different SIP carriers and found it to be a hinderance where some sip trunks were effected.
Try disabling it an manually enter the address.
Check this thread, maybe something in there might help.
Are you absolutely sure every little setting in every tab of SIP Trunking is the same as the other BCM?
Are you able to to put the BCM on an older router and direct to your mode (avoid current network) to test?
Or bring the BCM to the other site?
What about using only G729 as a codec in Media Parameters?
Outta Ammo...again!
________________________________________

=----(((((((((()----=
www.curlycord.com
Toronto, Canada
Add me to LinkedIN
RE: Calls Die on Hold Pt. 2
Brian Cox
Georgia Telephone
http://Georgia-Telephone.com
http://www.linkedin.com/in/briancox1952
RE: Calls Die on Hold Pt. 2
From my understanding, this is normal behavior for SIP across most platforms. In this case, the BCM does a blind-transfer to BcmAmp which kicks off a re-invite to change the RTP stream's destination. (again, from my understanding.)
Tones has the same issue, I've been using the onboard Music Manager which as far as I'm aware is the service "BcmAmp"
Curlycord:
I disabled STUN and entered the IP manually, no change.
I scoured your sourced thread and didn't find anything that tipped me off.
I put the BCM on an older router, and even exposed the device directly to the internet with zero NAT or Firewall, no change.
G.729 only, also no change!
exsmogger:
here's a zip file with a bunch of screenshots showing how I've got FlowRoute set-up on my system.
RE: Calls Die on Hold Pt. 2
I went through your screenshots and there are many differences from my settings. I'm attaching the screenshots from my own system where there are conflicts with your settings.
Brian Cox
Georgia Telephone
http://Georgia-Telephone.com
http://www.linkedin.com/in/briancox1952
RE: Calls Die on Hold Pt. 2
Thanks for doing that! There are indeed quite a few differences. I mirrored your SIP settings, changed every option one at a time and the issue remains.
For now I'll use the silence option for MOH, I think I'm going to ask around and see if anyone has a blank, unconfigured R6 image that I can use to test with because I have now wasted hours of my life trying to sort this issue out with what I've got, and I'm beginning to think something may have really gone wrong on the back-end.
RE: Calls Die on Hold Pt. 2
That's the thing with BCM, so powerful it works in different ways.
Will let exsmogger work with this one since he use Flowroute.
________________________________________

=----(((((((((()----=
www.curlycord.com
Toronto, Canada
Add me to LinkedIN
RE: Calls Die on Hold Pt. 2
RE: Calls Die on Hold Pt. 2
The one thing that stood out was that in SIP Trunks/RoutingTable you have 1 as the Destination Digit
The 1 would then match the 1 in the DialingPlan/Dest Code, but you do not have a 1 in your Dest Code programming, nor the Public Network/DN Lenghts.
So it seems I need to figure out how it works that way.
Here is my FAQ's that might indicate how I have programmed my lines: https://www.tek-tips.com/faqs.cfm?fid=7741
Perhaps I can add Flowroute to the FAQ.
Found this but for CISCO:
Support: try disabling Supports Re-invite
User: That worked!
________________________________________
=----(((((((((()----=
www.curlycord.com
Toronto, Canada
Add me to LinkedIN
RE: Calls Die on Hold Pt. 2
In the same area under ITSP association method you should select "From header proxy address match." This is what a Flowroute tech support gent told me it should be set to.
Brian Cox
Georgia Telephone
http://Georgia-Telephone.com
http://www.linkedin.com/in/briancox1952
RE: Calls Die on Hold Pt. 2
Brian Cox
Georgia Telephone
http://Georgia-Telephone.com
http://www.linkedin.com/in/briancox1952
RE: Calls Die on Hold Pt. 2
exsmogger: All good information, I've gone ahead and disabled NAT Compensation & Media Relay for now. I also changed over to "From header proxy address match" It's good to know that "Session refresh method" should be disabled. I believe I originally enabled that option because I was having a problem where calls would go silent exactly 30 minutes into the call.
I'm still not having any luck, but you guys have convinced me that I really need to sit down and study all of these things. My next step here is to ask a couple of friends of mine whether or not they may have an old ethernet hub somewhere, sit down and change each one of these options one by one and make test calls with a computer running wireshark on the hub so I can see exactly what's going on when and how.
I want to say that I really appreciate the time that y'all have given me on this issue.