Subject: Re: [Sipping] WGLC for Q.SIP-SIP mapping draft

From: Luis Emilio Martin <[email-masked]>
Date: Mon, 15 Sep 2003 10:29:25 +0200

Hello,

D.2.2.4/T.38 can be the most straightforward solution to implement fax transmission over IP. However, I think this procedure lacks of certain advanced features provided by Q.931 or ISUP. We are losing some interworking issues that are already considered in current Q.931-ISUP interworking  only by inserting IP equipment.

Referring to IAM your assumption is not correct. It is true that many ISUP networks do not use High Layer information, but this is not true in general. There are ISUP networks of mobile operators that use this information to determine the nature of the call (fax/voice). In GSM networks there is a value of the Bearer Capability (BC) to identify Group III Fax. This value is currently used. Moreover, most mobile terminals with fax
capabilities do not automatically change to fax receiving on tones detection. The cellular receives a call, the user picks up the phone and hears some strange whistles (fax tones).

Nevertheless, this is not true in Q.931, there is not a Group III Fax value for BC. This is, from my point of view, another reason for the need of identifying/setting HLC information additionaly to bearer capability (3,1 Khz audio), to allow correct ISDN-Q.931 interworking. In the ISUP flavour used for GSM the parameter Transmission Medium Requirement is usually set to 3,1 Khz audio.

Then, to solve these interworking problems, I think there could be two possibilities:

1- the calling gateway (voice+fax) could detect fax transmission from the ISUP HLC IE (from Bearer Capability) or Access Transport. In this case, the gateway could send a SIP INVITE suggesting T.38 and G.711 so that, if the called gateway supports T.38, it can generate HLC IE in the proper way (if it is configured so).

2- the calling gateway does not detect anything but send some MIME information conveying HLC IE, BC and other signalling protocol information. The called gateway can regenerate signalling information (indicating fax transmission, in this case) and generate a new invite to the calling gateway, proposing T.38 in SDP. This is a more general approach but some problems in negotiation can arise and should be studied.

Best regards,

Luis Martin

Juan Luis Esteban wrote:

