[OpenSIPS-Users] parallel forking and CANCEL/BYE

[Uwe Kastens]

Hello again,

I was wondering if there might be a bug with the correct handling of
Cancel in case of receiving and final answer.

I will fork one Call to 2 nodes. One node answers a little faster than
the other and will get the call. Opensips will send a CANCEL for the
other node which is sending a SIP/2.0 200 OK before receiving the
CANCEL. So this node is not answering with a 487 but with a 200/OK.

Opensips seems to drop the call leg and so the BYE from that node could
not be handled.

Is this behaviour RFC conform?

I will attach one ngrep and one opensips logfile

BR

Uwe




Uwe Kastens schrieb:
> Hi,
> 
> I am using opensips to fork calls to UAs which are registrered from 
> different IPs/Ports.
> 
> If one UA accepts the INVITE the other UAs will get a CANCEL.
> 
> Now I have one subscriber with 2 asterisk server which asked me to send 
> a BYE after the CANCEL. Otherwise he wants me to send an BYE which could 
> not be processed correctly on the opensips.
> 
> I am pretty sure, that this kind of handling would not be RFC conform 
> and so its not possible to handle this inside the routing script. Or did 
> I missed something?
> 
> BR
> 
> Uwe
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 

kiste lat: 54.322684, lon: 10.13586
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anon_log.gz
Type: application/x-gzip
Size: 9772 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20091020/804ad7a2/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anon_ngrep.gz
Type: application/x-gzip
Size: 1708 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20091020/804ad7a2/attachment-0001.bin