[SIP Beyond VoIP] Missing incoming RTP stream

Janusz Kowalczyk kowalczykjanusz at gmail.com
Wed Jun 26 13:21:41 CEST 2013


Thanks Saul. Will try to use this script as a base for my script :)

I'm not sure whether I have to use STUN server.
I tried using "sip-session" or "sip-audio-session" script with and without
STUN server configured and RTP worked both ways. And those calls were made
to/from EC2 instance.

This is slightly out of topic, but the only problem I have with both of
those scripts is that they send DTMF as RTP events even if the account is
configured to use inband ones.
I've enabled inband dtmf by:
sip-settings -a set user at myaccount.com rtp.inband_dtmf=True

To configure a STUN server for my account [ I used one out of many listed
here http://www.tek-tips.com/faqs.cfm?fid=7542 ] I run:
sip-settings -a set user at myaccount.com nat_traversal.stun_server_list='
stun.ekiga.net'

Here's how I launch the scripts:
sip-session --auto-answer -S -c ~/.sipclient -a user at myaccount.com
sip-audio-session --auto-answer -S -c ~/.sipclient -a user at myaccount.com

When I use "sip-session" to call my desk phone, and I use "/dtmf {0-9}"
command, then on desk phone I can barely hear some really faint and really
short signal which presumably is the DTMF.
When I use "sip-audio-session" to answer incoming calls from my desk phone,
when I press keys on my phone then all tones are send as RTP events.

I could attach pcap files but they're stripped off automatically :)

Here's my config file: ~/.sipclient/config
Accounts:
    user at myaccount.com
        enabled = true
        auth:
            password = some_password

        nat_traversal:
            stun_server_list = "stun.ekiga.net:3478",

        rtp:
            audio_codec_list = PCMA,
            inband_dtmf = true

        sip:
            outbound_proxy = "nat.myaccount.com:5065;transport=udp"

SIPSimpleSettings:
    default_account = user at myaccount.com
    instance_id = "urn:uuid:e83fa8c5-80b1-482f-bb2a-e9dd7bdd9ef8"
    audio:
        alert_device =
        input_device =
        output_device =








On 25 June 2013 17:31, Saúl Ibarra Corretgé <saul at ag-projects.com> wrote:

> Hi,
>
> On Jun 25, 2013, at 4:55 PM, Janusz Kowalczyk wrote:
>
> > Hi Guys,
> >
> > I'm trying to use SipSimple SDK write test scripts that will be executed
> with fabric on a remote machine without a soundcard (ie. Amazon EC2) and
> which would dial in to our voice service and play back some wav files
> and/or DTMF's.
> >
> >
> > At the moment I'm trying to use modified version of Saul's "jamesbond"
> script
> > https://github.com/saghul/sipsimple-examples/tree/master/jamesbond
> > to make a call and play a wav file once call is established. Modified
> script is at the end of email.
> >
> > The problem is that there's no incoming RTP stream. I doubled check
> firewall rules and UDP traffic is allowed on all ports. I've attached a
> pcap file from an example call.
> >
> > I'd be grateful if you could help me to figure out what's the problem.
> >
>
> Unless your service does NAT traversal you'll not be able to get inbound
> RTP, because you are running from a private IP address, unless there is
> direct routing between the two endpoints, which I'm assuming there isn't.
>
> > btw. Is there a good and simple example script that would make
> unattended calls, play wav files and DTMF tones?
> >
>
> Have a look at sip-audio-session script, it's part of the sipclients
> package. It doesn't play DTMF, but shouldn't be hard to add.
>
>
> Cheers,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>


-- 
Zapraszam na swojego foto-bloga: http://na100procentchyba.wordpress.com/
Autopodpis: Staraj się używać pola Ukryty do Wiadomości (UDW) przy
wysyłaniu wiadomości do wielu odbiorców, ograniczysz przez to
rozprzestrzenianie się spamu!
Autosignature: Try to use field BCC (blind carbon copy) when sending
message to many recepients, it will restrain spread of spam!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/sipbeyondvoip/attachments/20130626/1d004ff8/attachment.html>


More information about the SIPBeyondVoIP mailing list