> Hi,
>
> I really don´t understand why a VoIP GW should support D.2.2.3/T.38. This case should be limited to IAFs, which know in advance by other means that the call is a fax call (connected fax machine to a local POTS port, a PC-based fax application, etc...). Similarly, fax communications in the PSTN are connected audio calls with subsequent in-band T.30. T.38 bridges the IP gap and allows seamless T.30 communication between terminals.
> Regarding the elements in the fax path, there will only be 2 of them in a T.38 connection : emitting and receiving gateway, although I could think of scenarios with B2BUAs involved, in which case the B2BUA should map T.38 on both sides. Elements in the signaling path are not involved in intrinsic T.38 procedures.
>
> On the other hand, as far as I know there is no possible indication in IAM about the facsimile nature of a call,
> there is no ISUP parameter (TMR?¿) to map octet4/HLC IE fax info. Thus, encapsulating HLC to send it to the ISUP switch at a terminating GW just doesn´t make sense.
>
> D.2.2.4/T.38 and the scenarios defined in draft-ietf-sipping-realtimefax-02.txt work perfectly for VoIP Gateways and is the most straightforward solution. D.2.2.3/T.38 should be considered a particular case where IAFs are involved.
>
> Regards.
>
> Juan Luis Esteban
> Capcom-
>
> -----Mensaje original-----
> De: Luis Emilio Martin [mailto:[email-masked]]
> Enviado el: jueves, 21 de agosto de 2003 16:10
> Para: Juan Luis Esteban
> CC: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Asunto: Re: [Sipping] WGLC for Q.SIP-SIP mapping draft
>
> Hi,
>
> After some reading I have checked the coarse approach to T.38 and normal PSTN signalling protocols: ISUP, QSIG, ... DSS1 is another case, little effort of standardization is being made appart from ETSI, at least known to me.
>
> In my oppinion, there are some interworking issues widely open about fax transmission. There is an effort in draft-ietf-sipping-realtimefax-01.txt in order to define best current practices and fax call flow examples for real time fax but I should want to require your point of view about several topics that could be necessary in order to achieve succesful
> D.2.2.3 fax transmission and interoperability, from my point of view.
>
> Please consider the following scenario: a PSTN operator wants to have transparent fax transmission between an ISDN-SIP gateway and a SIP-ISUP gateway.
>
> ISDN terminal <---> SIP GW <------> SIP GW <-----> ISUP-enabled switch <---> ...
>
> 1. Detection at the "calling" gateway could be very useful in order to perform T.38 Annex D.2.2.3 fax transmision instead of D.2.2.4 fax transmission with REINVITE. Even more useful if information in HLC information element is important for the called ISUP network. Nothing seems
> to be definitely stated about which information elements in the PSTN protocol are required to trigger the fax detection in the calling SIP gateway. I mean: bearer capability information, high layer compatibility information and so on.
>
> 2. There is not recommendation about the SIP/SDP and T.38 information the calling gateway should generate after fax detection. T.38 is very oriented to H.323 but SIP call flows are less developed.
>
> 3. There is not suggestion about the fax negotiation method among all the elements in the fax path. T.38 speed management method 2 for UDP? . Roles of each node?. Behaviour after receiving T.30 CNG, V21 tones/IFPpackets?
>
> 4. Problems could arise with failures all over the fax path. How to manage them?
>
> 5. How to generate outbound PSTN signalling (i.e. ISUP) from SIP/SDP signalling?
>
> 6. How to transport HLC and LLC information if they were important/useful at destination network? They cannot be mapped to SDP so they should be transported in the SIP INVITE body as MIME type.
>
> All these issues arose when I was thinking T.38 Annex D.2.2.3 fax transmission could be a good idea and proper HLC generation at destination gateway would be the correct solution. Maybe I'm wrong but I think fax transmission is still quite important and, perhaps, it is being overestimated in standardization efforts for interworking. I must reckon it's a
> difficult point but it's worth.
>
> Two first questions to open discussion:
>
> 1. Could it be interesting fax detection on HLC detection at PSTN-SIP gateway?
> 2. What should be the best way to reach an agreement in "protocols" negotiation?
>
> Thank you in advance.
>
> Luis E. Martin
>
> Juan Luis Esteban wrote:
>
> > Luis,
> >
> > Most T.38 GW implementations rely on D.2.2.4/T.38 procedures (Voice and facsimile connection), where an audio session is established and switched over to T.38 on V.21 preamble fax seq detection by the receiving GW. This scenario is described also in 5.2.1/draft-mule-sip-t38callflows-02. A reINVITE is issued by the receiving GW to modify the session SDP.
> >
> > IMHO 5.1.2 is limited to the case where IAFs are involved in the transmission which is also described in D.2.2.3/T.38. Universal GWs supporting voice and fax simultaneously will most likely implement voice to fax switchover according to D.2.2.4/T.38, which seems to be obvious.
> >
> > Does anyone know about SIP GWs implementing D.2.2.3 procedures ?.
> >
> > regards,
> >
> > Juan Luis Esteban
> > Capcom-
> >
> > -----Mensaje original-----
> > De: Luis Emilio Martin [mailto:[email-masked]]
> > Enviado el: miércoles, 13 de agosto de 2003 11:08
> > Para: [email-masked]; [email-masked]
> > CC: [email-masked]; [email-masked]
> > Asunto: WG: [Sipping] WGLC for Q.SIP-SIP mapping draft
> >
> > Hello,
> >
> > > The QSIG SETUP message may optionally transport HLC and LLC Information elements which are not mentioned
> > > in the draft. You might want to add something like into section 10:
> > >
> > >"The gateway SHOULD (or SHALL(?)) not include a Low layer compatibility in the QSIG SETUP message. The
> > > gateway SHOULD not include a High layer compatibility information element in the QSIG SETUP message.
> > >
> > >NOTE: Inclusion of a HLC in the QSIG SETUP message might be useful, if the gateway knows prior to
> > > sending the QSIG SETUP message that fax is being transmitted (e.g., because of a corresponding
> > > SDP offer), it may include in the QSIG SETUP message a High layer compatibility information element
> > > indicating group 3 fax."
> >
> > It is discussed the possibility to include HLC IE in the QSIG SETUP if
> > an INVITE
> > was received with fax transmission information (i.e. T38 only), so that
> > fax
> > detection at destination does not depend on processing audio data. It
> > possibly is a matter of
> > configuration in the gateway.
> >
> > Sorry I am not very used to T.38 procedures and Fax Group 2/3 methods
> > but we are testing some gateways
> > with T.38 and automatic fax detection capabilities based on DSPs and
> > experiencing some strange
> > behaviours in these gateways, so that SETUP messages including HLC
> > produce INVITEs offering G.729 or
> > G.711 and a bit later new INVITES offering t38.
> >
> > In reverse direction, can a SIP gateway, upon reception of a SETUP
> > Message with Bearer Capability
> > 3,1 kHz Audio and an HLC indicating Fax Group 2/3, to map the HLC field
> > into an INVITE message
> > with an SDP offering T.38 only (not any other audio codec). The example
> > is
> > taken from chapter 5.1.2
> > http://www.watersprings.org/pub/id/draft-mule-sip-t38callflows-02.txt :
> >
> >       Content-Type: application/sdp
> >       Content-Length: 320
> >
> >       v=0
> >       o=ifaxgw1 2890846527 2890846527 IN IP4 ifax.here.com
> >       s=Session SDP
> >       c=IN IP4 ifaxmg.here.com
> >       t=0 0
> >       m=image 15002 udptl t38
> >       a=T38FaxVersion:0
> >       a=T38MaxBitRate:14400
> >       a=T38FaxFillBitRemoval:0
> >       a=T38FaxTranscodingMMR:0
> >       a=T38FaxTranscodingJBIG:0
> >       a=T38FaxRateManagement:transferredTCF
> >
> > It should be the most straightforward procedure to map fax but is my
> > interpretation correct?...
> > or the reception of a setUp with such IE values does not have enough
> > information to
> > include an SDP offering with T.38 only, so it is required to wait for
> > CNG/V21 detection
> > to pick all the information required, and a renegotiation is thus
> > required after call is
> > stablished?
> >
> > Thank you very much in advance
> >
> > Best Regards
> >
> > Luis Martin
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Juan Luis Esteban" <[email-masked]>
Date: Mon, 25 Aug 2003 17:45:41 +0200

Hi,

Regards.

Juan Luis Esteban
Capcom-

-----Mensaje original-----
De: Luis Emilio Martin [mailto:[email-masked]]
Enviado el: jueves, 21 de agosto de 2003 16:10
Para: Juan Luis Esteban
CC: [email-masked]; [email-masked];

Hi,

Thank you in advance.

Luis E. Martin