Hi Tony, I don't have any phones connected to sipXecs. All of this has been from the Avaya system to sipXecs
I have started to document the configuration on the wiki http://sipx-wiki.calivia.com/index.php/HowTo_configure_Avaya_CM_5.1_with_sipX Cheers Arne On Mon, Oct 26, 2009 at 6:34 PM, Tony Graziano <[email protected]> wrote: > Stupid question for me to ask this late, but do both systems have the > ability to dial each other natively via dialplan and are setup as gateways > in each others system? Would that matter? > > On Mon, Oct 26, 2009 at 2:31 PM, shouldbe q931 <[email protected]> > wrote: >> >> well, a "list trace tac" showed more than I thought it would. Trunk 60 >> is the SIP trunk linking the Avaya to sipXecs >> >> list trace previous >> Page 1 >> >> LIST TRACE >> >> time data >> >> 18:21:58 Calling party station 6999 cid 0x175 >> 18:21:58 Calling Number & Name 6999 Arne 6999, XXXXXX >> 18:21:58 dial 6815 route:UDP|AAR >> 18:21:58 term trunk-group 60 cid 0x175 >> 18:21:58 dial 6815 route:UDP|AAR >> 18:21:58 route-pattern 60 preference 1 cid 0x175 >> 18:21:58 seize trunk-group 60 member 27 cid 0x175 >> 18:21:58 Calling Number & Name NO-CPNumber NO-CPName >> 18:21:58 Setup digits 6815 >> 18:21:58 Calling Number & Name NO-CPNumber Arne 6999, XXXXXX >> 18:21:58 Proceed trunk-group 60 member 27 cid 0x175 >> 18:21:58 G711A ss:off ps:20 rn:1/1 10.200.100.33:11722 10.201.1.6:2054 >> 18:21:58 xoip: fax:PT modem:PT tty:UK 10.201.1.6:2054 uid:0x50084 >> 18:21:58 active trunk-group 60 member 27 cid 0x175 >> 18:22:07 conf/tran hold trunk-group 60 member 27 cid 0x175 >> >> press CANCEL to quit -- press NEXT PAGE to continue >> >> list trace previous >> >> LIST TRACE >> >> time data >> 18:22:07 active trunk-group 60 member 27 cid 0x176 >> 18:22:07 dial 6812 route:UDP|AAR >> 18:22:07 term trunk-group 60 cid 0x176 >> 18:22:07 dial 6812 route:UDP|AAR >> 18:22:07 route-pattern 60 preference 1 cid 0x176 >> 18:22:07 seize trunk-group 60 member 28 cid 0x176 >> 18:22:07 Calling Number & Name NO-CPNumber NO-CPName >> 18:22:07 Setup digits 6812 >> 18:22:07 Calling Number & Name 6815 6815 >> 18:22:07 Proceed trunk-group 60 member 28 cid 0x176 >> 18:22:07 denial event 1220: Recovery on timer expiry D1=0x83003c >> D2=0x66 >> 18:22:07 idle trunk-group 60 member 28 cid 0x176 >> 18:22:07 unhold trunk-group 60 member 27 cid 0x175 >> 18:22:07 idle trunk-group 60 member 27 cid 0x175 >> 18:22:40 TRACE COMPLETE trunk-group 60 cid 0x0 >> >> >> Command successfully completed >> >> So, from what you said, its passing back the other "number", which the >> Avaya is seeing as a number, and routing it appropriately. The Avaya >> is trying it, but it fails... >> >> It also rather agrees with my previous, in that it means that the >> numbers used by the conference bridge will need to "dialable" by the >> Avaya system, but c'est la vie :-) >> >> Cheers >> >> Arne >> >> On Mon, Oct 26, 2009 at 5:25 PM, Scott Lawrence >> <[email protected]> wrote: >> > On Mon, 2009-10-26 at 16:59 +0000, shouldbe q931 wrote: >> >> Oh, bother. >> >> >> >> I didn't quite understand the "proxy" limitation before now, I was >> >> hoping to be able to run it as a reasonably contained conference >> >> bridge, but if it requires each conference to have an "extension >> >> number" that is directly "dialable" from the PBX, it's quite a >> >> limitation, at least until a conference module that has a "lobby" >> >> function is available. >> > >> > The conference doesn't have to be directly dialable as long as the Avaya >> > correctly implements the SIP routing based on the URL it is sent... read >> > on. >> > >> >> I am also a little confused, taking my previous example. >> >> >> >> I call 6810 - it goes to voicemail >> >> I call 6812 - it goes to the conference >> >> I call 6815 - then 6810 and it goes to voicemail >> >> I call 6815 - then 6812 and it fails >> >> >> >> It appears to be handling the two AA "transfers" differently, or is it >> >> that the call to voicemail isn't "redirected" ? >> > >> > Both transfers are done the same way with a REFER. The one that went to >> > the extension looked like a dialable number, but the one to the >> > conference was referred to an address that's constructed with the >> > conference name as the user part of the SIP URL. If your Avaya system >> > is not correctly sending that back to sipXecs (as the domain part of the >> > URL specified), then that could be the difference. >> > >> > Again - all this is speculative. You need to figure out where that call >> > went after the REFER was sent to the Avaya. It does not seem to have >> > been correctly sent back to the sipXecs system. >> > >> > >> > >> _______________________________________________ >> sipx-users mailing list [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >> sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
