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

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



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

Attachment: smime.p7s
Description: Binary data