Source: http://www.google.com/patents/US20040001224?ie=ISO-8859-1
Timestamp: 2014-10-26 10:04:14
Document Index: 84245489

Matched Legal Cases: ['art 11', 'art 12', 'art 13', 'art 12', 'art 11', 'art 12', 'art 13', 'art 13', 'application No. 2002']

Patent US20040001224 - Network facsimile apparatus, facsimile communication system, and method that ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA network facsimile apparatus conforms to ITU-T Recommendation T.38 Standard and includes a function of transporting packet data by using one of TCP and UDP. A packet delay detection part detects a delay in packet transmission. A UDP/TCP selection part transports a succeeding packet of an address by...http://www.google.com/patents/US20040001224?utm_source=gb-gplus-sharePatent US20040001224 - Network facsimile apparatus, facsimile communication system, and method that can efficiently transport packetsAdvanced Patent SearchPublication numberUS20040001224 A1Publication typeApplicationApplication numberUS 10/437,139Publication dateJan 1, 2004Filing dateMay 13, 2003Priority dateJun 21, 2002Also published asUS7548332Publication number10437139, 437139, US 2004/0001224 A1, US 2004/001224 A1, US 20040001224 A1, US 20040001224A1, US 2004001224 A1, US 2004001224A1, US-A1-20040001224, US-A1-2004001224, US2004/0001224A1, US2004/001224A1, US20040001224 A1, US20040001224A1, US2004001224 A1, US2004001224A1InventorsTomohito KajiwaraOriginal AssigneeTomohito KajiwaraExport CitationBiBTeX, EndNote, RefManReferenced by (18), Classifications (15), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetNetwork facsimile apparatus, facsimile communication system, and method that can efficiently transport packetsUS 20040001224 A1Abstract A network facsimile apparatus conforms to ITU-T Recommendation T.38 Standard and includes a function of transporting packet data by using one of TCP and UDP. A packet delay detection part detects a delay in packet transmission. A UDP/TCP selection part transports a succeeding packet of an address by using UDP in a case where the delay in a preceding packet of the same address is equal to or greater than a predetermined value when transporting the packet data by using TCP, and transports a succeeding packet of an address by using TCP in a case where the delay in a preceding packet of the same address is less than the predetermined value when transporting the packet data by using UDP. Images(9) Claims(8)
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0046] In FIG. 1, an Internet FAX (network facsimile apparatus) 1 is connected to an IP network 100. In addition, a facsimile terminal apparatus (GIIIFAX) 2 is connected to the IP network 100 via an exchange 3 of a communication carrier and a VoIP gateway 4. The Internet FAX 1 conforms to ITU-T Recommendation T.38 Standard having a function of performing transport of data (packets) by either TCP or UDP. [0047] The internet FAX 1 includes a packet delay detection part 11 as packet delay detection means detecting the amount of delay in packet transmission, a UDP/TCP selection part 12 as UDP/TCP selection means performing transport of the succeeding communication of the same address by UDP if the delay is equal to or greater than a predetermined value when transporting data by using TCP, and performing transport of the succeeding communication of the same address by TCP if the delay is less than the predetermined value when transporting data by using UDP, and a transport setting part 13 as transport setting means setting the priority of TCP/UCP for each address as the parameter of a one-touch dial or an abbreviated dialing number. [0048]FIG. 2 is a sequence diagram showing a communication sequence among the Internet FAX 1, the gateway (GW) 4, and the GIIIFAX 2, which are shown in FIG. 1. Here, it is assumed that a transport layer is set to TCP by default. That is, the UDP/TCP selection part 12 selects TCP by default and performs communication using TCP/IP. [0049] The packet delay detection part 11 detects delay in a packet by recording reception of response from a command of a signal packet that serves as the response to a command such as DIS-DCS and postmessage, for example, EOP-MCF in FAX communication. When the value of the delay is equal to or greater than a predetermined time duration (four seconds, for example), the next communication with the same address is performed while giving priority over UDP. In other words, the UDP/TCP selection part 12 selects UDP and perform communication using UDP/IP. Thus, even if the network work load is increased, the probability that a T.30 timer times out due to delay is reduced. [0050] In UDP, there is no guarantee for the order (alignment) of packets and for packets lost. Therefore, if packet loss occurs when transmission as shown in FIG. 3A is performed, an error occurs. For this reason, in UDP/IP, packets are sent by adding redundant packets thereto so as to form a packet format (structure) as shown in FIG. 3B. [0051] In other words, as shown in FIG. 4, the transmission packets are sent by adding latest packets sent (packets that are already sent) thereto for securing sequence numbers for reassembling the packets sent and error recovery of packet loss. In FIG. 4, redundant packets are shown with broken lines. [0052] For example, when a packet 4 (the packet that is crossed out in FIG. 4) is lost, error recovery is performed by using a packet 4 for error correction that is added to and sent with a packet 5. [0053] In the present invention, the priority transport setting part 13 sets whether priority is to be given to TCP or UDP for each address as the parameter of the one-touch dial or the abbreviated dialing number. [0054] When establishing a call, the Internet FAX 1 reads the parameter of the one-touch dial or the abbreviated dialing number, varies the arrangement of OLC for data channel of a SETUP message, and sends a request of the transmitting source (sender) to a transmission destination (receiver). Hence, it is possible to select either TCP/UDP for each address in consideration of the network bandwidth of the transmission destination. Thus, it is possible to perform communication with less packet delay. FIG. 5 shows the process of the Internet FAX 1 on this occasion. [0055] First, in step S101, a connection is established with a terminal to be connected (destination terminal)(GIIIFAX2). In step S102, it is determined whether or not the priority transport is set with respect to the address of the destination terminal by the priority transport setting part 13. When the priority transport is set (YES in step S102), the priority transport is set to a default setting and a SETUP message is created in step S103. Then, in step S105, the SETUP message is sent. On the other hand, when the priority transport is not set (NO in step S102), in step S104, the SETUP message is created in consideration of the priority transport. Thereafter, the SETUP message is sent in step S105. [0056] After the SETUP transmission (step 5105), whether or not a CONNECT message is received is determined in step S106. Step S106 is repeated until the decision result becomes YES. After receiving the CONNECT message (YES in step S106), phase B connection is made in steps S107 and S108. In step S109, a POST message is sent and the transmission time thereof is recorded. Then, in step S110, it is determined whether or not a response to the POST message is received. Step S110 is repeated until the decision result becomes YES. When the response to the POST message is received (YES in step S110), the period (time difference) between the transmission of the POST message and the reception of the response is calculated in step S111. [0057] In step S112, it is determined whether or not the time difference between the transmission of the POST message and the reception of the response is equal to or more than a predetermined value (for example, four seconds). When the time difference between the transmission of the POST message and the reception of the response is equal to or more than the predetermined value (YES in step S112), the priority transport is set to UDP in step S113, and the process returns to step S101. On the other hand, when the time difference between the transmission of the POST message and the reception of the response is less than the predetermined value (NO in step S112), the process directly returns to step S101. [0058] As described above, according to the T.38 Standard, when communication is established using UDP/IP, in order to avoid packet loss, the redundant packets as shown with the broken lines in FIG. 4 are added. When the number of redundant packets is increased so as to raise the recovery level of packet loss, the packet size of (number of packets in) a transmission unit is increased. Delay using the number of the redundant packets as its coefficient is inserted between transmission packets of image data. With the delay, packet decoding is made processable. FIG. 6 shows this delay insertion process. [0059] First, in step S201, it is determined whether UDP transport or TCP transport is being performed. When TCP transport is being performed (NO in step S201), the process ends. When UDP transport is being performed (YES in step S201), packets (packets other than redundant packets) are sent in step S202. In step S203, it is determined whether or not the number of redundant packets is equal to or more than one. When the number of redundant packets is less than one (when there is no redundancy packet)(NO in step S203), the process ends. When the number of redundant packets is equal to or more than one (YES in step S203), a delay of �decode time x (the number of redundant packets +1)� is set in step S204. Then, the process returns to step S201. As described above, even if the number of redundant packets is increased in UDP, it is possible to control the probability that overflow occurs in packet reception on the receiving side to be low. [0060] In the present invention, in UDP, when FAX communication is performed in an ECM (Error Correction Mode) through exchange of DIS/DCS, it is possible to set the number of redundant packets to zero. FIG. 7 shows the process of setting the number of redundant packets to zero. [0061] First, a connection is established between the Internet FAX 1 and the destination terminal (GIIIFAX2) in step S301. Then, a SETUP message is sent to the destination terminal from the Internet FAX 1 in step S302. Subsequently, in step S303, whether or not the Internet FAX 1 receives a CONNECT message from the destination terminal is determined. Step S303 is repeated until the decision result becomes YES. When the Internet FAX 1 receives a CONNECT message from the destination terminal (YES in step S303), whether or not the Internet FAX 1 receives DIS from the destination terminal is determined in step S304. Step S304 is repeated until the decision result becomes YES. When the Internet FAX 1 receives DIS from the destination terminal (YES in step S304), the Internet FAX 1 sends DCS to the destination terminal in step S305. In step S306, whether or not the ECM transmission is performed is determined. When the ECM transmission is not performed (NO in step S306), the process proceeds to step S309. In step S309, communication (transmission by TCP or by UDP with redundant packets) is made. Then, in step S310, the call is released (communication is disconnected). On the other hand, when transmission is performed in the ECM (YES in step S306), in step S307, it is determined whether or not the transmission uses UDP. When the transmission does not use UDP (that is, transmission uses TCP: NO in step S307), the process proceeds to step S309, which is described above. When the transmission uses UDP (YES in step S307), the number of redundant packets is set to zero in step S308, and the process proceeds to step S309. As mentioned above, when UDP is used and transmission is in the ECM mode, redundant packets can be eliminated. Thus, it is possible to reduce network work load. [0062] In the present invention, when packet loss occurs in a case where FAX communication that is not in the ECM is performed through exchange of DIS/DCS, it is possible for the destination terminal to disconnect the communication (release the call). FIG. 8 shows the process where the (VoIP) GW 4 releases a call. [0063] First, in step S401, it is determined whether or not the GW 4 receives a SETUP message. Thereafter, the GW 4 sends the CONNECT message and DIS in steps S402 and S403, respectively. In step S404, the GW 4 determines whether or not the DCS is received. Step S404 is repeated until the decision result becomes YES. When the DCS is received (YES in step S404), the process proceeds to step S405. In step S405, the GW 4 receives PIX. Then, in step S406, the GW 4 determines whether or not a non-ECM transmission is performed. When a non-ECM transmission is not performed (NO in step S406), the process returns to step S405. When a non-ECM transmission is performed (YES in step S406), in step S407, the GW 4 determines whether or not the transmission uses UDP. When transmission does not use UDP (NO in step s407), the process returns to step S405. When transmission uses UDP (YES in step S407), in step S408, the GW 4 determines whether or not packet loss occurs. When packet loss does not occur (NO in step S408), the process returns to step S405. When packet loss occurs (YES in step S408), the GW 4 releases the call in step S409 and the process ends. Hence, it is possible to prevent a user on the transmitting side from misinterpreting that normal communication can be made when no error is signalled, even though packet loss occurs. [0064] The present invention is not limited to the specifically disclosed embodiments, and variations and modifications may be made without departing from the scope of the present invention. [0065] The present application is based on Japanese priority application No. 2002-181119 filed on Jun. 21, 2002, the entire contents of which are hereby incorporated by reference. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7313134May 12, 2005Dec 25, 2007Yahoo! Inc.Proxy server for relaying VOIP messagesUS7502132 *Apr 19, 2004Mar 10, 2009Ricoh Company, Ltd.Facsimile apparatusUS7701931Nov 21, 2005Apr 20, 2010Ricoh Company, Ltd.Network communication apparatus and method for performing a T.38 communication function using a voice capability of a gateway apparatusUS7751091Jun 20, 2006Jul 6, 2010Ricoh Company, Ltd.Communication terminalUS7769872Sep 16, 2004Aug 3, 2010Ricoh Company, Ltd.Gateway apparatus, network terminal apparatus and communication methodUS7876685 *Jul 23, 2008Jan 25, 2011Polycom, Inc.System and method for lost packet recovery with congestion avoidanceUS8233393 *Aug 8, 2008Jul 31, 2012Avaya Inc.System for transmitting high quality speech signals on a voice over internet protocol networkUS8321577Oct 4, 2005Nov 27, 2012Telefonaktiebolaget Lm Ericsson (Publ)Method for providing messaging using appropriate communication protocolUS8493862 *Dec 14, 2010Jul 23, 2013Polycom, Inc.System and method for lost packet recovery with congestion avoidanceUS8605620Jul 6, 2012Dec 10, 2013Avaya Inc.System for transmitting high quality speech signals on a voice over internet protocol networkUS8654787 *Jun 12, 2009Feb 18, 2014Dell Products L.P.Apparatus and method for remote communication and transmission protocolsUS8724143 *Apr 19, 2010May 13, 2014Fuji Xerox Co., Ltd.Image communicating apparatusUS20100246602 *Jun 12, 2009Sep 30, 2010Wyse Technology Inc.Apparatus and method for remote communication and transmission protocolsUS20110080610 *Apr 19, 2010Apr 7, 2011Fuji Xerox Co., Ltd.Image communicating apparatusUS20110252083 *Jun 2, 2010Oct 13, 2011Rebelvox, LlcApparatus and method for transmitting media using either network efficient protocol or a loss tolerant transmission protocolEP1670230A2 *Nov 8, 2005Jun 14, 2006Samsung Electronics Co, LtdMethod and device to transmit and receive fax dataEP1932299A1 *Oct 4, 2005Jun 18, 2008TELEFONAKTIEBOLAGET LM ERICSSON (publ)Method for providing messaging using appropriate communication protocolWO2006124271A2 *May 4, 2006Nov 23, 2006Yahoo IncProxy server for relaying voip messages* Cited by examinerClassifications U.S. Classification358/1.15, 370/395.52International ClassificationH04L29/06, H04L12/66, H04N1/32, H04L29/08Cooperative ClassificationH04L69/164, H04L69/16, H04L69/165, H04L29/06, H04L12/66European ClassificationH04L29/06J11, H04L29/06J9, H04L29/06, H04L12/66Legal EventsDateCodeEventDescriptionOct 1, 2012FPAYFee paymentYear of fee payment: 4Sep 2, 2003ASAssignmentOwner name: RICOH COMPANY, LTD., JAPANFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KAJIWARA, TOMOHITO;REEL/FRAME:014452/0244Effective date: 20030626RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google