* You are viewing Posts Tagged ‘RTP’

T38 and codecs negotiation

Hi,
I’m working with asterisk 1.4.35 and found an issue regarding codecs
negotiation when T38 is enabled (t38pt_udptl=yes).
In particular if the INVITE sdp contains no allowed codec the call is not
rejected with “488 – Not acceptable here” but it goes through and the 200 OK
SDP is as follows:

v=0
o=root 27285 27285 IN IP4 xxx.xxx.xxx.xxx
s=session
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio xxxxx RTP/AVP
a=silenceSupp:off – - – -
a=sendrecv

or

v=0
o=root 27285 27285 IN IP4 xxx.xxx.xxx.xxx
s=session
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio xxxxx RTP/AVP 96
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=silenceSupp:off – - – -
a=sendrecv

if in the originating INVITE there was the a line for telephone-event
mapping.
Looking chan_sip.c I understood that the problem is related to t38
capabilities and in particular at row 5636:

if (!newjointcapability) {
/* If T.38 was not negotiated either, totally bail out… */
if (!p->t38.jointcapability || !udptlportno) {
ast_log(LOG_NOTICE, “No compatible codecs, not accepting
this offer!n”);
/* Do NOT Change current setting */
return -1;
} else {
if (option_debug > 2)
ast_log(LOG_DEBUG, “Have T.38 but no audio codecs,
accepting offer anywayn”);
}
}

As I understand if t38 is globally enabled p->t38.jointcapability
and udptlportno are always true even so the call is never rejected.
As this behavior caused me some problems with a customer I modified, for the
moment, the line 5638 as follows:

if (!p->t38.jointcapability || !udptlportno || p->t38.state == T38_DISABLED)

cause if I understand well the code if there is no fax request in the INVITE
SDP p->t38.state is set to T38_DISABLED.
This did the trick for me but I don’t know the implications of such change
and if it is correct to manage it this way.

Kind regards,

Federico Cabiddu

Asterisk 1.8.0-beta5 Now Available

The Asterisk Development Team has announced the release of Asterisk 1.8.0-beta5.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/asterisk/

All interested users of Asterisk are encouraged to participate in the 1.8
testing process. Please report any issues found to the issue tracker,
http://issues.asterisk.org/. It is also very useful to see successful test
reports. Please post those to the asterisk-dev mailing list.

Asterisk 1.8 is the next major release series of Asterisk. It will be a Long
Term Support (LTS) release, similar to Asterisk 1.4. For more information about
support time lines for Asterisk releases, see the Asterisk versions page.

http://www.asterisk.org/asterisk-versions

This release contains fixes since the last beta release as reported by the
community. A sampling of the changes in this release include:

