[SIPForum-discussion] FAX Call Identification

[Maciej Wasiel]

Hi,
Is the re-invite for t.38 or g.711 pass-through (codec upspeed)? One way of distinguishing a fax call from a voice call is to detect fax tones in the initial audio stream; however, your media server is not guaranteed to have this capability.
Regards,
Maciej

From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of John Berg
Sent: Thursday, January 06, 2011 4:37 PM
To: 'discussion at sipforum.org'
Subject: Re: [SIPForum-discussion] FAX Call Identification

These specifications will also prove to be useful:

ITU-T Recommendation T.38, Procedures for Real-Time Group 3 Facsimile Communication over IP Networks
RFC3407
RFC4566

You might also check to be sure that the media capabilities indicate support for T.38 through each leg of the call, e.g.
a=pmft:T38
a=image udptl t38

The key is determining if T.38 can be used at the time of each SDP exchange.

Regards,
John


From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of Ronald del Rosario
Sent: Thursday, January 06, 2011 9:58 AM
To: Ashoke Kumar Ghosh; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] FAX Call Identification

Ashoke,

Please review the ITU Specification for T.38 (fax over IP) and IETF's SDP Extensions for Fax over IP Using T.38<http://tools.ietf.org/html/draft-ietf-mmusic-sdp-t38-00>.

All your questions will be answered there, well almost :)

Best.
Ron
http://packetboyperseus.blogspot.com



From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of Ashoke Kumar Ghosh
Sent: Wednesday, January 05, 2011 8:20 PM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] FAX Call Identification

Dear All,

We have SIP Application server platform that works in B2BUA mode. The platform handles the prepaid charging as well.
The Application Servere receives SIP request from the NGN Elements, applies account validation and initiates one new SIP Dialog with NGN for routing towards B party. The Application Server maintains two separate dialog for A party and B party.

We have observed that Re-INVITE message is received for normal voice calls for heart beating purpose for both legs of the call. The Application Server sends 200 OK on receipt of Re-INVITE message without SDP.

PROBLEM STATEMENT:

We are having one problem in terms of identifying the fax calls. Sample traces taken show that for fax calls are being set up initially like normal voice calls. After dialog confirmation, Re-INVITE message is being received from A party side with modified SDP. Since Application Server considers Re-INVITE as heart beating message, it is simply generating 200 OK without SDP. As a result, fax calls are failing.

QUESTIONS:

I would like to receive suggestions/references for handling fax calls.

1. Is there any RFC that proposes how fax calls should be handled.

2. How to identify the fax call/normal call. This is critical from charging aspect. Unless we are able to identify the call as fax call, we can not apply separate charging for fax calls.

3. We have raised the issue with our NGN vendor. They have suggested to compare the SDP parameters and for all Re-INVITE messages and if there is any difference observed from the initial SDP, then pass the modified SDP to B party leg.

I am not sure if Application Server as a B2BUA should inspect the SDP parameters and apply such validations. This is not only going to have lot of overheads, it is not going to resolve the issue of charging as fax call identification will still be required.

Would appreciate a quick response from the experts.
Thanks & Regards...

Ashoke Kumar Ghosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20110107/77cb2126/attachment-0002.html>