Image processing apparatus, information processing method, and storage medium

An image processing apparatus includes a reception unit configured to receive a session start message, a determination unit configured to determine whether the session start message received by the reception unit is a session start message from a public Internet Protocol network or a session start message from a local Internet Protocol network, an acquisition unit configured to acquire a media type included in the session start message received by the reception unit, and a control unit configured to determine whether a start of a session is allowed, based on a result determined by the determination unit and the media type acquired by the acquisition unit.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to an image processing apparatus, an information processing method, and a storage medium.

Description of the Related Art

Recently, attention has been paid to an Internet Protocol facsimile (IPFAX) that transmits and receives a facsimile (FAX) via an Internet Protocol (IP) network.

The Session Initiation Protocol (SIP) is used for a call connection between IPFAX devices, and the T.38 protocol for data communication. An IPFAX using the T.38 protocol, which can perform communication faster than a conventional analog FAX, can transmit and receive an image in a shorter time.

The IPFAX performs FAX communication between devices connected to an intranet (local IP network) or FAX communication between devices connected to a public IP network.

Communication within an intranet, which uses a company network or a local network for communication, does not involve communication fees.

On the other hand, communication on a public IP network, like communication on an existing analog public network, employs a pay-per system that involves a fee for each FAX communication.

Conventional IPFAX devices cannot be connected to the two types of IP network, i.e., local and public IP networks, at the same time. Therefore, conventional IPFAX can operate in any one of the two modes (local IP network mode and public IP network mode) selected according to a setting made by a user, or can operate only in one of the two modes.

In recent years, as a network has become diversified, there has been a need for an IPFAX device that can communicate with any of a device on a local IP network and a device on a public IP network without requiring a user to change the user setting.

According to the SIP protocol for call connections, an INVITE message is used to request a connection. An INVITE message includes a description described in Session Description Protocol (SDP) (See Japanese Patent Application Laid-Open No. 2012-90213).

The SDP is a protocol used to describe a multimedia session. For example, the SDP is used to describe information about the type of media to be communicated, that is, whether an audio is to be communicated (audio), whether an image is to be communicated (image, application), and whether a video is to be communicated (video). The media type (m) is used to determine what is to be communicated. Normally, “m=audio” is specified for IP telephony, and “m=image” or “m=application” is specified for IPFAX via a public IP network.

Because T.38 IPFAX usually does not provide the phone function, it is desirable to reject an INVITE message received from a phone. In particular, on a public IP network, a caller is charged for a call in spite of the fact that communication cannot be performed. To address this problem, in a conventional method, the media type “m=audio” is rejected but the media type “m=image” or “m=application” is accepted.

However, when IPFAX communication is performed via a local IP network, a message is transmitted usually via an SIP server that has a routing function and a registration function. This sometimes requires the user to follow a specific procedure depending on the type of the SIP server.

For example, the SIP server provided by a company requires a procedure in which “audio” is specified for the SDP media type of a first INVITE message, and after that, the media type is changed to “image”. Therefore, if all INVITE messages are simply rejected because the media type is “audio”, there is an issue that IPFAX communication cannot be performed via a local IP network.

There is a T.38 gateway (T.38 GW) capable of connecting an analog FAX to an IP network as an IPFAX. However, the T.38 GW provided by a company transmits an INVITE message in which “audio” is specified for the media type as described above. Normally, the T.38 GW is connected to a local IP network.

SUMMARY OF THE INVENTION

The present invention is directed to an image processing apparatus allowing connection from both a device on a local IP network and a device on a public IP network, and preventing unnecessary charging.

An image processing apparatus includes a reception unit configured to receive a session start message, a determination unit configured to determine whether the session start message received by the reception unit is a session start message from a public Internet Protocol network or a session start message from a local Internet Protocol network, an acquisition unit configured to acquire a media type included in the session start message received by the reception unit, and a control unit configured to determine whether a start of a session is allowed, based on a result determined by the determination unit and the media type acquired by the acquisition unit.

DESCRIPTION OF THE EMBODIMENTS

FIG. 1is a diagram illustrating an example of a system configuration of a FAX system that includes IPFAX devices. For the sake of simplicity, an IPFAX device is simply described as an IPFAX, and a FAX device is simply described as a FAX. An IPFAX is an example of an image processing apparatus.

The FAX system includes a local IP network1000and a public IP network1003.

Home gateways (HGW)1002and1010are gateways for connecting to the public IP network1003.

An IPFAX1(1001) is an IPFAX connected to the local IP network1000. The IPFAX1(1001) can communicate also with the public IP network1003via the HGW1002.

