Nortel 2-Way audio issues with Rauland
Moderator: Brekeke Support Team
-
- Posts: 13
- Joined: Fri Jul 10, 2009 6:39 am
- Location: Indiana
Nortel 2-Way audio issues with Rauland
1. Brekeke Product Name and version:Brekeke SIP Server/2.3.8.2/286
2. Java version:1.6.0_16
3. OS type and the version:Windows 2003 R2
4. UA (phone), gateway or other hardware/software involved:
Rauland Responder 5/ Nortel CS1k
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :
6. Your problem:
our deployment appeared to work without issue until a couple of months ago. now we have instances where only maybe 3 calls out of a 50 placed to the system will attain full 2-way audio. in the instances where the calls are not attaining 2-way audio, the brekeke SIP server will send the RTP packets to the appropriate target IP but they never hear the audio on the handset, and i never see any RTP traffic coming back from the handset.
In addition, i am routing the RTP traffic through the SIP server. so i have the RTP Relay set to "on" globally.
Here are my plans prior to the troubleshooting:
Pattern 1:
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4});.*@
[Deploy]
To=sip:%1%2@x.x.x.x
Pattern 2
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4})([0-9]{1,2});.*@
[Deploy]
To=sip:%1%2*%3@x.x.x.x
Tried making changes to the dial plan per Wiki Suggestions
Pattern 1
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4});.*@
[Deploy]
To=sip:%1%2@x.x.x.x
&net.sip.replacesdp.multipart=true
Pattern 2
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4})([0-9]{1,2});.*@
[Deploy]
To=sip:%1%2*%3@x.x.x.x
&net.sip.replacesdp.multipart=true
I also noticed the the &net.sip.replacesdp.multipart=true comes up as "red" in the dial plans screen when every thing else always shows up blue.
If needed i can post the wireshark captures.
Thanks,
Brad
2. Java version:1.6.0_16
3. OS type and the version:Windows 2003 R2
4. UA (phone), gateway or other hardware/software involved:
Rauland Responder 5/ Nortel CS1k
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :
6. Your problem:
our deployment appeared to work without issue until a couple of months ago. now we have instances where only maybe 3 calls out of a 50 placed to the system will attain full 2-way audio. in the instances where the calls are not attaining 2-way audio, the brekeke SIP server will send the RTP packets to the appropriate target IP but they never hear the audio on the handset, and i never see any RTP traffic coming back from the handset.
In addition, i am routing the RTP traffic through the SIP server. so i have the RTP Relay set to "on" globally.
Here are my plans prior to the troubleshooting:
Pattern 1:
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4});.*@
[Deploy]
To=sip:%1%2@x.x.x.x
Pattern 2
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4})([0-9]{1,2});.*@
[Deploy]
To=sip:%1%2*%3@x.x.x.x
Tried making changes to the dial plan per Wiki Suggestions
Pattern 1
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4});.*@
[Deploy]
To=sip:%1%2@x.x.x.x
&net.sip.replacesdp.multipart=true
Pattern 2
[Matching]
$request=^INVITE
To=sip:([0-9]{3})([0-9]{4})([0-9]{1,2});.*@
[Deploy]
To=sip:%1%2*%3@x.x.x.x
&net.sip.replacesdp.multipart=true
I also noticed the the &net.sip.replacesdp.multipart=true comes up as "red" in the dial plans screen when every thing else always shows up blue.
If needed i can post the wireshark captures.
Thanks,
Brad
is there any typing mistake in the &net.sip.replacesdp.multipart?
maybe update to latest version?
if capture packets at handset side, can you see the rtp packets coming from brekeke?
if client is behind NAT, check section6.2 at http://www.brekeke-sip.com/download/bss ... min_en.pdf
maybe update to latest version?
if capture packets at handset side, can you see the rtp packets coming from brekeke?
if client is behind NAT, check section6.2 at http://www.brekeke-sip.com/download/bss ... min_en.pdf
-
- Posts: 13
- Joined: Fri Jul 10, 2009 6:39 am
- Location: Indiana
The &net.sip.replacesdp.multipart as posted is the copy/paste from brekeke. I am not able to attain the packets from the handset side currently. Client is not behind a NAT. any thoughts of why a call may work fine with 2-way audio every 20 calls or so? the SIP setup never fails, it is only the RTP issue.
is there firewall or anti-virus program running or connect with brekeke server and is there enough port open for rtp? default brekeke rtp ports are 10000-10999. have you change rtp port range?
is brekeke server mem/cpu usage high when making 50 calls?
is brekeke server mem/cpu usage high when making 50 calls?
it seems brekeke sent rtp packets to handset ip:port. is it the correct ip and port which handset used for rtp?n the instances where the calls are not attaining 2-way audio, the brekeke SIP server will send the RTP packets to the appropriate target IP but they never hear the audio on the handset, and i never see any RTP traffic coming back from the handset.
-
- Posts: 13
- Joined: Fri Jul 10, 2009 6:39 am
- Location: Indiana
ports 10000-10999 are available on the server.
in addition, i forgot to mention in my initial post, i am able to successfully connect to my room's endpoints every time with 2-way audio if i use x-lite connected to the BBS.
mem/cpu is not high we making making calls. the 50 calls are performed one right after another so there isn't too much actual traffic on the server. also, the destination IP:port are correct.
I am told by the customers Nortel support that the calls that are not successfully establishing 2-way audio, that the CS1K's trace states that no-law was specified. However, i know for a fact based on the SIP packets and RTP packets we negotiate for PCMU and are sending PCMU. Nortel support thought we were sending 30ms rtp packets on those based on there trace logs.
The random calls that worked the call trace on the CS1K stated u-Law and 10ms rtp packets.
in addition, i forgot to mention in my initial post, i am able to successfully connect to my room's endpoints every time with 2-way audio if i use x-lite connected to the BBS.
mem/cpu is not high we making making calls. the 50 calls are performed one right after another so there isn't too much actual traffic on the server. also, the destination IP:port are correct.
I am told by the customers Nortel support that the calls that are not successfully establishing 2-way audio, that the CS1K's trace states that no-law was specified. However, i know for a fact based on the SIP packets and RTP packets we negotiate for PCMU and are sending PCMU. Nortel support thought we were sending 30ms rtp packets on those based on there trace logs.
The random calls that worked the call trace on the CS1K stated u-Law and 10ms rtp packets.
I was wondering if the poster had resolved this issue. We are currently experiencing the same issue except that we are not getting two-way audio on any of the calls from the hand sets to the system.
We are able to establish two-way audio both to the Nortel phones and the Rauland end points from X-lite, registered through Brekeke.
We are able to establish two-way audio both to the Nortel phones and the Rauland end points from X-lite, registered through Brekeke.
We have RTP Relay set to ON.
We are attempting to call back the Rauland end points (staff station, bed station) from Avaya 6120 handhelds and Avaya 1120 desk phones. The Rauland end points acknowledge the call, but do not establish the audio connection between the station and Avaya devices.
We have tried calling the stations using X-lite and are able to establish the two-way audio. We are also able to get the audio calling the handhelds and desk phones using X-lite.
The behavior is the same as experienced by the original poster, except that we are unable to any calls to establish audio between the Avaya devices and the Rauland end points.
We are also pursuing a response from Rauland.
We are attempting to call back the Rauland end points (staff station, bed station) from Avaya 6120 handhelds and Avaya 1120 desk phones. The Rauland end points acknowledge the call, but do not establish the audio connection between the station and Avaya devices.
We have tried calling the stations using X-lite and are able to establish the two-way audio. We are also able to get the audio calling the handhelds and desk phones using X-lite.
The behavior is the same as experienced by the original poster, except that we are unable to any calls to establish audio between the Avaya devices and the Rauland end points.
We are also pursuing a response from Rauland.
The PBX is an Avaya CS1000E (Formerly Nortel CS1000E). The sets are Avaya 6120 (Nortel 6120), and Avaya 1120E (Nortel 1120E). It is a standalone Siginalling server installed with the SIP gateway application. They are not registering anything through NRS, so the Avaya (Nortel) Sip gateway is pointed to the BSS server , Like the SIP-UA setup on Wiki.
All the Equipment is Nortel, Just rebranded Avaya due to the buy out. This is NOT an Avaya Call manager setup.
All devices are within different subnets, but all have the appropriate mask for there respective subnets.
Although calls from the handsets to the Nurse Call devices connect and we cannot hear audio in either direction, we can decode the rtp packets in wireshark and hear the audio from the NC device.
In tracing calls from the PBX side, calls to xlite work and connect with G.711 MU-LAW PAYLOAD 20Ms, calls to NC device connect with G.711 NO_LAW PAYLOAD 30Ms
Any Help would be greatly Appreciated.
All the Equipment is Nortel, Just rebranded Avaya due to the buy out. This is NOT an Avaya Call manager setup.
All devices are within different subnets, but all have the appropriate mask for there respective subnets.
Although calls from the handsets to the Nurse Call devices connect and we cannot hear audio in either direction, we can decode the rtp packets in wireshark and hear the audio from the NC device.
In tracing calls from the PBX side, calls to xlite work and connect with G.711 MU-LAW PAYLOAD 20Ms, calls to NC device connect with G.711 NO_LAW PAYLOAD 30Ms
Any Help would be greatly Appreciated.
No, Rauland is 20ms. Turns out we needed to set $session to SDP and sdp.audio.a.1 to ptime:20.
In case it helps anyone, our deploy plan wound up being:
To=sip:%1*%2*%3@
$auth=false
&net.sip.replacesdp.multipart=true
$session=sdp
&sdp.audio.a.1=ptime:20
This inserted the asterisks where we needed them and set the session and payload appropriately.
Props to tech support and our Avaya support for the help.[/b]
In case it helps anyone, our deploy plan wound up being:
To=sip:%1*%2*%3@
$auth=false
&net.sip.replacesdp.multipart=true
$session=sdp
&sdp.audio.a.1=ptime:20
This inserted the asterisks where we needed them and set the session and payload appropriately.
Props to tech support and our Avaya support for the help.[/b]