[Home]

Summary:ASTERISK-01832: Asterisk not sending "Sending Complete" on EuroISDN overlap span
Reporter:Steve Hanselman (shanselman)Labels:
Date Opened:2004-06-15 15:38:26Date Closed:2011-06-07 14:10:29
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) pritrace.txt
Description:Using the latest versions of asterisk, zaptel and libpri Asterisk is not sending the IE "Sending Complete" when making calls on EuroISDN spans that are set to overlap.

Attached is a trace of the call, and here is the pri show span:

Linux3*CLI> pri show span 2                                                                                                        
Primary D-channel: 47
Status: Provisioned, Up, Active

Switchtype: EuroISDN
Type: Network
Window Length: 0/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: -1
Linux3*CLI>

****** ADDITIONAL INFORMATION ******

Looking at q931.c it would appear that is the switch is EuroISDN and overlap is enabled then this should be sent?
Comments:By: Mark Spencer (markster) 2004-06-15 16:36:53

We do *not* send sending complete when overlap dial is enabled.

Can you explain what symptom leads you to think this is a bug?
By: Steve Hanselman (shanselman) 2004-06-15 17:12:38

Without it the GDK phone system does not route internals calls.

And the trace from Telewest of it placing an inbound overlap call shows that it is sending "Sending Complete".
By: Steve Hanselman (shanselman) 2004-06-15 17:16:11

Sorry, typo, that should read "does not route DDI calls".
By: Steve Hanselman (shanselman) 2004-06-15 17:18:41

This is the code in q931.c that looks as though it would achieve this in my case?

static FUNC_SEND(transmit_sending_complete)
{
       if (!pri->overlapdial && ((pri->switchtype == PRI_SWITCH_EUROISDN_E1) ||
(pri->switchtype == PRI_SWITCH_EUROISDN_T1))) {
               /* Include this single-byte IE */
               return 1;
       }
       return 0;
}
By: Steve Hanselman (shanselman) 2004-06-15 17:19:44

Sorry, just noticed the not in front of overlapdial......
By: Steve Hanselman (shanselman) 2004-06-15 17:23:19

Assuming that the above code correctly reflects the Q.931 spec then it looks as though Telewest have provisioned the circuit wrong from day 1, but by fluke, combined with an LG Electronics bug it works, as the GDK-186 is certainly overlap dialling on its outbound calls.

I say this as the individual digits are all delivered in seperate information IE's.
By: Steve Hanselman (shanselman) 2004-06-15 18:25:45

I think I'm withdrawing this as a red herring, have I completely misunderstood the overlap setting in zapata.conf, is this solely to do with overlap sending by Asterisk, and regardless of this setting, Asterisk will support overlap receiving?

If this is the case then please close this and I will change my configuration tomorrow.
By: Mark Spencer (markster) 2004-06-15 20:14:45

So I have to ask, why not just turn off overlap dial?
By: Steve Hanselman (shanselman) 2004-06-16 01:44:38

As I said I'm going to change the config.
By: Steve Hanselman (shanselman) 2004-06-16 12:47:38

Ok, no go there, if overlap dialling is off then the GDK will correctly receive a call and route it, but cannot make outbound calls (the overlap setting is not configurable on the GDK), if overlap is on then the GDK can place outbound calls, but cannot receive them as it does not receive the "Sending Complete" in the setup frame.

The Telewest switch does send the IE, does somebody have a definiutive answer on the standard?

The change would be to differentiate OverlapSending from OverlapReceiving?
By: Steve Hanselman (shanselman) 2004-06-16 13:28:16

Ok, I've commented out the if in q931.c that stops "Sending Complete" from being sent as a quick fudge for me, this works, I can now make and receive calls on voip via the PRI and those calls can be routed to the GDK, and the GDK can make calls.

I'm missing the calling number on the GDK and the only difference I can now see is that the Progress Indicator IE is sent by Telewest but not by Asterisk?
By: Mark Spencer (markster) 2004-06-16 13:34:17

I've updated CVS (untested) such that you should be able to force the sending complete to put a "w" at the end of the dialstring.  You'll need very latest CVS head.
By: Steve Hanselman (shanselman) 2004-06-16 13:36:23

Thanks. I'll grab it now and test it now.
By: Steve Hanselman (shanselman) 2004-06-16 16:57:48

