Transfer by Bridging a Call in 17.04

[pmkr...@gmail.com]

I was doing some traces today trying to troubleshoot call transfers with a T1/SIP gateway using release 17.04. I captured PCAPs with the System->Voicemail->Transfer by Bridging a call option enabled and disabled - in both cases, identical PCAPs appeared to be generated with REFERs issued. I was expecting no REFERs issued when the setting was enabled.

Has anyone else encountered this, or am I interpreting the settings and results incorrectly.

Many thanks in advance.

All the best
Peter

[Mihai Costache]

Hi Peter

That option applies just for the calls that are passing through AA

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/e1dfa8f1-05a7-4a1d-bb09-b007344583f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pmkr...@gmail.com]

Many thanks Mihai - and now understand. All the best Peter

On Wednesday, May 24, 2017 at 12:02:44 AM UTC-4, Mihai Costache wrote:

Hi Peter

That option applies just for the calls that are passing through AA

On 24 May 2017 12:10 am, <pmkr...@gmail.com> wrote:

I was doing some traces today trying to troubleshoot call transfers with a T1/SIP gateway using release 17.04. I captured PCAPs with the System->Voicemail->Transfer by Bridging a call option enabled and disabled - in both cases, identical PCAPs appeared to be generated with REFERs issued. I was expecting no REFERs issued when the setting was enabled.

Has anyone else encountered this, or am I interpreting the settings and results incorrectly.

Many thanks in advance.

All the best
Peter

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.

[Gerald Drouillard]

We had a problem where only the calls going through the AA were bridged.  We had to redirect the ITSP's IP incoming on 5060 to 5080 via a iptables rule on the server to get non AA calls to be able to transfer.

--

You received this message because you are subscribed to the Google Groups "sipxcom-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/e1dfa8f1-05a7-4a1d-bb09-b007344583f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards
--------------------------------------
Gerald Drouillard
Cell: 734.502.4356

[pmkr...@gmail.com]

Hi Gerald - we're experiencing precisely the same problem with this T1/SIP gateway - only AA callas are bridged. Non-AA calls fail to transfer correctly - I've opened up a ticket with the manufacturer and provided them with a pcap of a successful transfer from a Sangoma SBC.

Can you provide more details on your workaround - are you using IPTables to haripin the signaling through Sipxbridge?

Many thanks in advance.

All the best
Peter

On Wednesday, May 24, 2017 at 4:20:15 PM UTC-4, Gerald Drouillard wrote:

We had a problem where only the calls going through the AA were bridged.  We had to redirect the ITSP's IP incoming on 5060 to 5080 via a iptables rule on the server to get non AA calls to be able to transfer.

On Tue, May 23, 2017 at 5:09 PM, <pmkr...@gmail.com> wrote:

I was doing some traces today trying to troubleshoot call transfers with a T1/SIP gateway using release 17.04. I captured PCAPs with the System->Voicemail->Transfer by Bridging a call option enabled and disabled - in both cases, identical PCAPs appeared to be generated with REFERs issued. I was expecting no REFERs issued when the setting was enabled.

Has anyone else encountered this, or am I interpreting the settings and results incorrectly.

Many thanks in advance.

All the best
Peter

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/e1dfa8f1-05a7-4a1d-bb09-b007344583f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mihai Costache]

Hi guys,
""We had to redirect the ITSP's IP incoming on 5060 to 5080"" --> means that you sent the calls to sipxbrigde (internal SBC) If I remember correctly the issue then was that your ITSP could not sent to 5080 and calls were sent directly to proxy.

Yes if you need to bridge calls you can use sipxbridge, also sipxbridge transforms a REFER to a re Invite ... check this link
http://wiki.sipxcom.org/display/sipXcom/SIP+Trunking

"Supports call transfers locally: Call transfers are supported without sending the REFER to the ITSP. Therefore, it can handle both blind and consultative transfers and it is possible to transfer in or outbound calls via an ITSP back out to the ITSP (hair-pinned transfers)."

Good pointing Gerald

Best Regards,

Mihai Costache

"No problem can withstand the assault of sustained thinking. "

                                -  Voltaire

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/0681250b-d487-4850-bf8b-d4ad92dd5062%40googlegroups.com.

[Gerald Drouillard]

If you cannot get the ITSP to send inbound calls on port 5080 then:

iptables -t nat -F

iptables -A PREROUTING -t nat -i eth0 -s IP.OF.YOUR.ITSP -p udp --dport 5060 -j REDIRECT --to-port 5080

