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!

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

E.129 vs Hunt groups on Avaya IPO 11.0.4 SP1

Status
Not open for further replies.
scifan

scifan

Technical User
Joined
Mar 12, 2018
Messages
59
Location
US
We have a hunt group for the receptionists at a school, there's a 500v2 expansion chassis at each school, 9608's in the office area's, and E.129's in classrooms. Primary SIP server is the local 500v2.

Call flows and results:

E.129 from another site calls into the hunt group and is transferred to an E.129 and the call terminates/drops in ~ 35 seconds.

E.129 from another site calls into the hunt group and is transferred to an 9608 and it works properly.

9608 from another site calls into the hunt group and is transferred to an E.129 and it works properly.

E.129 from another site calls the other E.129 user directly, and no problem.

I haven't yet tested this for every site, but I suspect this is the case for several sites, if not all of our sites.

This started manifesting after our upgrade from 10.1.x to 11.0.x. I have to think this has something to do with the E.129's being SIP devices.

Thoughts about what to look at that could be causing this issue?

 
Sort by date Sort by votes
There is a system option, but I don't remember it's name exactly. It is called something like "allow direct media in NAT sites".

Perhaps that helps even if it wouldn't exactly explain the the difference between direct and transferred calls. But that is something new in v11

IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
 
Upvote 0 Downvote
I'll take a look for that.

Thank you!

I should note that our 20 something sites are all inter-connected on leased single mode fiber, and the backbone is at 10GB. The network addressing is all private/internal addressing. There's no NAT involved.

(I didn't setup this system, I inherited it.)
 
Upvote 0 Downvote
Found the setting - under System, under the top level VoIP tab, under the VoIP sub tab.

Thank you again.
 
Upvote 0 Downvote
As mentioned... From the features description this setting shouldn't have any effect in your setup. Nevertheless it's a change in 11.0 and no one knows what side effects it has.

IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
 
Upvote 0 Downvote
Additional testing today revealed this:

E.129 (SIP@site1) -> 9608 (H.323@site2) -> E.129 (SIP@site2) fails after 35 seconds
E.129 (SIP@site1) -> 9608 (H.323@site1) -> E.129 (SIP@site1) works
E.129 (SIP@site1) -> 9608 (H.323@site2) -> E.129 (SIP@site1) works
E.129 (SIP@site1) -> E.129 (SIP@site2) works

Both sites have voice gateways

I'm uncertain how the call legs would run for this bit of phone calling.



 
Upvote 0 Downvote
If you use Fortigate firewalls, disable H323, RAS, and SIP helpers. Most other firewall (I believe) use a similar naming scheme.
 
Upvote 0 Downvote
I could understand how this could be a network issue though I don't think this was an issue prior to the upgrade from 10.1 -> 11.0. I find it interesting that a direct call sip to sip works fine, but a call that connects to an H.323 phone, and is then transferred will terminate after 35 seconds. Routing does play a role though because a call within the local subnet doesn't drop.

There are no firewall's involved with internal site connections, however there are ACL's on the routing switches. We're running fairly simple static routing between sites. There are no syslog entries related to the sip call's being rejected due to the ACL's. Note that while they're configured as separate sites, the various schools/sites are inter-connected via leased dark fiber that is used for longer range 10GB connections. I will say that I'm not 100% certain why we have voice gateway's at each site when there are no trunks connected anywhere but in the data center. I suspect this was there for some sort of redundancy, but without the external trunks I think it doesn't necessarily provide that survivability.

Do sip to sip calls go directly between phones - even at remote sites where there's IP connectivity?

Do SIP to H.323 calls terminate to a voice gateway.

If it does route through a voice gateway, would a sip to H.323 call that then is transferred to a sip phone still leverage the voice gateway? Or would it try to switch to a direct connection?

I tend to wonder if this issue would be positively affected by enabling "Allow Direct Media Path" for the various SCN lines in our voice gateways?


 
Upvote 0 Downvote
Direct Media Path is enabled at the extension level. That answers part of that question.
 
Upvote 0 Downvote
What phone firmware versions are you at? I just recalled that we had an issue on our own production system at the earlier releases of the 4.0 SIP firmware. Try updating to latest SIP firmware and see what happens. I would recommened doing the H323 firmware update while you're at it. 11.0.4.1 runs 4.0 SIP out of the box, will have to manually upload newest firmware.

EDIT: Issue being that intermittently, our SIP phones when attempting to connect calls via transfer or conference, when the button is pushed, the phone would quickly flash "Acuiring Service" before bringing up the user profile again, dropping both calls. It was about a 6/10 attempts would result in this.
 
Upvote 0 Downvote
@nutritional_info the OP is having issues with an E129, not a J129.
 
Upvote 0 Downvote
The E.129's are running: 1.25.2.52

When I capture traffic from the E.129 test phone in my office to the "remote" site, the call connects to the local voice gateway for the duration of the call.

I think I need to run another packet capture for the remote end.

The last 3 packets for the main call are:

Request: BYE SIP:2477@10.x.x.2:30005; transport=tcp
3005 -> 8522 [ACK]Seq=2807 Ack 3901 Win17620 Len=0
Receiver Report Goodbye

I need to figure out a reasonable way to run this test while down there capturing traffic.

Is there a way to turn on port mirror on the phone via the web interface? or is that only an option via the cfg.xml file?
 
Upvote 0 Downvote
The SDP part in the corresponding SIP packets should give you some insight what happens.

Also the (S)RTP streams window of SysMon can show you necessary information.

IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
 
Upvote 0 Downvote
I did notice that all of our SCN trunks/connections are configured with DMP disabled while the extensions have it enabled. I see in help that DMP is normally enabled by default, but it appears that for some reason it's been disabled on our system.

I'm tempted to test this situation with DMP enabled. The network acl's currently configured would allow for direct site to site IP phone connectivity.
 
Upvote 0 Downvote
After having read elsewhere in the forum that making changes to a line will cause the gateway to restart, that pretty much throws cold water on this idea - at least during production hours.

I tried disabling the DMP setting for both of my test E129 phones, and there was no change.

It's strange, it's kind of like the RTP stream gets setup and running, but the SIP handshake doesn't complete and the remote E129 hangs up the call.

Again, this is only when a transfer event happens, if it's a straight call E.129 - gateway - gateway -> E.129 everything's happy.

if the call involves a transfer something like E.129 - gateway - gateway - 9608 - xfer -> E.129 this is when things go sideways after ~ 35 seconds.
 
Upvote 0 Downvote
After jumping through hoops, Avaya has had us turn off "Re-Invite" on the phones that are being used for testing, and this appears to have "solved" this issue. This basically disables DMP for these phones.

*sigh*
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

DiscLight
  • Locked
  • Question Question
VOIP Cloud vs Avaya IPO 500v2
Replies
9
Views
2K
Menniss
Menniss
R
  • Locked
  • Question Question
calls unable to reject on avaya j series phones for IPO
Replies
10
Views
1K
derfloh
derfloh
B
  • Locked
  • Question Question
Avaya IPO Yealink BLF feature keys.
Replies
6
Views
686
PhonesTech
PhonesTech
somewacko2
  • Locked
  • Question Question
SIP Trunking and hunt groups
Replies
2
Views
664
Menniss
Menniss
JM2009
  • Question Question
Ipo500v2 r10.1 group hunt time
Replies
3
Views
190
IPOriface
IPOriface

Part and Inventory Search

Sponsor

Back
Top