Benny Prijono wrote:
>
> Yeah, your server is messing up ICE (again). :)
>
> The rule regarding putting ICE in SDP is different for *initial*
> offer-answer and *subsequent* offer-answer. You only put selected
> candidate in subsequent offer/answer, and definitely you must use
> matching candidate in your c= and a=rtcp line. Doing it like above
> confuses the answerer, since the c= line mismatch, but at the same
> time the a=ufrag and a=passwd lines don't change so ICE restart
> procedure can't happen (and we can't restart ICE in the answer anyway).
>
> So bottom line, you really need to understand ICE before modifying
> PJSIP offer-answer SDP like that. If in doubt, re-read it again. :)
Hi!
I changed the server, and now it doesn't mess with subsequent offer and
subsequent answer.
However, I realized that I am experiencing a problem in the answerer: it
seems like his ICE connectivity tests are taking more time to complete
that the caller's tests: I can see that the subsequent offer arrives (at
on_rx_offer) *before* his on_ice_complete() gets called with
ice_strans_op = PJ_ICE_STRANS_OP_NEGOTIATION.
This way, as in on_rx_offer() I call *pjmedia_endpt_create_sdp*,
*pjmedia_transport_encode_sdp* and *pjsip_inv_set_sdp_answer*, the
subsequent offer is sent, but it doesn't seem correct, because it is
including again all the candidates, instead of only the candidates
selected bu the caller.
Here is an example of a subsequent answer sent by the answerer:
v=0
o=- 3425387269 3425387237 IN IP4 192.168.102.1
s=pjmedia
c=IN IP4 192.168.102.1
t=0 0
m=audio 4000 RTP/AVP 0 101
a=rtcp:4001 IN IP4 192.168.102.1
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:301c0bdb
a=ice-pwd:56ae0732
a=candidate:H 1 UDP 39 172.18.0.31 50839 typ host
a=candidate:H 1 UDP 39 192.168.102.1 50839 typ host
a=candidate:H 1 UDP 39 192.168.1.1 50839 typ host
a=candidate:H 1 UDP 39 172.18.0.68 50839 typ host
a=candidate:H 2 UDP 38 172.18.0.31 50840 typ host
a=candidate:H 2 UDP 38 192.168.102.1 50840 typ host
a=candidate:H 2 UDP 38 192.168.1.1 50840 typ host
a=candidate:H 2 UDP 38 172.18.0.68 50840 typ host
I think that the problem is related to the fact that the answerer hasn't
yet completed its tests.
In order to deal with that I added some code in on_rx_offer() to wait
for ICE to complete
while (ice_is_not_complete && nr_tries < MAX_TRIES) {
log("on_rx_offer waiting for ice to complete");
pj_thread_sleep(sleep_time);
nr_tries++;
}
However, no matter how long I wait, the ice will always completes after
this cicle completes, which leads me to believe that on_rx_offer()
should be running in the same thread used to perform the ICE
connectivity checks.
Am I wrong? Is this waiting cycle really needed?
Regards
Pedro Gon?alves
