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...

 

[telecotek1]

Again thanks for your help folks..

If it was an SBC configuration issue wouldn't I be reliably recreate the issue. I have the SBC sitting on a DMZ on my firewall. The firewall shouldn't be doing anything to the traffic.

 

[amriddle01]

Only way to know for sure is to bypass it, then work out why if it is

 

[telecotek1]

amriddle01 - Its true simple troubleshooting 101. I'll probably have to do this after hours. by the way this box is 9.1 but I have merged about a 100 changes at that sip line. I could blow it away for giggles

 

[telecotek1]

somewhat unrelated but my outgoing caller ID is unreliable and the provider said that they need to see the invite with E164 So I just added the + sign to the User | Sip tab in the contact field. when I dial my cell phone I see the + sign when I dial another cell (different carrier) no +. Am I modifying the correct field? Can I use ARS to insert the +. Sorry total SIP newb.

 

[derfloh]

There is an option in the SIP line config called use + for international or similar. Check that out.

 

[telecotek1]

Did several tests last night both from bypassing the sbc and with the sbc and couldn't duplicate a dropped call. But just had an ext have 3 drops in a row and the sysmon which really probably wont tell us much since we can't see what was happening on the sbc. Figured i'd offer it up anyway

13:08:49 348520361mS SIP Rx: UDP 10.10.101.251:5060 -> 10.10.101.254:5060
BYE sip:+12125551212@10.10.101.254:5060;transport=udp SIP/2.0
From: <sip:13475551212@10.10.101.251>;tag=sansay59757192rdb7132
To: "J Smith" <sip:12125551212@10.10.101.251>;tag=45884a196690ac45
CSeq: 2 BYE
Call-ID: 4383babb1a3ee243b63ebabb5a803248
Record-Route: <sip:10.10.101.251:5060;ipcs-line=1798;lr;transport=udp>
Supported: replaces
Max-Forwards: 65
Via: SIP/2.0/UDP 10.10.101.251:5060;branch=z9hG4bK-s1632-001228477187-1--s1632-
Content-Length: 0

13:08:49 348520363mS Sip: Cannot accept call: reason = 487 (Request Terminated)
13:08:49 348520363mS Sip: SIPDialog f1933d80 created, dialogs 2 txn_keys 10
13:08:49 348520364mS SIP Tx: UDP 10.10.101.254:5060 -> 10.10.101.251:5060
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 10.10.101.251:5060;branch=z9hG4bK-s1632-001228477187-1--s1632-
Record-Route: <sip:10.10.101.251:5060;ipcs-line=1798;lr;transport=udp>
From: <sip:13475551212@10.10.101.251>;tag=sansay59757192rdb7132
Call-ID: 4383babb1a3ee243b63ebabb5a803248
CSeq: 2 BYE
Supported: timer
Server: IP Office 9.1.6.0 build 153
To: "J Smith" <sip:12125551212@10.10.101.251>;tag=45884a196690ac45
Content-Length: 0