Base64 messages

[kent]

Anybody seen this? Appears to have only happed to one user (myself). I just deleted the user and recreated to fix. The message would be converted to Base64 from getmail or from using the PGadmin. I plan to install the latest updates this weekend but wondered if this has ever been seen before. Also if I change d to a TAP carrier, it would send correctly.

3/7/2006 10:13:39 AM Start connection to carrier: ARCHTEST
3/7/2006 10:13:39 AM Send using WCTP protocol
3/7/2006 10:13:39 AM ----------------------------------------
3/7/2006 10:13:39 AM Working on message to: wkwicker from: a
3/7/2006 10:13:39 AM Formatting message
3/7/2006 10:13:39 AM Message contained in single packet
3/7/2006 10:13:39 AM Sending message to wctp.arch.com/wctp
3/7/2006 10:13:39 AM Sent:
3/7/2006 10:13:39 AM <?xml version="1.0"?>
3/7/2006 10:13:39 AM <!DOCTYPE wctp-Operation SYSTEM "http://dtd.wctp.org/wctp-dtd-v1r1.dtd">
3/7/2006 10:13:39 AM <wctp-Operation wctpVersion="wctp-dtd-v1r1">
3/7/2006 10:13:39 AM <wctp-SubmitClientMessage>
3/7/2006 10:13:39 AM <wctp-SubmitClientHeader submitTimestamp="2006-03-07T15:13:39">
3/7/2006 10:13:39 AM <wctp-ClientOriginator senderID="a@pager.santeec**per.com" />
3/7/2006 10:13:39 AM <wctp-ClientMessageControl preformatted="true" />
3/7/2006 10:13:39 AM <wctp-Recipient recipientID="843********" />
3/7/2006 10:13:39 AM </wctp-SubmitClientHeader>
3/7/2006 10:13:39 AM <wctp-Payload>
[b]3/7/2006 10:13:39 AM <wctp-TransparentData encoding="base64">MTQwMDphOmE=</wctp-TransparentData>
3/7/2006 10:13:39 AM </wctp-Payload>
[/b]3/7/2006 10:13:39 AM </wctp-SubmitClientMessage>
3/7/2006 10:13:39 AM </wctp-Operation>
3/7/2006 10:13:40 AM Received:
3/7/2006 10:13:40 AM <?xml version="1.0"?>
3/7/2006 10:13:40 AM <!DOCTYPE wctp-Operation SYSTEM "http://wctp.arch.com/DTD/wctpv1-0.dtd">
3/7/2006 10:13:40 AM <wctp-Operation wctpVersion="1.0">
3/7/2006 10:13:40 AM <wctp-SubmitClientResponse>
3/7/2006 10:13:40 AM <wctp-ClientSuccess successCode="200" successText="Accepted" trackingNumber="0000000000">
3/7/2006 10:13:40 AM Your message for 8437280100 has been accepted for delivery.
3/7/2006 10:13:40 AM </wctp-ClientSuccess>
3/7/2006 10:13:40 AM </wctp-SubmitClientResponse>
3/7/2006 10:13:40 AM </wctp-Operation>
3/7/2006 10:13:40 AM Message sent
3/7/2006 10:13:40 AM SUCCESSFUL Stn:0 To:wkwicker Frm:a Msg:a
3/7/2006 10:14:57 AM Module Stopped
3/7/2006 10:15:28 AM Module Started
3/7/2006 10:15:29 AM Time synchronized with scheduler

[Tech Support]

PageGate will automatically deliver messages via WCTP encoded in Base64 if there are characters in the message that can't be sent transparently (mostly control characters). The whole Base64 thing should be transparent to the sender and the receiver of the messages. Are you seeing problems?

If you want to ensure messages aren't encoded, check the 'Drop non-printable characters' option on the recipient in question.

[kent]

The checkbox was checked to drop unprintable characters. Also I'm not sure how the special characters got in there, I just typed them into PGadmin. Sending a message to another user on the same carrier would work fine.

And yes, I was seeing problems. The messages on my pager were actually in B64 such as "MTQwMjprZW500m11c3NhZ2U=" but perhaps Arch doens't convert it to plain text.

I have all users temporally using TAP until I can apply the update to resolve another issue I was having. As I said before, I deleted\recreated the user and the problem went away. I was wondering how this happens and if it may happen to other users when I switch them back to WCTP as the problem first occured to my user when I switched from TAP to the WCTP carrier.

[Tech Support]

I double-checked, and if either the carrier or the recipient has 'Drop non-printable characters' checked, then the messages should never go out with Base64 encoding. In any case, Arch should be decoding the message on their end.

Best I can tell, either the upgrade will solve your problem, or the recipient was somehow corrupt. Give it a test after you upgrade, and if you still see any unusual behavior, please get back with us.