Comments inline. Jean-Fran�ois Sushil Kumar wrote: > I have few questions related to T.38 support in SIP. > > I'll be thankful even if you can answer some of them. Answering them with precision requires some implementation decisions to be made. So when I can't answer them, I'll provide some pointers rather than offering straight answers.
> Q1. In SDP, Is it possible to have following attributes at > the same time > > a=T38FaxUdpEC:t38UDPFEC > a=T38FaxUdpEC:t38UDPRedundancy The questions you have to ask yourself are: A) what does this SDP mean based on the T.38 recommendation? See section 9.3, answer is yes: you can advertize both capabilities. B) When building a sip t38 implementation, can both attributes be received? (I would assume always assume yes and be capable of handling the error cases). In this case, my understanding is that it is allowed to advertize both so you should be capable of receiving those attributes. What you decide to send based on what you receive is kind of implementation dependent. B) When building a sip t38 implementation, should you send both attributes or just one? This is up to your implementation. The FEC and UDP redundancy are 2 complementary mechanisms. > As examples in draft-ietf-sipping-realtimefax-01.txt shows Quick status on this old draft: While this draft is widely implemented and used today, the SIPPING wg chairs decided that this draft does not belong to SIPPING and should instead be moved to MMUSIC and utilize the offer/answer mechanism. I have not been able to follow up on that and based on the numerous emails I've been getting, folks seem to not need such a draft. > so, while at the same time table in "7. SDP Attribute Table > for T.38 sessions" shows either of these can be present but not both. That's the SDP grammar token definition: in one media attribute lines, only one token value must be provided. That does not meean you can't get multiple media attribute lines per the above. > Q2a. In SDP, is it possible to have both > a=T38FaxTranscodingMMR > a=T38FaxTranscodingJBIG ? See the elements of answer above, this is really a fax transcoding question that is given in t.38 (yes). > I think both can be present only with ":0" and not ":1".. > Is that true? T.38 changed and in their versioning, they changed how the SDP attributes are defined - sic. http://www.iana.org/assignments/sdp-parameters So check the latest itu-t specs, the old deprecated versions and based on the T38FaxVersion SDP attribute, you should have a definitive and normative answer. This discussion does not really belong to sip, it is a t.38 recommendation question. > Q2b. Same draft says these are boolean and "true if present" then > what is the use of ":0" and "1"? > > Q2c. Is it mandatory to append ":0" or ":1" for these attributes? > > > Q3a.Is it required to support RFC2833 for supporting T38? > Specially when the audio call is > established with a codec other than "0" before > switching to fax call? Implementation decision. > Q3b. Do all the fax machines/gateways establish the audio > call with codec "0" only ( as shown in the examples of > draft-ietf-sipping-realtimefax-01.txt and > draft-mule-sip-t38callflows-00.txt)? No, as the expired draft stated, we used G.711 for the examples. > Q4a. What are the minimum and maximum values of T38FaxRateManagement? Implementation decision. > > Q4b. Are these the only values for T38FaxRateManagement ? > 2400,4800,7200,9600,12000 and 14400 > > Q5. Is their any sdp attribute something like "transmitpower" > for fax calls? I don't think so. > Q6. What are the latest draft/RFC to refer for T38 suport in > SIP apart from > T.38 ITU specification? Check the upcoming t.38 updated recommendation, annex D. > > > Thanks and Regards, > > Sushil Kumar > Axes Technologies (I) Pvt. Ltd. > > > > > ____________________________________________________ > IncrediMail - Email has finally evolved - Click Here > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
