[asterisk-bugs] [LibPRI 0010321]: ISO Path Replacement (ANF-PR ) - InvoceID mismatch

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10321 
====================================================================== 
Reported By:                worta
Assigned To:                mattf
====================================================================== 
Project:                    LibPRI
Issue ID:                   10321
Category:                   General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.9  
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 438 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-27-2007 07:49 CDT
Last Modified:              08-31-2007 16:25 CDT
====================================================================== 
Summary:                    ISO Path Replacement (ANF-PR ) - InvoceID mismatch
Description: 
We're using libpri (438) with ANF-PR to connect our HiPath 4000 to Asterisk
1.4.9/ zaptel 1.4.4

Asterisk: pri_cpe, qsig 
HiPath4k: master, ecmav2

Path Replacement does not work because of a mismatched InvokeID, which
makes it unable for the HiPath to identify related calls. 

Call Flow is: HiPath(ext. 3892) => Asterisk => HiPath(ext. 5962)



====================================================================== 

---------------------------------------------------------------------- 
 mattf - 08-31-07 16:25  
---------------------------------------------------------------------- 
Ok, I have some more time to look at this.  I started going through the
documentation on this, and I have a few questions:

1.) Is this switch configured for ECMA style Q.SIG?  It looked like from
the trace that it was using ISO style Q.SIG.

2.) Second, the meaning of the return result (according to the ECMA
documentation) that you received says this about the meaning of that
result:

unrecognisedPDU -- signifies that the type of the APDU as evidenced by its
Type identifier, is not defined in clause 11.

Where clause 11 is the types of Rose components that are accepted.  This
is definitely an invoke APDU, so I can't see why that it would say that
unless perhaps your switch is configured for ISO Q.SIG instead of ECMA
Q.SIG, or perhaps the switch doesn't support this function. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-31-07 16:25  mattf          Note Added: 0069804                          
======================================================================