When a unidirectional stream is added (or when a stream direction is changed), tp-ssip fails to put that into the SDP.
I long thought it covered... Any specific examples with output under TPSIP_DEBUG=all TPORT_LOG=1?
You just have to make a sip call between two N900s.
Created attachment 32724 [details] syslog (from N900) Ok, my test case is: I called another device with video off. Then I upgrade to video on one side (so it should be sendonly, it doesnt). Then I upgraded from th other side. Then I downgraded (now the sendonly if there).
Created attachment 32725 [details] stdout/stderr (from same call)
Created attachment 32726 [details] tcpdump (from the same call again)
(In reply to comment #3) > Created an attachment (id=32724) [details] > syslog (from N900) > > Ok, my test case is: I called another device with video off. Then I upgrade to > video on one side (so it should be sendonly, it doesnt). It shouldn't: this way it allows the remote end to accept the video bidirectionally in the same re-INVITE transaction. The remote pending send flag attests to this on Telepathy side. If the other end accepts it as recvonly, the pending flag should be cleared and the direction drop to send only; but it didn't happen in this case. > Then I upgraded from > th other side. It's interesting what happened on the other end: the response (to CSeq: 110088588 INVITE) was bidirectional already, but the transports had local addresses. That's bad form for rawudp if it had STUN properly set up. Then, after four seconds, the other client sent its own re-INVITE (CSeq: 125847787 INVITE) with new NATified transport candidates. Can you replay and collect the logs from the other end, with the same network configuration it used this time? > Then I downgraded (now the sendonly if there). That went seemingly all right.
(In reply to comment #6) > It shouldn't: this way it allows the remote end to accept the video > bidirectionally in the same re-INVITE transaction. The remote pending send flag > attests to this on Telepathy side. If the other end accepts it as recvonly, the > pending flag should be cleared and the direction drop to send only; but it > didn't happen in this case. The other side is also a N900.. When it accepts the video upgrade, it doesn't start sending. So it should add a=recvonly, shouldn't it ?
(In reply to comment #7) > The other side is also a N900.. When it accepts the video upgrade, it doesn't > start sending. So it should add a=recvonly, shouldn't it ? Yes it should, that's why I'm asking for logs taken there.
Created attachment 32747 [details] here are logs from tp-ssip from both sides Same use case .. - 1 calls 2 audio-only - 1 upgrades to video (recvonly/sendonly are lacking) - 2 upgrades to video - 2 downgrades (a=recvonly is represent in INVITE, OK replies with a=sendonly) - 1 ends call
(In reply to comment #9) > Created an attachment (id=32747) [details] > here are logs from tp-ssip from both sides Thanks, I can see the problem now.
Branch with a fix: http://git.collabora.co.uk/?p=user/zabaluev/telepathy-sofiasip.git;a=shortlog;h=refs/heads/pending-send-fixes
The fix is merged upstream and available under tag telepathy-sofiasip-0.6.0, pending a proper fd.o release Real Soon Now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.