An IPFAX2(1004) is an IPFAX connected to the public IP network1003. An IP phone1009and the IPFAX2(1004) are connected to the public IP network1003via the HGW1010. An SIP server1005is connected to the local IP network1000. An IPFAX3(1006) is an IPFAX connected to the local IP network1000. The IPFAX3(1006) can communicate with the IPFAX1(1001) via the SIP server1005.

A T.38 gateway (T.38 GW)1007is a gateway (GW) connected to a public switched telephone network (PSTN) network1011and the local IP network1000. An analog FAX1008is an analog FAX connected to the PSTN network1011. The T.38 GW1007converts an SIP call connection to an analog phone call connection, and the T.38 protocol to the T.30 protocol, in real time to enable intercommunication between an IPFAX and an analog FAX.

An IPFAX has an IPFAX function of sending and receiving a FAX via an IP network.

FIG. 2is a diagram illustrating an example of a hardware configuration of the IPFAX1.

A central processing unit (CPU)801controls the devices in the IPFAX1(1001) and executes the processing of the flowchart, which will be described below, based on a control program stored in a read only memory (ROM)808.

A display/operation unit803displays a screen related to settings described below, and receives information entered via an operation.

A scanner unit804reads a document.

A print unit805prints print data saved in a random access memory (RAM)809or a hard disk drive (HDD)810.

The ROM808stores various control programs and data. The RAM809includes a work area for the CPU801, a save area in which data is saved during error processing, and a load area in which a control program is loaded.

The HDD810saves therein various control programs and print data such as set IP addresses, which will be described below.

A network interface (I/F) unit813is connected to the public IP network1003via the local IP network1000and the HGW1002.

A T.38 protocol creation/analysis unit814has the function of generating facsimile transmission information based on the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation T.38 protocol, and the function of extracting facsimile transmission information from a received protocol.

An IP packet creation/analysis unit806maps the ITU-T Recommendation T.38 protocol to an IP packet, and has the function of extracting the ITU-T Recommendation T.38 protocol from a received IP packet.

An image conversion control unit807performs compression/decompression, zooming, and linear density conversion of an image to be transmitted and received using FAX communication. The CPU801executes processing based on the programs stored in the ROM808or the HDD810to implement a software function of the IPFAX1and the processing according to a flowchart described below.

The T.38 protocol creation/analysis unit814and the IP packet creation/analysis unit806may be installed on the IPFAX1as software. This software is implemented when the CPU801executes the processing based on the programs.

FIG. 3is a diagram illustrating an example of a structure of an INVITE message and an SDP description.

The INVITE message includes an SIP start line2001, an SIP header field2002, a blank line2003, and an SIP message body2004described in the SDP. The SDP description may sometimes be the one such as an SIP message body2005. Because the details of each field and each line is described in recommendation reports such as the Request for Comments (RFC) 4566, their description is omitted here. The following describes only the media type described in the SDP description. Information about the type of media to be communicated is described in a line beginning with “m=” in the SIP message body2004or2005. For example, the SDP description “m=audio” in the SIP message body2004indicates that the media type is an audio (voice). Similarly, the SIP message body2005includes the SDP description “m=image” indicating that the media type is an image.

The INVITE message is an example of a session start message.

FIG. 4is a diagram illustrating an example of an IP address setting screen of a gateway and an SIP server used by the IPFAX1(1001). A setting screen3001includes an HGW IP address registration field3002, a local SIP server IP address registration field3003, and T.38 GW IP address registration fields3004,3005, and3006. The HGW IP address registration field3002contains the IP address of an HGW that is a gateway used to connect an IPFAX to a public IP network. The local SIP server IP address registration field3003contains the IP address of a local SIP server used to connect an IPFAX to a local IP network. Each of the T.38 GW IP address registration fields3004,3005, and3006contains the IP address of a T.38 GW used to perform communication between an IPFAX and an analog FAX. In this example, up to three T.38 GWs may be registered. However, the number of T.38 GWs used in this example does not limit the present exemplary embodiment.

As illustrated inFIG. 4, the IP address of an SIP server on a local IP network, the IP address of an HGW used to connect to a public IP network, and the IP address of a T.38 GW may be registered in an IPFAX.

A home gateway, a local SIP server, and a T.38GW are examples of devices.

FIG. 5is a diagram illustrating an example of a communication sequence when an image is transmitted from the IPFAX2(1004) to the IPFAX1(1001). In practice, a signal is transmitted between the HGW1010and the HGW1002via various servers and gateways on the public IP network1003. The description of those servers and gateways is omitted here for simplicity.

In step S4001, the IPFAX2(1004) transmits an INVITE message to the HGW1010to make a session connection (session start) request.

In step S4002, the HGW1010transmits the INVITE message to the HGW1002.

