[reSIProcate] Fw: Fw: CANCEL before provisional recieved.
Scott Godin
slgodin at icescape.com
Thu May 10 08:02:36 CDT 2007
You would need to create your own AppDialogSet and pass into the
makeInviteSession call.
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: Thursday, May 10, 2007 3:19 AM
To: resiprocate-devel at list.resiprocate.org
Subject: [reSIProcate] Fw: 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
<Notes://UASVR3/C2257284005AA0DA/DABA975B9FB113EB852564B5001283EA/424685
BAC1E3AEE2C22572D5004BBBF1>
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
<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 <mailto:bcampen at estacado.net> >
Sent by: resiprocate-devel-bounces at list.resiprocate.org
<mailto:resiprocate-devel-bounces at list.resiprocate.org>
04.05.2007 18:05
To
Volodymyr.Stepanov at aricent.com <mailto:Volodymyr.Stepanov at aricent.com>
cc
resiprocate-devel <resiprocate-devel at list.resiprocate.org
<mailto: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>
[mailto: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
<mailto:Volodymyr.Stepanov at aricent.com>
Cc: resiprocate-devel at list.resiprocate.org
<mailto: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 <mailto:bcampen at estacado.net> >
04.05.2007 16:53
To
Volodymyr.Stepanov at aricent.com <mailto:Volodymyr.Stepanov at aricent.com>
cc
<resiprocate-devel at list.resiprocate.org
<mailto: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 <mailto:stepanov_v_m at hotmail.com>
ICQ : 272708933_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
<mailto:resiprocate-devel at list.resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
<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
<mailto:resiprocate-devel at list.resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
<smime.p7s>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070510/6648780a/attachment.htm>
More information about the resiprocate-devel
mailing list