o Iñaki Baz Castillo [06/03/08 14:46]:
>> It may well be that the user at that one extension noticed the caller id
>> was that nasty bill collector that he doesn't want to talk to. So he
>> pushed the "reject this call totally" button, and that resulted in the
>> 6xx response. Not sending the call to VM is exactly what was intended.
>
> Ok, but imagine my case. In calls from PSTN if the called returns 4XX/6XX I
> want to forward the request to a media server to reproduce an early
> announcement ("the number you are calling is not available now"). The called
> shouldn't have the possibility of avoiding this forwarding to the caller
> since it's a provider decission, non him decission. But 6XX breaks the
> provider if he is using a proxy and not a B2BUA.
if you really want to do that, even if your user (the callee) decided to
not take the call, it sounds to me like this is exactly a case for
B2BUA: the provider<->callee dialog is in no case to be continued. so,
if you want a caller<->provider dialog to continue in that case, you
need two dialogs, hence B2BUA.
BR,
Stefan Sayer
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
