SIP Trunk Interoperability Issue with TWC Business Class

[pmkr...@gmail.com]

We have been working with a TWC Business customer who migrated their analog phone lines to a TWC Business SIP trunk. Most/all of the North American cable companies are deploying SIP trunks using the Cablelabs PKT-SP-ESG-I01-101103 specification with an Edge Services Gateway (ESG). TWC uses an Innomedia SBC as their ESG with separate cable modem d/s and u/s spectrum for their SIP trunk service.

Because the SBC does not support REFERs (some auto-attendant forwards use REFERs), an unmanaged gateway cannot be used. A registered SIP trunk was built between Sipxcom and the ESG - NAT traversal was disabled, and the public IP address is defined as the IP address of the Sipxcom server. Sipxcom at this TWC customer is configured very similarly to this interoperability document - https://sipfoundry.atlassian.net/wiki/display/sipXecs/Interworking+with+Optimum+Business+SIP+Trunking.

Everything appears to be working properly except for placing external calls off of hold on private and shared lines, where audio is lost. As I compare the PCAP traces for a working ITSP against this TWC SIP trunk installation, what is happening is that Sipxcom is not issuing an INVITE back to the ITSP after the call is taken off of hold. I also notice that TWC is sending 11 digits as the callerid to Sipxbridge (have opened ticket with TWC on this).

In staring at both traces, everything looks identical in the SIP messaging and works correctly (e.g. MOH) until the call is taken off of hold (see attached graphic). Is there another setting in Sipxcom that can force the INVITE back to TWC when the caller goes off hold.

This is a 14.04 Update 4 system with VVX400 phones at 4.1.7 firmware.

Any insights are greatly appreciated.

All the best
Peter

 

[Joegen Baclor]

It's hard to tell without seeing actual packet captures.  Can you attach the pcap instead?

--
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 http://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/d28d9215-a384-4488-abab-deb8e1af4442%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pmkr...@gmail.com]

Hi Joegen - many thanks. I am unable to strip some customer-proprietary information from the pcaps. Is there an email address where I can forward the pcaps to you?

All the best
Peter

[Joegen Baclor]

jba...@ezuce.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/e04688f9-dbc7-4bac-ab1e-8a32689e0981%40googlegroups.com.

[Joegen Baclor]

I got the pcap and have analyzed the working and the non-working captures.  If you filter out the leg from openuc to the polycom phone using sip.Call-ID == "OTY2NzI2MzE4NGRkMzFhN2E1MzU1ZmVmZDNlZWFmMmM.-0" as the filter, you would be able to see the message exchange.   There is something there that is peculiar packet 6128 is the initial hold attempt.  The CSeq fvalue for this INVITE is 1.  So far so good since this is the first request from the phone towards the caller.   This is followed by a BYE initiated by Polycom in packet 7161.  If you take a look at the CSeq of this BYE, you will see that the value is 3.   It skipped by one.  Therefore, there is a missing transaction that is not represented in this pcap.  The only way that could happen is if wireshark is unable to parse the message properly as SIP or tthe phone did send a second request (unhold) and it was lost in the network.  

Another peculiar thing I have noticed is that the request URI sent by Polycom is sip:7...@192.168.1.4:5090;x-sipX-nonat.  Notice that the user here is not the caller but the user-id of the Polycom.  This is not proper behavior.  The contact sent by sipxbridge is <sip:16463...@192.168.1.4:5090>

These two peculiar behavior of Polycom can only mean one thing.  There is an ALG in your client premises and messing around with SIP.  Get rid of it.

On 05/16/2015 03:04 AM, pmkr...@gmail.com wrote:

[pmkr...@gmail.com]

Thanks Joegen - excellent analysis, and always learn something new from your insights.

Let me do a stare-compare of the two pcaps again using your feedback and then respond back to TWC. It took some firmware upgrades with the Cablevision ESG (Edgemarc) to get full feature stability with Sipxecs, so am not surprised with your ALG conclusions. The good news is that the cable companies are large enough to get these types of issues addressed in a timely fashion.

Will keep you updated.

All the best
Peter

[pmkr...@gmail.com]

An brief update. I put a trace on one of the phones in my lab connected remotely via VPN to the customer system. When the phone came off hold, it wanted to issue an INVITE to the extension at port 5090 - those invites left my network okay but didn't reach the customer Sipxcom server. It turns out the customer router had ALG enabled - after disabling, we were able to take a private or shared line on one phone, take it off hold and maintain the audio connection.