* Fix issue where TOS is no longer set on RTP packets.
(Closes issue #17890. Reported, patched by elguero)

* Change pedantic default value in chan_sip from ‘no’ to ‘yes’

* Asterisk now dynamically builds the “Supported” header depending on what is
enabled/disabled in sip.conf. Session timers used to always be advertised as
being supported even when they were disabled in the configuration.
(Related to issue #17005. Patched by dvossel)

* Convert MOH to use generic timers.
(Closes issue #17726. Reported by lmadsen. Patched by tilghman)

* Fix SRTP for changing SSRC and multiple a=crypto SDP lines. Adding code to
Asterisk that changed the SSRC during bridges and masquerades broke SRTP
functionality. Also broken was handling the situation where an incoming
INVITE had more than one crypto offer.
(Closes issue #17563. Reported by Alexcr. Patched by twilson)

Asterisk 1.8 contains many new features over previous releases of Asterisk.
A short list of included features includes:

* Secure RTP
* IPv6 Support in the SIP Channel
* Connected Party Identification Support
* Calendaring Integration
* A new call logging system, Channel Event Logging (CEL)
* Distributed Device State using Jabber/XMPP PubSub
* Call Completion Supplementary Services support
* Advice of Charge support
* Much, much more!

A full list of new features can be found in the CHANGES file.

http://svn.digium.com/view/asterisk/branches/1.8/CHANGES?view=checkout

For a full list of changes in the current release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8.0-beta5

Thank you for your continued support of Asterisk!

SPA3102 FAX not working

Hi,

I have created one SIP extension in Asterisk and configured that extension
in SPA 3102. And connected one FAX machine to the SPA3102 and one to
Asterisk.

The problem is if I try to send FAX from SPA3102 to Asterisk i am not able
to send. But if the same if I try to send from Asterisk to SPA3102 it is
working.

In the SPA3102 following are the options I changed for the FAX settings,

Call Waiting Serv:No
Three Way Call Serv:No
Preferred Codec:G711u
FAX Passthru Method:ReINVITE
DTMF Tx Mode:Normal
FAX Enable T38:yes

After all these changes still I am not able to send the fax, while checking
in the rtp debug from SPA3102 to Asterisk the sequential no. 0 but whereas
from Asterisk to SPA3102 I can able to see some rtp traffic.

Your help would be much appreciated….

Possible malformed G729B – SID (VAD/DTX)framesfrom carrier endpoint ?

Steve-

>>>> We are in the process of debugging a voice quality issue for a client of
>>>> ours that is a VoIP services provider. The client uses a softphone that
>>>> runs on a pjsip stack.
>>>>
>>>> When placing a call using the softphone, it negotiates the use of G729
>>>> codec with the remote endpoint (ptime = 20ms). The endpoint transmits RTP
>>>> packets with encoded G729 payload. VAD/DTX is enabled. We see that the
>>>> last frame transmitted by the carrier side endpoint, before the beginning
>>>> of a period of discontinuous transmission has 20 bytes of payload. We have
>>>> verified that VAD/DTX is used by the carrier side endpoint by noting that
>>>> there exist successive RTP packets that differ by 1 in their sequence
>>>> number but have a timestamp difference> 160 and MARK bits are set in the
>>>> RTP header.
>>>>
>>>> Our understanding is that for G729B, the SID frame that is transmitted
>>>> before a period of discontinuous transmission has a size of 2 bytes.
>>>> However we see that ALL RTP packets sent by the carrier side end point has
>>>> a length of 20 bytes.
>>>>
>>>> Has anybody else seen this behavior from a carrier side endpoint ? Is
>>>> there an RFC or document that specifies
>>> Your understanding is correct. You need to infer from the length of the
>>> last frame being 2 bytes that it is a SID frame, and SID frames should
>>> only ever occur as the last frame in an RTP packet. If the SDP
>>> negotiation has agreed to used the annex B (CNG/DTX/VAD) option for
>>> G.729 you would normally expect to see a SID frame at the end of
>>> transmission. If the SDP negotiation has agree to do CNG/DTX/VAD by
>>> another means (which it can do) you won’t see those SID frames. Even
>>> when annex B is used, I think some systems may miss out the SID frames.
>>> The use of proper annex B processing requires additional patent licence
>>> payments, and I suspect some people try to fudge things to save a little
>>> cost.
>> We have Kamailio + rtpproxy running between the endpoints. Do you think it’s reasonable to convert the first
>> malformed SID frame (10 bytes) to 2 bytes, and then strip the following malformed SID frames until we see the
>> talkspurt marker bit is set? We could do that… I’m wondering if anyone has seen such malformed SID frames before.
>>
>> As a couple of additional notes, between us and the remote endpoint there appears to be using an ALOE Systems
>> (formerly MERA systems) MSiP system. So far the SDP negotiations we’ve tried (e.g. a=fmtp:18 annexb=no) have not
>> convinced the remote endpoint to disable VAD.
> What makes you think there is a SID with the wrong length, rather than
> no SID? Do the first 2 of the 10 bytes look like SID?

The first two bytes appear not to be a proper SID. However, as Vikram mentioned time-stamps show an increase greater
than ptime and MARK bit is set in the RTP header. Then there are several consecutive packets (from 10 to 100) with
this combination. Once we see the first of these, possibly we could strip and generate a correct SID.

> I expect if you have annexb set to no, then some other form of VAD is
> active, and suppressing transmission.

Yes… something in the middle… possibly the MSiP.

-Jeff

Possible malformed G729B – SID (VAD/DTX)frames from carrier endpoint ?

Steve-

> On 09/05/2010 04:08 AM, Vikram Ragukumar wrote:
>> Hello,
>>
>> We are in the process of debugging a voice quality issue for a client of
>> ours that is a VoIP services provider. The client uses a softphone that
>> runs on a pjsip stack.
>>
>> When placing a call using the softphone, it negotiates the use of G729
>> codec with the remote endpoint (ptime = 20ms). The endpoint transmits RTP
>> packets with encoded G729 payload. VAD/DTX is enabled. We see that the
>> last frame transmitted by the carrier side endpoint, before the beginning
>> of a period of discontinuous transmission has 20 bytes of payload. We have
>> verified that VAD/DTX is used by the carrier side endpoint by noting that
>> there exist successive RTP packets that differ by 1 in their sequence
>> number but have a timestamp difference> 160 and MARK bits are set in the
>> RTP header.
>>
>> Our understanding is that for G729B, the SID frame that is transmitted
>> before a period of discontinuous transmission has a size of 2 bytes.
>> However we see that ALL RTP packets sent by the carrier side end point has
>> a length of 20 bytes.
>>
>> Has anybody else seen this behavior from a carrier side endpoint ? Is
>> there an RFC or document that specifies
> Your understanding is correct. You need to infer from the length of the
> last frame being 2 bytes that it is a SID frame, and SID frames should
> only ever occur as the last frame in an RTP packet. If the SDP
> negotiation has agreed to used the annex B (CNG/DTX/VAD) option for
> G.729 you would normally expect to see a SID frame at the end of
> transmission. If the SDP negotiation has agree to do CNG/DTX/VAD by
> another means (which it can do) you won’t see those SID frames. Even
> when annex B is used, I think some systems may miss out the SID frames.
> The use of proper annex B processing requires additional patent licence
> payments, and I suspect some people try to fudge things to save a little
> cost.

We have Kamailio + rtpproxy running between the endpoints. Do you think it’s reasonable to convert the first
malformed SID frame (10 bytes) to 2 bytes, and then strip the following malformed SID frames until we see the
talkspurt marker bit is set? We could do that… I’m wondering if anyone has seen such malformed SID frames before.

As a couple of additional notes, between us and the remote endpoint there appears to be using an ALOE Systems
(formerly MERA systems) MSiP system. So far the SDP negotiations we’ve tried (e.g. a=fmtp:18 annexb=no) have not
convinced the remote endpoint to disable VAD.

-Jeff