Josh,
In the contrary, the ITSP actually offered T.38 in the INVITE. The
callee was polite enough to reject the offer by setting the port to
zero. The OP did not specify the call flow well for us to identify
who/which the callee is. Yes this is the proper way of rejecting the
stream and since it's the "proper" way, removing it makes it improper
which is a regression so the request will not get too much traction IMO.
Quote from RFC 3264:
6 Generating the Answer
The answer to an offered session description is based on the offered
session description. If the answer is different from the offer in
any way (different IP addresses, ports, etc.), the origin line MUST
be different in the answer, since the answer is generated by a
different entity. In that case, the version number in the "o=" line
of the answer is unrelated to the version number in the o line of the
offer.
For each "m=" line in the offer, there MUST be a corresponding "m="
line in the answer. The answer MUST contain exactly the same number
of "m=" lines as the offer. This allows for streams to be matched up
based on their order. This implies that if the offer contained zero
"m=" lines, the answer MUST contain zero "m=" lines.
The "t=" line in the answer MUST equal that of the offer. The time
of the session cannot be negotiated.
An offered stream MAY be rejected in the answer, for any reason. If
a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero. Any media formats listed are ignored. At least
one MUST be present, as specified by SDP.
Constructing an answer for each offered stream differs for unicast
and multicast.
Joegen
On 06/21/2011 08:18 PM, Josh Patten wrote:
This line is required for the proper function of the fax service as it
is T.38 only (no G.711 transport) and different ITSPs behave
differently when dealing with T.38. If your ITSP doesn't support T.38
(likely it doesn't) then they appear to disconnect the call.
On Tue, Jun 21, 2011 at 4:07 AM, Peter van der Salm
<peter.vanders...@smart-future.nl
<mailto:peter.vanders...@smart-future.nl>> wrote:
Hi All,
We have a SipXecs 4.4.0- 2011-05-10EDT22:48:21. Incoming calls
from one particular operator on a SIP trunk fail.
Further analyses has shown that the call is ended from the
operators side (Tele2), after the 200 OK on the INVITE is sent
from the SIPX
In the 200 OK there is in the SDP a line with with:
m=image 0 UDPTL 19
which seems to cause the problem. As far as my knowledge
stretches, this is a proper and allowed way to tell that (T.38?)
is not supported on the call, port =0 after all....
Just to keep thing down to earth: is there a way to make SipXecs
NOT send this line?
In fact the operator in question should correct its behavior, but
that may take a long time.....
I have attached the pcap.
Kind Regards,
Peter van der Salm
Smart Future cv,
Buys Ballotstraat 14,
3572 ZR Utrecht,
The Netherlands
phone: +31 308 793 512 <tel:%2B31%20308%20793%20512>
fax: +31 847 156 296 <tel:%2B31%20847%20156%20296>
mobile: +31 620 749 471 <tel:%2B31%20620%20749%20471>
petervanders...@smart-future.nl
<mailto:petervanders...@smart-future.nl>
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org <mailto:sipx-users@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
