Indeed, there was a small problem, in the future there will be a new
rfc.......
http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-07
One line from this draft:
"A glaring omission from this list is the "image" media type."
Paul
----- Forwarded by Paul Scheepens/EPO on 28-06-2011 08:55 -----
[email protected] wrote on 24-06-2011 16:42:11:
> 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 <[email protected]> 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
> > > <[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
> 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
> > >> [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
bematched 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/
> _______________________________________________
> 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/
