Subject: [Megaco] ignoring SDP info; RE: [Foip] COM 16 - C 194 (V.34 fallback in T.38)

From: "Schwarz Albrecht" <[email-masked]>
Date: Fri, 23 Oct 2009 08:40:11 +0200

Just a side note to 1:

Right, the semantic of ignore for SDP (RFC 2337, 3264, 4566) is one of
the reasons of T.38 interop issues because it undermines the requirement
of unambiguous T.38 configuration settings between both T.38 endpoints.

Further: there's a difference between 
a) SIP/SDP-controlled T.38 endpoints and 
b) H.248/SDP-controlled T.38 endpoints.
[note: the notion 'H.248/SDP' indicates H.248 text encoding, which uses
SDP in H.248 LD/RD as media description]

Semantic of ignore is allowed in case (a) for SIP, but not allowed for
the master-slave control relationship in H.248. The H.248 MG is not
allowed to ignore unknown SDP, he may react by an error code.

That is one of the motivations of our contribution C-320, which would
solve that particular problem for (a) (the problem does not exist for b,
and also not for H.323-controlled T.38 endpoints).

-Albrecht

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Chen, Ximing 
> M (Michael)
> Sent: Freitag, 23. Oktober 2009 05:08
> To: Hiroshi Tamura; Schulz, Edward D (Ed); [email-masked]
> Cc: [email-masked]
> Subject: Re: [Foip] COM 16 - C 194 (V.34 fallback in T.38)
> 
> Hi, Hiroshi,
> 
> Thanks for your comments.
> 
> 1. I would expect that the existing GWs will simply ignore 
> the fields that they do not understand. This should not be a 
> problem for SIP/SDP as some new fields were added in Annex D 
> recently (T38VendorInfo, for example).
> 
> 2. In the case of G3 only at one GW and V.34 only at the 
> other, GWs will have to stay in the VBD/V.152 mode and not to 
> switch to a T.38 mode. May be we should state this explicitly 
> in the recommendation.
> 
> 3. I will looking into the ASN.1 syntax for H.225.0. Perhaps 
> the first step is to add T38ModemType in Annex D (instead of 
> Annex B) for the SIP/SDP setup? 
> 
> 4. This document/contribution was originally a working 
> document for the SIP Forum's FoIP Task Group 
> (http://www.sipforum.org/content/view/310/252/)  which has 
> recently published a Problem Statement on T.38 
> (http://www.sipforum.org/component/option,com_docman/task,cat_
> view/gid,70/Itemid,261/). The purpose of the FoIP task group 
> is to investigate various issues (interoperability, 
> performance, etc) associated with T.38 in SIP networks. The 
> task group is currently converting the Problem Statement into 
> an IETF document.
> 
> Regards,
> 
> Michael
> ________________________________________
> From: Hiroshi Tamura [[email-masked]]
> Sent: Tuesday, October 20, 2009 3:32 AM
> To: Chen, Ximing M (Michael); Schulz, Edward D (Ed); 
> [email-masked]
> Cc: [email-masked]
> Subject: 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
> _______________________________________________
> FoIP mailing list
> [email-masked]
> http://sipforum.org/mailman/listinfo/foip
>

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 27 Oct 2009 03:59:14 +0100

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

*	From: Hiroshi Tamura <[email-masked]>
*	To: [email-masked]
*	Cc: [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked]
*	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

> From: Hiroshi Tamura [mailto:[email-masked]]
> Sent: Dienstag, 20. Oktober 2009 09:32
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [T16Q14] COM 16 - C 194 (V.34 fallback in T.38)
>
> Michael, Ed and All,
>