IPO and SIP trunk expectation 2

[Signo]

HI everyone its been a long time since I have posted but I have a question some of you experts might be able to answer.

I have been tasked to test a sip trunk to IPO and one thing I have to test is blind transfer.

IPO is 10.1.0.3.0 build 2

My steps are make call into IPO sip trunk, answer, transfer, dial call, get ringing, complete. The call works but when I complete and the two calls are joined they stay up on the IPO using two channels. They hairpin through the IPO and consume resources. This is no better then an analog trunk at that point.

I have been doing hosted for the last few years and I am used to seeing a refer back to the switch and the calls join and the phone no longer is involved.

I never did sip trunks to IPO so I dont know what is normal. So if you use sip trunks can you comment on what the normal behavior is.

 

[janni78]

First of all you not testing blind transfer if you're waiting for dialtone.
Blind transfer would be to just transferring the call without checking for dialtone, think it can only be done from Softconsole.

In your hosted solution even if you use REFER you would still have 2 connections in the hosted platform even though the phone isn't involved.
Same in IPO, you have the incoming and outgoing leg but when the call is transferred the phone isn't involved.

Now you could tell the service provider to "take over" the call releasing it from the PBX all together if they support it, but haven't seen a provider that supports this yet without issues.


"Trying is the first step to failure..." - Homer

 

[intrigrant]

It is a feature called "Partial Rerouting" or "Path Replacement" and must be enabled on the provider side.

To invoke the feature IP Office must send a "302 Moved Temporary" message as part of the transfer, then the provider can redirect the call directly thus releasing the SIP cahnnels to the IP Office. Direct media path must be enabled to use the function.

Most providers do not support the feature because the have problems with billing these calls.
A provider using a decent SIP platform are capable to provide this feature though.

 

[Pepp77]

In the UK Gamma used to offer this and we actually used it as a selling point for one customer, only to then have Gamma remove it just as we were testing with this customer!!

| ACSS SME |

 

[VoIP Numpty]

There's a bunch of settings (all SIP providers seem to invent their own specific implementation) on the SIP trunk to use REFER for transfers on the same SIP trunk.

http://marketingtools.avaya.com/kno...ice/mergedProjects/manager/Html.SIP_Line.html

But you'll need to check what the ITSP supports and how they want it configuring, it maybe covered in the App Notes if there's one for your provider -

http://marketingtools.avaya.com/kno...LFILE=appnotes.xml&TEMPLATE=app_template.html

 

[Signo]

Janni78, I realize the transfer is not truly blind, and was wondering how you do a true blind transfer now I know. Thank you for that info.

As far as releasing the call from the PBX this was my goal. Since we are the provider of the SIP trunk we can change settings and we would like to provide what you describe. A lot of the interop documents say blind transfer was tested and worked, but not if the calls were taken off the IPO.

Intrigrant, Thanks for your description of what you expect to see for this to work. We have some call traces in with our platform provider to see what they think. I know they want to see a REFER but the 302 moved temporary has me interested. We are in the US and they are in the UK so it takes time to work on stuff.

pepp77, thanks for the info this reinforces the fact that this feature is problematic.

VoIP Numpty, Our platform provider did have interop notes but they were dated back years and IPO release 6. So a lot of things have changed since then.

I am working with our engineers and dont know SIP as good as they do, but they know nothing about IPO which is making this more difficult. I know enough about IPO to get by.

I told them I would ask the experts and your responses are greatly appreciated.

 

[intrigrant]

Maybe this is of your interest:

http://wiki.innovaphone.com/index.php?title=Course12:Advanced_-_SIP_Provider

They start with "Unfortunately, SIP trunk standardization is still in its early phase. As a result, there are a lot of minor and less minor kludges and pitfalls when it comes to interfacing to a SIP provider." which sounds like a realistic approach.

It is a article everybody here working with SIP should read, there is a lot to learn to be a better skilled technician.

When you perform manually a transfer, either a blind or consulted transfer then it is Partial Rerouting(PR), if a call is diverted sirectly(aka blind), either by a divert setting set by a user or through a ICR destination, then it is ReDirection(RD)

There is a differnce between them, always test both.

 

[Signo]

Thank you intrigrant I will be sure to read the article.

 

[IPGuru]

* given for the link
love this quote




Do things on the cheap & it will cost you dear

 

[Signo]

I wanted to thank everyone for their input on this matter.

Through testing using the input from here we have managed to find the issue preventing the transfers from working as expected.

We can successfully warm transfer a call, and the SIP channels clear, the the call stays connected to the remaining parties through our platform. We can do a semi-blind transfer, wait for ringing and the SIP channels clear, the call stays connected to the remaining parties. So the resources on the IP Office are not being consumed.

A true blind transfer with softconsole does not work but we see problems with the auth-digest from the IPO so we are leaning toward a IPO issue here. Now that we have successful transfers to compare its a little easier to see the problem.

Thanks so much for all the help. As a possible SIP trunk provider we want to have the best implantation possible for our customers and you all just help that happen in respect to IPO compatibility. We may not even offer the product depending on ROI, but who know.

 

[VoIP Numpty]

On that page I linked to previously there is a setting for "Blind REFER", though if the aut is an issue it maybe an IP Office bug.