Re: [Asterisk-Users] [patch] fix libpri problem in Q931_INFORMATION handling
Peter Svensson wrote: What is c-ourcallstate set to at this time? Can you provide a debug log (pri intense debug span xxx) of the call? it's Q931_CALL_STATE_ACTIVE - that's what it should be after a call is established. Asterisk only expects INFORMATION elements when expecting overlap digits (i.e. before CONNECT, PROCEEDING etc). After that it expects digits as inline dtmf. Yep - but ISDN phones normally do not encode inline DTMF. Therefor Keypad information can be sent. According to Q.931 called party address IEs in the INFORMATION message should only be sent during overlap digit transmission, which ends when PROCEEDING is sent. Well I have read the Q.931 specification too but for eg. Siemens HiCom PBXs and phones use keypad IEs within a connected call and no DTMF. This leads me to at least invent a new configuration parameter for ignoring the call state when receiving such IEs. Any other ideas? Deti ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] [patch] fix libpri problem in Q931_INFORMATION handling
On Thu, 17 Feb 2005, Deti Fliegl wrote: Peter Svensson wrote: Asterisk only expects INFORMATION elements when expecting overlap digits (i.e. before CONNECT, PROCEEDING etc). After that it expects digits as inline dtmf. Yep - but ISDN phones normally do not encode inline DTMF. Therefor Keypad information can be sent. Ok, then INFORMATION with keypad IE needs to be handled differently from IE called number. According to Q.931 called party address IEs in the INFORMATION message should only be sent during overlap digit transmission, which ends when PROCEEDING is sent. Well I have read the Q.931 specification too but for eg. Siemens HiCom PBXs and phones use keypad IEs within a connected call and no DTMF. This leads me to at least invent a new configuration parameter for ignoring the call state when receiving such IEs. I read the ets 300 403 01 spec as well as a more reacent revision of the Q.931 spec. Q.931 allows the keypad IE to signal called party number (during call setup) or to convey supplementary service information (pushed digits similar to dtmf). Q.931 allows the called party number IE to signal called party digits during call setup. The EuroISDN spec. in ets 300 403 01 is stricter - the keypad IE can not be used for overlap digits, only after the call setup. Are the digits you send encoded as Keypad IE? In that case a setting to allow keypad IE digits to always be accepted as dtmf digits may be the best solution. Peter ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] [patch] fix libpri problem in Q931_INFORMATION handling
Peter Svensson wrote: Ok, then INFORMATION with keypad IE needs to be handled differently from IE called number. This is what it looks like with pri intense debug enabled: Informational frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 N(S): 116 0: 0 N(R): 126 P: 0 8 bytes of data -- ACKing all packets from 125 to (but not including) 126 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter Protocol Discriminator: Q.931 (8) len=8 Call Ref: len= 2 (reference 7/0x7) (Originator) Message type: INFORMATION (123) [2c 01 31] Keypad Facility (len= 3) [ 1 ] Feb 16 11:42:25 VERBOSE[2975]: [ 02 01 e8 fc 08 02 00 07 7b 2c 01 31 ] I read the ets 300 403 01 spec as well as a more reacent revision of the Q.931 spec. Q.931 allows the keypad IE to signal called party number (during call setup) or to convey supplementary service information (pushed digits similar to dtmf). Q.931 allows the called party number IE to signal called party digits during call setup. The EuroISDN spec. in ets 300 403 01 is stricter - the keypad IE can not be used for overlap digits, only after the call setup. Are the digits you send encoded as Keypad IE? In that case a setting to allow keypad IE digits to always be accepted as dtmf digits may be the best solution. see trace above. It's definitely a Keypad IE and its sent not as called party digits but instead of DTMF tones. This is imho the only way to make a Siemens HiCom PBX work with Asterisk Voicemail or IVR menus. I guess there are a couple of ISDN devices out there that act the same. Deti ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] [patch] fix libpri problem in Q931_INFORMATION handling
On Thu, 17 Feb 2005, Deti Fliegl wrote: Protocol Discriminator: Q.931 (8) len=8 Call Ref: len= 2 (reference 7/0x7) (Originator) Message type: INFORMATION (123) [2c 01 31] Keypad Facility (len= 3) [ 1 ] Feb 16 11:42:25 VERBOSE[2975]: [ 02 01 e8 fc 08 02 00 07 7b 2c 01 31 ] see trace above. It's definitely a Keypad IE and its sent not as called party digits but instead of DTMF tones. This is imho the only way to make a Siemens HiCom PBX work with Asterisk Voicemail or IVR menus. I guess there are a couple of ISDN devices out there that act the same. I think we agree that keypad elements may/should be passed as digits. Since this may or may not be desireable always and is a change from earlier behaviour then perhaps it should be an option? I *think* it would be ok to always pass keypad elements - it is the responsibility of an isdn device not to send both keypad and inband tones. I think it is best to only allow keypad elements always and leave called party elements disabled except during call setup. Peter ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] [patch] fix libpri problem in Q931_INFORMATION handling
On Wed, 16 Feb 2005, Deti Fliegl wrote: I tried to use Voicemail from a PRI interface but it didn't work because pressing a key on the ISDN phone just caused Q931_IE_KEYPAD_FACILITY messages which are normally handled by a bri-stuffed libpri. Unfortunately a wrong if condition stops keypad messages from being passed to the channel driver. The patch attached to this mail removes the 2 lines from the code. --- q931.c~ 2005-02-16 18:21:33.907803750 +0100 +++ q931.c 2005-02-16 18:21:33.909803485 +0100 @@ -2877,8 +2877,7 @@ q931_release_complete(pri,c,PRI_CAUSE_INVALID_CALL_REFERENCE); break; } - if (c-ourcallstate!=Q931_CALL_STATE_OVERLAP_RECEIVING) - break; + pri-ev.e = PRI_EVENT_INFO_RECEIVED; pri-ev.ring.call = c; pri-ev.ring.channel = c-channelno | (c-ds1no 8); What is c-ourcallstate set to at this time? Can you provide a debug log (pri intense debug span xxx) of the call? Asterisk only expects INFORMATION elements when expecting overlap digits (i.e. before CONNECT, PROCEEDING etc). After that it expects digits as inline dtmf. According to Q.931 called party address IEs in the INFORMATION message should only be sent during overlap digit transmission, which ends when PROCEEDING is sent. Peter ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
