Client 1 never konws if the ACK was received by Client 2. Thus client 1
can not terminate the session due to ACK failures - as it does not know
about these failures.
Client 2 knows about failed ACKs - thus it is the responsibility of
client 2 to terminate the call (with BYE):
RFC 3261, 13.3.1.4:
If the server retransmits the 2xx response for 64*T1 seconds without
receiving an ACK, the dialog is confirmed, but the session SHOULD be
terminated. This is accomplished with a BYE, as described in Section
15.
regards
Klaus
Am 20.09.2010 16:29, schrieb Montevecchi Massimiliano:
> Hi
>
> I am using pjsua rel. 1.8.
>
> I have 2 pjsua connected the an IMS platform based on OPENIMSCORE project.
>
> One (pjsua#1) has access to the pcscf from internet using its IP address
> and the other one is connected on the same Lan of the pcscf.
>
> I am experimenting the following problem:
>
> 1. Pjsua#1 calls PJSUA#2
>
> 2. PJsua#2 receives the INVITE and accepts the call sending 200OK
>
> 3. Pjsua#1 receives the 200 OK and tries to send ACK.
>
> 4. Pjsua#1 does not send ACK because DNS resolution fails.
>
> 5. Pjsua#1 does not take care of the failure and changes anyway the
> state of the call to CONNECTED
>
> 6. Pjsua#2 sends again 200 OK until max retransmission then declares
> disconnect the call.
>
> The question is:
>
> When the last try to transmit the ACK fails, the INVITE dialog should
> not complete correctly and the call activation should fail, doesn?t it?
>
> Best Regards
>
> */Massimiliano Montevecchi/*
>
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