In step S4003, the HGW1002transmits the INVITE message to the IPFAX1(1001). Because the INVITE message in steps S4001, S4002, and S4003is transmitted using an IPFAX communication over the public IP network, the media type is “image” or “application”.

As will be described below inFIG. 8, the IPFAX1(1001) analyzes the IP packet of the INVITE message transmitted from the HGW1002, acquires the IP address, and compares the acquired IP address with the IP addresses registered via the screen illustrated inFIG. 4. Because the IP address of the home gateway set in the field3002matches the IP address included in the INVITE message, the IPFAX1(1001) determines that the INVITE message received in step S4003is transmitted from the HGW1002. Therefore, the IPFAX1(1001) determines that the transmission source of this INVITE message is a device connected to the public IP network.

In step S4004, the IPFAX1(1001) transmits to the HGW1002a success message (200 OK) including a status code of 200 indicating that the incoming call is acceptable.

In step S4005, the HGW1002transmits “200 OK” to the HGW1010.

In step S4006, the HGW1010transmits “200 OK” to the IPFAX2(1004).

After that, in step S4007, an IPFAX image is transmitted from the IPFAX2(1004) to the IPFAX1(1001) via the HGWs1010and1002using image communication based on the T.38 protocol.

The session is then disconnected by disconnection processing in steps S4008, S4009, S4010, S4011, S4012, and S4013.

FIG. 6is a diagram illustrating an example of a communication sequence when an image is transmitted from the IPFAX3(1006) to the IPFAX1(1001). On the SIP server1005, the procedure is assumed to be necessary in which a session is once established by specifying “audio” for the media type, and after that, reconnected by specifying “image” for the media type.

In step S5001, the IPFAX3(1006) transmits an INVITE message to the SIP server1005to make a session connection request.

In step S5002, the SIP server1005transmits the INVITE message to the IPFAX1(1001). In the INVITE message in steps S5001and S5002, “audio” is specified for the media type.

The IPFAX1(1001) analyzes the IP packet of the INVITE message transmitted from the SIP server1005, acquires the IP address, and compares the acquired IP address with the IP addresses registered via the screen illustrated inFIG. 4. The IP address of the local SIP server set in the field3003matches the IP address included in the INVITE message. Therefore, the IPFAX1(1001) determines that the INVITE message received in step S5002is transmitted from the local SIP server1005. As a result, the IPFAX1(1001) determines that the transmission source of this INVITE message is a device connected to the local IP network.

In step S5003, the IPFAX1(1001) transmits, to the SIP server1005, “200 OK” indicating that the incoming call is acceptable.

In step S5004, the SIP server1005transmits “200 OK” to the IPFAX3(1006).

After that, in step S5005, IPFAX1(1001) transmits to the SIP server1005an INVITE message in which the media type “image” is specified, according to the specific procedure described above.

In step S5006, the SIP server1005transmits to the IPFAX3(1006) the INVITE message in which the media type “image” is specified.

In steps S5007and S5008, “200 OK” is transmitted from the IPFAX3(1006) to the IPFAX1(1001), and a session is established with the media type “image”. In step S5009, an IPFAX image is transmitted from the IPFAX3(1006) to the IPFAX1(1001) via the SIP server1005using an image communication based on the T.38 protocol.

The session is then disconnected by disconnection processing in steps S5010, S5011, S5012, and S5013.

FIG. 7is a diagram illustrating an example of a communication sequence when a call is transmitted from the IP phone1009to the IPFAX1(1001).

In practice, a signal is transmitted between the HGW1010and the HGW1002via various servers and gateways on the public IP network1003. The description of those servers and gateways is omitted here for simplicity.

In step S6001, the IP phone1009transmits an INVITE message to the HGW1010to make a session connection request.

In step S6002, the HGW1010transmits the INVITE message to the HGW1002.

In step S6003, the HGW1002transmits the INVITE message to the IPFAX1(1001).

Because the INVITE message in steps S6001, S6002, and S6003is a call from the IP phone, the media type is “audio”.

If the IPFAX1(1001) receives the call at this point, the usage fee of the public IP network is charged in spite of the fact that the call with the IP phone cannot be made.

The IPFAX1(1001) in the present exemplary embodiment analyzes the IP packet of the INVITE message transmitted from the HGW1002, acquires the IP address, and compares the acquired IP address with the IP addresses registered via the screen illustrated inFIG. 4. Because the IP address of the home gateway set in the field3002matches the IP address included in the INVITE message, the IPFAX1(1001) determines that the INVITE message received in step S6003is transmitted from the HGW1002. Therefore, the IPFAX1(1001) determines that the transmission source of this INVITE message is a device connected to the public IP network.