cvs still isn't reflecting the change, do I need to do something other than cvs update?
By: Mark Spencer (markster) 2004-06-16 20:26:26

Might need to wait a bit to get it to take effect.  It can take as much as 45 minutes to an hour for the mirrors to update.  Again, you will need to update both libpri and asterisk.  I just realized that we haven't been updating the mirrors today so that's now resolved and the first update should be in ~ 15 minutes.
By: Steve Hanselman (shanselman) 2004-06-17 03:17:11

Ok, chan_zap has now updated in CVS, but no updates onlibpri, I'll wait until this evening and try again as the circuit is now back on our production PBX.
By: Steve Hanselman (shanselman) 2004-06-17 08:04:56

libpri, asterisk and zaptel have all now updated, it's compiled and I'll check it this evening.

Any idea what needs to happen to get the progress indicator out?
I haven't looked at the code yet, I will shortly.
By: Steve Hanselman (shanselman) 2004-06-17 12:12:27

Just swapped over, can now place and receive calls from the gdk with eh w postfix on the dialled number, fantastic, thanks.

Do you want to open a seperate bug for the call progress?

Also, is there an online reference to Q.931 so I can see what's a bug and what's a curiosity of the GDK?
By: Mark Spencer (markster) 2004-06-17 14:28:04

What's the call progress issue?
By: Steve Hanselman (shanselman) 2004-06-17 16:27:06

Telewest is sending a progress indicator and asterisk isn't?
By: Mark Spencer (markster) 2004-06-18 00:03:40

That doesn't do me any good.  Can you explain in a bit more detail when you're expecting Asterisk to send a progress indicator and on what message?  if you're not sure, go find someone on irc that can help you get a clear description.
By: Steve Hanselman (shanselman) 2004-06-18 10:10:58

Let's close this one as it relates purely to the overlap sending complete, which is indeed fixed (thanks).

I'll look into the progress indicator properly and then open another if required.
By: Steve Hanselman (shanselman) 2005-04-07 04:39:08

The fix for this bug has been reversed in the last 24-48 hours, I'm searching through the CVS changes to see why.

Sending Complete is now no longer sent on an overlap span even with the w postfix.

edited on: 04-07-05 05:04
By: Paul Cadach (pcadach) 2005-04-07 05:02:47

This should be fixed by libpri, not at chan_zap. Currently if you have additional information to be sent to called party you shouldn't include "sending complete" IE except for EuroISDN, which should be checked by libpri.
By: Paul Cadach (pcadach) 2005-04-07 05:12:33

Try attached patch.
By: Steve Hanselman (shanselman) 2005-04-07 05:15:24

Just about to try that, where is the "w" postfix handled in the code, I can't find it?

I'm trying to see what has changed that actually reversed this as up until yesterday morning it was fine.
By: Paul Cadach (pcadach) 2005-04-07 05:36:08

Try cvs diff -r 1.425 -r 1.426 channels/chan_zap.c to see exact changes in chan_zap.c. There is call to pri_sr_set_called() where 3rd argument is to include or not to include "Sending Complete" IE on SETUP message. If you request overlap dialing (with 'w' within number to be called), so Sending Complete IE shouldn't be sent, and call will stay in address collecting state. For EuroISDN "Sending Complete" is required (i.e. overlap dialing isn't supported), so it should be checked and added by libpri level, what is done by attached patch.
By: Steve Hanselman (shanselman) 2005-04-07 05:45:29

Yep, that has fixed it, presume that this makes the "w" redundant on the numbers now?
By: Paul Cadach (pcadach) 2005-04-07 05:49:12

IMHO 'w' was redudant many days ago (about one year). At least I always have 'Sending complete' on SETUP messages and don't specifes any 'w' after a number...
By: Paul Cadach (pcadach) 2005-04-07 05:53:10

Oops. This patch is wrong (EuroISDN _ALLOWS_ overlap dialing, as specified by EN 300 403-1). Just remove 'w' and you should have the same functionality as with this patch.
By: Steve Hanselman (shanselman) 2005-04-07 06:21:53

It certainly seems to be working, we have a EuroISDN switch (a GDK) that uses overlap dialling when making calls (1 digit per info message), but requires the sending complete on receiving a call.
By: Paul Cadach (pcadach) 2005-04-07 06:40:14

