I'm going to repeat this to you again, on the receiving side you need to set:
You haven't set the a or p variable or whatever Description *SMS(queuename|[a][s])* *SMS(queuename|[s]|number|message)* *deprecated* a answer, i.e. send initial FSK packet. s act as service centre talking to a phone. On 4/18/07, Yuan LIU <[EMAIL PROTECTED]> wrote:
>From: Per Jessen <[EMAIL PROTECTED]> >Date: Wed, 18 Apr 2007 14:48:45 +0200 > >Per Jessen wrote: > > > Per Jessen wrote: > > > > OK, part of the confusion is now clearing up. But I'm not getting > > much further. When I try to send an SMS, I see the call going > > through, but no SMS is ever sent. > >This is a bit of what I see in the debug output: (this is sending a >longer message, protocol 2): > >P[ 2] --> caps:Speech pi:0 keypad: sending_complete:0 >P[ 2] --> None > -- mISDN/3-u54 answered Local/[EMAIL PROTECTED],2 > > Channel Local/[EMAIL PROTECTED],1 was answered. > > Launching SMS(0622100000|t) on Local/[EMAIL PROTECTED],1 >P[ 2] * IND: Got Fixup State:CONNECTED L3id:50012 > == Spawn extension (Internal, 0622100000, 2) exited non-zero >on 'Local/[EMAIL PROTECTED],2' >P[ 2] I IND :FACILITY oad:0434439000 dad:0622100000 pid:19 >state:CONNECTED >P[ 2] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:00622100000 >P[ 2] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0 >P[ 2] --> caps:Speech pi:0 keypad: sending_complete:0 >P[ 2] --> AOCD currency: currency:FR. amount:10 multiplier:1 >typeOfChargingInfo:-1220842403 >P[ 2] I IND :INFORMATION oad:0434439000 dad:0622100000 pid:19 >state:CONNECTED >P[ 2] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:00622100000 >P[ 2] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0 >P[ 2] --> caps:Speech pi:0 keypad: sending_complete:0 >P[ 2] --> None > -- SMS[-1] RX 93 00 6D > -- SMS[0] TX 10 98 96 00 10 01 00 00 11 06 00 00 00 00 00 00 00 12 >03 00 02 00 04 13 65 00 53 65 63 75 72 69 74 79 20 72 65 73 65 61 72 63 >68 65 72 73 20 68 61 76 65 20 74 72 61 63 65 64 20 73 70 61 6D 2D 73 65 >6E 64 69 6E 67 20 62 6F 74 6E 65 74 20 63 6C 69 65 6E 74 73 20 62 61 63 >6B 20 74 6F 20 6E 65 74 77 6F 72 6B 73 20 72 75 6E 20 62 79 20 74 68 65 >20 55 53 20 6D 69 6C 69 74 61 72 79 2E 17 01 00 01 18 0A 00 30 34 33 34 >34 33 39 30 30 30 1B 01 00 01 1C 03 00 00 00 00 E8 >P[ 2] I IND :DISCONNECT oad:0434439000 dad:0622100000 pid:19 >state:CONNECTED >P[ 2] --> channel:1 mode:TE cause:16 ocause:16 rad: cad:00622100000 >P[ 2] --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0 >P[ 2] --> caps:Speech pi:8 keypad: sending_complete:0 >P[ 2] --> org:1 nt:0, inbandavail:1 state:10 >P[ 2] --> queue_hangup > >In all the other examples I've come across on the 'net, there are multil >lines beginning "SMS[x] RX/TX .....". The operator seems to hang up on you. Good thing is, the operator is at least responding to your call and sending you that initial answer. This may sound bizarre but try the s option and operate in mttx mode. I vaguely remember seeing a comment about one operator does some role reversal. (May not be due to protocol 2.) If you have an extra channel to spare with (seems you do), can also try to set up a context to receive SMS so you know all your commands/dial plan are working before testing against operator. (I always test via SIP channel to simplify my debugging. You can do so, too.) Yuan Liu >/Per Jessen, Zürich _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
