Re: Pcap

[Guido Schmidt]

On Thu Dec 31, 2015 at 3:07 PM Tommy Laino wrote:

> 1.Can you grab a pcap from tcpdump or wireshark. The ones from Homer
> don’t show much information on your connection to the ITSP

The first file is a tcpdump on our PBX. The second one is from the
WAN-port on the firewall (using pfSense's built-in packet capture tool,
limited to traffic from and to the ISP's IP).


> 2.This appears that you are using 5060 as your registration port on
> SipXecs. Is that correct?

Do you mean the registrar config? In that case no, it is set to the
default, 5070.


> 3.What type of firewall are you using? What kind of NAT is setup on it?

The firewall is a pfSense. I set it up to use symmetrical NAT for all
outgoing traffic from the PBX. Also incoming port 5070, 5080 and
30000-31000 are forwarded to the PBX (per ITSP docs, although when I
registered one phone directly with the ITSP it seems only 5080 was
necessary).


Guido Schmidt
--
Schalloch Musikhandel GmbH
Percussionsabteilung
Firmensitz: Karolinenstraße 4-5, 20357 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 22770
Geschäftsführer: Christoph Scheffler
Tel 040-43 84 94
Fax 040-430 29 47

Öffnungszeiten:
Mo-Mi 10-19 Uhr
Do+Fr 10-20 Uhr
Sa 10-16 Uhr

Sie erreichen mich:
Mo 13-19 Uhr
Di+Do 10-19 Uhr
Jeden 2. Sa 10-16 Uhr

[Todd Hodgen]

5070 won't be necessary on the firewall, but 5080 will.

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

--
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/568AB11B.6080009%40schalloch.de.
For more options, visit https://groups.google.com/d/optout.

[pmkr...@gmail.com]

Guten Abend Guido,

I took a peak at your PCAPs - if I interpret your PCAP correctly, 192.168.0.130 is the edge IMS proxy (or gateway) provided by your ITSP and sits inside your network (the registers do not appear in the pfsense pcap). The Sipxcom voice server is using IP address 192.168.0.120. It looks like the ITSP edge proxy is being programmed to register to Sipxbridge and uses port 5060, and the core ITSP proxy (217.0.23.100) is hardcoded to send invites using port 5080. The core proxy then does not respond with authentication credentials (it may be the edge proxy's responsibility).

My suggestion on your next steps is to work with the ITSP (or their GUI interfaces) to have Sipxbridge register to the edge proxy. The edge proxy will provide username/password credentials that will then be provisioned in Sipxbridge. When Sipxbridge registers to the edge proxy, its source port will be 5080 - I would assume that the edxge proxy will pass that 5080 port information to the core proxy.

The cable companies(called MSOs) in North America have incorporated IMS principles into their Packetcable architecture for their SIP trunk offerings for enterprises - the implementations vary by provider. These two wiki pages may help you http://wiki.sipxcom.org/display/sipXcom/Interworking+with+Cablevision+Optimum+Business+SIP+Trunks and http://wiki.sipxcom.org/display/sipXcom/Interworking+SipXcom+with+TWC+SIP+Trunks.

Peter

[Michael Picher]

Well, Technion nothing can register to sipxbridge.  SipXbridge can register to something...

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/69e83962-1bd0-414d-b2d5-f72c5fcf6354%40googlegroups.com.

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

--

Thanks,

   Mike

-----------------------------------------------------------------------------------------

There are 10 types of people in this world...  Those who understand binary and those who don't.

[Michael Picher]

Technion... Hahaha. Technically... Stupid autocorrect.

[rda...@mppanthers.org]

Thanks Mike for the responses and insight - much appreciated. So you know, we have a Pfsense<->Sipxcom configuration in our lab, and was able to replicate Guido's configuration against a NA ITSP. My response was based on a 30 minute analysis and stare/compare of Guido's pcaps against pcaps from a NA ITSP. Absent of any details, I made some strawman assumptions from the PCAP Guido provided. Any errors in analysis are mine and mine alone - my response was in the spirit of helping others in the community. 

So you also know, I have very warm memories of running cross-country meets at Bates College while in university (think this is your neck of the woods). I still run daily, often listening to Podcasts  - at my age, the goal is weight management more than 'personal best times'. On my run this afternoon I listened to this podcast - thought you might enjoy it https://www.youtube.com/watch?v=ReRcHdeUG9Y.

Keep up the great work at eZuce and with the open source community. 

All the best

Peter

[Michael Picher]

Wasn't trying to be critical Peter, I hope you didn't take it that way.  Just wanted to clarify that registration of a SIP trunk is an outbound operation (from sipXbridge to provider).

Your recommendation of trying to get the provider to allow dialog based authentication is a good one because then the ITSP side will send back to the proper port on sipXbridge.  Most of the providers just want to use IP based authentication and then they fail to want to support sending traffic inbound on port 5080 UDP (the only way sipXbridge will receive trunk traffic properly).

I haven't evaluated the PCAP, but from your analysis there is one thing that raises suspicion to me.  That has to do with the SIP trunk being provided on an internal IP address.  There is a setting in sipXbridge that might be fighting Guido here.  If your SIP trunk provider is dropping a SIP trunk in on the inside of your network (or on a different VLAN off a firewall) the Administrator might not want to (ok, REALLY don't want to) specify the outside address of the sipXcom system (address used by media relay).  This setting is in the Gateway details (Devices -> Gateways -> GATEWAY NAME -> ITSP Account -> Show Advanced Settings -> Use public address for call setup.  This setting is enabled by default. If your ITSP trunk termination is not outside your NAT and you still want to use sipXbridge to interface to that trunk you may need to uncheck this setting.

Bates is about a half hour south of me. Great campus and one of the excellent schools clustered in central Maine (Colby, Bates, Bowdoin).  I really like Sinek too.  His book 'Start with Why' is an excellent read (there's a great companion video on YouTube for this).

Thanks,

  Mike

Michael Picher, VP of Product Innovation
eZuce, Inc.

300 Brickstone Square

Suite 104

Andover, MA. 01810

O.978-296-1005 X2015 
M.207-956-0262
@mpicher <http://twitter.com/mpicher> 

linkedin
www.ezuce.com

Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee(s) named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. FMS

--

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/562c8011-3630-4291-9f47-2f216334eee0%40googlegroups.com.

[pmkr...@gmail.com]

No worries Mike. I just took a quick look at the PCAP again, and the registrations was for a Berofix VoIP gateway and not for the SIP trunk to the ITSP, so my mistake. I assumed the SIP trunk registration took place normally, and validated that by looking at the sipxbridge log file in the configuration.tar file provided earlier.

I do notice on the SIP invite from Telefonica that on the TO: header of the incoming SIP INVITE request, that the user=phone attribute is applied. I see it as well on the P-Asserted Identity field. When Sipx sees this, does it treat the INVITE as coming from an internal phone, and requests authentication credentials ....

When Sinok made his rant on Wall Street banking behavior, it reminded me of a book I recently read called the The Flash Boys. The book focuses on high frequency trading industry, but there is a subplot around a programmer working on trading systems using open source technologies for a major bank. Great book, especially if one works with open source technologies. I'm going to read Sinok's book ...

Peter

[Guido T]

Thank you Peter and Michael! Your answers make me realize how little I know about the variety of possible setups. It didn't even occur to me to specify mine in more detail. I'm sorry if that led to unnecessary work. OK, here is what I have:

1 VDSL-line (dynamic IP) + SIP-account with
1 VDSL-Modem: Draytek Vigor 130 in bridge-mode
1 PC as router/firewall with pfSense: WAN-port connected to VDSL-modem, LAN: 192.168.0.110

1 BRI-line
1 BRI-gateway: beroNet berofix (2xBRI 2xFXS): 192.168.0.130
Calls over the BRI-line work without problems.
 
1 PC with sipXcom: All-in-one install (proxy, registrar, sbc, ...) on this box: 192.168.0.120
You can find the PBX-config in my original post.
A couple of phones: snom 720, all in the same subnet: 192.168.0.0/24
DNS-Server: 192.168.0.102

Nothing inside my LAN that the ITSP has provided.

Hope this it's a bit clearer now.
Guido

[Guido T]

Ups, crosspost.

So if understand this right, sipx should not require auth for external calls? If that's so, how do I stop it?

Thanks
Guido

[pmkr...@gmail.com]

Guido - most ITSPs have hosted SIP phone as well as SIP trunk offerings from the same account. With Sipx and SIP trunks, the account needs to be set up in IP/PBX server mode - see attached image from voip.ms site.

With incoming INVITE coming in with user=phone attribute, it appears your Telefonica account may be set up in SIP phone rather than IP PBX Server mode - can you doublecheck your settings?

Peter

[Joegen Baclor]

sipXbridge log (in debug) should tell the whole story.   My guess why sipXbridge is rejecting this call is because of any of the 2 reasons

1.  call came in from an IP address that sipXbridge does not know about?

2.  call came in from a domain that sipXbridge did not register to.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/6485b9cc-129a-4923-a6d1-de406a4d9b48%40googlegroups.com.

[pmkr...@gmail.com]

I think you are correct on next steps. In looking into the incoming invite with user=phone issue signals how to interpret the dialplan in front of the @ sign. I also ran some traces for incoming calls from voip.ms where registration was configured as a phone and then as a PBX server. In both cases, user=phone parameter was not used and there was no 407 authentication issued back from Sipx. However with the SIP service set to softphone/iax support, the six digit sip registration number was sent as the calling number in the invite - with that number defined as an alias against a user, Sipx answered the call. With the voip.ms service set to PBX server, the actual 10 digit calling number was used in the invite.

We should analyze the sipxbridge logs in debug mode for an incoming call.

Appreciate your input Joegen - I always learn something new.

Peter

[Guido T]

Joegen,

1. the call came from the same IP that sipXbridge registers against. Does that qualify? If not, what does?
2. is that the domain part in the from-header? In that case it is different. The invite from-header contains the domain of the caller's ITSP so I guess this is not what you meant. Or should it contain our ITSP's domain?
See also attached the sipXbridge.log.

Peter, our ITSP does not offer any such settings like voip.ms does. Support is practically nonexistent. They only offer their own all-in-one dsl-router-pbx and if you don't want that you're on your own.

[pmkr...@gmail.com]

Hi Guido - understood and thank you. I briefly looked at the attached log file and it does not have debug log level enabled. To enable, go to Devices->SIP Trunk SBCs->SipXbridge-1. Change the logging level from NOTICE to DEBUG and hit apply.

Before placing the incoming call, capture the SIP trunk registration messages in debug mode by disabling the SIP Trunk gateway, waiting 20 seconds or so, and then enable again to ascertain the trunk has registered again to your ITSP. Finally, place your incoming call. After the call is complete, place the Sipxbridge logging level back to notice. The Sipxbridge log file should show DEBUG level log messages.

Peter

[Joegen Baclor]

>> The invite from-header contains the domain of the caller's ITSP so I guess this is not what you meant. 

>> Or should it contain our ITSP's domain?

This pretty much sums it up.   If you register to a SIP trunk, sipXbridge would identify that SIP trunk by the domain.   So yes, the INVITE must be coming from your ITSP's domain. 

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/505497f1-e863-4115-8431-876a535542d9%40googlegroups.com.

[Guido T]

Hey Peter,

this is odd, loglevel was already set to DEBUG before I made the call. I was a little surprised to not see any debug-entries myself, but then I thought heck, what do I know?
Switching it back and forth I got debug-entries in the log, but after dis- and re-enabling the gateway the log-level seemed to have gone to something other than DEBUG again. But I have to serve customers and cannot concentrate on this now. Will try later again. Thanks for taking the effort in detailing the necessary steps.

Guido

[Guido T]

Thanks Joegen! I think I'm starting to understand. So what I experience here is completely normal behaviour on sipXcom's side and as ISTP is not rewriting the domain I have only the IP left for identification, right? Can I do that with sipXcom? And if yes, how?

Peter, in case there is still something to check I also attached another log with debug-level working. But first I again experienced the debug-level getting lost after I switched the gateway off and on. After switching log-level back and forth I finally have a call logged with debug-messages.

Guido

[pmkr...@gmail.com]

Hi Guido,

I did a stare and compare of your sipxbridge log against an incoming call into my lab system (15.12.1) from Voip.ms with sipxbridge.log in debug mode. Despite differences in the INVITE headers between your ITSP and voip.ms, both logs look identical until just three statements before the incoming "407 proxy required SIP packet" arrives from Sipxproxy. So I took a closer look at the Invite from your ITSP and the outgoing invite from Sipxbridge to Sipxproxy - they both have the user=phone attribute in the header (i.e. <sip:+49179...@telefonica.de;user=phone>;). I analyzed a packet capture of an incoming voip.ms call when the SIP trunk setting is in phone/softphone mode instead of PBX server mode. When the trunk account is in 'phone/softphone' mode, voip.ms replaces the incoming DID number with the account number assigned to the trunk before issuing the INVITE to the PBX; furthermore there is no user=phone attribute included in the SIP header of the incoming invite. My best guess (and I'm not a developer so stand to be corrected) is that the user=phone attribute from the initial incoming ITSP invite, when forwarded to Sipxproxy, is triggering the 407 proxy required response.

Hope this helps.

Peter

[Joegen Baclor]

Guido -  Is user 04043183760 an alias to a real user in the system?  If this is not an alias, then the call might be hitting a dialplan that requires a permission.

Peter - no.  URI parameter user=phone has no semantics in sipx authentication.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/9e114064-80e2-4a68-93df-df9fa1eae146%40googlegroups.com.

[Guido T]

That was the problem! The alias was wrong. I ommited the area code 040. This works with calls coming from the BRI-gateway but not here.
Thanks Joegen!

Also thanks Peter for all your efforts!

Guido

On Thursday, January 14, 2016 at 5:03:16 AM UTC+1, Joegen Baclor wrote:

Guido -  Is user 04043183760 an alias to a real user in the system?  If this is not an alias, then the call might be hitting a dialplan that requires a permission.

Peter - no.  URI parameter user=phone has no semantics in sipx authentication.


On Thursday, 14 January, 2016 02:18 AM, pmkr...@gmail.com wrote:

Hi Guido,

I did a stare and compare of your sipxbridge log against an incoming call into my lab system (15.12.1) from Voip.ms with sipxbridge.log in debug mode. Despite differences in the INVITE headers between your ITSP and voip.ms, both logs look identical until just three statements before the incoming "407 proxy required SIP packet" arrives from Sipxproxy. So I took a closer look at the Invite from your ITSP and the outgoing invite from Sipxbridge to Sipxproxy - they both have the user=phone attribute in the header (i.e. <sip:+491...@telefonica.de;user=phone>;). I analyzed a packet capture of an incoming voip.ms call when the SIP trunk setting is in phone/softphone mode instead of PBX server mode. When the trunk account is in 'phone/softphone' mode, voip.ms replaces the incoming DID number with the account number assigned to the trunk before issuing the INVITE to the PBX; furthermore there is no user=phone attribute included in the SIP header of the incoming invite. My best guess (and I'm not a developer so stand to be corrected) is that the user=phone attribute from the initial incoming ITSP invite, when forwarded to Sipxproxy, is triggering the 407 proxy required response.

...