media stream activity detection. How do you do this?
regards mark
________________________________
Von: Gang Liu <gangban..lau at gmail.com>
An: pjsip list <pjsip at lists.pjsip.org>
Gesendet: Freitag, den 25. September 2009, 04:57:04 Uhr
Betreff: Re: [pjsip] CANCEL pjsua bug?
Yes, you could go this way.
At my side, I prefer let it be, and 200 OK timer or media stream activity detection will clear such calls.
regards,
Gang
On Thu, Sep 24, 2009 at 11:37 PM, M.S. <hamstiede at yahoo.de> wrote:
>Hi Gang,
>my work around (in application layer) looks like this:
>
>void CSIP_Wrapper::on_call_tsx_state(pjsua_call_id call_id, pjsip_transaction *tsx, pjsip_event *e)
>{
> /* PJSIP Bugfix: early CANCEL for incomming calls doesn' produce call hangup
>> i saw it in call_info.state: PJSIP_INV_STATE_CONNECTING and PJSIP_INV_STATE_INCOMING */
>
> if (tsx->method.id==PJSIP_CANCEL_METHOD)
>> { if (tsx->role==PJSIP_ROLE_UAS)
>
> { pjsua_call_hangup(call_id,0, NULL, NULL);
> } }
>}
>
>this fix is working fine.
>
>regards
>
> Mark
>
>
>
________________________________
Von: Gang Liu <gangban.lau at gmail.com>
>An: pjsip list <pjsip at lists.pjsip.org>
>Gesendet: Donnerstag, den 24. September 2009, 10:28:25 Uhr
>Betreff: Re: [pjsip] CANCEL pjsua bug?
>
>inline.
>
>
>On Thu, Sep 17, 2009 at 7:51 PM, M.S. <hamstiede at yahoo.de> wrote:
>
>>>
>>
>>
>>
>>
>>>>
________________________________
Von: Gang Liu <gangban.lau at gmail.com>
>>An: pjsip list <pjsip at lists.pjsip.org>
>>Gesendet: Donnerstag, den 17. September 2009, 10:29:36 Uhr
>>Betreff: Re: [pjsip] CANCEL pjsua bug?
>>
>>in your log message, inv transaction was sent 200 OK and it was complete.
>>>>
>> VOIP2009/09/16
>> 12:05:19.904
>> -HDL- cSipWrapper.cxx(1140) dlg0x2b1894 Sending Response msg
>> 200/INVITE/cseq=5448 (tdta0x2b6650)
>>
>>> yes, i think this is the race condition, pjsua answered the invite, and the opposite sent the CANCEL request.
>>
>>
>You are right.
>>
>
>>>
>>>> VOIP2009/09/16 12:05:19.968
>> -HDL- cSipWrapper.cxx(1140) dlg0x2b1894 Transaction tsx0x2b4c7c state changed to Completed
>>
>>Do you see a SIP UA will drop the call when it recv CANCEL after call connected?
>>
>>> No of cause, the call will not droped. I received no PJSIP_INV_STATE_DISCONNECTED in the pjsua callback on_call_state(...)
>>
>>
>
>It is because UAC sent ACK after CANCEL. So the call was connected. If no ACK incoming, pjsua would drop the call after 200 OK retransmission timeout.
>
> VOIP2009/09/16 12:05:20.289 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2b4c7c Incoming Request msg
> ACK/cseq=5448 (rdata0x41a23854) in state Completed
>
>I saw another race condition before which may cause pjsip-ua api (0.9.0 release) deadlock.
>
>UAC UAS
> -- INV -->
> <-- 100 --
>>
> <-- 4XX --
> --- ACK -->
> -- CANCEL -->
>
>ACK and CANCEL came in at the same millisecond, but ACK first. If multi threads were polling pjsip endpoint events, deadlock maybe happen.. But I couldn't find a solution to fix this issue.
>
>regards,
>Gang
>
>
>>>
>>>>
>>regards mark
>>
>>reagrds,
>>Gang
>>
>>
>>
>>
>>On Thu, Sep 17, 2009 at 3:40 PM, M.S. <hamstiede at yahoo.de> wrote:
>>
>>>>>
>>>answered from which side? the opposite sent a CANCEL. My application answered every incomming call, but this is
>>>>>>the race condition. I think the sip state machine must transfer the call to a disconnecting state.
>>>
>>>regards
>>>
>>> Mark
>>>
>>>
>>>
>>>>>>
>>>
>>>
>>>
________________________________
Von: Gang Liu <gangban.lau at gmail.com>
>>>An: pjsip list <pjsip at lists.pjsip.org>
>>>Gesendet: Donnerstag, den 17. September 2009, 04:52:06 Uhr
>>>Betreff: Re: [pjsip] CANCEL pjsua bug?
>>>
>>>It seems your call was answered.
>>>
>>>regards,
>>>Gang
>>>
>>>
>>>On Wed, Sep 16, 2009 at 10:38 PM, M.S. <hamstiede at yahoo.de> wrote:
>>>
>>>>>>>
>>>>
>>>>Hi,
>>>>>>>>if i made testcalls with very short incomming calls (<1sec) it happens, that incomming CANCEL
>>>>messages wasn't handled by stack. Here is the log:
>>>>I used Version V1.4
>>>>
>>>>>>>>
>>>>
>>>>
>>>>regards mark
>>>>
>>>>#OK incomming call will proceed everything is fine:
>>>>
>>>>VOIP2009/09/16 12:05:19.628 -HDL- cSipWrapper.cxx(1140) strm0x2b8184 Decoder stream started
>>>> VOIP2009/09/16 12:05:19.646 -HDL-
>>>> cSipWrapper.cxx(2037) SAG OnStreamCreated CALL-ID:8
>>>> VOIP2009/09/16 12:05:19.664 -HDL- cSipWrapper.cxx(1307) SCO InitMediaCall CALL_ID:8 PTime:40 SPF:320
>>>> VOIP2009/09/16 12:05:19.684 -HDL- cSipWrapper.cxx(1140) conference.c Creating conference bridge with 4 ports
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:19.711 -HDL- cSipWrapper.cxx(2043) SAG CALL-ID:8 BC:0
>>>> VOIP2009/09/16
>>>> 12:05:19.730 -HDL- cSipWrapper.cxx(1140) pjsua_media.c Media updates, stream #0: PCMU (sendrecv)
>>>> VOIP2009/09/16 12:05:19.750 -HDL- cSipWrapper..cxx(1103) SRW OnCallMedia:MediaActiv CALL-ID:8
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:19.770 -HDL- cSipWrapper.cxx(489) SWR SSP Register Slot:2
>>>> VOIP2009/09/16 12:05:19..788 -HDL-
>>>> cSipWrapper.cxx(1140) conference.c Port 1 (CALL) transmitting to port 2 (SSP)
>>>> VOIP2009/09/16 12:05:19..811 -HDL- cSipWrapper.cxx(500) SRW SSP Channel CALL-ID:8 SrcID:1 SnkID:2 CNT:3 DEV:/dev/mySSP1
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:19.835 -HDL- cSipWrapper..cxx(1140) inv0x2b1894 Sending Response msg 200/INVITE/cseq=5448 (tdta0x2b6650)
>>>> VOIP2009/09/16 12:05:19.904 -HDL- cSipWrapper.cxx(1140) dlg0x2b1894 Sending Response msg
>>>> 200/INVITE/cseq=5448 (tdta0x2b6650)
>>>> VOIP2009/09/16 12:05:19.924 -HDL- cSipWrapper...cxx(1140) tsx0x2b4c7c Sending Response msg 200/INVITE/cseq=5448 (tdta0x2b6650) in state Proceeding
>>>> VOIP2009/09/16 12:05:19..947 -HDL- cSipWrapper.cxx(1140) tsx0x2b4c7c State changed from Proceeding to Completed, event=TX_MSG
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:19.968 -HDL- cSipWrapper.cxx(1140) dlg0x2b1894 Transaction tsx0x2b4c7c state changed to Completed
>>>> VOIP2009/09/16
>>>> 12:05:19.988 -HDL- cSipWrapper.cxx(1017) SRW OnCallState CALL-ID:8 ST:4
>>>>
>>>>
>>>># here comes the CANCEL Message from the opposite:
>>>>
>>>> VOIP2009/09/16 12:05:20.006 ThreadID=0x00020009 cSipWrapper.cxx(1140) sip_endpoint.c Processing incoming message: Request msg CANCEL/cseq=5448 (rdata0x41a23854)
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:20.022 ThreadID=0x00020009 cSipWrapper.cxx(1140) dlg0x2b1894 Received Request msg CANCEL/cseq=5448 (rdata0x41a23854)
>>>> VOIP2009/09/16 12:05:20.049 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2bece4 Transaction created for Request msg
>>>> CANCEL/cseq=5448 (rdata0x41a23854)
>>>> VOIP2009/09/16 12:05:20.070 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2bece4 Incoming Request msg CANCEL/cseq=5448 (rdata0x41a23854) in state Null
>>>>
>>>>
>>>># the CANCEL message response will created
>>>>>>>>
>>>>
>>>>
>>>>
>>>>VOIP2009/09/16 12:05:20.091 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2bece4 State changed from Null to Trying, event=RX_MSG
>>>> VOIP2009/09/16 12:05:20.110 ThreadID=0x00020009 cSipWrapper.cxx(1140) dlg0x2b1894 Transaction tsx0x2bece4 state changed to Trying
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:20.129 ThreadID=0x00020009 cSipWrapper.cxx(1140) endpoint Response msg
>>>> 200/CANCEL/cseq=5448 (tdta0x2bf488) created
>>>> VOIP2009/09/16 12:05:20.150 ThreadID=0x00020009 cSipWrapper..cxx(1140) dlg0x2b1894 Sending Response msg 200/CANCEL/cseq=5448 (tdta0x2bf488)
>>>> VOIP2009/09/16 12:05:20.169 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2bece4 Sending Response msg 200/CANCEL/cseq=5448 (tdta0x2bf488) in state Trying
>>>>
>>>>
>>>># and here i expecting a change to "disconnecting" state but nothing happens !!!! the call looks like connected forever...
>>>>
>>>> VOIP2009/09/16 12:05:20.192 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2bece4 State changed from Trying to Completed, event=TX_MSG
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:20.213
>>>> ThreadID=0x00020009 cSipWrapper.cxx(1140) dlg0x2b1894 Transaction tsx0x2bece4 state changed to Completed
>>>> VOIP2009/09/16 12:05:20.232 ThreadID=0x00020009 cSipWrapper.cxx(1017) SRW OnCallState CALL-ID:8 ST:4
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:20.250 ThreadID=0x00020009 cSipWrapper..cxx(1017) SRW OnCallState CALL-ID:8 ST:4
>>>> VOIP2009/09/16 12:05:20.268 ThreadID=0x00020009 cSipWrapper.cxx(1140) sip_endpoint..c Processing incoming message: Request msg ACK/cseq=5448 (rdata0x41a23854)
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:20.289 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2b4c7c Incoming Request msg
>>>> ACK/cseq=5448 (rdata0x41a23854) in state Completed
>>>> VOIP2009/09/16 12:05:20.317 ThreadID=0x00020009 cSipWrapper.cxx(1140) tsx0x2b4c7c State changed from Completed to Confirmed, event=RX_MSG
>>>> VOIP2009/09/16 12:05:20.345 ThreadID=0x00020009 cSipWrapper.cxx(1140) dlg0x2b1894 Transaction tsx0x2b4c7c state changed to Confirmed
>>>>>>>>
>>>>
>>>>
>>>> VOIP2009/09/16 12:05:20.362 ThreadID=0x00020009 cSipWrapper.cxx(1017) SRW OnCallState CALL-ID:8 ST:5
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>>>>>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
>>>>
>>>>
>>>
>>>
>>>_______________________________________________
>>>>>>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
>>>
>>>
>>
>>
>>_______________________________________________
>>>>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
>>
>>
>
>
>_______________________________________________
>>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090925/55a4c631/attachment-0001.html>
