Well said Tony, >> 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.
I think 3263 is very explicit on this fact. "Any media formats listed are ignored." translates to nothing else but that. So interpreting this versus 3551 is anything but ignoring it. On 06/24/2011 06:47 PM, Tony Graziano wrote: > Am I the only that finds RFC3551 interesting in that it doesn't apply > to t38? Why would the ITSP reference RFC3551? It's for audio and video > only. > > the port 0 with PT of 19 is sofia rejecting the sdp FS doesn't support > it. The only time it came up in FS is when an ITSP was not ignoring > port zero and moving on the the next offer... port is 0, so its not > legitimate. Do we cloud it up and say udptl is t38 and make that part > more legitimate? > > m=image 51458 udptl t38 > > That's a legitimate response, but it's not a fax call. > > I would ask the FS guys their thoughts on the comments from your ITSP, > and I fully suspect their suggestion to change udptl t38 would be > considered "problematic" because its legitimate. FS says port 0 the > udptl and now besides changing freeswitch, the code in which it > assembles the response from the t38 module from soft switch has to be > altered. > > Your ITSP should see port 0 and decide 'insufficient information" and > move on, not drop. > > I think the ITSP is stuck in looking at RFC3551 which is an extremely > weak argument since they are the ones who are offering t38 in the > first place, and RFC3551 is for audio/video SDP only. I think, rather, > you need to make them focus on what RFC is at hand here, RFC3264. This > describes the proper way to answer an offer. m=0 means, don't use this > one, not drop it. > > I don't usually chime in on this type of discussion, but when someone > wants to make big changes to something that is not broken, it makes me > shudder, because a broken ITSP should not be driving the project this > way. > > I also would point out that there might be more than one way to do > this, using an SBC, to insulate this. When using SBC's we see crappy > Asterisk implementations that dont work as pure sip calls, so we made > a rule for these in the SBC to handle these connections differently, > even when TELE2 and T38 were not involved. > > Have you considered using Karoo in front of sipx to see if it can > manipulate this into a friendly and workable solution? > > On Wed, Jun 22, 2011 at 7:56 PM, Peter van der Salm > <[email protected]> wrote: >> Well Paul, that is a good question! Fact is that Tele2 offers it in their >> INVITE SDP anyway. >> I learned today that according to the Tele2 engineers and Andreas from Unet, >> the reason that the call is dropped is in the number '19' that is sent in >> the SDP response: >> >> m=image 0 UDPTL 19 >> >> 19 is the payload type, which is defined in RFC3551 as 'reserved': >> >> 6. Payload Type Definitions >> >> Tables 4 and 5 define this profile's static payload type values for >> the PT field of the RTP data header. In addition, payload type >> values in the range 96-127 MAY be defined dynamically through a >> conference control protocol, which is beyond the scope of this >> document. For example, a session directory could specify that for a >> given session, payload type 96 indicates PCMU encoding, 8,000 Hz >> sampling rate, 2 channels. Entries in Tables 4 and 5 with payload >> type "dyn" have no static payload type assigned and are only used >> with a dynamic payload type. Payload type 2 was assigned to G721 in >> RFC 1890 and to its equivalent successor G726-32 in draft versions of >> this specification, but its use is now deprecated and that static >> payload type is marked reserved due to conflicting use for the >> payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4). >> Payload type 13 indicates the Comfort Noise (CN) payload format >> specified in RFC 3389 [9]. *****Payload type 19 is marked "reserved" >> because some draft versions of this specification assigned that >> number to an earlier version of the comfort noise payload format.****** >> The payload type range 72-76 is marked "reserved" so that RTCP and >> RTP packets can be reliably distinguished (see Section "Summary of >> Protocol Constants" of the RTP protocol specification). >> >> So if we could change the '19' in something more appropriate, the issue >> would likely not occur. >> I assume that it is not important with what we replace the '19', as long as >> it is something that exists in RFC3551 >> After all the offer is refused anyway with port=0. To make it completely >> correct, we might answer what is sent, which is 't38' instead of '19'. So >> the m-line in the invite reads: >> m=image 51458 udptl t38 >> It seems that this has been a problem in Freeswitch before, see here: >> http://lists.freeswitch.org/pipermail/freeswitch-users/2010-February/054125.html >> I cannot find that it was solved there..... >> >> 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] >> >> >> >> On Jun 22, 2011, at 13:54 , [email protected] wrote: >> >> 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<[email protected]> 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 >>> [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/_______________________________________________ >> 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/ >> > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
