On Fri, Jun 27, 2008 at 7:11 PM, Pedro Gon?alves <pedro.pandre at gmail.com> wrote: > Hi again. > > I managed to solve that specific problem, but however I am noticing these > issues (I've updated PJSIP from SVN this morning): > 1) When creating the initial answer, the callee does not include candidates > for component 2 in SDP; even thought this does not happen when generating > the initial offer, and the code is the same. I've attached the log for that > part: we can see that 8 candidates are being gathered, 4 for component 1 and > 4 for component 2. However, only component 1's candidates go into the SDP. > Why? Is it because the server is removing the a=rtcp line as the RTCP port > is equal to the RTP port + 1, and so the callee receives the initial offer > without a=rtcp? > Something like that. If the offer only has 1 component, then pjsip will answer with 1 component too. I suspect the offer doesn't have both the a=rtcp and a=candidate for the second component (otherwise if a=candidate is present for the second component, but a=rtcp doesn't exist, pjsip will answer with a=ice-mismatch). What user agent do you use for the other side? > 2) When sending the re-INVITE, its SDP is somewhat strange: > o=- 3423579320 3423579321 IN IP4 172.18.0.212 > s=pjmedia > c=IN IP4 192.168.1.91 > t=0 0 > m=audio 5030 RTP/AVP 3 101 > a=rtpmap:3 GSM/8000 > a=sendrecv > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ice-ufrag:39b32d12 > a=ice-pwd:074d4dc8 > a=candidate:S 1 UDP 31 77.54.250.64 1122 typ srflx raddr 172.18.0.212 rport > 1122 > a=candidate:H 1 UDP 23 172.18.0.212 1122 typ host > a=candidate:S 2 UDP 30 77.54.250.64 1123 typ srflx raddr 172.18.0.212 rport > 1123 > a=candidate:H 2 UDP 22 172.18.0.212 1123 typ host > a=ice-ufrag:39b32d12 > a=ice-pwd:074d4dc8 > a=candidate:H 1 UDP 23 172.18.0.212 1122 typ host > a=remote-candidates:1 172.18.2.117 62562 > a=candidate:Rac1200d4 1 UDP 0 192.168.1.91 5030 typ relay raddr 172.18.0.212 > 1122 > a=candidate:Rac1200d4 2 UDP 0 192.168.1.91 5031 typ relay raddr 172.18.0.212 > 5028 > > As we can see, only candidates for component 1 are sent ( this may be > related with the issue related in 1) ). Furthermore, ice-ufrag and ice-pwd > are included twice. Is all this ok? > No it's not okay. Although it probably won't cause failure since (I presume) that does not cause ICE negotiation to restart, it's still not correct. I could not reproduce this with pjsua. Are you sure pjmedia_transport_encode_sdp() is not called twice? Because that will explain it. > 3) Lastly, the most important: when receiving the re-INVITE in the callee, > on "on_rx_request" callback, I call *pjmedia_transport_encode_sdp*, > *pjmedia_sdp_neg_set_remote_offer* and *pjsip_int_set_sdp_answer*. They all > succeed, but however the response is not sent. Do I have to call any send > method? > I don't think on_rx_request() is the right callback to receive re-INVITE, please (re-)read my email (*and* the documentation, *and* the source). If I have to (re)explain every step of the way then that will take toooo long. :) Cheers Benny
