On Wednesday 01 March 2006 14:50, Tobias Richter wrote: > > I wasn't saying they were sending 'sending complete'. > But if the user types '[1][2][3][4][send]' the phone should send > '[1234]' as a block. The Beetel does '[1][2][3][4]'.
Uhm... ok, so, avoid saying "en-bloc", cause it has a very specific meaning in the ISDN specs. The phone behavior is fine, there is no requirement on how to group digits in INFO messages. In some situation vISDN behaves like that. In facts, certification tests do several combinations of SETUP/INFO messages to test overlap dialing. One test even verifies you can send up to 25 digits while the Called Party Number IE only supports 20 digits. Anyway, there is absolutely nothing wrong in the phone. > No. The timeout is useless in this case. An ordinary user, familiar with > GSM phones, will never type '[1][2][3][4][send][5]'. There is an IE specifically made to say to the network "Ok, I'm done" and it is "Sending Complete". As long as the phone does not send it, I can not assume the number is complete. There is no alternative, not in vISDN, neither in any other compliant ISDN complementation, you either write your dialplan with limited digits matches (this is what is done on every public network) or design/find as ISDN terminal which sends "Sending complete". > I see that this is not much of a problem to you, because you are > fine with your fixed length numbers. I'm not fine, but as long as most ISDN terminal do not send "sending complete", that is the ONLY solution. Implementing other heuristic behaviors will break standards compliance. Of course, the code is open, you are free to patch chan_visdn, it won't even be too difficult but your implementation will be non-compliant and our declaration of conformance will not apply. Bye, _______________________________________________ Visdn-hackers mailing list [email protected] https://mailman.uli.it/mailman/listinfo/visdn-hackers
