< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] Fw: Fw: CANCEL before provisional recieved.


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@xxxxxxxxxxx
<Volodymyr.Stepanov@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxx>

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@xxxxxxxxxxx
 ICQ : 272708933



 "Scott Godin" <slgodin@xxxxxxxxxxxx>

08.05.2007 16:48

To <Volodymyr.Stepanov@xxxxxxxxxxx>, "Byron Campen" <bcampen@xxxxxxxxxxxx>

cc <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxxxxxxx 
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of 
Volodymyr.Stepanov@xxxxxxxxxxx
 Sent: Tuesday, May 08, 2007 3:28 AM
 To: Byron Campen
 Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
 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@xxxxxxxxxxx
 ICQ : 272708933



 Byron Campen <bcampen@xxxxxxxxxxxx>

07.05.2007 23:24


To Volodymyr.Stepanov@xxxxxxxxxxx

cc <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxx>
 Sent by: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx

04.05.2007 18:05




To Volodymyr.Stepanov@xxxxxxxxxxx

cc resiprocate-devel <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxxxxxxx 
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Byron 
Campen
 Sent: Friday, May 04, 2007 10:44 AM
 To: Volodymyr.Stepanov@xxxxxxxxxxx
 Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
 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@xxxxxxxxxxxx>

04.05.2007 16:53




To Volodymyr.Stepanov@xxxxxxxxxxx

cc <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxxxx
 ICQ : 272708933_______________________________________________
 resiprocate-devel mailing list
 resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
 https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
 _______________________________________________
 resiprocate-devel mailing list
 resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
 https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel@xxxxxxxxxxxxxxxxxxxx

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel




 _______________________________________________
 resiprocate-devel mailing list
 resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
 https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
 <smime.p7s>






































_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel