Controlled transfer to external number

[OXE_4400]

Hi,

Is it possible to return to URS strategy if external number doesn't answer or busy?
I am using TRoute['0123456789','',RouteTypeDirect,''].

[cavagnaro]

No

Enviado de meu C6602 usando Tapatalk

[Dionysis]

I've achieved this kind of thing using a SIP Server/SBC environment, but you need to transfer to a monitored DN, not an external number.  So if it's always the same number you're going to, you can create that number as a trunk group dn, and transfer to that.  In the options of your DN put a contact value that sends the call to your external MGW, then set the appropriate refer-enabled and oosp-transfer-enabled options.

This way the SIP Server doesn't remove itself from the path and you should be able to control the call after the transfer fails.

So in your example above:
Create a trunk group DN called "0123456789" with the option contact = <sbc ip address>:<sbc sip port>

Then TRoute['0123456789','',RouteTypeDirect,'']

You'll need to do some experimenting with the refer and oosp options though, can't remember those off the top of my head.

[cavagnaro]

Well conditions are many and not all implementation has a SIP server available for outgoing calls
Also, what happens if is an AA or VM who answers?
Knowing Oxe's, he is asking about an Alcatel architecture... Where no, is not possible to do without all that investment

Enviado de meu C6603 usando Tapatalk

[Dionysis]

Damned PBX's, always making life difficult.

[OXE_4400]

Not Alcatel T-server. SIP server case. Frankly speaking we have some Genesys SIP server installation behind Alcatel.

Dionysis,
Thank You.
Is it difficult for You to check for some additional details?

Yes. I need to control transfer to fixed external number (some external call center).

[Dionysis]

In that case, you might be able to use exactly the process I've defined. 

The refer and oosp settings may just work out of the box, there are only 2 values for each (true/false) and the combinations control what type of transfer you do for either a 2 step, or 1 step transfer (a TRoute counts as 1 step), INVITE, REINVITE or REFER.  You would need to experiment with what works best for your specific use case.  In my case, we set refer-enabled = false and oosp-transfer = true, which means you get a REFER on a single step transfer, but an INVITE when doing a 2 step.  How you set it will depend on how the interface to the outside world, assuming that'll be the OXE, reacts to each INVITE type.  There's a table in the SIP Server deployment guide detailing which combinations get what results.

To configure it:
- Create a DN of type "Trunk Group DN" in your SIP Server switch.  The number for this should be the exact number you need to dial from the SIP Server to go out through the Alcatel to the final destination.
- Set the contact option for that DN to be the SIP interface you would normally configure a trunk DN to point to.
- In your routing strategy, transfer to the number, then handle the red / green ports in IRD to do whatever you need them to.

It's pretty much as simple as that, let me know if you need any other info.

note: I did this with a Dialogic BN-2020 acting as an ISDN gateway, not an Alcatel so as soon as the config leaves Genesys I'll be of no help at all.

[genesysbasha]

Yes, It is possible.......

[nonny]

[b]  - In your routing strategy, transfer to the number, then handle the red / green ports in IRD to do whatever you need them to.[/b]

Silly question, but as far as red/green, what should you put to identify whether the call was answered or not vs some other error/fault on the red port?

[Dionysis]

In theory, you could do error segmentation on the red port to identify different types of error if you needed to.