VoIP Mailing List Archives

[mkarp at securesilence...]

Hello,

I am using a GSM based endpoint connected to freeswitch that makes calls to
the PSTN via a SIP gateway (SBC). The SBC uses PCMU between itself and
freeswitch.

When I make an outgoing call from a GSM based device via freewsitch to the
PSTN via the SBC, everything works fine and audio works in both directions
for both end points. I looked at the console logs and they do indicate that
I am using GSM.

Console output when I dial and before answer on the GSM device:

v=0
o=- 74 0 IN IP4 10.229.0.58
s=session
c=IN IP4 10.229.0.58
b=CT:17
t=0 0
m=audio 59806 RTP/AVP 8 0 3 97 101
k=base64:P6l1kBQy3canYTWZkxccjAVtTWO9g/N5L4gxLtX0UnM
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=encryption:optional

Console output once it rings and after I answer on the PSTN side:

v=0
o=FreeSWITCH 1227887572 1227887573 IN IP4 10.229.0.10
s=FreeSWITCH
c=IN IP4 10.229.0.10
t=0 0
a=sendrecv
m=audio 30896 RTP/AVP 3 101 13
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

When I receive a call from the SIP gateway, the endpoint making the call
(not on freeswitch) can't hear me speaking from the GSM device connected to
freeswitch. I can hear everything fine on the GSM device.

Here is the console output for the call info coming in from the PSTN.

v=0
o=FreeSWITCH 1227902084 1227902085 IN IP4 38.113.164.132
s=FreeSWITCH
c=IN IP4 38.113.164.132
t=0 0
a=sendrecv
m=audio 16724 RTP/AVP 0 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

Here is how I have vars.xml configured:

<X-PRE-PROCESS cmd="set" data="global_codec_prefs=GSM"/>
<X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMU,PCMA,GSM"/>


When I prioritize GSM on the outbound codec prefs I get static on the PSTN
side.

<X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=GSM,PCMU,PCMA "/>

Any ideas?

Maxim.


_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[Prometheus001 at gmx.net]

Hello Maxim,

can you reach another internal device except the GSM one in order to see
whether it's GSM codec specific?

However I can see that you're using local IPs (10.x.x.x) so I expect
that they are natted. This often causes one way audio when the external
rtp-ip is not set. Please try to set a
<param name="ext-rtp-ip" value="stun:stun.freeswitch.org"/>
entry to internal.xml and external.xml in your SIP profiles and see if
it works. Use stun at least for the internal profile (FQDN and external
IP most probably will not work)

Best regards
Peter

Maxim Karp schrieb:

[mkarp at securesilence...]

Hi Peter,

Thanks for your response.

When I use PCMU two-way audio works fine.

When I make outgoing calls from a Freeswitch extension (using GSM) and then
out to a gateway using PCMU everything works fine.

When I receive calls from the same gateway, the end point behind the gateway
can't hear me.

The GSM-PSMU (and viceversa) transcoding for outgoing from an endpoint
associated with a Freeswitch extension to the external gateway is perfect
but incoming there seems to be an issue.

Maxim.

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org
[mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Peter P
GMX
Sent: December-01-08 3:39 AM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Inbound 1-way audio issue using GSM codec

Hello Maxim,

can you reach another internal device except the GSM one in order to see
whether it's GSM codec specific?

However I can see that you're using local IPs (10.x.x.x) so I expect
that they are natted. This often causes one way audio when the external
rtp-ip is not set. Please try to set a
<param name="ext-rtp-ip" value="stun:stun.freeswitch.org"/>
entry to internal.xml and external.xml in your SIP profiles and see if
it works. Use stun at least for the internal profile (FQDN and external
IP most probably will not work)

Best regards
Peter

Maxim Karp schrieb:

[anthony.minessale at g...]

probably pstn side has acknowledged our gsm then sent ulaw anyway and we think its gsm.
most likely there are multiple codecs in the accept packet from the gateway and they expect us to figure out what codec to use based on the first packet we get from them rather than just accepting one codec in the sdp like 90% of devices so we have a proper chance to setup optimal packetization. This is one of those lame parts of the RFC that describe complete unscalable stupidity that some stuff likes to tout for who knows why.

one thing you can try is to set the variable aboslute_codec_string in the dial to force
only gsm to be advertised at all making it impossible for the remote end to respond with multiple codecs.

<action application="bridge" data="{absolute_codec_string=GSM}sofia/<profile>/<uri>"/>




On Fri, Nov 28, 2008 at 6:36 PM, Maxim Karp <mkarp@securesilence.com (mkarp@securesilence.com)> wrote: