2009/1/15 Bernhard Suttner :
> The Refer-To Number is correct, but I want to transfer to an unknown
> number (unknown on the PBX side). I have tested this scenario with some
> others PBX's and they response f.e. with Forbidden. In that case the
> dialog will not be destroyed. Therefore I think this
Hi,
The Refer-To Number is correct, but I want to transfer to an unknown
number (unknown on the PBX side). I have tested this scenario with some
others PBX's and they response f.e. with Forbidden. In that case the
dialog will not be destroyed. Therefore I think this should also work
with Asterisk.
2009/1/14 Bernhard Suttner :
> So, if you have an Asterisk PBX, you have to allow the 484, because
> Asterisk PBX will cancel the REFER with 484.
It does not like your Refer-To header?
> sip/sip_util.c
>
> case 484: /* Address Incomplete */
> case 485: /* Ambiguous */
>/** @par 484 Address
Hi,
I have found the solution for me.
So, if you have an Asterisk PBX, you have to allow the 484, because
Asterisk PBX will cancel the REFER with 484.
sip/sip_util.c
case 484: /* Address Incomplete */
case 485: /* Ambiguous */
/** @par 484 Address Incomplete and 485 Ambiguous
Hi,
If I senda refer to the PBX, the PBX does answer with 484 Address
Incomplete. Afterwards, the sofia sip stack does change the call state
from ready to terminated and will fire and event to the application
which does hangup the call. Is there any reason to do it like that? If
I get a 403 Forbi
