external rtpproxy.It will signal sip ua when no rtp packets there.
regards,
Gang
On Fri, Sep 25, 2009 at 2:29 PM, M.S. <hamstiede at yahoo.de> wrote:
>
> 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 <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 <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/4ea0a558/attachment-0001.html>