iptables -L-n -t nat

iptables-save >/etc/sysconfig/iptables

chkconfig iptables on

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/0681250b-d487-4850-bf8b-d4ad92dd5062%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[pmkr...@gmail.com]

Thanks Gerald - I tested this with a Sangoma SBC provisioning the SIP profile facing Sipxcom to use port 5080 (bypassing the attached procedure I assume and thank you). Incoming external calls through the SBC to Sipxcom worked, including call transfer. However outgoing external calls through Sipxcom failed - the call signaling never left Sipxcom (17.04). I'm still working through the details. If this works, we'll test onsite using the production Patton 4970 gateway.

Is anyone working with the Patton T1/SIP gateway using 17.04 and have call transfers on Polycom phones successfully working? We have an incident open with Patton here ...

All the best
Peter

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/0681250b-d487-4850-bf8b-d4ad92dd5062%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gerald Drouillard]

On Wed, May 31, 2017 at 11:02 AM, <pmkr...@gmail.com> wrote:

Thanks Gerald - I tested this with a Sangoma SBC provisioning the SIP profile facing Sipxcom to use port 5080 (bypassing the attached procedure I assume and thank you). Incoming external calls through the SBC to Sipxcom worked, including call transfer. However outgoing external calls through Sipxcom failed - the call signaling never left Sipxcom (17.04). I'm still working through the details. If this works, we'll test onsite using the production Patton 4970 gateway.

Is anyone working with the Patton T1/SIP gateway using 17.04 and have call transfers on Polycom phones successfully working? We have an incident open with Patton here ...

Do you have the gateway setup as a "sip trunk" or "unmanaged gateway" in sipx?  It probably needs to be a sip trunk for bridging to work properly.

[pmkr...@gmail.com]

Thanks Gerald - the gateway was indeed set up as a SIP trunk, but on a HA cluster. I'm in the process of replicating the tests on a standalone system.

All the best
Peter

[pmkr...@gmail.com]

On a standalone Sipxcom system with an SBC, I am now able to successfully place incoming and outgoing calls using Sipxbridge.

Not sure I want to use Sipxbridge on an HA cluster, even if it's only running on the primary node and this technique works. Will test further.

Thanks again Gerald for the support here.

All the best
Peter

[pmkr...@gmail.com]

Believe we have gotten to the root cause on why non-AA transfers using the Patton 4970 and Sipxcom 17.04 was not working. By default, the Patton does not process REFERs from 'untrusted nodes'. Although Sipxcom is defined as a trusted node in the Patton gateway, the phones are not. The Patton responds with a 503 service unavailable to the REFER request. There is an option in the gateway to disable that security check - once disabled, blind/consultative transfers started working.

All the best
Peter

[Benedikt Machens]

Hi Peter,

the phones do not need to be "trusted" by the Patton gateway. Normally every SIP Traffic flows over a Proxy so you need only them in the trust list. It sounds wrong if a phone communicates direclty with the Patton without the Proxy.



Regards,
Benedikt

[pmkr...@gmail.com]

Hi Benedikt,

You may be correct here - the Patton 6.9 configuration guide states that 503 service unavailable is generated by default when coming from an untrusted node. In the guide, trusted nodes are defined (my understanding) as IP addresses or fqdns in the remote statements included as part of SIP interfaces (which are  Sipxcom IP addresses). The 503 service unavailable comes after Sipxcom sends a REFER to the Patton gateway as part of a blind/consultative transfer, so if Sipxcom is trusted by the Patton, then the only other component 'untrusted' are the phones. Your response reminded me that we made one more change - the DNS server for the Patton was pointed at at Sipxcom DNS server. In the the REFER sent by Sipxcom, the REFER-FROM and REFER-TO addresses use the SIP domain (e.g. lvtest.com) rather than the actual IP address - the Patton may also be generating the 503 Service unavailable message because it cannot resolve the SIP domain when it tries to generate the INVITE using the REFER-TO field. This is easy enough to validate ... thanks for responding!

All the best
Peter

[Benedikt Machens]

Hi,

i see this behavior with Yealink phones because they dont have to use a outbound proxy. So without SIP domain inside FROM or TO they try to by-pass the SipXcom and communicate directly with the Patton which fails.

Regards,
Benedikt

[pmkr...@gmail.com]

Understood. We just turned on the 503 service unavailable check on the Patton again and placed some test calls - transfers work so the issue was an incorrect DNS server address. Vielen Dank nochmal Benedikt. All the best Peter