How to fund a bidirectional channel in Lightning Network by two participants? (Edited) I brought up a similar question here: (Link to question) for a payment channel (in general case and without specifying which payment channel implementation.) Since this funding channels depends on the platform and implementation, I bring up that question specifically for Lightning Network (last version).

How to fund a bidirectional channel in Lightning Network (last version) by two participants?

To clarify better the question, I bring up following scenario:

Assuming two users want to create a bidirectional channel between themselves such that user_1 wants to pay n BTC to user_2 at the end. And user_2 wants to pay m BTC to user_1 at the end.

So, the capacity of this channel must be (n + m) BTC. Logically, n BTC of channel's capacity must be provided by user_1 and m BTC of channel's capacity must be provided by user_2.

However, since they create together only one channel between themselves, how can they manage capacity of this channel? Since the channel is bidirectional, it is wisely, logical and fair that its capacity must be funded by both users, so how can they establish this channel together with (n + m) BTC ? 

Please note that:
(1) non of users do NOT trust each other and (2) do NOT want to finalize a micro-payment (settlement) before capacity of the channel becomes (n + m) BTC.

Edit: Here: (Link to answer) it's mentioned by @Jestin that : "the fee must be paid by whichever party creates the funding transaction." If so, each of both users prefer NOT to create the funding transaction to avoid paying fees. What happens in a situation users do not know and do not trust each other? What does incentive one of users to be volunteer to pay the fees?

Note: If you think that question is not clear enough, please let me know.
1) Peer A sends msg to Peer B


Unsigned Funding TX template including:
// Input A (unsigned, just outpoint)
// Output A (change)


2) Peer B sends msg to Peer A


Completed unsigned Funding TX template, which adds:
// Input B (unsigned, just outpoint)
// Output B (change)
// 2-of-2 Multi-sig Output (still requires sig A, sig B)
Signature for Peer A's first commitment Transaction (Unsigned funding TX is completed, so TXID is non-malleable for witness transactions. Commitment TX's can therefore be signed without risk of being invalidate by parent malleability).


3) Peer A sends msg to Peer B


Signature for Peer B's first commitment Transaction. 
Now both commitment Transactions (for A and B) are signed.


4) Peer B sends msg to Peer A


B's Signature for funding transaction.
Now A has complete Funding TX after signing itself.


Caveat: If Peer A fails to respond after step 4, Peer B must double-spend its funding input to prevent future interference.