[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-20-2007 05:26 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)



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

---------------------------------------------------------------------- 
 worta - 08-20-07 05:26  
---------------------------------------------------------------------- 
Do you need the 'pri debug' from the very same trace? The HiPath trace was
done by a Siemens Technician and I'm unable to repeat it easily. 
But I can repeat the test and attach the asterisk trace only.

Our switchs expects (according to Siemens) the Invoke ID given in the
response packet of the ISOCallTransferCompl (2nd Call) to be related to the
first call's ID. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-20-07 05:26  worta          Note Added: 0069077                          
======================================================================