Transfering SIP calls back out a SIP trunk

[baldwincl]

IP500 4.2.14
I have SIP trunks hooked up to an Alcatel OXE. Calls are working fine, i can conference and when i forward all than a single trunk is used while the call is in progress but when i try to transfer back out the sip trunk the transfer button just beeps.
System Status says
Extension = 500, Pressed Fixed Feature, Button = Transfer

Monitor doesn't show anything at all when i press transfer.

Doesn't look to me like it is passing the OXE any info.

The OXE tech said he is looking for the header "Replaces" RFC3891.

any ideas or am i going to have to set up a conference to transfer calls (wasting 2 trunks)?

 

[Bas1234]

On the sip line try to tick "RE-Invite Supported"

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________

 

[baldwincl]

no Change

 

[Bas1234]

Try to tick "Registration Required", set the codec settings to G.711 or G.729 on both systems DON'T leave them on Automatic.

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________

 

[baldwincl]

Thanks for the replies
registration was already required and i set it to 729 and still no change

 

[kholladay]

Do you have only 1 Call Appearance button or only 2 with “Reserve Last CA” enabled?

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[IPOfficeIreland]

How many vcm channels do you have available?

 

[baldwincl]

Sorry I guess I didn't explain myself very well.
I have 4 VCM Channels and 2 sip channels.
I successfully make the first call, hit transfer and the second call goes through on the second line with the first going on hold. When the second person picks up and I hit the transfer button that is when nothing happens.

 

[baldwincl]

Ok,
Looks like it only supports the following RFCs

2833 [7]


RTP Payload for DTMF digits, telephony tones and telephony signals.

3261 [8]


SIP Session Initiation Protocol.

3264 [11]


An Offer/Answer Model with Session Description Protocol (SDP).

3323 [14]


A Privacy Mechanism for SIP

3489 [18]


STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NAT's).

3824 [24]


Using E.164 Numbers with the Session Initiation Protocol (SIP).

E.164 is the ITU-T recommendation for international public telecommunication numbering plans.

So unless someone else knows otherwise I will assume there is no transfer.

 

[IPOfficeIreland]

It could be a vcm issue. Are you using an IP phone, if so can you test on a tdm.

Can you also go to monitor, enable all SIP, enable all System options, including Development Tracing. Close this window, on the toolbar across the top select Status -Voice compression (TI).

This will show you what VCM channels are being used. I suspect that you are using 2 for the incoming and so don't have enough to perform hold transfer actions.

Get the provider to lock down RFC2833 for DTMF rather than leaving it to auto. Post a full sip trace of the call sequence.