Let's make it more text crunchy....one for the weekend (although I
have other plans :)
(Please tell me I am wrong, but I can't find proof that I am)
Officially "m=image" is not a defined SDP media type:
rfc 4566:
<media> is the media type. Currently defined media are "audio",
"video", "text", "application", and "message", although this list
may be extended in the future (see Section 8).
or
_http://www.iana.org/assignments/sdp-parameters_
A valid request should look more like this:
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 telephone-event
a=fmtp:96 0-15,32-35
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18 96
a=cpar: a=fmtp:96 0-16,32-35
a=cdsc: 4 image udptl t38
a=cdsc: 5 image tcp t38
(although according to _http://www.ietf.org/rfc/rfc3407.txt_
Each capability description in the capability set is on the form:
a=cdsc: <cap-num> <media> <transport> <fmt list>
where <cap-num> is an integer between 1 and 255 (both included) used
to number the capabilities, and <media>, <transport>, and <fmt list>
are defined as in the SDP "m=" line.
)
In some rfc's m=image is used however:
rfc4145:
m=image 54111 TCP t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
rfc4572:
m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
A nice example is _http://www.ietf.org/rfc/rfc5347.txt_
where both formats are used depending on who was writing probably....
But unless my google skills are deteriorating then sdp does not
support m=image, and that makes the request malformed => drop it.
Paul
Joegen Baclor <jbac...@ezuce.com> wrote on 24-06-2011 14:44:33:
>
> 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
> > <peter.vanders...@smart-future.nl> 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
Andreasfrom 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
> >> petervanders...@smart-future.nl
> >>
> >>
> >>
> >> On Jun 22, 2011, at 13:54 , pscheep...@epo.org 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<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/
> >>
> >> _______________________________________________
> >> 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/
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
