I wouldn't be too positive about those "positives"...
The IPRs were not & never will be "a win". I thing was "won". Patents were challenged & the challengers lost their challenge, leaving vplm with nothing lost, nothing gained. All they did was maintain what they had from the beginning. That's a "plus" I guess, but not a win. And besides, the whole thing was a debacle put on by a known corrupt agency. No bout-a-doubt-it! It took 3 panels & a real threat of RICO charges, by Sawyer, to finally "obtain" the <cough, cough> unanimous & unprecedented ruling. The whole thing was obviously a farce of the highest kind. If you can't recognize that, I don't think that's very objective. Every single allegation against the patents was up against the fact that all claims are considered VALID from the point of patenthood. That's what the USPTO is assumed to be doing in the 1st place, is to expertly look at all the patenmt claims when the patent application is presented to them. Therefore the whole corrupt debacle turned out to be zero sum game. It took 3 freakin panels 1 whole year to finalky decide they didn't need any RICO charges leveled agin them. Those are the facts. That is the reality!
Some claims HAVE been invalidated. Reversals are conjecture therefore don't deserve to be counted as "a positive".
The artificially induced lower OS share count has been QUICKLY gapping back up. It's huge at 1.7b
With the huge legal quagmire, I don't honestly think it possible to know for a fact that all requisite filings are complete..
I submit that "defendant friendly" & "fair judge" is a misnomer & an impossibility. It's red herring. It is AT ONCE a conflict. The 2 things cannot fairly coexist!
"most cases settle before trial"
And yet there are still no overtures despite the fact that naturally, as time goes by, the price goes up. Not seeing any settlements ever!
Source codes, in a trial, are protected by law!
The allegation about Apple admitting relay use is absotively posolutely ludicrous. I researched & spoke (posted) on this when the allegation 1st surfaced, years ago. I'm in the electronics business. The use of relays is so common in any & all electronic systems is well known & that point would be laughed out of court. I asked for anybody to identify what was the admitted infringment by Apple, for the last couple yrs. No one could or would answer it. Most could not answer it because they were just regurgitating what someone else said. And the other didn't reveal it because of what an embarrassment it is to allege. The apple expert knew full well that there was no issue admitting use of relays. Ppl keep regurgitating that any many other "points" as thought they actually have diligent in depth understanding of the facts. Not seeing that at all... Below is just one of many examples of relay use in the industry in routing phone calls (or faxes as the case may be)...
Configuring VoIP Fax Relay Using CallManager
and a Voice Gateway
Document ID: 13949
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Configure the Cisco CallManager Server to Route the Fax Calls
Step-by-Step Instructions
Configure the Gateway
Verify
Troubleshoot
Related Information
Introduction
This document explains how to force fax calls to use Voice over IP (VoIP) Fax Relay rather than local
hairpinning. This functionality is useful in a scenario that includes a Primary Rate ISDN (PRI) port accepting
voice and fax calls. The voice calls are directed to IP phones and the fax calls are directed to Foreign
Exchange Station (FXS) ports on the same router.
Local hairpinning of analog calls on a router without a time-division multiplexing (TDM) bus makes those
calls subject to delay on the router backplane and Digital Signal Processor (DSP) buffers, and therefore
unreliable. VoIP in general, and Fax Relay specifically, overcomes this problem for fax calls by terminating
them directly on the router DSP.
This forced Fax Relay is accomplished when you route the incoming fax call setup to the Cisco CallManager
server, and then immediately redirect it to the same gateway.
In summary, the gateway now terminates the fax call using Fax Relay on one leg, establishes a VoIP Fax
Relay call between its voice cards routed through the Cisco CallManager, and then re-establishes the fax call
on the FXS call leg.
Note: Only the call setup messages pass through the Cisco CallManager. After the VoIP call is established,
data travels directly between the ingress and egress DSPs on the gateway voice cards.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on the software and hardware versions:
• Cisco CallManager versions 3.x and 4.x
The information in this document was created from the devices in a specific lab environment. All of the
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.
Conventions
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Configure the Cisco CallManager Server to Route the Fax
Calls
Use this procedure to configure the Cisco CallManager server to route the fax calls.
Note: The setup in this document makes use of Cisco CallManager 3.0. However, the concept is relevant for
all versions of Cisco CallManager including 3.x and 4.x.
Step-by-Step Instructions
Complete these steps to configure the Cisco CallManager server to route fax calls.
Select Device > Phone > Add New Phone to create a dummy extension.
In this case, Phone Type Cisco 30 VIP is used.
1.
2. Insert a dummy MAC address in the MAC address field. For instance, 00AABBCCDDEE.
In the Button Template field, be sure to select a 30 VIP handset (it has plenty of line appearances) and
insert it into the database.
3.
Assume these for the dummy extension (use any numbers that are available on your system):
? line 1 is extension 4444, call forward always to 5555
? line 2 is extension 4445, call forward always to 5556
? line 3 is extension 4446, call forward always to 5557
? line 4 is extension 4447, call forward always to 5558
The Call Forward Always settings route patterns that point back out to the H.323 gateway,
specifically to the FXS ports. This forces the router to establish a VoIP call. Therefore, it should use
Fax Relay to terminate the fax call on one leg and bridge it to the FXS call leg.
Click on the first line appearance and enter a dummy number in the Directory Number field. In this
example 4444 is used. Then, enter a Forward All number that points back to the FXS destination
pattern. This example uses 5555.
4.
In the VoIP world, route patterns are the equivalent of static routes. The only difference is that route
patterns point to an E.164 number instead of an IP address. Create and insert a Route Pattern that
matches the forward all number from the dummy extension and direct this to the H.323 gateway with
the FXS ports (the H.323 gateway must have been added previously). In order to do this, go to the
Route Plan menu and select Route Plan > Route Pattern > Add a New Pattern.
5.
Go back to the Dummy Extension Configuration page and add a new line number, (for example,
4445) and call forward all numbers (5556). Create a new Route Pattern that matches the Call Forward
All number and points to the H.323 gateway. Repeat this for each fax line you have.
6.
Configure the Gateway
On the gateway, create these VoIP and plain old telephone server (POTS) dial-peers:
!
Dial-peer voice 1 voip
Destination-pattern 444.
!--- Wildcard match for 444X numbers.
Session target ipv4:172.16.1.252
Codec g711ulaw
Ip precedence 5
Dtmf-relay h245-alpha
!
dial-peer voice 5555 pots
destination-pattern 5555
port 1/0/0
!
dial-peer voice 5556 pots
destination-pattern 5556
port 1/0/1
!
dial-peer voice 5557 pots
destination-pattern 5557
port 1/1/0
!
dial-peer voice 5558 pots
destination-pattern 5558
port 1/1/1
You should now be able to receive fax calls on your system.
Verify
Use the show voice call summary command to verify the change of the codec when the fax call is processed
by the DSP.
Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which
allows you to view an analysis of show command output.
Troubleshoot
There is currently no specific troubleshooting information available for this configuration.
Related Information
• Configuring Cisco Fax Relay
• Fax Relay Troubleshooting Guide
• Configuration on a Cisco WS-X6624 with an H.323 Gateway
• Voice Technology Support
• Voice and IP Communications Support
• Troubleshooting Cisco IP Telephony
• Technical Support & Documentation - Cisco Systems
Contacts & Feedback | Help | Site Map
© 2014 - 2015 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of
Cisco Systems, Inc.
Updated: Apr 28, 2006 Document ID: 13949
Treble kaboomski
AI
