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!

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

diversion on vpn

Status
Not open for further replies.

cnhui

Technical User
Aug 17, 2005
10
IT
hello,
i've a problem with diversion on no answer in vpn betwen two pbx; they are connected in q-sig for the first choice and in second on vpn. When a call in Q-SIG is diverted back(CDINI) for busy or no answer it'ok, but when in vpn only the busy diversion it's ok.
Anybody can help me ??

Thanks
 
The ROUTE parameter are:

<ROCAP:ROU=05;ROUTE CATEGORY DATA
ROU SEL TRM SERV NODG DIST DISL TRAF SIG BCAP
5 5110000010000010 5 2101000001 0 30 128 00141415 111100000031 101100

END

<RODAP:ROU=05;ROUTE DATA
ROU TYPE VARC VARI VARO FILTER
5 SL60 H'00000210 H'05480000 H'26810000 NO

END

<RODDP:DEST=822;EXTERNAL DESTINATION ROUTE DATA
DEST DRN ROU CHO CUST ADC TRC SRT NUMACK PRE
822 42 1606100000000251006000000 0 1 0
5 1 1505100000000252005000000 0 4 0

END
 
Hi

Have you made some trace in SLP60 at both end in the case it failed that could explain the probem?
 
Here are the traces of the slp60 on both end, i called from the 57473 the 55483 in VPN, but the CDINI on no answer didn't diverted the call.

CALLED PBX:

CALLING PARTY NUMBER IE:
Numbering Plan Identification: Private numbering plan
Type of Number: Unknown
Number Digits: 55483


IDNX SERVICE SELECTION IE:
Service Selection value: Template 0


PRIORITY ROUTING IE:
PRIR value: 0


TRANSIT COUNTER IE:
Transit Count Value: 0


SINGLE OCTET UUI IE:
Type of party: Digital Extension


CALLING CONNECTED NUMBER IE:
Numbering Plan Identification: Private numbering plan
Type of Number: Unknown
Presentation Indicator: Presentation Allowed
Spare Reserved
Screening Indicator: User provided, verified and passed
Calling Connected Number:36057473


CALLING CONNECTED NAME IE:
Display Presentation Rules: Presentation of field 1
Name Presentation Restriction: Name presentation allowed
Name 1: presidio 7

CALLING PBX:

Incoming Message: ALERTing
Call Reference: 16 12 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol




PROGRESS INDICATOR IE:
Coding Standard: CCITT standard
Location: Local private network e.g., PBX
Progress Description: Destination address is non-ISDN. Destination user equipment is non-ISDN equipment


PROGRESS INDICATOR IE:
Coding Standard: CCITT standard
Location: Remote local network
Progress Description: In-band information or an appropriate pattern is now available


UUI IE:
Protocol Discriminator: User Specific Protocol


SINGLE OCTET UUI IE:
Type of party: Digital Extension


CALLING CONNECTED NUMBER IE:
Numbering Plan Identification: Private numbering plan
Type of Number: Unknown
Presentation Indicator: Presentation Allowed
Spare Reserved
Screening Indicator: User provided, verified and passed
Calling Connected Number:55483


SINGLE OCTET UUI IE:
General Response:Acknowledge

Thanks
 
From the called party this should be the problem,but how can i resolve it?

Outgoing Message: USER INFOrmation
Call Reference: 6D 00 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

UUI IE:
Protocol Discriminator: User Specific Protocol


SINGLE OCTET UUI IE:
Type of party: Analog Extension


SPECIFIC FACILITY IE:
Service/Function: Call Diversion
Service Action/Diversion: Divert on No Reply


COMPLEMENTARY NUMBER IE:
Numbering Plan Identification: Private numbering plan
Type of Number: Local Number
Presentation Indicator: Restricted
Spare, Reserved
Screeing Indicator: User provided, verified and passed
Digits: 56060


CALLING CONNECTED NUMBER IE:
Numbering Plan Identification: Unknown
Type of Number: Unknown
Presentation Indicator: Presentation Restricted
Spare Reserved
Screening Indicator: User provided, verified and passed
Calling Connected Number:55483


SINGLE OCTET UUI IE:
General Response:Acknowledge


<<<<

13.51.10.520 00048 HWSW SIGNAL DLIDATALONG (H'0002)
FROM EQU NO 1-2-00-00
TO SLP60 (H'037B) EXE B IN LIM 001
WITH 0 1 2 3 4 5 6 7 8 9
000 H'01 H'00 H'08 H'02 H'6D H'00 H'7D H'08 H'02 H'82
010 H'E2 H'14 H'01 H'07 H'00 H'00 H'00 H'00 H'00 H'00
020 H'00 H'00



>>>>
Incoming Message: STATUS
Call Reference: 6D 00 (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

CAUSE IE:
Coding Standard: CCITT standard
Location: Local network
Cause Value: Protocol error
Cause Values, CCITT Standard: Message not compatible with call state or message


CALL STATE IE:
Coding Standard: CCITT standardized coding
Call State Value: Call Received

Thank you
 
Hi

It seems that to VPN provider does not accept the USER INFO message in receive call state
I don't know about your provider, but mine specify that USER INFO is accepted only in 2 cases, and none of them is regarding diversion on no answer.
It could also be a problem regarding the identification of the calling connected number, but I doubt regarding the cause of the release.

The best way is to request /// to remove the Message USER INFO in call state N4 ;
N4 mean that the network has receive and indication that the calling party is reached (ALERT) but no other answer (CONNECT, DISCONNECT, RELEASE...) has been received for a outgoing call.
This is tricky and I knew how to perform it in the past in the MESSAGESENCTRL table, but know ....if anybody else to how to perform, I would be great to refresh my memory and solve the problem of CNHUI
 
Hi,

i don't know if your problem is already solved.
as fouesnant already wrot the User Info Message is not supported from your provider. this is a very common behavior , at least in europe. the provider mostly don't support UUI2 . UUI2 is a user-user-service after the alerting. if you change the vari to =04480000, maybe you get success now with diversion on no answer.
but this will cause a new setup from the system where the diverted party is in! this causes also some different behaviors regarding the display info at the calling party side. there is no update about the diversion is executed, but it should be done.
good luck
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top