David,
I have also come across the same scenario. In the instance I worked
on it was a case of double jeopardy where the 486 response code back to the
B2BUA that processed calls for the domain maps this to local treatment and
therefore answers the call - terminating it on a media server to do so.
Creating from a signalling point of view from the user a 'successful'
call.
You perhaps will have the opportunity at the GW peforming the ISUP -
SIP mapping to customise the response returned but as you have pointed out
(RFC3261 / 3666) there may not be a 'better' response code. And if you did
say change the response code mapping from 486 to say 480 Temporarily
Unavailable, would that change the behaviour of your SIP server in
answering the call and playing double treatment ?, I doubt it.
I believe our exact scenario was triggered by calls to mobile numbers that
were for instance switched off resulting in the PSTN network announcement
"the mobile phone you are calling is currently switched off or not in a
mobile service area..." <--something like that.
Our kludge included mapping the non-PSTN second treatment played by
the media server to something forgiveable like a couple of seconds of fast
busy or 0.5 seconds of silence... before terminating the answered call with
a BYE and having the server flag the CDR so that the completed call is not
billable.
Regards - Wayne.
***********************************
David asked:
Here's a bit of a strange questions, but one who's answer eludes me.
I have a service that takes SIP calls and interacts with them. Sometimes
the service has to interact with calls that have not yet been answered
(they are in the equivalent of ALERTING on the ISDN side of things). So,
I get the INVITE, I send back a 183 to playback some service announcement
and now I want to hang-up on the call as "NORMAL" in the ISDN world.
However, since the call has not been answered, I can only send a 3xx-6xx
status message to end the call. There are no messages that seem to allow
me to do that. In the ISDN world I would simply release with normal as
the cause code.
I've looked in RFC 3666 and the best that it has is section 3.4, but that
releases with cause busy. That's unacceptable for the user experience as
it would cause the user to hear a service announcement followed by a busy
signal. Any of the interoperability documents for PSTN gateways (over
which I will likely have no control) only release with normal as a result
of a CANCEL or BYE. I can't send a CANCEL because I'm the recipient of
the call, and I can't send a BYE because I haven't answered the call; nor
do I want to.
Am I missing something?
David
--
[EMAIL PROTECTED] | phone: 902-832-2649 fax: 902-832-1015
"Complex problems have simple, neat and wrong solutions" - H. L. Menken
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.
This email, including all attachments, is confidential. If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments. Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error. If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
