[Kamailio-Users] Stupid softswitch sending a CANCEL with "To tag" in parallel forking

Daniel-Constantin Mierla miconda at gmail.com
Tue Sep 22 18:46:09 CEST 2009


Hello,

On 22.09.2009 18:38 Uhr, Iñaki Baz Castillo wrote:
> Hi, I've experimenting an absurd issue when a softswitch calls to
> Kamailio and receives two 180 (with different To tags) due to parallel
> forking made by Kamailio.
>
> When the softswitch receives the second 180 (with the second To tag)
> it sends a ridiculous CANCEL with To tag matching the second To tag
> received (yes, a CANCEL with To tag !!!).
>
> Of course Kamailio replies "403 Why do you send a CANCEL with To tag?
> please read the RFC 3261". Unfortunatelly the softswitch didn't go to
> the school and ignores the 403 by repeating the CANCEL. And the worst,
> when *any* of the ringing phones answerw, the softswitch ignores the
> 200 so the call is never established.
>
> IMHO there is nothing I can do to "fix" this stupid issue. I've tried
> to reply 200 for the CANCEL but the softswitch is not happy (it seems
> that it expects the 487 from the canceled branch). And of course, if I
> do "t_relay()" for the CANCEL then Kamailio cancels both branches (the
> correct behavior).
>
> The only hyper exotic "solution" I can imagine is the following:
>
> - Kamailio receives the wrong CANCEL with To tag "2".
> - Reply 200 for the CANCEL to make the softswitch happy.
> - Reply 487 with To tag "2" to make the softswitch happy (IMHO this is
> not possible).
> - Generate a spoofed BYE for the second branch (that with To tag "2").
>
> Of course, this is not possible with dialog module as it doesn't
> handle parallel forking.
>
> Any suggestion? (yes, I would like to kill the softswitch).
>   

try to use onreply route and remove the tag parameter from the To header 
(eventually remove contact header so no much indication about who 
replies). Maybe the softswitch goes ok this time. Probably is better to 
drop 183 in such case.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/





More information about the sr-users mailing list