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!

Capture RTP on CS1K phones

Status
Not open for further replies.

nortavaya

Technical User
Sep 20, 2006
415
MA
Hello team,

I have issue with some ip phones (1100 series) connected to the CS1K system, when they try to call from CS1K to IP Phones located on IP Office system (through SIP Trunk) the call rings, however no speech path

But some other phones work fine (from CS1K side), I checked everything between good and bad phones (FW, IP, ports, config, TN...etc) all configs are similar, the only thing different is the MAC address

I tried to capture RTP traffic from this phones, but I didn't got enough informations through mirrored port of 1100 phone

Do you have an idea from where I can have a complete RTP traces ? and perhaps what can be the issue ?

Thank you in advance
 
My guess is it could be an issue with the signal server they are registered to. If you have more than 1 signal server in the Node they should load share. It's possible that the phones that don't work are all registered to the same SS, just a guess though. Voice traffic is carried over the TLAN and call set up is carried over the ELAN, so I would start looking at the TLAN Subnet.
 
Thank you KCFLHRC for you reply, of corse we have two SS Server, the first one is located on the main site and the second on the GR site, also all IP Phones on the GR site are having this issue (no speech path)

But, on the IP configuration of all IP phones, we have already set S1 as primary SS and S2 as secondary

I will check how I can printout the ip phones registered by SS1 and SS2
 
There is NRS programming that has to be completed properly for the Geo Redundancy to work properly. Although it may sound silly the S1 IP at the Geo site should really be the SS at the Geo site and then NRS redirects it to the primary SS if it is reachable. You really shouldn't configure a S2. Don't shoot the messenger, but that is the way it is supposed to be done.
 
Thank you KCFLHRC, so you mean that the NRS configuration can be the issue ? however the call from GR site to the other site through SIP trunk works, it is just issue with speech path
 
in geo redundancy you are supposed to config S1 as the local SMG Node IP and S2 as the Main Site Node IP

The reason is like KCFLHRC say that it first registers with the S1 at the SMG and is then forwarded to the main site. If the S1 fails as the sig server is goosed at the SMG site for example, then after the number of configured time outs it will register direct to the main site using the S2.
 
log in to the SMG callserver and in LD 117 do a "stat ss" or "ecnt zone" and you should not see any registered sets. Or in the Sig Server at the SMG site do an "isetShow" which should also show no registered sets.

For example this is one of our SMGs

LD 117
=> ecnt zone 106
Zone: 106
Number of Registered Ethersets : 0
Number of Unregistered Ethersets : 5


And then the main site

=> ecnt zone 106
Zone: 106
Number of Registered Ethersets : 5
Number of Unregistered Ethersets : 0


=>
 
Actually the S2 shouldn't really be needed at all because S1 is the GEO Site and NRS routes it to the primary site. Then if the GEO site cant redirect to the main then it will automatically register to the GEO site. Like I said, NRS has to be set up properly for it to work properly.
 
And if the geo Sig server or call server are down for any reason sets won't register unless you config the s2
 
Hello, I don't think this issue is relating to the Geo configuration, because all ip sets are registered on the main Sig Server

To confirm this, I did a test by bringing IP Phone that was working fine on main site and when I connect it on the GR site network, we got the issue of dead air when calling over SIP Trunk

I suspect issue with network rules (Firewall, router...etc) configured between the GR site and IPO site, may they are blocking RTP streams

Because all GR site are having this issue of dead air, once we bring one phone from GR site and put it on the main site network, it works fine

 
Try running PCAP on your Sig Servers. This will capture all traffic on the TLAN. If the call is going out a SIP trunk the traffic will have to be routed via the SS.
 
Thanks aarondyck, I think is not necessary to run PCAP on the follower Sig Server, because all IP Phones will register on the Primary SS, hence we run PCAP only on this SS

However, how we demonstrate that the issue is not coming from CS1K system and it is from network side ?

I need to see only if traffics is going through SS ?

Note that the main site works fine, and GR site are having only issue with dead air (the phone rings, but no speech path)

Thank you
 
In all likelihood it is an issue with a firewall between the main and GR sites. By running pcap on your main SS And simultaneously running the port mirroring on the set you should be able to compare and see if there are any packets being dropped.

Strange question: If you leave the call up for 5-10 seconds does speechpath establish? I've seen this in the past where a firewall was dropping RTP on inbound calls across a WAN because the PBX sent an ICMP message that the endpoint isn't ready. This is documented on the Juniper web site. I couldn't find the Avaya solution that I published on this issue, it may not be publicly available. The Juniper solution can be seen at
 

Thanks for the details, even if we let the call up for more than 10s we still have issue

The issue is only when calling from GR site of CS1K to the IP Office system through SIP Trunk
However when we call from the main site of same CS1K to the IP Office site we don't have this issue

the reason why I suspect RTP dropping packets between GR site (CS1K) and IP Office site

thank you
 
I've been thinking further on this and I still think it's a network issue.

When a call is set up on a CS1000 SIP Trunk the system tries to do direct media path to the phone. There is probably a firewall rule in place that is dropping the RTP to the phone since there is no request originating from inside the GR Site firewall to the IP Office.

You can negate this by using a SIP Trunk Bridge ( however fixing the firewall rule to allow unsolicited traffic between the voice subnets at the GR site and the IPO Site would possibly fix the issue as well.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top