[reSIProcate] Fw: Fw: CANCEL before provisional recieved.
Jason Fischl
jason at counterpath.com
Thu May 10 10:36:28 CDT 2007
If you make the AppDialogSet (not AppDialog) it will be created when
you make it and you can call cancel on it at any time.
On 5/10/07, Volodymyr.Stepanov at aricent.com
<Volodymyr.Stepanov at aricent.com> wrote:
>
> >>You would need to create your own AppDialogSet and pass into the makeInviteSession call.
>
> Ok.
> But ,as I understand, AppDialog creating only after provisional (or any 1XX) received?
> Am I right?Or you mean something else?
> What should I do?
> Thanks.
> ----- Forwarded by Volodymyr Stepanov/R&D Ukraine on 10.05.2007 18:25 -----
>
> Volodymyr Stepanov/R&D Ukraine
>
> 10.05.2007 10:19
>
> To <resiprocate-devel at list.resiprocate.org>
>
> cc
>
>
> Subject Fw: [reSIProcate] Fw: CANCEL before provisional recieved.
>
>
>
>
>
>
>
>
> ----- Forwarded by Volodymyr Stepanov/R&D Ukraine on 10.05.2007 10:18 -----
>
> Volodymyr Stepanov/R&D Ukraine
>
> 10.05.2007 10:18
>
> To "Scott Godin" <slgodin at icescape.com>
>
> cc
>
>
> Subject RE: [reSIProcate] Fw: CANCEL before provisional recieved.Link
>
>
>
>
>
>
> But on this stage I don't have valid invite session :(
>
> resip::InviteSessionHandle handle = m_pDum->findInviteSession(*m_currOutgInviteId);
> if (handle.isValid())
> {
> DebugLog(<< "CSipWorker::HangCall: handle.isValid() - handle->getAppDialogSet()->end()");
> handle->getAppDialogSet()->end();
> DebugLog(<< "CSipWorker::HangCall: handle.isValid() - handle->getAppDialogSet()->end() finished");
> }
> else if (m_outgInviteMsg && !m_outgInviteMsg->isInvalid()
> && m_outgInviteMsg->isRequest()
> && (pSession->GetState() != eUnreachable)
> && (pSession->GetState() != eBusy)
> && (pSession->GetState() != eDisconnected))
> {
> std::cout<<"CSipWorker::HangCall: Send cancel";
> resip::SipMessage* pCancelMessage = resip::Helper::makeCancel(*m_outgInviteMsg);
>
> resip::SharedPtr<resip::SipMessage> pShCancelMessage(pCancelMessage);
> m_pDum->send(pShCancelMessage);
> m_outgInviteMsg = NULL;
> DebugLog(<< "CSipWorker::HangCall: Send cancel finished");
> }
>
>
> Is it completely wrong?
> Thanks!
> Best regards,
>
> Volodymyr Stepanov
> MSN : stepanov_v_m at hotmail.com
> ICQ : 272708933
>
>
>
> "Scott Godin" <slgodin at icescape.com>
>
> 08.05.2007 16:48
>
> To <Volodymyr.Stepanov at aricent.com>, "Byron Campen" <bcampen at estacado.net>
>
> cc <resiprocate-devel at list.resiprocate.org>
>
> Subject RE: [reSIProcate] Fw: CANCEL before provisional recieved.
>
>
>
>
>
>
>
> If you use AppDialogSet::end() to CANCEL the call end this is all taken care of for you:
> https://www.resiprocate.org/DUM_Ending_an_Invite_Session
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of Volodymyr.Stepanov at aricent.com
> Sent: Tuesday, May 08, 2007 3:28 AM
> To: Byron Campen
> Cc: resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] Fw: CANCEL before provisional recieved.
>
>
> if (m_outgInviteMsg && !m_outgInviteMsg->isInvalid()
> && m_outgInviteMsg->isRequest()
> && (pSession->GetState() != eUnreachable)
> && (pSession->GetState() != eBusy)
> && (pSession->GetState() != eDisconnected))
> {
> std::cout<<"CSipWorker::HangCall: Send cancel";
> resip::SipMessage* pCancelMessage = resip::Helper::makeCancel(*m_outgInviteMsg);
>
> resip::SharedPtr<resip::SipMessage> pShCancelMessage(pCancelMessage);
> m_pDum->send(pShCancelMessage);
> m_outgInviteMsg = NULL;
> DebugLog(<< "CSipWorker::HangCall: Send cancel finished");
> }
>
>
> That's all application do to signal about tear down the call.(maybe something erong here too? :) )
>
> Probably I should change my app architecture to provide ability to send "some sort of note-to-self to send a CANCEL once a provisional comes in",
>
> Best regards,
>
>
> MSN : stepanov_v_m at hotmail.com
> ICQ : 272708933
>
>
>
> Byron Campen <bcampen at estacado.net>
>
> 07.05.2007 23:24
>
>
> To Volodymyr.Stepanov at aricent.com
>
> cc <resiprocate-devel at list.resiprocate.org>
>
> Subject Re: [reSIProcate] Fw: CANCEL before provisional recieved.
>
>
>
>
>
>
>
>
>
>
>
> What is your app doing to signal its intent to tear down the call?
>
> Best regards,
> Byron Campen
>
>
> Yes,I'm using DUM ...
> Any suggestions?
>
> Best regards,
>
> Volodymyr Stepanov
>
>
>
> Byron Campen <bcampen at estacado.net>
> Sent by: resiprocate-devel-bounces at list.resiprocate.org
>
> 04.05.2007 18:05
>
>
>
>
> To Volodymyr.Stepanov at aricent.com
>
> cc resiprocate-devel <resiprocate-devel at list.resiprocate.org>
>
> Subject Re: [reSIProcate] Fw: CANCEL before provisional recieved.
>
>
>
>
>
>
>
>
>
>
>
>
> Are you using DUM? I got the impression that this was not the case.
>
> Best regards,
> Byron Campen
>
> FYI - DUM should be handling all of this.
>
>
>
> From: resiprocate-devel-bounces at list.resiprocate.org [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of Byron Campen
> Sent: Friday, May 04, 2007 10:44 AM
> To: Volodymyr.Stepanov at aricent.com
> Cc: resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] Fw: CANCEL before provisional recieved.
>
>
>
> If you are going to freeze the CANCEL transaction, it needs to be done at the TU. So, if your app decides to end a call, it needs to put some sort of note-to-self to send a CANCEL once a provisional comes in, and if a final response comes in, to send a BYE.
>
>
>
> Best regards,
>
> Byron Campen
>
>
> Byron Campen <bcampen at estacado.net>
>
> 04.05.2007 16:53
>
>
>
>
> To Volodymyr.Stepanov at aricent.com
>
> cc <resiprocate-devel at list.resiprocate.org>
>
> Subject Re: [reSIProcate] Fw: CANCEL before provisional recieved.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Sending a CANCEL before a provisional response is invalid behavior. Right now, the stack forges a CANCEL/200 and sends it to the TU, but does not allow the CANCEL to hit the wire. From here, if B never sends a provisional, the INVITE transaction will time-out, causing the stack to send a simulated INVITE/408. However, if B does respond, the call will continue normally. (This is something a TU must be prepared to handle; just because you get a CANCEL/200 doesn't mean the remote UAS will end the INVITE transaction.) If B does send a provisional, but never sends a final response, it is up to A to decide at what point it wishes to end the transaction. (The TU does this by sending a CANCEL; this will cause the stack to put a CANCEL on the wire, and start a timer that will cause the INVITE transaction to be torn down, if it never gets a response)
>
> Best regards,
> Byron Campen
>
>
>
>
>
> Lets try again :)
> B sends provisional,but there is large time gap between A INVITEs and B receives this INVITE, and answers back.
> I know that sending CANCEL before provisional is incorrect.
> I trying to find "standart" solution for ,maybe, waiting for provisional or "freeze" CANCEL transaction.
> Maybe there is another way to deal with my problem?
> Thanks.
>
> Sorry :)
>
> MSN : stepanov_v_m at hotmail.com
> ICQ : 272708933_______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
>
> resiprocate-devel mailing list
>
> resiprocate-devel at list.resiprocate.org
>
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> <smime.p7s>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
More information about the resiprocate-devel
mailing list