Why is T.38 offered in the first place, if it's just a phone call.
If it isn't be offered it won't be rejected.
And even if m = image is rejected, when m = audio is accepted the caller
could still accept the call.
Is the operator to blame here or the caller?
- who is creating the INVITE
- who is rejecting the call
Paul
Peter van der Salm <peter.vanders...@smart-future.nl> wrote on 21-06-2011
21:10:04:
> 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
> petervanders...@smart-future.nl
>
> 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 <
> 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
> fax: +31 847 156 296
> mobile: +31 620 749 471
> petervanders...@smart-future.nl
>
>
>
>
>
> _______________________________________________
> sipx-users mailing list
> 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/
>
>
> 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
> petervanders...@smart-future.nl
>
> _______________________________________________
> 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/
