[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Megaco] [T16Q14] COM 16 - C 194 (V.34 fallback in T.38)

Hiroshi,
put my comments [ABS] below inline.
Regards, Albrecht
 
____________________________________________________
Albrecht,

> > 1 New Version 4
> > Confirmation. This content is only for new version (4).
> > It is not influenced in the existing versions (0-3), that is,
> > existing implementation.
> > Is it correct?
>
> No.
> User plane and control plane should be decoupled.
> The ITU-T Rec. T.38 provides a specification for both planes (which
> might be a failure in retrospect):
> - User plane: T.38, cl. 6 - 10 + Annex A for syntax
> - Control plane:
> a) Annex B: H.323
> b) Annex D: SIP/SDP
> c) Annex E: H.248
>
> Thus, the indication and negotiation of T.38 (user plane) configuration
> via control plane is an orthogonal process in comparison to finally
> agreed T.38 configuration(s).

I know. I was a T.38 editor.

> Thus, the proposal by C-320 is basically applicable for all T.38
> versions. It allows to negotiate also older T.38 version than v4.

Simple.
The older version than v4 does not understand the new parameters like
t38UDPNoEC.
When an implementation with the capability of v4 communicates with an former
implementation,
the negotiated version is not v4, thus, the new way cannot be used.
Is it correct?
 
[ABS] The indication and negotiation of such parameters is exactly the responsibility of the control plane signalling protocol. Your comment underlines that all T.38 parameters shall be explicitly negotiated. A T.38 endpoint, not supporting requested parameters or value settings, must indicated this back explicitly to the calling side. It would explicitly reject here that particular T.38 configuration. Any other behaviour of a called T.38 endpoint, like not supporting a dedicated T.38 configuration, but (silently) accepting a request, is just one cause of present interop issues.

> What means "existing implementation"?
> Do you got a tightly coupled user/control plane implementation in mind?
> A T.38 IAF?
> If you think about a SIP-controlled T.38 device, then of course every
> modification of the control plane capabilities are related to your
> SIP/SDP implementation, but should not impact your T.38 user plane
> implementation.
>
> SIP/SDP:
> Existing Annex D/T.38 is using SDP Offer/Answer (which is defined in RFC
> 3264).
> C-320 proposes additional support of "Revised SDP Offer/Answer" ...
> which allow successfull negotiations with RFC 3264 capable SIP/T.38
> endpoints (due to backward compatibility).

I think you already consider the backward compatiblity with the existing
machines in market.
I do not worry so much.

> > 2 H.323 call-setup
> > Is this proposal not targeted for H.323 call-setup (Annex B)?
> > T38FaxUdpEC is a common negotiation paramerter.
> > I do not say that it should also be included in Annex B.
> >
>
> No.
> It's just about SIP/SDP-controlled T.38 service, thus Annex D, but not
> for Annex B or Annex E.

Unless it is wanted in Annex B/E, it is OK for me, although it is a little
unbalanced
in control plane.
 
[ABS] We got to recognize that these different control plane protocols are fairly different. Thus, it is not really unbalanced in my opinion. Each of these three protocols (H.323, SIP, H.248) provides just a slightly different model for indication and negotiation of capabilities and resources for media configurations. 
 
Best regards,
--
Hiroshi Tamura



> -----Original Message-----
> From: Hiroshi Tamura [mailto:tamura at cs.ricoh.co.jp]
> Sent: Dienstag, 20. Oktober 2009 09:32
> To: Michael.Chen at lsi.com; Ed.Schulz at lsi.com; t09sg16q14 at lists.itu.int
> Cc: tamura at cs.ricoh.co.jp
> Subject: [T16Q14] COM 16 - C 194 (V.34 fallback in T.38)
>
> Michael, Ed and All,
>
> As I cannot attend the meeting next week, let me comment here.
>
> 1 Combination of New emitting GW and existing receiving GW
> Receiving GW does not understand the new field "T38ModemType".
> Is it guaranteed that it just ignores the field?
> Did you fully consider the compatibility item with the
> current implementation?
>
> 2 G3 only at one GW and V.34 only at the other GW What
> happens in this case? It implicitly says "prefer" type.
>
> 3 Annex B
> As it is H.323 call-setup, you should consider the ASN.1
> syntax to add H.225.0.
> I do not remember the exact recomendation.
>
> 4 Recommendation to Industry
> How do you proceed?
>
> Best regards,
> --
> Hiroshi Tamura
>
>
>