Re: [reSIProcate] [recon-devel] Bad behaviour in forking
I'm pretty sure there is nothing illegal about sending a BYE to one
leg of a forked call, as long as a dialog has been established - which
is the case if the 180 response contains a to tag and contact header.
I don't think there is any guarantee that a proxy you are using must
cancel all other forks when one end point answers (although this is
how most proxies work).
I'm not sure why iptel Rtp-Proxy would have trouble with this, if it
is correctly doing dialog matching.
Note: I'm cross posting this question to resip-devel to see if anyone
else feels differently.
Scott
2009/2/20 Julio Cabezas <jcabezas@xxxxxxxxxxxxx>:
> Hi,
>
>
>
> In a test of testua with forking I observed a behavior that
> seems to be non-compliant.
>
>
>
> The setup:
>
> One testua.exe instance registered with an AOR1
>
> Two instances GUA1, GUA2 of a generic softphone registered both with an AOR2
>
> One proxy server (iptel.org)
>
>
>
> The test:
>
> testua places a call to AOR2
>
> The call is forked to both GUA1 and GUA2
>
> testua receives 180 from both GUAs via proxy
>
> GUA1 answers the call sending 200
>
> testua receives 200 from GUA1, sends ACK
>
> testua sends BYE to GUA2
> <== the bad
> behaviour, trying to "cancel" one of the branches
>
> proxy responds with 481 Call/Transaction does not
> exist to the BYE
>
>
>
>
>
> By the way, iptel.org seemed to be confounded with that,
> because its RTP-Proxy did not forward correctly the RTP packets of the
> established call...
>
>
>
>
>
> Best regards,
>
> Julio Cabezas
>
> _______________________________________________
> recon-devel mailing list
> recon-devel@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/recon-devel/
>