Rightfax over qsig outbound dialling

[splinkio]

We have installed rightfax over a qsig connection on a npra card. Works great inbound, sends via email to users desktops. However, using the faxutil client, trying to dial outbound, we are getting "phone line problem"

The system is setup so that a trunk group of 33 can be abdialed. Then the digits are pushed over the link, so the rightfax server can pick them up and use the DNIS to route it accordingly. 9 is a normal ARS overlapping trunk group seize, but for some reason, from the qsig connection i cant dial this.

Anyone else offer any advice ?

[tot3nkopf]

As I understand from your post you have OXE not OXO. See if you have Connection Category configured so that QSIG trunk may connect to public trunk. Also see if your QSIG trunk translator is automatic, if not see if you have configured 9 in your DDI translator (also put atrace on it to be sure that 9 is what it sends in front of public number)

Anyway if you have OXO:
check trunk joining (if over R5.0 try to put a trace on QSIG to see what it sennds to OXO)

Regards.

[splinkio]

yes sorry have oxe not oxo not looking where i was posting.

Have checked all that. This is the trace i get. I dont understand "locking shift. codeset : 5"

[ ______________________________________________________________________________
| (401547:000032) Physical-Event :
| long: 37 desti: 0 source: 0 cryst: 2 cpl: 24 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP [05] Call ref : 28 00
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 90 90 a3
| IE:[18] CHANNEL (l=3) a9 83 87 -> T2 : B channel 7 exclusive
| IE:[70] CALLED_NUMBER (l=6) -> 80 Num : 73499
| [a1] Sending complete
|______________________________________________________________________________

______________________________________________________________________________
| (401547:000033) 1324: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 2 cpl: 24 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CALL PROC (02) Call ref : a8 00
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3) a1 83 87 -> T2 : B channel 7 preferred
|______________________________________________________________________________

______________________________________________________________________________
| (401547:000034) 1324: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 26 desti: 0 source: 15 cryst: 2 cpl: 24 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : ALERT (01) Call ref : a8 00
|______________________________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 80 88
| [95] Locking shift. codeset : 5
| IE:[32] EI_PARTY_CATEGORY (l=1) -> EXTENSION (1)
|______________________________________________________________________________

______________________________________________________________________________
| (401547:000035) 1324: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 22 desti: 0 source: 15 cryst: 2 cpl: 24 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT (07) Call ref : a8 00
|______________________________________________________________________________
|
| [95] Locking shift. codeset : 5
| IE:[32] EI_PARTY_CATEGORY (l=1) -> EXTENSION (1)
|______________________________________________________________________________

______________________________________________________________________________
| (401549:000036) Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 2 cpl: 24 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT ACK (0f) Call ref : 28 00
|______________________________________________________________________________

______________________________________________________________________________
| (401631:000037) Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 2 cpl: 24 us: 0 term: 0 type a5
| tei: 0 >>>> message received : DISCONNECT [45] Call ref : 28 00
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 80 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________/i]


73499 is a physical extension on the same system which the npra card is connected to.

All other circuits which we have connected to over services have no problem dialling at all, and i dont think we get these messages.

Any idea would be cool

[tot3nkopf]

See if you can enable in your system to disregard (ignore) IE information messages it receives. search this forum. There are several posts about this topic.

Regards.