Comments for Marc's Blog http://marc.storck.lu/blog Things from me about me ... Thu, 26 Apr 2012 21:39:18 +0000 hourly 1 http://wordpress.org/?v= Comment on LuxFibre disables alternative VoIP services? by Marc http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17356 Marc Thu, 26 Apr 2012 21:39:18 +0000 http://marc.storck.lu/blog/?p=714#comment-17356 Thanks for saving me some work Antonis! (And yes you are right, if you configure an IP phone to use the Fritz!Box as SIP server/proxy/registrar then this SIP flow will again be sent to VLAN39. The SIP server on the Fritz!Box is a B2BUA (back to back user agent) so the SIP flow going towards the VLAN39 is not just routed as regular Internet traffic but as locally generated SIP traffic.) However, if supported by your LinkSys you can still configure the second SIP account/line on the Linksys to connect to the Fritz!Box that way you can make and receive calls via the primary non-EPT VoIP Account and receive calls for your EPT number via the secondary account (in case you want to use your EPT pone number on the Linksys). Thanks for saving me some work Antonis!

(And yes you are right, if you configure an IP phone to use the Fritz!Box as SIP server/proxy/registrar then this SIP flow will again be sent to VLAN39. The SIP server on the Fritz!Box is a B2BUA (back to back user agent) so the SIP flow going towards the VLAN39 is not just routed as regular Internet traffic but as locally generated SIP traffic.)

However, if supported by your LinkSys you can still configure the second SIP account/line on the Linksys to connect to the Fritz!Box that way you can make and receive calls via the primary non-EPT VoIP Account and receive calls for your EPT number via the secondary account (in case you want to use your EPT pone number on the Linksys).

]]> Comment on LuxFibre disables alternative VoIP services? by Antonis Kyriazis http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17355 Antonis Kyriazis Thu, 26 Apr 2012 19:16:26 +0000 http://marc.storck.lu/blog/?p=714#comment-17355 Hi again It works: I gave one of my Linksys'es to a colleague recently converted to luxfibre, proxy (SIP) and STUN already configured, IP through DHCP and he was able to ring me with that phone. Conclusion: you were right, fritz only sends to VLAN 39 only internally converted voice (analog/S0 port) or IP phones configured as such (obviously the requirement to connect directly the IP phone to a port means to let fritz 'learn' the MAC address). Pity that our german friends could not provide that information themselves after three weeks of persisting inquiries of mine, in both languages! After the installation I intend to run an FTP server. Anything out of the ordinary, I will gladly post to this nice blog. Good night antonis Hi again

It works: I gave one of my Linksys’es to a colleague recently converted to luxfibre, proxy (SIP) and STUN already configured, IP through DHCP and he was able to ring me with that phone. Conclusion: you were right, fritz only sends to VLAN 39 only internally converted voice (analog/S0 port) or IP phones configured as such (obviously the requirement to connect directly the IP phone to a port means to let fritz ‘learn’ the MAC address).
Pity that our german friends could not provide that information themselves after three weeks of persisting inquiries of mine, in both languages!
After the installation I intend to run an FTP server.
Anything out of the ordinary, I will gladly post to this nice blog.

Good night
antonis

]]> Comment on LuxFibre disables alternative VoIP services? by Marc http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17354 Marc Sun, 22 Apr 2012 19:54:53 +0000 http://marc.storck.lu/blog/?p=714#comment-17354 OK, so you have not yet confirmed that the Fritz!Box works differently than what I already confirmed previously. The screenshot provided shows the configuration element responsible to bind the Fritz!Box's internal VoIP Daemon to a specific VLAN on the WAN interface. The Fritz!Box cannot just guest which VLAN to use, so it must be configured somewhere. Please make sure to distinguish between VoIP packets generated locally on the Fritz!Box and VoIP packets generated by devices connected to the Fritz!Box. The VoIP packets generated by the Fritz!Box is subject to the configuration element in the screenshot. The current behavior of the Fritz!Box is to route locally generated (inside the Fritz!Box itself) VoIP to the VLAN configured via the menu shown in the screenshot, all the remaining traffic, including VoIP traffic generated on devices connected to the Fritz!Box is routed via the VLAN 35 (the HighSpeed Internet VLAN). I will try to re-test the current situation in the upcoming weeks, unfortunately I have some other projects going on, so it may take a while. OK, so you have not yet confirmed that the Fritz!Box works differently than what I already confirmed previously. The screenshot provided shows the configuration element responsible to bind the Fritz!Box’s internal VoIP Daemon to a specific VLAN on the WAN interface. The Fritz!Box cannot just guest which VLAN to use, so it must be configured somewhere.

Please make sure to distinguish between VoIP packets generated locally on the Fritz!Box and VoIP packets generated by devices connected to the Fritz!Box. The VoIP packets generated by the Fritz!Box is subject to the configuration element in the screenshot.

The current behavior of the Fritz!Box is to route locally generated (inside the Fritz!Box itself) VoIP to the VLAN configured via the menu shown in the screenshot, all the remaining traffic, including VoIP traffic generated on devices connected to the Fritz!Box is routed via the VLAN 35 (the HighSpeed Internet VLAN).