However when a shared line across two phones is defined, one phone answers the call, puts it on hold, and then the call is answered on the other phone, the audio is lost. In analyzing the packet capture, the bearer path is always sent through Sipxbridge when the call is taken on and off hold from the same phone. However, when the second phone picks up the shared line, Sipxbridge instructs the ESG via SDP to send the RTP stream directly to the phone (a proxy optimization?).  The ESG sends RTP traffic using the correct phone IP address, but with the MAC address of the Sipxcom server. The Sipxcom server picks up the RTP packet from the ESG (it's in the packet capture) and immediately discards it.

Have passed this along to the TWC technical folks.

Many thanks again for the assistance!

Peter

[Joegen Baclor]

Glad to help.  Send beer.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/619dc54a-7483-4ce1-b6b2-9fe7503b49e2%40googlegroups.com.

[pmkr...@gmail.com]

Certainly Joegen ... let me know where to send! While you're waiting though, I have another question :). We worked with TWC this morning to fix some of the ESG routing problems but one issue remains. When a shared line is answered by one phone, put on hold, and then picked up by another phone with the same shared line, there is no audio on either end (external phone or phone attached to Sipxcom). What is happening is as follows:

• Incoming call is answered by shared line on phone 1. Both the SIP signaling and RTP go through Sipxcom
• Call is put on hold by phone 1. As long as Phone 1 takes call off of hold and puts back on hold, everything works fine. SIP signaling and RTP go through Sipxcom.
  
• If phone 2 picks up the shared line, Sipxcom instructs the ESG to send the RTP traffic directly to Phone 2. In looking at the packet captures from the phone and Sipxcom perspective, the ESG is sending RTP traffic directly to the phone in the downstream direction. However in the upstream direction, the phone is sending RTP packets to Sipxcom, which then relays them to the ESG. The ESG is expecting RTP packets to come from the phone, not Sipxcom, so drops the packets.
  

We have gone in this direction using Sipxbridge and SIP trunking as the ESG does not support REFERs. Is there any way to force Sipxcom to send all SIP signaling and RTP traffic through Sipxbridge.

I have PCAPs from the Sipxcom and Phone perspective if needed.

[pmkr...@gmail.com]

We have done some more work on the TWC Business SIP trunk interoperability issue. TWC have made adjustments to their Edge Services Gateway (ESG) but there is still no audio on a shared line after putting the call on hold on one phone and picking it up on a second phone. Last evening, I captured a trace of the same call flow using Cablevision's ESG with Sipx release 4.6 update 10 where this is working without issue and analyzed the SIP messages (see attached image) against the TWC system.

With sipXcom 14.04 update 4, the voice server instructs the ESG to send the outbound RTP bearer path directly to the phone instead of relaying through the voice server. I did an audit of the Sipx configurations, and the SIP trunk/NAT traversal settings appear identical (except for dialplan).

I can make copies of the pcaps available offline (pe...@louisavoice.com) - any further insights is greatly appreciated.

Many thanks in advance for the support.

Peter

[pmkr...@gmail.com]

I did some more lab work on this interoperability issue using a Sangoma SBC to emulate TWC's ESG at the customer site. I also captured a trace from a customer system running Sipx 4.6 update 10 with Cablevision SIP trunks (same architecture)  and analyzed the signaling - my findings:

• With Sipx 4.6 update 10 and Cablevision's ESG, the bearer path always went between Sipxbridge and the ESG,never directly to the phones.
• The TWC customer Sipxcom server is running 14.04 update 4. In the lab, I tested with Sipxcom 14.04 update 3 and 14.10 update 1 with the Sangoma SBC to see whether this issue could be replicated - the voice server and BLA behaved identically to Sipx update 10 - the bearer path always goes through Sipxcom and not between the phones and SBC.
  
• What I did notice during this effort is that a restart of Sipxbridge after significant SBC changes / testing or pushing system profiles was not sufficient to clear trunk/nat states on the voice server, but a reboot of Sipxcom reset all states. I encountered this twice, but was unable to repeat this issue consistently.
  

I recommended a reboot of the customer system and resumption of interoperability testing.

Peter

[Michael Picher]

Peter, do you have an outbound proxy set on the phones?  If not, try adding one.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/2711db13-8f5c-42c4-a0fc-d2cca95bdf58%40googlegroups.com.

[pmkr...@gmail.com]

The customer system was restarted last evening, and the RTP bearer path issue still exists with BLA enabled lines and Sipxbridge instructs the TWC ESG to send the bear path directly to the phone.

In quickly comparing this TWC business trace to working traces with Sipxcom and Optimum Business's ESG and lab SBC emulating the ESG, I have noticed the following:

• With the lab SBC and Optimum Business traces, when the call is taken off hold and Sipxbridge issues the Re-invite back to the ESG/SBC, the Optimum ESG and SBC responds with a 200 OK and does not request authentication credentials.
  
• With TWC, their ESG responds back with authentication credentials, even though the tag information on the RE-INVITE  from Sipxbridge to the TWC ESG is similar what we're seeing with the working Optimum ESG and lab SBC traces.  

From call flow examples I've seen in IETF documents, re-invites do not normally require authentication - would anyone know whether authentication on re-invites is allowed? The secondary question is whether anyone would know how Sipxbridge would respond to authentication requests from an ESG on a re-invite - e.g. when it receives the authentication request, Sipxbridge thinks the ESG is a phone, and therefore sends the ESG the IP address of the phone taking the phone off of hold rather than the voice server IP address ...

I'm asking TWC to see whether authentication can be disabled for re-invites.

Peter

[pmkr...@gmail.com]

An update - I managed to duplicate the TWC ESG behavior in the lab using an SBC without authentication after the re-invite when the call is taken off hold. Sipxbridge for some reason instructs the SBC/ESG to send the bearer path directly to the phone instead of Sipxcom. I went through the call flows for each tag associated with the various invites for this call and benchmarked against the working Optimum trace I captured several days ago. Everything looks identical except for the SDP  to the ESG to send RTP traffic to the phone rather than Sipxcom.

I must be missing something obvious :(. Attached are links to the lab pcap file and lab set setup.

Any insights are greatly appreciated.

Peter

https://www.dropbox.com/s/q5sjddy5pjyf37l/Lab%20Configuration.pptx?dl=0
https://www.dropbox.com/s/idvjyrolsf3x6f2/sbctosipx.pcap?dl=0

[Todd Hodgen]

Question – if you are using a Session Border Controller, why would you be using the sipxbridge in your configuration?  Shouldn’t your SBC just be defined as an unmanaged gateway, and it will do the bridging required for the calls?     I believe you should only be using the bridge feature when you don’t have a session border controller in the call path to an ITSP.

 

Todd R. Hodgen

President / Founder

Sound IP Telecom

http://SIPTelecom.systems

206-432-4344 - Direct

206-390-4689 - Cell

 

Your Puget Sound Telcom Partner

 

Do you Like Snow, Rain, Sleet, Hail, Thunder, Lightning?

If you do, then you will love the Cloud!

 

We appreciate your business referrals!

A Division of Misiu Systems LLC

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/1e8d1ccd-cea9-49bc-a885-fb09c78d2917%40googlegroups.com.

[pmkr...@gmail.com]

The initial post on this thread (and know this is a long post) answers this question Todd. The ESG as defined by Packetcable (and certainly the TWC implementation) does not support REFERs, which is used by the autoattendants to forward calls when using an unmanaged gateway. By using Sipxbridge and registered trunks, Autoattendant transfers are issued to the ESG as re-invites by Sipxcom.

If we can get through this current issue, and given that all cable companies adhere to Packetcable standards when deploying their networks, Sipxcom would be cable-company ready with their SIP trunk offerings (with QoS for voice) across all operators in North America with very little changes required between operators.

Peter

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

[George Niculae]

Peter,

I think we already have the solution for this, have you tried to turn this settings on true in System > Voicemail?

George

Transfer By Bridging the call	true false	(Default: false)
	Bridge call for transfer through IVR / AutoAttendant (default transfer method use SIP REFER method) Enable this option to fix integration with ITSPs / SBCs that does not support SIP REFER and if you want to have ringback played while transferring call.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/1e8d1ccd-cea9-49bc-a885-fb09c78d2917%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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 http://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/9c9df7cf-480c-4397-8e33-c1f79c454990%40googlegroups.com.

[pmkr...@gmail.com]

Thanks George - I just tested this capability with 15.05 with a simulated cable ESG configuration with unmanaged gateway from Sipxcom to the ESG/SBC and this does indeed provide the solution we are looking for.

Quick question - the customer is currently running on release 14.04 update 4. Is it safe to update the repo file to point to baseurl=http://download.sipxcom.org/pub/sipXecs/15.05/CentOS_6/$basearch and then do a yum update to get the customer to 15.05, or do advise building a new 15.05 system from scratch and restoring from backup?

Appreciate the support.

Peter

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 http://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/1e8d1ccd-cea9-49bc-a885-fb09c78d2917%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Picher]

Yes.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/1e8d1ccd-cea9-49bc-a885-fb09c78d2917%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 http://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/9c9df7cf-480c-4397-8e33-c1f79c454990%40googlegroups.com.

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

--
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 http://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/bdeabd72-e2c3-452a-8a12-c4a06f3c44e4%40googlegroups.com.