Is your call scheme works without 'w'? I just want to close this ticket...
By: Steve Hanselman (shanselman) 2005-04-07 06:44:03

Yes, just removed the w's and it all still works as it should do, thanks.
By: Paul Cadach (pcadach) 2005-04-07 06:56:24

Configuration issue.
By: Steve Hanselman (shanselman) 2005-09-01 06:18:24

This functionality has been reversed again, on the latest CVS we no longer see the sending_cojmplete IE sent to our GDK system from asterisk.
By: Steve Davies . (stevedavies) 2005-09-01 07:07:30

Hi Mark et al,

The symptoms here are exactly the same as the ones with Rightfax that lead to me submitting bug ASTERISK-4649.

Does seem to be some combination of maybe bug and maybe config and maybe understanding.

But I still have a customer where a patch is needed to get Rightfax to see numbers sent by Asterisk.

Steve
By: Steve Hanselman (shanselman) 2005-09-01 07:15:55

Ok, the change came with rev 1.483 of chan_zap.c on the 7/Aug which reversed the sense of the "w" (this indicates that the call is complete).

I think the greater issue is the fact that even if (s) is true (*s) will always be zero as this code ensures that the w is changed to a string terminator and the pointer is moved on.....  why are we checking *s and s rather than just s?

if (p->sig != SIG_FXSKS) {
   p->dop.op = ZT_DIAL_OP_REPLACE;
   s = strchr(c + p->stripmsd, 'w');
   if (s) {
       if (strlen(s) > 1)
           snprintf(p->dop.dialstr, sizeof(p->dop.dialstr), "T%s", s);
       else
           p->dop.dialstr[0] = '\0';
       *s = '\0';   <---  
       s++;         <---
   } else {
       p->dop.dialstr[0] = '\0';
   }
I suspect that the previous change was because somebody was seeing the IE and didn't want to...

I think the simple change is this:

pri_sr_set_called(sr, c + p->stripmsd + dp_strip, pridialplan,  (s) ? 1 : 0);
By: Steve Hanselman (shanselman) 2005-09-01 07:21:48

Ok, I've made that change and it works as expected, terminate a number with "w" and the call will be marked as complete and the SENDING_COMPLETE IE will be sent, don't terminate it and it won't.
By: Steve Hanselman (shanselman) 2005-09-01 07:23:13

As an aside, the w is also a valid character for app_dial, is this an issue?
By: Michael Jerris (mikej) 2005-09-02 22:43:36

mattf-  Can you review this please.
By: Steve Davies . (stevedavies) 2005-09-05 03:18:30

I have a customer where Asterisk can't send calls to Rightfax on a PRI because number-complete is not signalled.

He has been running on a patch I supplied; I submitted that patch to Mantis and it briefly went in, but Mark reverted it as an incorrect fix.

Anyway - I asked my customer to test his setup with current cvs-head; he did so and reports that the number-complete is still not sent.

Here's his email:

-----------------------------------

Hi Steve,

Once again, no go... I tried with a "w" and a "W".... (and if I understand the bug tracker, then I need to pass the W at the end of the number, not as an option to dial)

(I am going to have to revert back to your patch)

<snip>

   -- Accepting call from '0832727727' to '2305' on channel 0/31, span 1
   -- Executing NoOp("Zap/31-1", "0832727727|2305") in new stack
   -- Executing Macro("Zap/31-1", "forward-pabx|2305|0832727727") in new stack
   -- Executing NoOp("Zap/31-1", "macro-forward-pabx=>2305:0832727727") in new stack
   -- Executing SetCallerPres("Zap/31-1", "allowed") in new stack
   -- Executing Dial("Zap/31-1", "Zap/r3/2305W||r") in new stack
-- Making new call for cr 32785
   -- Requested transfer capability: 0x00 - SPEECH
> Protocol Discriminator: Q.931 (8)  len=37
> Call Ref: len= 2 (reference 17/0x11) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                              Ext: 1  User information layer 1: A-Law (35)
> [18 03 a1 83 91]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 17 ]
> [6c 0c 00 83 30 38 33 32 37 32 37 37 32 37]
> Calling Number (len=14) [ Ext: 0  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)
>                           Presentation: Presentation allowed of network provided number (3) '0832727727' ]
> [70 06 80 32 33 30 35 57]
> Called Number (len= 8) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0) '2305W' ]
   -- Called r3/2305W
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 17/0x11) (Terminator)
< Message type: SETUP ACKNOWLEDGE (13)
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 17/0x11) (Terminator)
< Message type: CALL PROCEEDING (2)
   -- Zap/79-1 is proceeding passing it to Zap/31-1
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 17/0x11) (Terminator)
< Message type: ALERTING (1)
   -- Zap/79-1 is ringing
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 17/0x11) (Terminator)
< Message type: DISCONNECT (69)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
<                  Ext: 1  Cause: Unknown (16), class = Normal Event (1) ]
-- Processing IE 8 (cs0, Cause)
   -- Channel 0/17, span 3 got hangup request
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 17/0x11) (Originator)
> Message type: RELEASE (77)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Unknown (16), class = Normal Event (1) ]
   -- Hungup 'Zap/79-1'
 == No one is available to answer at this time (1:0/0/0)
   -- Executing Hangup("Zap/31-1", "") in new stack
   -- Hungup 'Zap/31-1'
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 17/0x11) (Terminator)
< Message type: RELEASE COMPLETE (90)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
<                  Ext: 1  Cause: Unknown (16), class = Normal Event (1) ]
-- Processing IE 8 (cs0, Cause)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
amber*CLI>
</snip>

