Re: [reSIProcate] Forked INVITEs
I am using DUM.
I have done more investigation into this and changed my code so that on
canceling the call, I close all the call legs through InviteSession::end( )
and that seems to terminate everything properly, sending a BYE to each leg
(urg, I guess I should say "dialog" and not leg), no 481 errors anymore.
Eyebeam does the same, it also sends a BYE. Or should I send a CANCEL?
I am still seeing 481 errors when terminating a call that has been
established after forking. I noticed DUM keeps open handles for all call
legs, even after one answers. When I terminate the active call leg, it
takes about 20 seconds for DUM to terminate the other call legs by sending
a BYE (and it receives 481 in response to the BYE). If I try to terminate
all the call legs after an established call, I get 481s (except for the
active call leg) but the handles in DUM are closed right away (onTerminated
event being fired).
CG
Robert Sparks To
<rjsparks@nostrum Christian_Gavin@xxxxxxxxxxxx
.com> cc
resiprocate-devel@xxxxxxxxxxxxxxxxx
rg
01/17/2006 11:09 Subject
AM Re: [reSIProcate] Forked INVITEs
Chris -
The call flow you're seeing (through the INVITEs and CANCELs anyhow)
is correct.
When a proxy forks it is only going to forward one final response
(when that response
is non-2xx) to an INVITE. It's possible to get more than one 2xx, but
that's an edge case
that is made as unlikely as possible by the rules in section 16 of
3261. You will never
see both a 2xx final response and some other non-2xx final response.
Now, for the BYE question. The protocol is doing the right thing
given that a BYE was
sent, but sending the BYE was (probably) silly. Are you using DUM or
the stack directly
for this flow? Were the 180s using the 100rel extension?
RjS
On Jan 16, 2006, at 11:49 AM, Christian_Gavin@xxxxxxxxxxxx wrote:
> Hi,
>
> I am testing the following scenario with resip 0.9 on WinXP. Server
> is SER
> 0.9 on Solaris.
>
> One client is registered as sip:chris@xxxxxxxxxx (server.com is a
> placeholder for the SIP server I am using). Let's call this client A.
>
> Two other clients are registered as sip:chris2@xxxxxxxxxx (let's
> call these
> client B and client C). Client A calls B and C and then cancels the
> INVITE:
>
> - chris INVITEs chris2
>
> - both clients registered under chris2 (client B and C) ring, send 180
> Ringing to server which is turn sends both 180 Ringing to chris
>
> - chris cancels the INVITE
>
> - chris receives a 200 Canceling from the server
>
> - clients B and C receive a Cancel
>
> - B and C send a 200 OK in response to the Cancel and a 487
> Request
> Terminated to the server
>
> - the server sends ACKs to B and C
>
> - chris receives a 487 Request Terminated from the server (with
> same To:
> and From: tags as specified in the first 180 Ringing coming from
> client B)
>
> - chris ACKs the 487 Request Terminated
>
> At this time, B and C are done with canceling. However, chris
> (client A)
> has only received one 487 Request Terminated from the server,
> corresponding
> to the call leg A <-> B. Client A thinks the extra call leg created by
> forking (A <-> C) still exists, and 20 seconds later, reSIProcate
> on client
> A sends a BYE to client C to terminated this call leg. Client C
> replies
> with a 481 Call / Transaction Does Not Exist.
>
> Shouldn't reSIProcate automatically close all call legs once the
> initial
> INVITE has been canceled? Or should the server send an extra 487 to
> chris
> to indicate that this second call leg was terminated?
>
> Thanks,
> Christian
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel