See http://tools.ietf.org/rfc/rfc3362.txt
On 06/24/2011 10:42 PM, pscheep...@epo.org wrote:
Let's make it more text crunchyone 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 typ
Let's make it more text crunchyone 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:
is the media type. Currently defined media are "audio",
"video", "te
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
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 an
I'd raise a sipXecs JIRA (http://track.sipfoundry.org) as an external
problem so this is at least flagged. If you would like it addressed sooner
rather than later I'd also raise it over at FS.
On Wed, Jun 22, 2011 at 7:56 PM, Peter van der Salm <
peter.vanders...@smart-future.nl> wrote:
> Well P
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
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
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 f
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
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, Pe
not that I know of (easily). fs is setup to receive faxes so the call is
going to a DID used for faxing, right?
calls to an endpoint or aa shouldn't be negotiated as t.38 calls. sipx
thinks the cal destination is a fax number , right?
On Jun 21, 2011 5:07 AM, "Peter van der Salm" <
peter.vanders..
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 lin
12 matches
Mail list logo
