×

Discussion Board

Page 1 of 13 1234567891011 ... LastLast
Results 1 to 15 of 186
  1. #1
    Registered User
    Join Date
    Jun 2004
    Posts
    1

    SyncML , OBEX over Bluetooth

    Hi All,
    I have seen some postings on this discussion boards, that some of you were successful in Syncing mobile with PC application with OBEX over Bluetooth.

    I'm interested in developing one such application .
    Can you please guide me how to go about this ?

    I have a BT USB dongle (WIDCOMM Stack). I have read the SyncMl OBEX binding spec, but don't have prior experience on BT.
    I'm intereseted in Using my application on PC as OBEX Client.

    If there is some reference code, It would be great.

    Regards,
    PVS

  2. #2
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    First you need a Nokia or a Sony Ericsson mobile phone which supports SyncML over OBEX. Currently these should be Nokia (3220, 6220,)? 6230, 6620, 6630, 6810, 6820, 7610, 9500 and Sony Ericsson K500, K700, S700, V800, Z1010. The Nokia 6650 and 7600 do not have it. Then you have to pair both devices and from the computer you have to browse for the SyncML Client Bluetooth profile. You might need to search for it with its UUID (or OBEX, RFCOMM or L2CAP UUID) explicitly as it is not in the public browsable group on some Nokia phones.

    Bind a serial port to this profile. Then you have to make an OBEX Connect as described within the SyncML OBEX Binding which contains very detailed examples at the end. Now you have to talk WBXML and send a Server Alerted Sync like this:
    Code:
    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
    <!DOCTYPE SyncML PUBLIC
    			'-//OMA//DTD SYNCML 1.1//EN'
    			'http://www.openmobilealliance.org/DTD/OMA-SyncML-RepPro-DTD-V1_1_2-20030505-D.dtd'
    >
    <!--
    	see SyncML Sync Protocol, version 1.1.2; chapter 13.1 Sync Alert
    -->
    <SyncML xmlns='SYNCML:SYNCML1.1'>
    	<SyncHdr>
    		<VerDTD>1.1</VerDTD>
    		<VerProto>SyncML/1.1</VerProto>
    		<SessionID>1</SessionID>
    		<MsgID>1</MsgID>
    		<Target>
    			<LocURI>/</LocURI>
    		</Target>
    		<Source>
    			<LocURI>GSM Remote ML</LocURI>
    		</Source>
    	</SyncHdr>
    	<SyncBody>
    		<Alert>
    			<CmdID>1</CmdID>
    			<Data>206</Data>
    			<Item>
    				<Source>
    					<LocURI>Contacts</LocURI>
    				</Source>
    				<Meta>
    					<Type xmlns='syncml:metinf'>text/x-vcard</Type>
    				</Meta>
    			</Item>
    		</Alert>
    		<Alert>
    			<CmdID>2</CmdID>
    			<Data>206</Data>
    			<Item>
    				<Source>
    					<LocURI>Events</LocURI>
    				</Source>
    				<Meta>
    					<Type xmlns='syncml:metinf'>text/x-vcalendar</Type>
    				</Meta>
    			</Item>
    		</Alert>
    		<Alert>
    			<CmdID>3</CmdID>
    			<Data>206</Data>
    			<Item>
    				<Source>
    					<LocURI>Notes</LocURI>
    				</Source>
    				<Meta>
    					<Type xmlns='syncml:metinf'>text/plain</Type>
    				</Meta>
    			</Item>
    		</Alert>
    		<Final/>
    	</SyncBody>
    </SyncML>
    See my webpage for its WBXML representation.
    The ‘Final’ element of the SyncML package must be within a End-of-body OBEX header. This seems to be one of the various bugs of the current Nokia SyncML OBEX server. These are all MIME types I know which work with these mobile phones. Note that the MIME types are case-sensitive within the SyncML client - again a bug of Nokia.

    If you have problems with SyncML, first start a search at the archive of its Yahoo group. A lot of problems (most with SyncML over HTTP) are discussed there already.
    Last edited by traud; 2007-09-20 at 08:20.

  3. #3
    Registered User
    Join Date
    Jun 2003
    Posts
    2
    traud,

    Could you list the exact order and values of the OBEX headers you are sending in the OBEX PUT and GET requests? I've tried sending PUT request in one or two packets, leaving some headers out etc., but I'm always receiving an error code 0xD0 (Internal server error) or 0xD3 (Service not available).

    If I send the request without final bit set (0x02), I get a return code 0x90 (Continue), but the reply to the final packet is 0xD0... if I send the same final packet twice, I might get a success response second time.

    Sending a GET packet always crashes Srcs application on the phone and I have to restart the Bluetooth service.

    Regards,
    samuli

  4. #4
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    I did not use more than described within the SyncML OBEX binding specifications. First I send a PUT with connection ID, type (application/vnd.syncml+wbxml) and length headers.

    Connection ID depends on the CONNECT response. If I get a connection ID there, it is on for the whole session. In SyncML you always have a connection ID but you want to code a OBEX client/server which is a technology neutral as possible. The length header is added always if the length of the data is known in advance. Again this has nothing to do with SyncML. The type header has to be set by your SyncML over OBEX engine! This is actually the whole SyncML related header. The PUT has no body/end-of-body because this behaviour is recommended by IrDA OBEX. You simply wait for a CONTINUE before you send masses of data chunks.

    After this I send a PUT with a body header only. The last PUT has a end-of-body - it contains the XML Final element. The IrDA OBEX specification suggests to send a PUT with an empty end-of-body header because this allows the OBEX server to ABORT the transfer at any time and an OBEX client knows it failed. Nokia has a bug here as far as I can tell, because you need the XML final element within the end-of-body header.

    Within a GET I have connection ID and type (application/vnd.syncml+wbxml) headers.

    Make sure your CONNECT was successful, you make a DISCONNECT with a connection ID and you are using the SyncML Bluetooth profile! If you need further help just ask.
    Last edited by traud; 2004-08-14 at 11:43.

  5. #5
    Registered User
    Join Date
    Jun 2003
    Posts
    2
    Hi traud,

    I had done everything you recommended, except sending the first PUT request without a body. Now I have tried that too. All requests give me a "continue" reply except the final one (0xD0).

    I can send PUT requests to Object Push and File Transfer services without any problems, but somehow SyncML related requests will fail. Ouch. I started to wonder if my WBXML code is somehow invalid and thus affecting the OBEX server behaviour (which it probably shouldn't, but...). On the other hand, every WBXML code I've tried has led to the same result. The phone I'm using is Nokia 7610.

    Anyway, thanks for your elaborate answer.

  6. #6
    Registered User
    Join Date
    Jul 2004
    Posts
    5

    SyncML , OBEX over Bluetooth

    I've been able to get a reply from the phone. The phone is now sending me SyncML in WBXML when i sent my request. Now the problem has moved to the GET request. This is waht I do:

    CONNECT req
    PUT req (connection id, type, len)
    PUT req (endofbody, high bit set)
    GET req (connection id, type)
    here the phone replies with a CONTINUE and an empty body
    GET req (connection id, type)
    here the phone replies with a CONTINUE and the body contains some SyncML
    GET req

    the phone hangs


    any suggestion ?

    Thanks
    Matteo

  7. #7
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    The OBEX Server of Nokia's SyncML seems not to be another OBEX server. Someone at Nokia seems to have a lot of time and did not understand enough of OBEX. If I recall it correctly I experienced problems within OBEX if my XML was wrong! My WBXML wasn't wrong yet. Should I post my WBXML in hexadecimal characters or do you want to post yours and I have a look onto it? You could even e-mail me your WBXML as binary.

    Great to know the Nokia 7610 has SyncML over OBEX too - I thought we would have to wait for Symbian OS 8.0. As far as I know the Nokia 7610 does not have mRouter anymore. Is that correct?

    @pelatimtt
    I am sending the connection id and the type (application/vnd.syncml+wbxml) every time although this should not be needed - but this was an old OBEX client implementation of myself which I reuse.

    What is within that partial SyncML - should be a lot already.

    Just for curiosity which phone do you use?

  8. #8
    Registered User
    Join Date
    Jul 2004
    Posts
    5

    SyncML , OBEX over Bluetooth

    I've now been able to get a reply from the phone when I send my GET request. My feeling is that the OBEX server sometimes hangs when the WBXML code is not correct.

    BTW, I'm now able to get a reply from the phone when I send my server alerted sync. This is what I get translated in XML

    <?xml version="1.0"?>
    <!DOCTYPE SyncML PUBLIC "-//SYNCML//DTD SyncML 1.1//EN" "http://www.syncml.org/docs/syncml_represent_v11_20020213.dtd">
    <SyncML xmlns="syncml:SYNCML1.1">
    <SyncHdr>
    <VerDTD>
    1.1
    </VerDTD>
    <VerProto>
    SyncML/1.1
    </VerProto>
    <SessionID>
    10
    </SessionID>
    <MsgID>
    1
    </MsgID>
    <Target>
    <LocURI>
    GSM Remote ML
    </LocURI>
    </Target>
    <Source>
    <LocURI>
    IMEI:352505003019058
    </LocURI>
    </Source>
    <Meta>
    <MaxMsgSize xmlns="syncml:metinf">
    3584
    </MaxMsgSize>
    </Meta>
    </SyncHdr>
    <SyncBody>
    <Status>
    <CmdID>
    1
    </CmdID>
    <MsgRef>
    1
    </MsgRef>
    <CmdRef>
    0
    </CmdRef>
    <Cmd>
    SyncHdr
    </Cmd>
    <TargetRef>
    IMEI:352505003019058
    </TargetRef>
    <SourceRef>
    GSM Remote ML
    </SourceRef>
    <Data>
    200
    </Data>
    </Status>
    <Status>
    <CmdID>
    2
    </CmdID>
    <MsgRef>
    1
    </MsgRef>
    <CmdRef>
    1
    </CmdRef>
    <Cmd>
    Alert
    </Cmd>
    <SourceRef>
    Contacts
    </SourceRef>
    <Data>
    200
    </Data>
    </Status>
    <Status>
    <CmdID>
    3
    </CmdID>
    <MsgRef>
    1
    </MsgRef>
    <CmdRef>
    2
    </CmdRef>
    <Cmd>
    Alert
    </Cmd>
    <SourceRef>
    Events
    </SourceRef>
    <Data>
    200
    </Data>
    </Status>
    <Status>
    <CmdID>
    4
    </CmdID>
    <MsgRef>
    1
    </MsgRef>
    <CmdRef>
    3
    </CmdRef>
    <Cmd>
    Alert
    </Cmd>
    <SourceRef>
    Notes
    </SourceRef>
    <Data>
    200
    </Data>
    </Status>
    <Alert>
    <CmdID>
    5
    </CmdID>
    <Data>
    201
    </Data>
    <Item>
    <Target>
    <LocURI>
    Contacts
    </LocURI>
    </Target>
    <Source>
    <LocURI>
    /telecom/pb.vcf
    </LocURI>
    </Source>
    <Meta>
    <Anchor xmlns="syncml:metinf">
    <Last>
    0
    </Last>
    <Next>
    15
    </Next>
    </Anchor>
    </Meta>
    </Item>
    </Alert>
    <Alert>
    <CmdID>
    6
    </CmdID>
    <Data>
    201
    </Data>
    <Item>
    <Target>
    <LocURI>
    Events
    </LocURI>
    </Target>
    <Source>
    <LocURI>
    /telecom/cal.vcs
    </LocURI>
    </Source>
    <Meta>
    <Anchor xmlns="syncml:metinf">
    <Last>
    0
    </Last>
    <Next>
    0
    </Next>
    </Anchor>
    </Meta>
    </Item>
    </Alert>
    <Alert>
    <CmdID>
    7
    </CmdID>
    <Data>
    201
    </Data>
    <Item>
    <Target>
    <LocURI>
    Notes
    </LocURI>
    </Target>
    <Source>
    <LocURI>
    /telecom/note.txt
    </LocURI>
    </Source>
    <Meta>
    <Anchor xmlns="syncml:metinf">
    <Last>
    0
    </Last>
    <Next>
    0
    </Next>
    </Anchor>
    </Meta>
    </Item>
    </Alert>
    <Put>
    <CmdID>
    8
    </CmdID>
    <Item>
    <Source>
    <LocURI>
    ./devinf11
    </LocURI>
    </Source>
    <Meta>
    <Type xmlns="syncml:metinf">
    application/vnd.syncml-devinf+xml
    </Type>
    </Meta>
    <Data>
    <DevInf xmlns="syncml:devinf">
    <VerDTD>
    1.1
    </VerDTD>
    <Man>
    Nokia Corporation
    </Man>
    <Mod>
    Nokia 6820
    </Mod>
    <FwV>
    V 3.70
    </FwV>
    <SwV>
    V 3.70
    </SwV>
    <HwV>
    1701
    </HwV>
    <DevID>
    IMEI:352505003019058
    </DevID>
    <DevTyp>
    phone
    </DevTyp>
    <DataStore>
    <SourceRef>
    /telecom/pb.vcf
    </SourceRef>
    <MaxGUIDSize>
    8
    </MaxGUIDSize>
    <Rx-Pref>
    <CTType>
    text/x-vcard
    </CTType>
    <VerCT>
    2.1
    </VerCT>
    </Rx-Pref>
    <Tx-Pref>
    <CTType>
    text/x-vcard
    </CTType>
    <VerCT>
    2.1
    </VerCT>
    </Tx-Pref>
    <SyncCap>
    <SyncType>
    1
    </SyncType>
    <SyncType>
    2
    </SyncType>
    <SyncType>
    7
    </SyncType>
    </SyncCap>
    </DataStore>
    <DataStore>
    <SourceRef>
    /telecom/cal.vcs
    </SourceRef>
    <MaxGUIDSize>
    8
    </MaxGUIDSize>
    <Rx-Pref>
    <CTType>
    text/x-vcalendar
    </CTType>
    <VerCT>
    1.0
    </VerCT>
    </Rx-Pref>
    <Tx-Pref>
    <CTType>
    text/x-vcalendar
    </CTType>
    <VerCT>
    1.0
    </VerCT>
    </Tx-Pref>
    <SyncCap>
    <SyncType>
    1
    </SyncType>
    <SyncType>
    2
    </SyncType>
    <SyncType>
    7
    </SyncType>
    </SyncCap>
    </DataStore>
    <DataStore>
    <SourceRef>
    /telecom/note.txt
    </SourceRef>
    <MaxGUIDSize>
    8
    </MaxGUIDSize>
    <Rx-Pref>
    <CTType>
    text/plain
    </CTType>
    <VerCT>
    </VerCT>
    </Rx-Pref>
    <Tx-Pref>
    <CTType>
    text/plain
    </CTType>
    <VerCT>
    </VerCT>
    </Tx-Pref>
    <SyncCap>
    <SyncType>
    1
    </SyncType>
    <SyncType>
    2
    </SyncType>
    <SyncType>
    7
    </SyncType>
    </SyncCap>
    </DataStore>
    <CTCap>
    <CTType>
    text/x-vcard
    </CTType>
    <PropName>
    BEGIN
    </PropName>
    <ValEnum>
    VCARD
    </ValEnum>
    <PropName>
    VERSION
    </PropName>
    <ValEnum>
    2.1
    </ValEnum>
    <PropName>
    END
    </PropName>
    <ValEnum>
    VCARD
    </ValEnum>
    <PropName>
    N
    </PropName>
    <PropName>
    TEL
    </PropName>
    <ParamName>
    PREF
    </ParamName>
    <ParamName>
    WORK
    </ParamName>
    <ParamName>
    HOME
    </ParamName>
    <ParamName>
    VOICE
    </ParamName>
    <ParamName>
    FAX
    </ParamName>
    <ParamName>
    CELL
    </ParamName>
    <PropName>
    NOTE
    </PropName>
    <PropName>
    URL
    </PropName>
    <PropName>
    EMAIL
    </PropName>
    <PropName>
    LABEL
    </PropName>
    </CTCap>
    <CTCap>
    <CTType>
    text/x-vcalendar
    </CTType>
    <PropName>
    BEGIN
    </PropName>
    <ValEnum>
    VCALENDAR
    </ValEnum>
    <ValEnum>
    VEVENT
    </ValEnum>
    <ValEnum>
    VTODO
    </ValEnum>
    <PropName>
    VERSION
    </PropName>
    <ValEnum>
    1.0
    </ValEnum>
    <PropName>
    END
    </PropName>
    <ValEnum>
    VCALENDAR
    </ValEnum>
    <ValEnum>
    VEVENT
    </ValEnum>
    <ValEnum>
    VTODO
    </ValEnum>
    <PropName>
    DTSTART
    </PropName>
    <DataType>
    datetime
    </DataType>
    <PropName>
    DTEND
    </PropName>
    <DataType>
    datetime
    </DataType>
    <PropName>
    SUMMARY
    </PropName>
    <PropName>
    DUE
    </PropName>
    <PropName>
    AALARM
    </PropName>
    <DataType>
    datetime
    </DataType>
    <PropName>
    DALARM
    </PropName>
    <DataType>
    datetime
    </DataType>
    <PropName>
    RRULE
    </PropName>
    <PropName>
    CATEGORIES
    </PropName>
    <PropName>
    LOCATION
    </PropName>
    <PropName>
    STATUS
    </PropName>
    <PropName>
    PRIORITY
    </PropName>
    </CTCap>
    <CTCap>
    <CTType>
    text/plain
    </CTType>
    <PropName>
    </PropName>
    <DataType>
    chr
    </DataType>
    <Size>
    3000
    </Size>
    </CTCap>
    </DevInf>
    </Data>
    </Item>
    </Put>
    <Final>
    </Final>
    </SyncBody>
    </SyncML>


    After this message when I try a new PUT request the phone hangs, so I really believe it depeds on the content of the WBXML code.

    Can you post your XML or WBXML code ?
    BTW, I'm using a Nokia 6820

    Thanks
    Matteo

  9. #9
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    I do not understand your question. Please try again. What do you send within your next OBEX PUT? You have to send a SyncML initalisation response which is described within Sync Protocol chapter 9.2 and Representation Protocol chapter 6.4.1 of SyncML 1.1.2.

    Do you need such a XML document? This depends in many parts of the init request of the client you just got. But if you need I can give you my solution.

    Just some notes:
    I would not post an IMEI to a public forum and please edit your post and make a [ c o d e ] and [ / c o d e ] around your XML. This will preserve the tabbing and ease the reading of such large XML documents which are produced of SyncML.

    What WBXML do you need? It would make more sense to send your WBXML to me via email. Perhaps I have time to look at it and find the bug. I need the origin XML too. SyncML WBXML generation is quite easy if you use a XML SAX parser. I done mine in two days for encoding/decoding. Simply follow the Backus Naur Form (BNF) within WBXML. But there are some WBXML generators available too.
    Last edited by traud; 2004-08-20 at 14:11.

  10. #10
    Registered User
    Join Date
    Jul 2004
    Posts
    5

    SyncML , OBEX over Bluetooth

    Thanks for the info. I solved the GET related problem and it was due to something in the WBXML code. I have an additional question about WBXML that is not very clear to me.

    In the same WBXML file it is possible to find token codes (tags) from the SyncML DTD, the Meta Information DTD and the DevInf DTD. It is pretty clear that it is possible to switch between SyncML DTD and Meta Information DTD by simply changing the page code to 0x01. The thing that I don't understand is how can I switch to the DevInf DtD in the same file since the page code is still 0x00 and the only thing changing is Document Public Identifier defined only once in the beginning of the WBXML file.

    If you want i send send you the WBXML file I'm talking about. My e-mail address is "matteo (at) dolce (dot) it".

    Thanks
    Matteo

  11. #11
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    This is a very good question and in my opinion one of various big WBXML bugs within current SyncML specifications (up to 1.2).

    I filed this with various other WBXML related things as comment to the OMA SyncML working group already but I see no progress. From my point of view the SyncML working group has no deep understanding of WBXML. If you have a look at the naming conventions (tocken vs. value in chapter 8.1 of the 1.1.2 Representation protocol) and the WBXML example (wrong place for back codepage switches; chapter 15.1 in Data Sync Protocol 1.1.2) this gets obvious. This device information WBXML problem is the worst. SyncML says the WBXML conversion should be transparent and not changing the XML…

    As you see in chapter 9.2.1 and 9.1.1 of Sync Data Protocol 1.1.2 it is quite clear within XML thanks to its great name space support. The only solution I know: You have to mark the content of <Data> from #PCDATA to #CDATA (via <Data><![CDATA[your device information]]></Data>) which means within WBXML you have to mark the content of the Data element of the Device Information Item Element as "opaque". This is the way the Nokia SyncML client implementation does it. Have a look into it.

    But as I said this is against the "rules" because chapter 5.1 device information says: "The use of [WBXML] format is external to this specification and should be transparent to any XML application supporting this DTD". Well they only say "should". The current SyncML is a lousy and terrible specification. Or someone can tell us a better solution. Please! I do not know one and I would not even came to this either without the Nokia implementation.
    Last edited by traud; 2004-08-21 at 16:05.

  12. #12
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    Just an update for all who want to use SyncML over OBEX via a cable connection.

    All Nokia SyncML over OBEX phones which use the Nokia USB data cable DKU-2 follow the USB CDC WMC 1.0 specification. So there is an interface for OBEX communication. Because I have DKU-5 phones only, I can't check if the SyncML OBEX Server is avilable there too. I my opinion Nokia SyncML OBEX has its own server so I can't asume it automatically.

    Could someone test this. This would avoid Nokia FBus via a cbale connection for these new phone.

    Has anyone checked the IrDA IAS entries for the latest phones. Again my Nokia 6820 has no SyncML over OBEX entry. Anyone checked the default OBEX channel for SyncML over OBEX? Or do newer phones have correct SyncML IAS entries?

    Nokia seems to learn a bit - years behind but finally CDC WMC is here.
    Last edited by traud; 2004-11-02 at 12:34.

  13. #13
    Registered User
    Join Date
    Sep 2003
    Posts
    10
    Thanks everyone (especially Traud) that has contributed to this thread.

    I have managed to do a SyncML sync with a Nokia 6820. After a succesful sync, the 6820 will always use fast sync and only send contacts that are changed (which is good). I do however need some way to tell the phone that I have (in some cases) lost the sync and need a refresh of all contacts. I try to do as the spec say and reply with 508 (refresh needed) to a sync alert, but this only crashes the phone.

    Anyone have any suggestions?

    BR
    /Ulf

  14. #14
    Registered User
    Join Date
    Mar 2003
    Posts
    4,105
    Good question. Never came so deep - so just theory of chapters 9.2 and 10.5 of the Data Sync Protocol v1.1.2:
    Way 1
    After the server has sent the Sync Alert, and if the client does not agree with the sync anchor in that Alert, then the Client MUST start a slow sync. … Note that it is not necessary for the client to compare the sync anchor from the server.
    Normally if your anchors in ther server alert message you send should be wrong, the Nokia should start slow sync. If it does a fast sync it ignores sync anchors from the server.
    Way 2
    If the client or the server needs to initiate the slow sync after receiving the alert for the normal synchronization, they need to send back an error status for that Alert in addition the slow sync alert. The error code, which is used in this case, MUST be 508 (Refresh required).
    Crashes this? Do you send a status 508 and an alert 201?

    You reply with 508 to a sync alert package? You mean you reply to an init from client (package #2) with an init (package #3) which contains:
    SyncBody > Status > Data > 508
    SyncBody > Alert > Data > 201
    Way 3
    If the devices are synchronizing with each other at the first time, the slow sync MUST be initiated.
    The dirty way, simply change the target (and source?) in your sync alert.

  15. #15
    Registered User
    Join Date
    Sep 2003
    Posts
    10
    Thanks Traud for your suggestions.

    I agree with your three ways to do it.

    Way 1: I just now tried to make the achors incorrect but it seems like the phone does not consider the server anchors.

    Way 2: I tried sending response 508 + a new alert for 201but this crashed the Nokia 6820. I might be missing something or the 6820 needs something not obvius to me...
    I will have to try some more, since this is the correct way.

    Way 3: Good one, I hadnt though of that. I tried it and it worked, but only when I changed Source found in SyncHdr. Not very nice sollution, but it might be needed if I cant get way 2 working.

    I will report any further progress.

    /Ulf

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×