If the device connected to the public IP network is an IPFAX, an INVITE message in which “image” or “application” is specified for the media type should be transmitted. Therefore, the IPFAX1(1001) determines that the device on the public IP network, which has transmitted the INVITE message in which the media type “audio” is specified, is not an IPFAX.

Therefore, in step S6004, the IPFAX1(1001) transmits to the HGW1002a media mismatch error (status code 488, warning code 304) (a response 488-304) indicating the rejection of the incoming call.

In step S6005, the HGW1002transmits the response 488-304 to the HGW1010.

In step S6006, the HGW1010transmits the response 488-304 to the IP phone1009. In this communication, a session is not established.

FIG. 8is a flowchart illustrating an example of information processing performed when the IPFAX1(1001) receives an incoming call from the IPFAX2(1004), IPFAX3(1006), or IP phone1009. The IPFAX2(1004) is connected to the public IP network1003, the IPFAX3(1006) is connected to the local IP network1000, and the IP phone1009is connected to the public IP network1003.

First, in step S7001, the IPFAX1(1001) receives an INVITE message.

In step S7002, the IPFAX1(1001) acquires the transmission source IP address from the IP packet of the INVITE message. The IPFAX1(1001) compares the acquired transmission source IP address with the IP addresses registered via the screen illustrated inFIG. 4. If the transmission source IP address matches the IP address of the home gateway set in the field3002, as a result of the comparison, the IPFAX1(1001) determines that the INVITE message is transmitted from a device on the public IP network. If the transmission source IP address matches the IP address of the SIP server set in the field3003, as a result of the comparison, the IPFAX1(1001) determines that the INVITE message is transmitted from a device on the local IP network. The IPFAX1(1001) determines the transmission source of the INVITE message similarly if the transmission source IP address matches one of the IP addresses of T.38 GWs set in the fields3004,3005, and3006. That is, the IPFAX1(1001) determines that the INVITE message is transmitted from an analog FAX connected to the T.38 GW connected to the local IP network. If the acquired transmission source IP address does not match any of the registered IP addresses, it is estimated that the INVITE message is received not via a gateway or an SIP server, but directly from a device connected in the peer-to-peer mode. In this case, the IPFAX1(1001) determines that the INVITE massage is transmitted from a device on the local IP network as well.

In step S7003, the IPFAX1(1001) acquires a media type from the SDP description included in the INVITE message.

In step S7004, if the transmission source is the local IP network as result of the acquisition in step S7002(“LOCAL IP NETWORK” in step S7004), the IPFAX1(1001) advances the processing to step S7005. If the transmission source is the public IP network (“PUBLIC IP NETWORK” in step S7004), the IPFAX1(1001) advances the processing to step S7006.

In step S7005, if the media type acquired in step S7003is “audio”, “image”, or “application” (YES in step S7005), the IPFAX1(1001) advances the processing to step S7007. If the media type is none of them (for example, the media type is “video”) (NO in step S7005), the IPFAX1(1001) advances the processing to step S7008.

In step S7006, if the media type acquired in step S7003is “image” or “application” (YES in step S7006), the IPFAX1(1001) advances the processing to step S7007. If the media type is none of them, (for example, the media type is “audio” or “video”) (NO in step S7006), the IPFAX1(1001) advances the processing to step S7008.

In step S7007, the IPFAX1(1001) accepts the incoming call, transmits to the transmission source a response indicating a successful transmission (status code 200), and then advances the processing to step S7009.

In step S7008, the IPFAX1(1001) rejects the incoming call, and transmits a media mismatch error (status code 488, warning code 304) to the transmission source.

In step S7009, the IPFAX1(1001) receives an IPFAX image. After receiving the image, the IPFAX1(1001) advances the processing step S7010.

In step S7010, the IPFAX1(1001) disconnects the session.

An exemplary embodiment of the present invention is also implemented by executing the following processing. That is, software (a program) for implementing the function of the exemplary embodiment described above is supplied to a system or an apparatus via a network or various storage media. The computer (or CPU or micro processing unit (MPU)) of the system or the apparatus reads the program and executes the processing.

According to the exemplary embodiments described above, on a public IP network, an INVITE message is rejected if the media type “audio” is specified in the INVITE message received from a phone with which communication cannot be performed. This prevents unnecessary communication fee from being incurred by the caller side. In addition, on a local IP network, an INVITE message in which the media type “audio” is specified is accepted according to a specific procedure, whereby IPFAX communication can be performed.

Therefore, according to the present invention, connection from both a device on a local IP network and a device on a public IP network can be performed, and at the same time, unnecessary charging can be prevented.

This application claims the benefit of Japanese Patent Application No. 2013-067075 filed Mar. 27, 2013, which is hereby incorporated by reference herein in its entirety.