Joegen, As far as I can judge this, you are totally right. However for all practicalities it means that the people depending on the SipXecs cannot be reached by customer from that specific operator. Which they experience as pretty annoying, after all everything should work, is not it... Just for your information, the operator is the caller, and the SipX extension is the callee in this case, which is on the local network (192.168.4.x) So indeed the callee properly rejected the T38, after all its is a call to a normal phone. I am considering to provide a couple users with a fax extension, so that sipx does not have to answer with port 0, but instead can do provide a 'normal' port. Just don't know if it would solve the issue for the time being. Anyway thanks all for your very helpful comments! This makes it much cleare to explain what goes wrong.
Peter van der Salm Smart Future cv, Buys Ballotstraat 14, 3572 ZR Utrecht, The Netherlands phone: +31 308 793 512 fax: +31 847 156 296 mobile: +31 620 749 471 [email protected] On Jun 21, 2011, at 14:31 , Joegen Baclor wrote: > 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 >> <[email protected]> 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 >> fax: +31 847 156 296 >> mobile: +31 620 749 471 >> [email protected] >> >> >> >> >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> 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 >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ Smart Future cv, Buys Ballotstraat 14, 3572 ZR Utrecht, The Netherlands phone: +31 308 793 512 fax: +31 847 156 296 mobile: +31 620 749 471 [email protected]
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
