Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Calling Through CS1K

Status
Not open for further replies.

dclake

IS-IT--Management
Feb 3, 2009
247
LC
Hi everyone.

I have just setup a BCM to call through an E1 trunk on a CS1k through a SIP trunk. calling works but I get a weird problem where I don't get ringing tone. All the user gets is dead air until the remote party picks up.

Has anyone experienced this?
 
I've found this below. I'm not sure if it will offer any help?.

Problem scenario:
A network of CS1000E rls 6 systems connected via SIP virtual trunks
User at Node A calls a user at Node B and does not hear any ringback tone, although the target set is ringing. After 32 seconds ringback tone is suddenly given to the caller

Examination of packet captures showed that Node B was sending the '180 Ringing' message but it was not getting through to Node A. After resending the '180 Ringing' six times Node B sent a '500 Server Internal Error' packet which did get through to Node A. On receipt of this message Node A resent the SIP Invite and this time the '180 Ringing' response was received as expected and ringback tone was heard by the caller, 32 seconds after the original SIP Invite was sent.

The '180 Ringing' packets that failed to get through to Node A had a size of 1485 bytes. The one that did get through after the second SIP Invite was much smaller - about 600 bytes.

The customer's network was using GRE Tunnelling, which added an overhead of 24 bytes to each packet, so the maximum allowable packet size on the network was 1476 bytes, rather than the MTU size of 1500 set on the CS1000 nodes.
Note that the MTU of 1500 excludes the 14 byte Ethernet header, so a packet seen as 1485 bytes in Wireshark is 1471 bytes as far as the routers are concerned.
The network routers were configured to reject packets over the allowable limit of 1476 bytes and send a fragmentation request to the originator. This fragmentation mechanism was seen to be working for larger packets.
The 1485 (1471) byte packets were below the fragmentation threshold but were nonetheless being dropped in the network.

Investigation by the customer's network manager found that Path MTU Discovery on the 7200 routers was 'broken'. He believes that this is a bug in the Cisco IOS. PMTUD was turned off and that resolved the problem.


All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

If it's working, then leave it alone!.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top