< Previous by Date | Date Index | Next by Date > |
Thread Index | Next in Thread > |
Volodymyr Stepanov/R&D
Ukraine
10.05.2007 10:18 |
|
"Scott Godin"
<slgodin@xxxxxxxxxxxx>
08.05.2007 16:48 |
|
Byron Campen <bcampen@xxxxxxxxxxxx>
07.05.2007 23:24 |
|
Byron Campen <bcampen@xxxxxxxxxxxx>
Sent by: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx 04.05.2007 18:05 |
|
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 |
|
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>