Gees, I take a few days off to get married and I come back to this

OK, here are the some explanations for you:
xid = An IrDA discovery frame - ffffffff means it is sent to a broadcast address
snrm = Set normal response mode - this is telling the other device what connection settings it would like to use for the IrDA link.
ua = Un-numbered acknowledgement, sent to ack non-information frames (SNRMs for example)
rr = receiver ready, used to keep the IrDA link alive when not sending actual data.
i = Information frame
command and response guesses are coorect
ca = Connection address
pf = Poll Final bit, the low level IrDA stuff takes care of it and should be fine, if you need more info check out the IrLMP spec (I think)
nr = This is a sequencing number, it send back the number of the next frame it is expecting, so in this case the Pocket PC is waiting for frame 3 and the Empeg is waiting for frame 4.

So what could be the problem, it looks like when you do the TTP connect you do not give the Empeg any credits

04:23:37.991451 i:cmd < ca=d4 pf=1 nr=2 ns=3 LM slsap=01 dlsap=24
CONN_CMD TTP
credits=0(7)

so when the Empeg responds it doesn't give the PPC any credits

04:23:38.020927 i:rsp > ca=d4 pf=1 nr=4 ns=2 LM slsap=24 dlsap=01
CONN_RSP TTP
credits=0(7)

so the TTP link is up, but it cannot send the OBEX connect frame, as it has no credits to be able to send it, so the link will just sit there RRing unitl it gets disconnected, or one side decides to send credits (and then the other side will normally give some credits back). One of the things we do when we are running low on credits is to give the other device a credit in the hope it will send us some back.

Hope that helps, if you have further questions then let me know I should get round to them while I catch back up.