I basically agree (as almost usually) with Paul. From the protocol compliancy point of view, adding a new m line for the T.38 stream (regardless it is the first or the second one, both options are allowed in my interpretation of RFC3264) is allowed as well as replacing the first one, formerly audio. >From the logical point of view, the T.38 stream will replace the audio stream, so the best option (as recommended by RFC3264) is to reuse the same m-line, so that there's no ambiguity about what the offerer is asking for. This way would require a new INVITE in case the answerer doesn't support T.38, to fallback to G.711. The way to use two m-lines would allow the offerer to choose the right "codec" (T.38 or G.711) according to its capabilities, but this option move the problem to the "application" level, because receiving two m-lines may also be considered a request to open two different stream. Therefore the answerer need a logic saying: one m line offers T.38 so it is a fax, if I support it then open the T.38 stream and stop (port=0) the audio stream, otherwise reject (port=0) the T.38 stream and open the G.711 stream. Some vendors started to implement the reinvite with two m lines for allowing the fallback, but unfortunately this way (that might be reasonable if standardized) is not widely implemented by answerers, leading to many interoperability problems and strong dispute about who shall solve the problem (especially when the two domains are different operators). Unless the two m-lines method will become a standard (at least de facto), replacing the audio stream (with subsequent fallback if needed) looks presently as the most reliable solution.
Andrea _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