I will try to re-test the current situation in the upcoming weeks, unfortunately I have some other projects going on, so it may take a while.

]]> Comment on LuxFibre disables alternative VoIP services? by Antonis Kyriazis http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17353 Antonis Kyriazis Sun, 22 Apr 2012 19:01:21 +0000 http://marc.storck.lu/blog/?p=714#comment-17353 Here the screendump I got from AVM: https://docs.google.com/open?id=0BwxmMjjsqKVeVnRTQ1VySzJyRWc The Interface Description document is stored on the P&T server (telecom->operators->documents->interfaces). I talked to the phone with some EPT's people to confirm that no test installation is available to test one of my IP phones. They also promise a free dynamic public address, should my ftp server not function, but I don't dare to order an installation before previously testing it. In between, the support people of AVM are unable to give me accurate answers, and proposed me to write a request to their presales people, which I did. If the VLANs work like you wrote, then VoIP traffic must be bridged to VLAN 39, not? I home AVM will answer. rgds ak Here the screendump I got from AVM: https://docs.google.com/open?id=0BwxmMjjsqKVeVnRTQ1VySzJyRWc
The Interface Description document is stored on the P&T server (telecom->operators->documents->interfaces).
I talked to the phone with some EPT’s people to confirm that no test installation is available to test one of my IP phones. They also promise a free dynamic public address, should my ftp server not function, but I don’t dare to order an installation before previously testing it. In between, the support people of AVM are unable to give me accurate answers, and proposed me to write a request to their presales people, which I did.
If the VLANs work like you wrote, then VoIP traffic must be bridged to VLAN 39, not?
I home AVM will answer.

rgds
ak

]]> Comment on LuxFibre disables alternative VoIP services? by Marc http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17352 Marc Sun, 22 Apr 2012 18:29:38 +0000 http://marc.storck.lu/blog/?p=714#comment-17352 You're reasoning is not wrong, however the Fritz!Box runs Linux 2.6. It's actually a very customized linux 2.6 kernel but you can still do a lot of things for free (well for the cost of a Fritz!Box). I now also recognize where your text comes from. It's the technical description of the Ethernet interface provided by the optical network termination equipment to the Fritz!Box. It does however not describe the internal behavior of the Fritz!Box. VLANs are not extended into the internal routing of the Fritz!Box, they are used to provide 2 WAN interfaces to the Fritz!Box within 1 single physical RJ45 Ethernet plug. The previous behavior of the Fritz!Box (and I will try to confirm this is still the case) was to attach the VoIP Daemon statically (via a configuration parameter) to the (virtual) WAN interface VLAN39, while anything else is attached to the (virtual)WAN interface VLAN35. The Fritz!Box was not providing Layer4 based routing, only some kind of source-based routing, eventually process-owner based routing. Also there is no technical need for NAT44 (double NAT) in general. The possibility to order a public IP address at cost documents this very clearly. (There are other ways to proof this, but I'm lazy and I've chosen the shortest way). Although, address conservation might be a political reason for NAT44. For a even better understanding, can you confirm you actually tried to use an external VoIP device connected via to a LAN port of the Fritz!Box? You’re reasoning is not wrong, however the Fritz!Box runs Linux 2.6. It’s actually a very customized linux 2.6 kernel but you can still do a lot of things for free (well for the cost of a Fritz!Box).

I now also recognize where your text comes from. It’s the technical description of the Ethernet interface provided by the optical network termination equipment to the Fritz!Box. It does however not describe the internal behavior of the Fritz!Box. VLANs are not extended into the internal routing of the Fritz!Box, they are used to provide 2 WAN interfaces to the Fritz!Box within 1 single physical RJ45 Ethernet plug.

The previous behavior of the Fritz!Box (and I will try to confirm this is still the case) was to attach the VoIP Daemon statically (via a configuration parameter) to the (virtual) WAN interface VLAN39, while anything else is attached to the (virtual)WAN interface VLAN35. The Fritz!Box was not providing Layer4 based routing, only some kind of source-based routing, eventually process-owner based routing.

Also there is no technical need for NAT44 (double NAT) in general. The possibility to order a public IP address at cost documents this very clearly. (There are other ways to proof this, but I’m lazy and I’ve chosen the shortest way). Although, address conservation might be a political reason for NAT44.

For a even better understanding, can you confirm you actually tried to use an external VoIP device connected via to a LAN port of the Fritz!Box?

]]> Comment on LuxFibre disables alternative VoIP services? by Antonis Kyriazis http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17351 Antonis Kyriazis Sun, 22 Apr 2012 17:56:06 +0000 http://marc.storck.lu/blog/?p=714#comment-17351 See for yourself (received from their support) that it is NOT a EPT's configuration trick. In fact, EPT would certainly have to separate the two situations, telephony-destined datagrans and public internet-destined ones, thus the need to double NAT, as to keep telephony traffic to a totally isolated network. If the AVM's box has a switching engine, then a layer 3/4 switching modification would make the trick. I quickly browsed Cisco, HP and Netgear hardware, and I suspect that only a modular, sophisticated $,$$$ box could at the same time be L3-switch, VDSL router and integrated VDSL-modem (PPPoE). Obviously not any simple customer's situation... rgds ak See for yourself (received from their support) that it is NOT a EPT’s configuration trick. In fact, EPT would certainly have to separate the two situations, telephony-destined datagrans and public internet-destined ones, thus the need to double NAT, as to keep telephony traffic to a totally isolated network. If the AVM’s box has a switching engine, then a layer 3/4 switching modification would make the trick. I quickly browsed Cisco, HP and Netgear hardware, and I suspect that only a modular, sophisticated $,$$$ box could at the same time be L3-switch, VDSL router and integrated VDSL-modem (PPPoE). Obviously not any simple customer’s situation…

