SIP Calls dropping when call forwarded to SIP trunk?

[telecotek1]

We are call forwarding calls temporarily to temporary DID's that terminate on a SBC/IPO. I know call forwarding is traditionally unreliable. But we have been call forwarding to cell phones in the past without issue. But now that we are call forwarding to our sip trunk all of the inbound calls that are call forwarding to the switch drop at a level 0f 75%. We don't experience any dropped calls on DID's that directly terminate on the SIP trunk. Is there anyway to maybe decrease the sensitivity of the SBS/IPO to at least stop the dropped calls or potentially fix the problem all together? If the cell phone call forwarding didn't work then I would just chalk it up to the pbx performing the call forwarding but works reliably.

Thanks in advance we are really having a major problem...

 

[IPOLackey]

Hi Telecotek1,

Need to start with a monitor trace to make sure the targeting is working correctly and the system is actually trying to call forward. If it is then it's a move to the SIP trunk to see why it's not taking the call. May be a P-Asserted ID issue, or even a SIP ALG issue on the firewall/router.

Hope that helps for a next step, or post what you see on the sys mon and ssa.

 

[telecotek1]

I'm way beyond that. I can see in my traces that it looks like a normal drop. It's just very strange how it's only when I forward to my sip trunk. I can see the calls hit the appropriate station they talk and then the call just gets wanky after that. but all traces in sys mon and wireshark look pretty normal. the funny thing is that if I call forward to a cell phone it works perfectly. It's only when I forward the call to my SIP trunk. I'm having the carrier temporarily call forward these DID's for now. But it would be nice to know why this is happening or if there is something that can be done!

Just to be clear I'm forwarding from my PBX in one office to a new office that has a sip trunk.

thanks for your help.

 

[amriddle01]

The system doesn't know it's a forwarded call to treat it any differently from a normal DID call, it is just a normal DID call. Basically this issue is not the IPO or SBC, it's before that

 

[telecotek1]

I know isn't that so strange that it works fine for a cell phone but not the SIP trunk. If it wasn't during business hours I'd spend more time looking at traces to really get a full understanding of what's going on. Something odd but just can't figure out where.

 

[amriddle01]

Could be the interconnect/routing of the source/exchange of the forward, it's not your side though

 

[tslytsly]

I've had issues where SIP trunk to SIP trunk forwards result in no audio.
The way to fix that is to make sure you have Keepalives setup on the VOIP tab of the relevant LAN port:

tslytsly, established 1984

 

[amriddle01]

I don't think this is SIP trunk to SIP trunk forward offsite, I think he's saying it's a forward to his SIP trunks

 

[tslytsly]

I don't think this is SIP trunk to SIP trunk forward offsite, I think he's saying it's a forward to his SIP trunks

ah, I really should have read the OP more carefully...

in that case, how long into the call do they drop?

tslytsly, established 1984

 

[telecotek1]

About 2 mins they are saying I wasn't in the office yesterday so not 100% sure. I had the carrier call forward the calls instead of my PBX and I'm still hearing that calls are dropping.

 

[telecotek1]

I have a bit more information on this. I'm working on the floor today so I can watch exactly what the users are experiencing. I had a user have an inbound call it was like they couldn't answer the call - phone rang and they lifted the handset and couldn't hear the person. I then made a test call and it seemed to ring on multiple appearances when I hung-up on the inbound I moded over to the next appearance assuming that the user was just receiving another inbound call. I picked it up and it was ringing. strange.. the carrier just sent me a bunch of pcaps. See what I see.

 

[amriddle01]

You aren't very clear in what you're doing.
The above calls are direct DID calls or forwarded calls to that DID, what happens with direct if not?

 

[telecotek1]

I know. I'm sorry - not sure what I wrote there. Thanks

Here's the scenario in our old office we have digital PRI with an old system with a range of DID's. We opened a new office with a SIP trunk and we got some temporary DID's on this sip trunk. Because of some issues the port got delayed for our DID's. So I currently have the carrier call forwarding about 10 of our DID's. So what I've done in the system to make this as transparent as possible and this could be part of the problem. I've created a huntgroup for each user and routed the DID to the end user. I did this because I want to manipulate the outbound caller ID to show our existing DID's and not the temporary numbers that are assigned to the new SIP trunk. This works fine on all outbound calls. Inbound works some times. Not sure if this makes a difference at all in this but figured id mention.

This last call I was referring to in the previous post. End users phone rang (remember all inbound calls are forwarded in via the previous carrier) enduser lifted the handset and the phone continued to ring. I then immediately following that attempted to recreate that call. I call from my cell to his DID and when the call came in it rang the first appearance then I noticed both of his other appearance had calls ringing so I went to the next appearance. picked it up and there I heard ringing. Couldn't pick the third appearance I was too late. What makes this really hard to troublehoot is all of forwarded/inbound calls show only the endusers DID info for caller ID and not the actual person calling in. So I'm not sure if that was the original caller trying to call back on one of the other call appearances. Or something screwy going on. I have never actually had a cropped call. But every other person on the team has. I never had a DID on the old system so that's the difference people are calling me on the DID that terminates on the Carriers SIP trunk.

That was a mouthful. Thanks for reading.

 

[telecotek1]

Just happened to me on my phone (Not call forwarded) on a inbound call. Lifted the handset - no-one there appearance still ringing pressed it. there was my caller. Then proceded to have a 15 minute perfectly clear conversation. Had the same person call me back and I lifted the handset and was able to answer the call.

 

[IPOLackey]

This is starting to sound like a SIP ALG issue on your new setup. The call forwarding is a red-herring and nothing to do with how the calls are connecting. Sounds like the call keeps getting presented to the system.

 

[amriddle01]

Bypass the SBC temporarily (they're typically overkill/not required anyway) see what happens then....just for testing purposes

 

[telecotek1]

That's going to be hard to do mid-day. But OK I'll give that a go. I'll have to reconfigure the IPO to do so obviously. I wonder if there is a tweak on the SBS that I can make to clean this up maybe? then I was thinking of the way I have the LAN configured and devices connected. I would think tho if it was lan/vlan congfiguration issue that I would see packet loss in system status all tho I don't put much credence in what system status shows. But system status doesn't show one single instance of packet loss.

 

[amriddle01]

Tip for you (pre 9.1), editing existing SIP lines and not "Immediate" rebooting doesn't work.
Delete the line, put it back in with the correct details and then "Merge" and that will work

 

[amriddle01]

Packet loss requires the stream to have started and then go bad to be seen, if when going off-hook to answer you're getting silence then the RTP stream isn't even starting so no packet loss will be measured

 

[tslytsly]

it really does sound like a firewall issue.
if the SIP trunk provider doesn't receive the 100 TRYING from their INVITE they will send another.
When you ring a DDI this will often present as multiple calls on multiple LA keys.
It could be SIP-ALG or possibly the router/SBC is doing PAT on outbound traffic, ie. it is translating the source port of the outgoing packets from 5060 to something else.

tslytsly, established 1984