Re: [AVT] Re: draft-jones-avt-audio-t38-04.txt

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

See below

Hiroshi Tamura wrote:


> I understand what you are saying.
>
> At first, I want to say,
> although I am familiar with T.38 to some extent, I am not the editor of
> T.38 amd2, which has just been recommended. 
> Also, I am not the man who proposed to introduce SIP/SDP call-setup in
> T.38.
>
> When SIP/SDP call-setup was included in T.38 in Nov 2000, T.38 Annex
> D.2.3
> already had the following sentences:
> "The RFC 2327 Session Description Protocol (SDP) provides mechanisms for
>  describing sessions for SIP. However, new attributes (section 6 of SDP)
> are
>  required to support ITU-T Rec. T.38. Specifically, the following
> options are
>  registered with IANA as valid att-field and att-value values per the
> procedure
>  noted in Appendix B of SDP (RFC 2327). Note that options without values
> are
>  boolean - their presence indicates that they are valid for the
> session."
>
> They still exist. I believe the editor of T.38 amd2 made the texts that
> Paul quoted, considering the above.
>
> I would like to say general things from the standard point of view.
> We already have products in our market. The change in Annex D.2.3 could
> cause
> interoperability issues.
>
> However, regarding T.38 amd2, it is very new.
> If we could deal with this issue very soon, it might not cause a new
> one.
> In order to do that, you need to propose a corrigendum to ITU-T.

I have not proposed to change the a=T38attributes. They are defined, and 
they are used in a m= block where one has udptl or TCP as protocol 
identifiers. However for m= blocks that has RTP as protocol identifier 
there is need to stay to the rules, and preferable follow any 
recommendations. However as I understand it, it is allowed to define the 
usage of the "a=fmtp" line freely. So to avoid creating an discrepancy 
between the MIME registration and the T.38 I think the most sensible 
thing is to keep the current text, which uses the presence.



> Some negotiated parameters written in the I-D do not offer multiple
> choices.
> I am sorry I do not understand the Offer/Answer model completely.
> Some of them may not be applied to the model. Is it true?


Sorry, I do not understand what you ask about. To my understanding, any 
parameter needing to have a configuration value that apply in both 
directions, will have to use a rule saying that the answer MUST NOT 
change it. Instead one will need to use different PTs offering different 
configurations.

But you should consider in regards to the T.38 what happens if one has 
multiple active payload types, does that work, if each direction 
communicate with different settings. I could think that if there some 
inband signalling, and both parties must do it, then both sides must use 
the same payload type. If so you will probably need to force the 
negotiating parties to perform a 1 of N choice.


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt