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

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

*	From: Hiroshi Tamura <[email protected]>
*	To: [email protected]
*	Cc: [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected]
*	Subject: Re: [T16Q14] RE: COM 16 - C 320 - E (T.38 -
Consideration of "revised SDP Offer/Answer)
*	Date: Mon, 26 Oct 2009 08:57:57 +0900 (JST)

________________________________

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:[email protected]]
> Sent: Dienstag, 20. Oktober 2009 09:32
> To: [email protected]; [email protected]; [email protected]
> Cc: [email protected]
> 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
>
>
>

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco