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 <shouldbeq...@googlemail.com>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 > <scott.lawre...@nortel.com> 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 sipx-users@list.sipfoundry.org > 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 sipx-users@list.sipfoundry.org 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/