rgds
ak

]]> Comment on LuxFibre disables alternative VoIP services? by Marc http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17350 Marc Sun, 22 Apr 2012 17:14:11 +0000 http://marc.storck.lu/blog/?p=714#comment-17350 Hello Antonis, I'll have to lookup information about Transport Layer based VLANs on the AVM Fritz!Box. However it's possible that this is a new option activated by the customized Fritz!Box configuration used by EPT. Regards, Marc Hello Antonis, I’ll have to lookup information about Transport Layer based VLANs on the AVM Fritz!Box. However it’s possible that this is a new option activated by the customized Fritz!Box configuration used by EPT. Regards, Marc

]]> Comment on LuxFibre disables alternative VoIP services? by Antonis Kyriazis http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17348 Antonis Kyriazis Sat, 21 Apr 2012 18:33:10 +0000 http://marc.storck.lu/blog/?p=714#comment-17348 Bad news, I am afraid. The Fritzbox, can only create VLANs according to the QoS, therefore VLAN 39 will contain also VoIP traffic coming out from the IP phones. Only workaround is a level-3 fast ethernet switch (WLAN->DSLAM) to assign VoIP traffic destined to a specific public internet host to VLAN 35. The P&T's description states clearly: 4.2. Layer 2 configuration As the interface is an Ethernet interface, the layer 2 configuration is also based on Ethernet and the traffic separation (High Speed Internet and Voice) is done via the two service VLAN’s (IEEE 802.1q). VLAN 35 is used for the High Speed Internet traffic, and VLAN 39 for the Voice. The HAG needs to tag the traffic based on the service. So, it won't work! cheers Bad news, I am afraid. The Fritzbox, can only create VLANs according to the QoS, therefore VLAN 39 will contain also VoIP traffic coming out from the IP phones.
Only workaround is a level-3 fast ethernet switch (WLAN->DSLAM) to assign VoIP traffic destined to a specific public internet host to VLAN 35. The P&T’s description states clearly:
4.2. Layer 2 configuration
As the interface is an Ethernet interface, the layer 2 configuration is also based on
Ethernet and the traffic separation (High Speed Internet and Voice) is done via the two service VLAN’s (IEEE 802.1q).
VLAN 35 is used for the High Speed Internet traffic, and VLAN 39 for the Voice. The HAG needs to tag the traffic based on the service.
So, it won’t work!
cheers

]]> Comment on LuxFibre disables alternative VoIP services? by Antonis Kyriazis http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17346 Antonis Kyriazis Fri, 13 Apr 2012 03:49:23 +0000 http://marc.storck.lu/blog/?p=714#comment-17346 Great. Thanks a lot. I unfortunately could not find these on the avm doc (not sufficiently detailed as by other networking brands). As far for the double NAT (to escape it), they promised me a public dynamic address for free, as with LuxDSL. It remains to follow the IPver6 developments, as I understand, soon (a couple of years) it will become compulsory. Thank you Marc. ak Great.

Thanks a lot. I unfortunately could not find these on the avm doc (not sufficiently detailed as by other networking brands).
As far for the double NAT (to escape it), they promised me a public dynamic address for free, as with LuxDSL.
It remains to follow the IPver6 developments, as I understand, soon (a couple of years) it will become compulsory.

Thank you Marc.
ak

]]> Comment on LuxFibre disables alternative VoIP services? by Marc http://marc.storck.lu/blog/2012/03/luxfibre-disables-alternative-voip-services/comment-page-1/#comment-17345 Marc Fri, 13 Apr 2012 00:02:36 +0000 http://marc.storck.lu/blog/?p=714#comment-17345 Hello Antonis, the restriction only applies to VoIP services provided from within the Fritz!Box itself. It does not apply to VoIP devices connected via Ethernet to the Fritz!Box, such devices are handled just like a PC or a game console or any other network equipment. So as long as the DECT base supports SIP itself and does not rely on the Fritz!Box to convert ISDNSIP you won't have any issues. The Liknsys phones will work as usual. Hello Antonis,

the restriction only applies to VoIP services provided from within the Fritz!Box itself. It does not apply to VoIP devices connected via Ethernet to the Fritz!Box, such devices are handled just like a PC or a game console or any other network equipment. So as long as the DECT base supports SIP itself and does not rely on the Fritz!Box to convert ISDNSIP you won’t have any issues. The Liknsys phones will work as usual.

]]>