[Asterisk-Dev] Re: [Asterisk-cvs] libpri q931.c,1.90,1.91

[dbruce at bananatel.com]

----- Original Message -----
From: <creslin at digium.com>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Friday, October 29, 2004 9:36 AM
Subject: Re: [Asterisk-Dev] Re: [Asterisk-cvs] libpri q931.c,1.90,1.91


> On Thu, Oct 28, 2004 at 05:46:03PM -0700, Kevin P. Fleming wrote:
> > creslin at digium.com wrote:
> >
> > >If you can test it for me :-)  I took it out because of some problems
that
> > >could be related to this that cropped up today.  If anybody else has
any
> > >problems
> > >I'd like to hear about it.
> >
> > Just tell me what I need to do... I've got an Asterisk connected to a
> > DMS-250 using NI-2, properly receiving Calling Name via Facility IE.
> > Even though my telco does allow me to get the CNAM database updated when
> > I assign DIDs, I'd like to be able supply Calling Name directly as well
> > (and I believe it is currently working, using a CVS HEAD pull from about
> > 6 weeks ago).
>
> I don't believe that we've had calling name over facility transmit
capability
> in CVS.  I just started working on this (and had to add the functions for
it)
> within the last couple of weeks.  But anyway, that's another matter...
>
> I need to find some documentation so that I can find out what switches
(NI2 in
> your case) support this type of message.  I'm just somewhat concerned what
a
> switch might do if I send it a facility IE w/ calling name in it and it
doesn't
> know what to do with it.  If you can find me some docs that tell me that
transmit
> of calling name information is supported in NI2 I'll add it back in.
>
> I am relatively certain that it works with Q.SIG, NI3, and 5ESS, but I'm
not
> certain about other switchtypes (including NI2).
>
> Matthew Fredrickson
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev


According to all the Q.931 documentation I have been able to find.. sending
an unrecognized invoke message should result in a response that is dictated
by the interpretation component: the switch should return a 'RESULT REJECT'
error message and continue the call (interpretation: discard unrecognized
invoke pdus) or disconnect the call (all other interpretations). If the call
is disconnected, you will get the result reject facility message immediately
followed by a disconnect or release message.

During the initial testing I did when I first implimented this, and
enquiries I made to the switch engineers for various providers and
manufacturers, I found that, for the caller name facility, the usual (and
pretty much universal) action taken is to ignore it with no indication.

In actual inplimentation though, the response from the switch is both
provider dependant and equipment manufacturer dependant. For example, the
current software load for a lucent 5ess switch will reject a
EnhancedExplicitEctExecute facility if it includes an interpretation
component (even though the specs say that the component is valid in this
context), and it will not return a response at all if it receives an invalid
caller name facility. BUT, the operation of the switch is dictated by the
individual service provider unique combination of perferences... and even
the switch engineers (for the provider and the manufacturer) may not know
the exact response to expect for a given set of commands. (it took two weeks
for the manufacturers engineers to discover why the
EnhancedExplicitEctExecute facility was failing with a RETURN_REJECT, then,
once fixed, another week to discover why the facility then gave a
RETURN_ERROR) The more features that a provider offers on the switch the
worse the problem gets... as many of the features interact with each
other...

IMHO... send the facility.... expect no return message... and ignore any
return message that we don't understand... and have a configuration option
to turn the function off completely.


Regards,

Derek Bruce
BananaTel Communications