×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Calls Die on Hold Pt. 2

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.

RE: Calls Die on Hold Pt. 2

Your best to use the term "drop", not "die"

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

(OP)
Curly, Good to know. I used the term "die" simply because the call can still be seen as active in BCM Monitor when this happens. The call just goes silent but never actually drops. Now I know!

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 is confusing to me, and i might out in left field, why should the ITSP care or even get an indication that the call is on hold. That's an internal function of the BCM. The BCM shouldn't even be broadcasting a state change to the ITSP.

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

(OP)
Allworxguy:

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

(OP)
Brian,

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

You SIP programming differs so much from my SIP accounts and Dest/Route/Plan programming that I am just going to shut my mouth and wonder how yours even works at all, maybe I play later someday....lol
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

(OP)
Well, I'm not a telco guy, but a sysadmin. Phones are definitely not my specialty, I had to piece this together by reading the manual and as many forum posts as I could. Have I gone about setting up my Dest/Route/Plan programming up in the worst possible way? what exactly, if you don't mind me asking do you see wrong with the way I've set it up? Genuinely, this question is an attempt to gain more knowledge on something I'm not trained specifically on.

RE: Calls Die on Hold Pt. 2

If it works it's not necessarily wrong.

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

I have 2 guesses on the original problem. "Enable local NAT compensation" under SIP Trunking-Public-Advanced should not be checked. That will definitely hose the voice ports navigating the local router's NAT and cause the lost calls on hold.

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

Another thing is to definitely disable the "Session refresh method." The setting above it for "NAT pinhole maintenance" serves to keep the connection alive. I spent many hours tracing packets through the BCM50 and found that the "NAT pinhole maintenance" setting was the key to keeping Flowroute working smoothly.

Brian Cox
Georgia Telephone
http://Georgia-Telephone.com
http://www.linkedin.com/in/briancox1952

RE: Calls Die on Hold Pt. 2

(OP)
Curlycord: Thanks for the link! I'm going to dig into that and really try to wrap my head around the document.

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close