Reg. How client receives SMS PUD

Reg. How client receives SMS PUD

[=?unknown-8bit?b?4LC44LCk4LGN4LCvIOCwleCwv+Cwt+Cxi+CwsOCxjQ==?=]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Hi all,

oFono stack decodes the incoming PDU. Is there any option that client can
receive the direct PDU from oFono with out processing (i.e. decoding).

If such option available, how can I achieve this.

Similarly in case sending message oFono will form (encode) the PDU based on
the data passed to it. Instead is there any possibility that client can form
the PDU and send it to oFono stack ?


Thanks,
Satya.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 453 bytes --]

Re: Reg. How client receives SMS PUD

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Hi Satya,

> Hi all,
> 
> oFono stack decodes the incoming PDU. Is there any option that client can
> receive the direct PDU from oFono with out processing (i.e. decoding).

This feature is only planned for reception of SMS Application Source / 
Destination port addressing PDUs.  oFono will not support this for regular 
text messages.  What use case do you have in mind here?

> 
> If such option available, how can I achieve this.
> 
> Similarly in case sending message oFono will form (encode) the PDU based on
> the data passed to it. Instead is there any possibility that client can
>  form the PDU and send it to oFono stack ?

There's no way to submit a PDU directly to oFono.  If you want to send 
arbitrary PDUs then you'll need to extend the sms atom API and write a plugin 
to do so.

For both of these topics, please see the oFono TODO file (SMS section) for our 
plans in this area.

Regards,
-Denis

How about offering a raw way for SMS

[Zhang, Caiwen]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Hi all,

Ofono stack encodes SMS before send it.  User may need send some special
SMS. Such as send a v-card via SMS. 

It need to add user data header to indicate it is a v-card. Ofono
currently does not support this feature. How about 

offering an API for user to sending raw PDU directly?  such as:

         void SendRawMessage(string pdu)

So,  user can encode it by himself and send the PDU. It can also applied
to sending message with validity period/status report 

requirement and so on.

 

Similarly,  how about sending out the raw PDU when dispatch incoming
message?  There are many kinds of

SMS, such as voice mail notification, MMS notification, push mail
notification etc.  How about sending out the raw 

PDU to upper layer and depending on upper layer to decode and decide how
to process it? 

 

Thanks,

Caiwen








[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2274 bytes --]

Re: How about offering a raw way for SMS

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

Hi Caiwen,

please don't piggy-back on other threads. For new questions/discussion,
please start a brand new thread.

> Ofono stack encodes SMS before send it.  User may need send some
> special SMS. Such as send a v-card via SMS. 
> 
> It need to add user data header to indicate it is a v-card. Ofono
> currently does not support this feature. How about 
> 
> offering an API for user to sending raw PDU directly?  such as:
> 
>          void SendRawMessage(string pdu)
> 
> So,  user can encode it by himself and send the PDU. It can also
> applied to sending message with validity period/status report 
> 
> requirement and so on.
> 
>  
> 
> Similarly,  how about sending out the raw PDU
> when dispatch incoming message?  There are many kinds of
> 
> SMS, such as voice mail notification, MMS notification, push mail
> notification etc.  How about sending out the raw 
> 
> PDU to upper layer and depending on upper layer to decode and decide
> how to process it? 

this is exactly what we NOT wanna do. There will be one entity that does
PDU encoding and decoding and this will be oFono. The reason behind this
is that keeping copies of PDU encoder/decoder around in every single
application is pretty much a really bad idea. We want it in one central
place with a large set of unit tests and proper long term testing. This
helps improving quality and ensures security and stability.

Having upper layers dealing with raw PDU is a design mistake that has
been made in the past way too many times. And this stops with oFono now.

So if you wanna send vCards or something similar, then you need to
extend oFono with interfaces to send vCards. Same goes for receiving
functionality.

Regards

Marcel