On Fri, 2008-11-14 at 17:26 +0530, Akshata Saralaya wrote: > Hi All, > > While testing the blind transfer scenario, I came across a test in > which I have a doubt with the expected scenario. > > Scenario : > 1. Phone1 has international permission disabled ( Call controller ) > 2. Phone2 has international permission enabled (Callee ) > 3. Phone2 calls Phone1 > 4. Phone1 blind transfers to an international number > > As per our test cases expected result is : > Phone1 gets an error message stating that it is not authorized to dial > international numbers. Call should not get established. > > But the actual result is : > Call is established. > > Is this the expected behavior?
While possibly not the intuitive result, this is correct. In a blind transfer, the controlling phone (1 in this case) just instructs the transferred phone (2) to call a specified target. In sipXecs, we also cause the server to annotate that instruction with an extra parameter that confers the permissions of the controller on the transferee. Normally, this annotation will prevent the transferee from being challenged when they make the new call to the target. In this case, what happened is that the annotation was not sufficient, since 1 did not have the requisite permission, so the transferee was challenged, but since Phone2 has the permission, it was able to authenticate the call as itself and complete it. The results would have been different had Phone1 tried a consultative transfer - since Phone1 does not have international dialing permission, it would not have been able to set up the consultative outside call as the first step. This is why the REFER (with Replaces) to complete a consultative transfer is not challenged by the proxy the way a REFER without replaces (blind transfer) is - the authorization for the call to the target has already been done when the consultative leg is established. So... no bug... change your expected result. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
