I'd like to add one more item. We are having a great deal of trouble getting Verizon and Cisco to work together to resolve a question about the ISDN signaling when using the CC-Diversion header to redirect an unanswered call to an Octel 350 system hanging off a Verizon DMS100.

The redirection works, the CC-Diversion header is applied, the originally call number (OCN) is carried in the outbound signaling message but the caller either 1) gets the general voicemail greeting if the calling party number is not a valid voicemail box or 2) gets the voicemail greeting associated with the calling party mailbox if the calling party has a mailbox on the system. Yes I said *calling* party. The OCN seems to be ignored. I'm still working on this but if you are in a Centrex environment you may want to identify a telco support contact to help make the redirection work.

Just a thought - Steve

Christopher Crawford wrote:

Thanks for the help with this question. The manual provides an example for a creating a header when diverting to voicemail for a negative response. To support the draft http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-08.txt a reason (e.g. 486 busy here) would need to be understood in order to support the diversion header. From the example and the ser documentation, it appears as if there is no current method to detect exactly which 4xx response was returned. Is my statement correct?

(Clipped from ser user's documentation)

Example 3-11. Forwarding to PBX/Voicemail via Cisco Gateways route{ # if we do not get a positive reply, continue at reply_route[2] t_on_failure("2"); # forward the request to all destinations in destination set now

t_relay(); }

failure_route[2] { # request failed (no reply, busy, whatever) ... forward it again # to pbx's voicemail at phone number 6000 via Cisco gateway at # 192.168.10.10; append proprietary CC-Diversion header field with # original request uri in it, so that the gateway and voicemail # know, whom the request was originally intended for append_branch("sip:6000@192.168.10.10"); append_urihf("CC-Diversion: ", "\r\n"); t_relay(); }

Regards,

Chris

...

-----Original Message-----

...

Diversion header support

This example from administration guide may solve some of the problems you are solving or at least you can use it as a programming pattern: http://www.iptel.org/ser/doc/seruser/seruser.html#AEN1018

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi Christopher,

I'm using this method and it works fine for me:

failure_route[1] {

if(t_check_status("486")){ ~ #486 means busy ~ prefix("b"); ~ log(1,"The person is on the phone!!!\n"); ~ } else { ~ prefix("u");

~ log(1,"The person is unavailable!!!\n");

~ } } }

Best regards.

Christopher Crawford wrote: | Thanks for the help with this question. The manual provides an example | for a creating a header when diverting to voicemail for a negative | response. To support the draft | http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-08.txt a | reason (e.g. 486 busy here) would need to be understood in order to | support the diversion header. From the example and the ser | documentation, it appears as if there is no current method to detect | exactly which 4xx response was returned. Is my statement correct? | | (Clipped from ser user's documentation) | | Example 3-11. Forwarding to PBX/Voicemail via Cisco Gateways | route{ | # if we do not get a positive reply, continue at reply_route[2] | t_on_failure("2"); | # forward the request to all destinations in destination set now | | t_relay(); | } | | failure_route[2] { | # request failed (no reply, busy, whatever) ... forward it again | # to pbx's voicemail at phone number 6000 via Cisco gateway at | # 192.168.10.10; append proprietary CC-Diversion header field | with | # original request uri in it, so that the gateway and voicemail | # know, whom the request was originally intended for | append_branch("sip:6000@192.168.10.10"); | append_urihf("CC-Diversion: ", "\r\n"); | t_relay(); | } | | | Regards, | | Chris | | | |>-----Original Message----- |> |> |>>Diversion header support |> |>This example from administration guide may solve some of the problems |>you are solving or at least you can use it as a programming pattern: |>http://www.iptel.org/ser/doc/seruser/seruser.html#AEN1018 |> | | | _______________________________________________ | Serusers mailing list | serusers@lists.iptel.org | http://lists.iptel.org/mailman/listinfo/serusers | |

- -- ============================================ Rodrigo P. Telles telles@devel-it.com.br Gerente de Projetos Devel-IT - http://www.devel-it.com.br Grupo TDKOM ============================================