-----------------------------------

By contrast, here's what happens with my patch:

-----------------------------------
<isdn trace of sending complete>
amber*CLI>
   -- Accepting call from '0832727727' to '2305' on channel 0/10, span 1
   -- Executing NoOp("Zap/10-1", "0832727727|2305") in new stack
   -- Executing Macro("Zap/10-1", "forward-pabx|2305|0832727727") in new stack
   -- Executing NoOp("Zap/10-1", "macro-forward-pabx=>2305:0832727727") in new stack
   -- Executing SetCallerPres("Zap/10-1", "allowed") in new stack
   -- Executing Dial("Zap/10-1", "Zap/r3/2305||r") in new stack
-- Making new call for cr 32771
   -- Requested transfer capability: 0x00 - SPEECH
> Protocol Discriminator: Q.931 (8)  len=37
> Call Ref: len= 2 (reference 3/0x3) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                              Ext: 1  User information layer 1: A-Law (35)
> [18 03 a1 83 82]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 2 ]
> [6c 0c 00 83 30 38 33 32 37 32 37 37 32 37]
> Calling Number (len=14) [ Ext: 0  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)
>                           Presentation: Presentation allowed of network provided number (3) '0832727727' ]
> [70 05 80 32 33 30 35]
> Called Number (len= 7) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0) '2305' ]
> [a1]
> Sending Complete (len= 1)
   -- Called r3/2305
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 3/0x3) (Terminator)
< Message type: CALL PROCEEDING (2)
   -- Zap/64-1 is proceeding passing it to Zap/10-1
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 3/0x3) (Terminator)
< Message type: ALERTING (1)
< [18 03 a9 83 82]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 2 ]
</isdn>
-----------------------------------

Thanks,
Steve
By: Paul Cadach (pcadach) 2005-09-05 06:23:37

Passing 'W' together with calling number is incorrect - check attached PRI trace, you shouldn't see 'W' at 'Calling number' IE.
By: Steve Hanselman (shanselman) 2005-09-05 06:27:24

It's a lower case w you need
e.g. number would be 01234w

Steve

Can one of the bugmasters commit this change to CVS or state why it's incorrect?

Thanks
By: Steve Davies . (stevedavies) 2005-09-05 06:58:42

Hi,

As my customer noted in his email, he tried both "w" and "W".  Unfortunately, the trace he sent was with the big W.

I did ask him for a trace with a small-w; he will send this evening and I'll post it.

Steve
By: Paul Cadach (pcadach) 2005-09-05 07:12:07

Stevedavies, please, post your traces as attachments, do not include them into note's body. Also, check related ticket(s).
By: Michael Jerris (mikej) 2005-09-05 08:32:23

This is a duplicate of 4771.  Which one needs to be closed?
By: Paul Cadach (pcadach) 2005-09-05 08:33:46

ASTERISK-4649 totally covers this issue.