Summary:ASTERISK-07356: q.931 FACILITY message with caller name in facility IE never sent from pri_net side
Reporter:Rolf Braun (rbraun)Labels:
Date Opened:2006-07-18 15:08:26Date Closed:2006-07-28 09:45:16
Versions:Frequency of
Environment:Attachments:( 0) patch-1.2.3
( 1) patch-svn
Description:There is code in libpri to send the caller name and possibly other data in a Facility IE in addition to the Display IE in the SETUP message. When operating as pri_net, libpri adds the facility IE to a pending FACILITY message rather than to the setup message, which I am told is correct. However, in many (most?) cases, the FACILITY message never gets sent.


The code to send the facility message from already queued APDUs is the function q931_facility(). It is called in a number of places explicitly (EECT and its dms100 counterpart in trunk, and AOC; it is also called when a SETUP ACKNOWLEDGE message is received. However, SETUP ACKNOWLEDGE is only sent, according to the Q.931 standard, to "indicate that call establishment has been initiated, but additional information may be required" (Q.931 05/98, p.23). As caller name is merely desired but not required the lack of it would not normally trigger a SETUP ACKNOWLEDGE message. Instead, the next message received is CALL PROCEEDING.

In testing against an upstream 5ESS switch running in National ISDN 2 mode, the FACILITY message with caller name is sent by the 5ESS in response to (or immediately after, in any case) the CALL PROCEEDING message. (The 5ESS behavior may actually be asynchronous as the telco waits for the "dip" to complete to get the caller name.) We needed libpri to do the same thing when operating as the network end, as the Avaya IP Office product expects caller name only in a facility IE within a FACILITY message. Patching libpri to send any pending FACILITY message in response to a CALL PROCEEDING message fixed our issues presenting caller name to the Avaya PBX. The enclosed patches accomplish this change for libpri 1.2.3 (our setup) and svn trunk; the only difference between the two is the line numbers.
Comments:By: Matthew Fredrickson (mattf) 2006-07-21 10:38:33

I'll commit this, but it needs to be disclaimed before I can do anything with it.

By: Serge Vecher (serge-v) 2006-07-21 11:04:10

rbraun: please see the bottom of this page http://bugs.digium.com/main_page.php and fax one of the disclaimer forms to Digium. Please confirm with a note here when done.

By: Rolf Braun (rbraun) 2006-07-27 17:02:25

disclaim.changes faxed today with a reference to this bug number. Let me know if you need anything else.

By: Matthew Fredrickson (mattf) 2006-07-28 09:45:16

Applied to trunk and 1.2