Re: clarification needed

[Amit Bhayani]

Hi Arav,

This is known issue http://code.google.com/p/mobicents/issues/detail?id=3000

This will be fixed in CR3 release. Still need to do some analysis.

Amit. 

On Tue, Dec 20, 2011 at 6:47 AM, Aravindan G <aravi...@gmail.com> wrote:

Hi Amit,

Stumbled upon this use case when testing direct dialing of USSD String from Simulator like *123*2#

When this direct dialing string was used and dialed from the simulator , Ussd string parsed and given to SB comes as *123*2#@

I saw this problem at GSMCharsetEncoder.java

// The final one if total bits are not LCM of 8

//if (bitpos % 8 != 0) {

out.put((byte) (b & 0xFF));

//}

To over come this problem, i replaced GSMCharsetEncoder and Decoder in USSDStringimpl by JCharset and the jar is replaced both at Simulator and Gateway and now when i dial USSD String from Simulator as *123*2# it is coming to Parent SBB as *123*2# as the encoder and decoder are replaced but when i view the same via wireshark it is coming as different characters... this is not right...

Any pointers to the same would be appreciated

REgards

Arav

[Shilpa]

Hi Amit,

Checked the code in trunk.This issue is still seen.

This is because the string we are passing(*123*2#) is of length 7.

According to GSM 03.38 spec, packing for 8n-1 characters is different.

If the total number of characters to be sent equals (8n-1) where n=1,2,3 etc. then there are 7 spare bits at the end of the
message. To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the
carriage return or <CR> character (defined in subclause 7.1.1) shall be used for padding in this situation, just as for Cell
Broadcast.
If <CR> is intended to be the last character and the message (including the wanted <CR>) ends on an octet boundary,
then another <CR> must be added together with a padding bit 0. The receiving entity will perform the carriage return
function twice, but this will not result in misoperation as the definition of <CR> in subclause 7.1.1 is identical to the
definition of <CR><CR>.

We have fixed this issue by changing the GSMCharsetEncoder/GSMCharsetDecoder code to handle USSD messages.

Thanks,
Shilpa 

[Amit Bhayani]

Hi Shilpa,

Thanks for clarification. I tested this and agree that it still has @ at the end. It will be great if you can submit patch for GSMCharsetEncoder/GSMCharsetDecoder

Thanks and Regards,

Amit.

[Sergey Vetyutnev]

Hello!

I have understood the problem. Will fix this ussue.

We should remember that there are two different implementations of
GSMCharset in 1.x and in the trunk. First one is used only for USSD
encoding. The second one - for both SMS and USSD encoding (and CBS in
future). SMS and USSD have have two different styles of encoding. Only
when USSD we should add "<CR>" character as a padding. So we should
give to the GSMCharsetEncoder/GSMCharsetDecoder the extra option
"boolean USSDStyleEncoding" (in trunk). In 1.x we have only USSD-style
encoding and no extra options.

[Sergey Vetyutnev]

Hello Shilpa!

I have commited update both in trunk and 1.x. You can check it.

[Shilpa]

Tested with the code from trunk.The issue is fixed.