thread940-1459783
So, quite a late response to thread above, but thought i'd share this.
IP500v2 6.0.18 with 4 Channel SIP on Public IP from Orcon.
Tried trunk to trunk, via seq hunt group with user uncond fwd to external number.
Result, connects OK, RTP relay shows sys status, but no speech either way.
SO... added another trunk to system via different ITSP Orcacom, this time set sys SC for the external after hours call centre to be dialed via Orcacom registered trunk.
Result, connects and speech perfect. very good he says, that worked!
THEN... what happens if i set the Orcacom trunk destination the same as the Orcon trunk with the main number and dial it, hence trunk to trunk on same ITSP.
Result, connects shows for split second on Sys Status, speech is perfect, BUT this time, the call drops away from the Avaya Sys status, and continues happily.
SO. Orcon don't tie the RTP streams together at their end, they're happy for the RTP stream to go all the way to the CPE, get tied up in knots and firewalls and NAT perhaps? dunno?
Orcacom trunk/ITSP has the brains to know that the RTP has travelled all the way from exchange to CPE/Avaya, and come back again, so it makes the path shorter by bringing it all back to the exchange.
Hope that makes sense!? thoughts / comments/ explanations?!
Cheerio
Chris
So, quite a late response to thread above, but thought i'd share this.
IP500v2 6.0.18 with 4 Channel SIP on Public IP from Orcon.
Tried trunk to trunk, via seq hunt group with user uncond fwd to external number.
Result, connects OK, RTP relay shows sys status, but no speech either way.
SO... added another trunk to system via different ITSP Orcacom, this time set sys SC for the external after hours call centre to be dialed via Orcacom registered trunk.
Result, connects and speech perfect. very good he says, that worked!
THEN... what happens if i set the Orcacom trunk destination the same as the Orcon trunk with the main number and dial it, hence trunk to trunk on same ITSP.
Result, connects shows for split second on Sys Status, speech is perfect, BUT this time, the call drops away from the Avaya Sys status, and continues happily.
SO. Orcon don't tie the RTP streams together at their end, they're happy for the RTP stream to go all the way to the CPE, get tied up in knots and firewalls and NAT perhaps? dunno?
Orcacom trunk/ITSP has the brains to know that the RTP has travelled all the way from exchange to CPE/Avaya, and come back again, so it makes the path shorter by bringing it all back to the exchange.
Hope that makes sense!? thoughts / comments/ explanations?!
Cheerio
Chris