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

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Aug 2003 12:49:05 +0100

Thomas,
 
Thanks for your comments. I have taken them all into account except for the
following.
 
<SNIP>
In Section 8.1 4th para is stated: 
"The processing of any valid QSIG message that does not satisfy any of 
these conditions is outside the scope of this specification." 
This seems to be a little bit vague for somebody not familiar with QSIG. 
Since the interworking only comprises QSIG Basic Call, you could be more
specific and mention the unconsidered features provided by ISO 11582 by
adding:

"This includes a QSIG SETUP message intended to establish a call-independent
signalling connection and  connectionless transport as specified in [3]."
[JRE] The statements were not really intended to exclude QSIG features
beyond basic call, but were intended to cover QSIG messages that are not
suitable for mapping to SIP messages because they do not relate to an
existing SIP call or, in the case of a QSIG SETUP message, the call is not
suitable for routing to SIP. I believe the existing text is adequate for
this purpose. There is already a statement in section 1 that QSIG signalling
in support of supplementary services is outside the scope. However, I could
stress this with a separate statement in 8.1 that call-independent
signalling connections and connectionless transport are outside the scope.
Do you think this would be helpful?

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."
[JRE] I will add something. In addition I will add something concerning the
opposite direction, allowing HLC and LLC to be taken into account when
deriving SDP offer information.

</SNIP>
 
Regards,
 
John ([email-masked] <mailto:[email-masked]> )

---

From: "Juan Luis Esteban" <[email-masked]>
Date: Thu, 14 Aug 2003 14:51:22 +0200

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