[SOLVED][WebRTC] Asterisk12 fails to read sip.conf properly

rafaelpierri · September 3, 2013, 9:55pm

Has anyone faced something similar? Maybe I have missed something.

This is what happens:

sip.conf is set as following:

[general] context=public allowguest=yes udpbindaddr=0.0.0.0:5060 tcpenable=yes tcpbindaddr=0.0.0.0:5060 transport=ws,wss srvlookup=yes encryption=yes avpf=yes
And although I have ‘avpf=yes’, I still get the following warnings on log file (probably that also causes me an ‘Incompatible SDP’ error on my SIP client):

[Sep  3 18:00:13] VERBOSE[3236] res_http_websocket.c:   == WebSocket connection from '192.168.220.92:36518' for protocol 'sip' accepted using version '13'
[Sep  3 18:00:21] VERBOSE[3236][C-00000004] netsock2.c:   == Using SIP RTP CoS mark 5
[Sep  3 18:00:21] WARNING[3236][C-00000004] chan_sip.c: Received SAVPF profle in audio offer but AVPF is not enabled: audio 52085 RTP/SAVPF 109 0 8 101
[Sep  3 18:00:21] WARNING[3236][C-00000004] chan_sip.c: Insufficient information in SDP (c=)...

This is how I’ve made it:

1 - Built Asterisk 12 from source;
2 - Configured Asterisk to accept WebRTC calls, following these guidelines;
3 - No significant changes to Dialplan example were made;
4 - ‘CLI> reload’ was issued without success;
5 - Server was rebooted and frustration overtook me.

navaismo · September 4, 2013, 2:13am

Share the sip peer configuration, the complete sip debug & the JavaScript log from your webrtc client(if apply).

rafaelpierri · September 4, 2013, 12:39pm

Here they are:

Asterisk’s log, with sip debug info:

[code][Sep 4 09:14:03] VERBOSE[1886] res_http_websocket.c: == WebSocket connection from ‘192.168.220.92:37812’ for protocol ‘sip’ accepted using version ‘13’
[Sep 4 09:14:03] VERBOSE[1886] chan_sip.c:
<— SIP read from WS:192.168.220.92:37812 —>
REGISTER sip:mordor:5060 SIP/2.0
Via: SIP/2.0/WS mqo96ktucn5c.invalid;branch=z9hG4bK7935059
Max-Forwards: 69
To: sip:abc@mordor:5060
From: sip:abc@mordor:5060;tag=9ilfamn1jl
Call-ID: f3623o8sh3o353hv1tlr4b
CSeq: 81 REGISTER
Contact: sip:m76g86ej@mqo96ktucn5c.invalid;transport=ws;reg-id=1;+sip.instance=“urn:uuid:5f034f1b-e782-47b5-a6e7-4267a331c65a”;expires=600
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 0

<------------->
[Sep 4 09:14:03] VERBOSE[1886] chan_sip.c: — (12 headers 0 lines) —
[Sep 4 09:14:03] VERBOSE[1886] chan_sip.c:
<— Transmitting (no NAT) to 192.168.220.92:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/WS mqo96ktucn5c.invalid;branch=z9hG4bK7935059;received=192.168.220.92
From: sip:abc@mordor:5060;tag=9ilfamn1jl
To: sip:abc@mordor:5060;tag=as53a50312
Call-ID: f3623o8sh3o353hv1tlr4b
CSeq: 81 REGISTER
Server: Asterisk PBX 12.0.0-alpha1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="179432c9"
Content-Length: 0

<------------>
[Sep 4 09:14:03] VERBOSE[1886] chan_sip.c: Scheduling destruction of SIP dialog ‘f3623o8sh3o353hv1tlr4b’ in 32000 ms (Method: REGISTER)
[Sep 4 09:14:12] VERBOSE[1074] chan_sip.c: Really destroying SIP dialog ‘suuhar0vtjg5vbpsarm98d’ Method: REGISTER
[Sep 4 09:14:35] VERBOSE[1074] chan_sip.c: Really destroying SIP dialog ‘f3623o8sh3o353hv1tlr4b’ Method: REGISTER[/code]
SIP client configuration:

CustomJsSIP = "js/jssip-0.3.0.js" CustomJsSIPSettings = { uri: 'sip:abc@mordor:5060', // password: null, ws_servers: 'ws://mordor:8088/ws/', // display_name: 'Teste', // authorization_user: null, // register: null, // register_expires: null, // no_answer_timeout: null, // trace_sip: null, stun_servers: null, // turn_servers: null, // use_preloaded_route: null, // connection_recovery_min_interval: null, // connection_recovery_max_interval: null, // hack_via_tcp: null, // hack_ip_in_contact: null }; Settings = { videoDisabledByDefault: true };
SIP client log, caught on Firebug:

navaismo · September 4, 2013, 12:46pm

The asterisk sip debug stop at 401, usually the client resend the register or invite again but in the sip debug is missing. Also please share the sip.conf entry for that peer, the JS log seems very poor does the JSSIP API has a log feature?

rafaelpierri · September 4, 2013, 1:12pm

I’ll try to find a more detailed log with JSSIP. On the previous post, I have shared the complete sip.conf file, except by the commented lines:

[quote=“rafaelpierri”]
sip.conf is set as following:

[general] context=public allowguest=yes udpbindaddr=0.0.0.0:5060 tcpenable=yes tcpbindaddr=0.0.0.0:5060 transport=ws,wss srvlookup=yes encryption=yes avpf=yes[/quote]

I don’t know if I forgot to provide configuration for that specific peer but my intention, with that file is to assign all incoming SIP calls to a recording as set on Dialplan’s ‘public’ context.

navaismo · September 4, 2013, 3:54pm

Ok, so you there is no peer for the webrtc client because you want that clients act as GUEST peers, hmm I’m not sure if guest peers can handle the avpf stuff, what happen if you create an specific peer and try to register against that?

rafaelpierri · September 5, 2013, 7:06pm

Hi there!

I made changes to sip.conf file, and I fixed that SAVPF error:

[general] context=public allowguest=yes udpbindaddr=0.0.0.0:5060 tcpenable=yes tcpbindaddr=0.0.0.0:5060 transport=ws,wss srvlookup=yes [abc] type=friend host=dynamic secret=123 ; put a strong, unique password here instead context=public allow=all encryption=yes avpf=yes
Now Asterisk gives me an encryption error, as seen below. I read on other posts that SAVPF can only run over WSS. This one tells that an optimal configuration for SAVPF must include both TLS and SRTP.

Please, is it possible to run Asterisk WebRTC feature without TLS? Do you have a hint on what is missing?

[code]<------------->
[Sep 5 15:44:18] VERBOSE[1388] chan_sip.c: — (14 headers 18 lines) —
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Using INVITE request as basis request - dpcsg7adtlb8m5b2gd4o
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found peer ‘abc’ for ‘abc’ from 192.168.220.92:44255
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] netsock2.c: == Using SIP RTP CoS mark 5
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found RTP audio format 109
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found RTP audio format 0
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found RTP audio format 8
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found RTP audio format 101
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found audio description format opus for ID 109
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found audio description format PCMU for ID 0
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found audio description format PCMA for ID 8
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Found audio description format telephone-event for ID 101
[Sep 5 15:44:18] WARNING[1388][C-00000002] chan_sip.c: Rejecting secure audio stream without encryption details: audio 42534 RTP/SAVPF 109 0 8 101
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c:
<— Reliably Transmitting (no NAT) to 192.168.220.92:5060 —>
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/WS buju3ntk154b.invalid;branch=z9hG4bK8194587;received=192.168.220.92
From: “abc” sip:abc@mordor;tag=74coh47fo6
To: sip:123@mordor;tag=as4d68b04f
Call-ID: dpcsg7adtlb8m5b2gd4o
CSeq: 5294 INVITE
Server: Asterisk PBX 12.0.0-alpha1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

<------------>
[Sep 5 15:44:18] VERBOSE[1388][C-00000002] chan_sip.c: Scheduling destruction of SIP dialog ‘dpcsg7adtlb8m5b2gd4o’ in 32000 ms (Method: INVITE)
[Sep 5 15:44:18] VERBOSE[1388] chan_sip.c:
<— SIP read from WS:192.168.220.92:44255 —>
ACK sip:123@mordor SIP/2.0
Via: SIP/2.0/WS buju3ntk154b.invalid;branch=z9hG4bK8194587
To: sip:123@mordor;tag=as4d68b04f
From: “abc” sip:abc@mordor;tag=74coh47fo6
Call-ID: dpcsg7adtlb8m5b2gd4o
CSeq: 5294 ACK

<------------->
[Sep 5 15:44:18] VERBOSE[1388] chan_sip.c: — (6 headers 0 lines) —
[Sep 5 15:44:29] VERBOSE[1048] chan_sip.c: Really destroying SIP dialog ‘ce91sji986f1j00k9mm4’ Method: INVITE
[Sep 5 15:44:35] VERBOSE[1048] chan_sip.c: Really destroying SIP dialog ‘s3i8r6c4seeeho844gdti5’ Method: REGISTER
[/code]

navaismo · September 5, 2013, 8:22pm

I never tried the wss call, but as far I know if you are using FireFox you need to add certificates and exceptions to those certs in order firefox can work with. With chorme seems is easier.

And nothing say that wss must use TLS. Try a google search to find the best WSS with your JSS(i use sipml5).

rafaelpierri · September 5, 2013, 8:26pm

Do you use a encrypted channel between sipml5 and Asterisk? Is that mandatory?

navaismo · September 6, 2013, 12:43am

No i don’t use wss at all(yet), its not mandatory with chrome, but for firefox it need some certs.

Here is a link to sipml5 group one user explain how he solve the wss issue: groups.google.com/forum/#!topic … 58YmHx5euE

rafaelpierri · September 6, 2013, 1:02pm

Thank you so much for the support!

I guess I figured it out!

In this example, what you see is what you get:

It seems that Firefox 23 does not writes on SIP Encryption Details field, but Chrome does. Now I can get my call answered!!!

But I cannot hear nothing. I read on other posts that this could be a Firewall or NAT issue, although I tryed some workarounds I couldn’t find a solution. Any ideas on this?

[code][Sep 6 09:54:24] VERBOSE[1350] chan_sip.c: — (10 headers 0 lines) —
[Sep 6 09:54:24] VERBOSE[1351][C-00000001] pbx.c: – Executing [s@public:2] MP3Player(“SIP/abc-00000001”, “/home/pierri/knees.mp3”) in new stack
[Sep 6 09:54:31] VERBOSE[1039] chan_sip.c: Really destroying SIP dialog ‘shqh1bb9q11i05s3lo3pdi’ Method: REGISTER
[Sep 6 09:54:59] VERBOSE[1039] chan_sip.c: Reliably Transmitting (NAT) to 192.168.220.92:51201:
OPTIONS sip:67d4l1lv@s13vja869adu.invalid;transport=ws SIP/2.0
Via: SIP/2.0/WS 192.168.220.69:5060;branch=z9hG4bK7acd6edd;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@192.168.220.69;tag=as38c9c68a
To: sip:67d4l1lv@s13vja869adu.invalid;transport=ws
Contact: sip:asterisk@192.168.220.69:5060;transport=WS
Call-ID: 3f8ebe84095afe34725b68fb311e2dde@192.168.220.69:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 11.5.1
Date: Fri, 06 Sep 2013 12:54:59 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

[Sep 6 09:54:59] VERBOSE[1350] chan_sip.c:
<— SIP read from WS:192.168.220.92:51201 —>
SIP/2.0 200 OK
Via: SIP/2.0/WS 192.168.220.69:5060;branch=z9hG4bK7acd6edd;rport
To: sip:67d4l1lv@s13vja869adu.invalid;transport=ws;tag=hp8tcivekp
From: “asterisk” sip:asterisk@192.168.220.69;tag=as38c9c68a
Call-ID: 3f8ebe84095afe34725b68fb311e2dde@192.168.220.69:5060
CSeq: 102 OPTIONS
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE
Accept: application/sdp,application/dtmf-relay
Content-Length: 0

<------------->
[Sep 6 09:54:59] VERBOSE[1350] chan_sip.c: — (9 headers 0 lines) —
[Sep 6 09:55:00] VERBOSE[1039] chan_sip.c: Really destroying SIP dialog ‘3f8ebe84095afe34725b68fb311e2dde@192.168.220.69:5060’ Method: OPTIONS[/code]

navaismo · September 6, 2013, 2:40pm

Check that the ice servers aren’t blocked in your network, based on the IP on the logs your clients are inside the network set explicit nat=no fr the sip client, another thing if you are using your own code check the audio_remote is correctly used.

If the issue persist, share the complete sip debug for the failed call.

rafaelpierri · September 6, 2013, 6:53pm

Hi, I don’t get it. My Asterisk configuration files aren’t planned to work with STUN, TURN or NAT. Why should blockage of ICE servers impact on audio transmission?

I explicitly set ‘nat=no’, and Dialplan syntax seems ok:

sip.conf:

[general] context=public allowguest=yes nat=no transport=ws srvlookup=yes [abc] type=friend host=dynamic secret=123 context=public allow=all encryption=yes avpf=yes icesupport=no
extensions.conf:

[general] static=yes writeprotect=no clearglobalvars=no [public] exten => 123,1,Answer ; Answer the line exten => 123,2,Playback(beep) exten => 123,3,MP3Player(/home/pierri/knees.mp3) exten => 123,4,Hangup ; Hang them up.
Last run log:

[code][Sep 6 15:46:27] VERBOSE[1854] pbx.c: == Registered custom function ‘QUEUE_WAITING_COUNT’
[Sep 6 15:46:27] VERBOSE[1854] pbx.c: == Registered custom function ‘QUEUE_MEMBER_PENALTY’
[Sep 6 15:46:27] VERBOSE[1854] loader.c: app_queue.so => (True Call Queueing)
[Sep 6 15:46:27] VERBOSE[1854] config.c: == Parsing ‘/etc/asterisk/cli_permissions.conf’: Found
[Sep 6 15:46:27] VERBOSE[1854] asterisk.c: Asterisk Ready.
[Sep 6 15:46:27] VERBOSE[1854] config.c: == Parsing ‘/etc/asterisk/cli.conf’: Found
[Sep 6 15:46:28] VERBOSE[1899] res_http_websocket.c: == WebSocket connection from ‘192.168.220.92:52291’ for protocol ‘sip’ accepted using version ‘13’
[Sep 6 15:46:28] VERBOSE[1899] chan_sip.c: – Registered SIP ‘abc’ at 192.168.220.92:52291
[Sep 6 15:46:37] VERBOSE[1858] asterisk.c: – Remote UNIX connection
[Sep 6 15:46:37] VERBOSE[1902] asterisk.c: – Remote UNIX connection disconnected
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c:
<— SIP read from WS:192.168.220.92:52291 —>
INVITE sip:123@mordor SIP/2.0
Via: SIP/2.0/WS n49g1ekmnn6e.invalid;branch=z9hG4bK6859483
Max-Forwards: 69
To: sip:123@mordor
From: “abc” sip:abc@mordor;tag=dnj5ufvbim
Call-ID: 1hcha52vcjhf1p7e0o2n
CSeq: 6376 INVITE
Contact: sip:0i41lb7q@n49g1ekmnn6e.invalid;transport=ws;ob
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 1616

v=0
o=- 8739426064175944428 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiw
m=audio 32798 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 192.168.220.92
a=rtcp:32798 IN IP4 192.168.220.92
a=candidate:1387236902 1 udp 2113937151 192.168.220.92 32798 typ host generation 0
a=candidate:1387236902 2 udp 2113937151 192.168.220.92 32798 typ host generation 0
a=candidate:472675030 1 tcp 1509957375 192.168.220.92 0 typ host generation 0
a=candidate:472675030 2 tcp 1509957375 192.168.220.92 0 typ host generation 0
a=ice-ufrag:AkPB2Hq5nbOQlaJU
a=ice-pwd:3hhzAJE85fprYRJofAUgqNNq
a=ice-options:google-ice
a=fingerprint:sha-256 05:91:C6:DB:BA:5D:AA:17:E2:AE:BF:20:CB:CA:C3:9B:0A:63:73:4C:77:E1:DB:F5:B5:06:75:24:D4:67:FA:E1
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:bk5LlKThe9Frc17KBemlkO9TadIkdYqkqkLUocqO
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:huh2HSt6padWVQL/PnZWEjgGr+CP5Yykb/27hDKb
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3622034717 cname:h/fGmo/Z1Wwlriua
a=ssrc:3622034717 msid:bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiw bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiwa0
a=ssrc:3622034717 mslabel:bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiw
a=ssrc:3622034717 label:bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiwa0
<------------->
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c: — (13 headers 39 lines) —
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Using INVITE request as basis request - 1hcha52vcjhf1p7e0o2n
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found peer ‘abc’ for ‘abc’ from 192.168.220.92:52291
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c:
<— Reliably Transmitting (no NAT) to 192.168.220.92:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/WS n49g1ekmnn6e.invalid;branch=z9hG4bK6859483;received=192.168.220.92
From: “abc” sip:abc@mordor;tag=dnj5ufvbim
To: sip:123@mordor;tag=as76d93fa0
Call-ID: 1hcha52vcjhf1p7e0o2n
CSeq: 6376 INVITE
Server: Asterisk PBX 11.5.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="2b6cb439"
Content-Length: 0

<------------>
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Scheduling destruction of SIP dialog ‘1hcha52vcjhf1p7e0o2n’ in 32000 ms (Method: INVITE)
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c:
<— SIP read from WS:192.168.220.92:52291 —>
ACK sip:123@mordor SIP/2.0
Via: SIP/2.0/WS n49g1ekmnn6e.invalid;branch=z9hG4bK6859483
To: sip:123@mordor;tag=as76d93fa0
From: “abc” sip:abc@mordor;tag=dnj5ufvbim
Call-ID: 1hcha52vcjhf1p7e0o2n
CSeq: 6376 ACK

<------------->
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c: — (6 headers 0 lines) —
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c:
<— SIP read from WS:192.168.220.92:52291 —>
INVITE sip:123@mordor SIP/2.0
Via: SIP/2.0/WS n49g1ekmnn6e.invalid;branch=z9hG4bK7660857
Max-Forwards: 69
To: sip:123@mordor
From: “abc” sip:abc@mordor;tag=dnj5ufvbim
Call-ID: 1hcha52vcjhf1p7e0o2n
CSeq: 6377 INVITE
Authorization: Digest algorithm=MD5, username=“abc”, realm=“asterisk”, nonce=“2b6cb439”, uri=“sip:123@mordor”, response="f2ab463dc22c8f3072fdc7417ca75cb4"
Contact: sip:0i41lb7q@n49g1ekmnn6e.invalid;transport=ws;ob
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 1616

v=0
o=- 8739426064175944428 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiw
m=audio 32798 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 192.168.220.92
a=rtcp:32798 IN IP4 192.168.220.92
a=candidate:1387236902 1 udp 2113937151 192.168.220.92 32798 typ host generation 0
a=candidate:1387236902 2 udp 2113937151 192.168.220.92 32798 typ host generation 0
a=candidate:472675030 1 tcp 1509957375 192.168.220.92 0 typ host generation 0
a=candidate:472675030 2 tcp 1509957375 192.168.220.92 0 typ host generation 0
a=ice-ufrag:AkPB2Hq5nbOQlaJU
a=ice-pwd:3hhzAJE85fprYRJofAUgqNNq
a=ice-options:google-ice
a=fingerprint:sha-256 05:91:C6:DB:BA:5D:AA:17:E2:AE:BF:20:CB:CA:C3:9B:0A:63:73:4C:77:E1:DB:F5:B5:06:75:24:D4:67:FA:E1
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:bk5LlKThe9Frc17KBemlkO9TadIkdYqkqkLUocqO
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:huh2HSt6padWVQL/PnZWEjgGr+CP5Yykb/27hDKb
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3622034717 cname:h/fGmo/Z1Wwlriua
a=ssrc:3622034717 msid:bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiw bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiwa0
a=ssrc:3622034717 mslabel:bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiw
a=ssrc:3622034717 label:bjZwoNO9c9j8mHRcNW3uN7nj733QO5jWDNiwa0
<------------->
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c: — (14 headers 39 lines) —
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Using INVITE request as basis request - 1hcha52vcjhf1p7e0o2n
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found peer ‘abc’ for ‘abc’ from 192.168.220.92:52291
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] netsock2.c: == Using SIP RTP CoS mark 5
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 111
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 103
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 104
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 0
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 8
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 107
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 106
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 105
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 13
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found RTP audio format 126
[Sep 6 15:46:56] DEBUG[1899][C-00000000] sip/sdp_crypto.c: Accepting crypto tag 0
[Sep 6 15:46:56] DEBUG[1899][C-00000000] sip/sdp_crypto.c: Crypto line: a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:kE9i++03djnEQFWij5UO4/BlWap6Qrb3MAhDWgJ9
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found unknown media description format opus for ID 111
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found unknown media description format ISAC for ID 103
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found unknown media description format ISAC for ID 104
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found audio description format PCMU for ID 0
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found audio description format PCMA for ID 8
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found unknown media description format CN for ID 107
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found unknown media description format CN for ID 106
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found unknown media description format CN for ID 105
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found audio description format CN for ID 13
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Found audio description format telephone-event for ID 126
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Capabilities: us - (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|speex16|ilbc|g726aal2|g722|slin16|jpeg|png|h261|h263|h263p|h264|mpeg4|red|t140|siren7|siren14|testlaw|g719|speex32|slin12|slin24|slin32|slin44|slin48|slin96|slin192|silk8|silk12|silk16|silk24), peer - audio=(ulaw|alaw)/video=(nothing)/text=(nothing), combined - (ulaw|alaw)
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x3 (telephone-event|CN|), combined - 0x1 (telephone-event|)
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Peer audio RTP is at port 192.168.220.92:32798
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: Looking for 123 in public (domain mordor)
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c: list_route: hop: sip:0i41lb7q@n49g1ekmnn6e.invalid;transport=ws;ob
[Sep 6 15:46:56] VERBOSE[1899][C-00000000] chan_sip.c:
<— Transmitting (no NAT) to 192.168.220.92:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/WS n49g1ekmnn6e.invalid;branch=z9hG4bK7660857;received=192.168.220.92
From: “abc” sip:abc@mordor;tag=dnj5ufvbim
To: sip:123@mordor
Call-ID: 1hcha52vcjhf1p7e0o2n
CSeq: 6377 INVITE
Server: Asterisk PBX 11.5.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:123@192.168.220.69:5060;transport=WS
Content-Length: 0

<------------>
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] pbx.c: – Executing [123@public:1] Answer(“SIP/abc-00000000”, “”) in new stack
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] chan_sip.c: Audio is at 11476
[Sep 6 15:46:56] DEBUG[1904][C-00000000] sip/sdp_crypto.c: Crypto line: a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:kE9i++03djnEQFWij5UO4/BlWap6Qrb3MAhDWgJ9
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] chan_sip.c: Adding codec 100003 (ulaw) to SDP
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] chan_sip.c: Adding codec 100003 (ulaw) to SDP
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] chan_sip.c: Adding codec 100004 (alaw) to SDP
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] chan_sip.c: Adding codec 100004 (alaw) to SDP
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] chan_sip.c:
<— Reliably Transmitting (no NAT) to 192.168.220.92:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/WS n49g1ekmnn6e.invalid;branch=z9hG4bK7660857;received=192.168.220.92
From: “abc” sip:abc@mordor;tag=dnj5ufvbim
To: sip:123@mordor;tag=as594058a1
Call-ID: 1hcha52vcjhf1p7e0o2n
CSeq: 6377 INVITE
Server: Asterisk PBX 11.5.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:123@192.168.220.69:5060;transport=WS
Content-Type: application/sdp
Content-Length: 393

v=0
o=root 21988095 21988095 IN IP4 192.168.220.69
s=Asterisk PBX 11.5.1
c=IN IP4 192.168.220.69
t=0 0
m=audio 11476 RTP/SAVPF 0 0 8 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:kE9i++03djnEQFWij5UO4/BlWap6Qrb3MAhDWgJ9

<------------>
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c:
<— SIP read from WS:192.168.220.92:52291 —>
ACK sip:123@192.168.220.69:5060;transport=ws SIP/2.0
Via: SIP/2.0/WS n49g1ekmnn6e.invalid;branch=z9hG4bK6814754
Max-Forwards: 69
To: sip:123@mordor;tag=as594058a1
From: “abc” sip:abc@mordor;tag=dnj5ufvbim
Call-ID: 1hcha52vcjhf1p7e0o2n
CSeq: 6377 ACK
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 0

<------------->
[Sep 6 15:46:56] VERBOSE[1899] chan_sip.c: — (10 headers 0 lines) —
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] pbx.c: – Executing [123@public:2] Playback(“SIP/abc-00000000”, “beep”) in new stack
[Sep 6 15:46:56] VERBOSE[1904][C-00000000] file.c: – <SIP/abc-00000000> Playing ‘beep.gsm’ (language ‘en’)
[Sep 6 15:46:57] VERBOSE[1904][C-00000000] pbx.c: – Executing [123@public:3] MP3Player(“SIP/abc-00000000”, “/home/pierri/knees.mp3”) in new stack
[Sep 6 15:47:00] VERBOSE[1872] chan_sip.c: Really destroying SIP dialog ‘4visbn478u3fphnmhql3m5’ Method: REGISTER
[/code]

navaismo · September 6, 2013, 9:30pm

The rtp debug show packets flowing through both IP’s?

rafaelpierri · September 6, 2013, 10:05pm

The first and last server mention is:

[Sep 6 18:48:24] VERBOSE[1698] http.c: Bound HTTP server to address 192.168.220.69:0
For sake of simplicity, I have ommited a lot of packets and log data:

[Sep 6 18:48:26] VERBOSE[1743] res_http_websocket.c: == WebSocket connection from '192.168.220.92:53528' for protocol 'sip' accepted using version '13' [Sep 6 18:48:26] VERBOSE[1743] chan_sip.c: -- Registered SIP 'abc' at 192.168.220.92:53528 [Sep 6 18:48:42] VERBOSE[1702] asterisk.c: -- Remote UNIX connection [Sep 6 18:48:42] VERBOSE[1746] asterisk.c: -- Remote UNIX connection disconnected [Sep 6 18:48:48] VERBOSE[1702] asterisk.c: -- Remote UNIX connection [Sep 6 18:48:48] VERBOSE[1749] asterisk.c: -- Remote UNIX connection disconnected [Sep 6 18:48:58] VERBOSE[1716] chan_sip.c: Really destroying SIP dialog '4visbn478u3fphnmhql3m5' Method: REGISTER [Sep 6 18:49:02] VERBOSE[1702] asterisk.c: -- Remote UNIX connection [Sep 6 18:49:02] VERBOSE[1753] asterisk.c: -- Remote UNIX connection disconnected [Sep 6 18:49:42] VERBOSE[1743][C-00000000] netsock2.c: == Using SIP RTP CoS mark 5 [Sep 6 18:49:42] DEBUG[1743][C-00000000] sip/sdp_crypto.c: Accepting crypto tag 0 [Sep 6 18:49:42] DEBUG[1743][C-00000000] sip/sdp_crypto.c: Crypto line: a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:jtaz4/nSB+v8xJ9HY1WIA2eHCZoRkTFqJ5rdLt5U^M [Sep 6 18:49:42] VERBOSE[1756][C-00000000] pbx.c: -- Executing [123@public:1] Answer("SIP/abc-00000000", "") in new stack [Sep 6 18:49:42] DEBUG[1756][C-00000000] sip/sdp_crypto.c: Crypto line: a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:jtaz4/nSB+v8xJ9HY1WIA2eHCZoRkTFqJ5rdLt5U^M [Sep 6 18:49:42] VERBOSE[1756][C-00000000] pbx.c: -- Executing [123@public:2] Playback("SIP/abc-00000000", "beep") in new stack [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020919, ts 000160, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] file.c: -- <SIP/abc-00000000> Playing 'beep.gsm' (language 'en') [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020920, ts 000320, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020921, ts 000480, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020922, ts 000640, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020923, ts 000800, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020924, ts 000960, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020925, ts 001120, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020926, ts 001280, len 000164) [Sep 6 18:49:42] VERBOSE[1756][C-00000000] res_rtp_asterisk.c: Sent RTP packet to 192.168.220.92:39776 (type 00, seq 020927, ts 001440, len 000164)
I can see a stream from server to client, nothing much on the opposite way. Should the client be sending something back?

rafaelpierri · September 9, 2013, 12:59pm

Making further analysis with Wireshark, I’ve discovered the following pattern on client side:

No.  |Time      |Source        |Destination   |Protocol |Length|Info
56025|977.448619|192.168.220.69|192.168.220.92|UDP      |218   |Source port: 12112  Destination port: 53887
56032|977.468128|192.168.220.69|192.168.220.92|UDP      |218   |Source port: 12112  Destination port: 53887
56034|977.487433|192.168.220.69|192.168.220.92|UDP      |114   |Source port: 12113  Destination port: 53888
56035|977.487459|192.168.220.92|192.168.220.69|ICMP     |142   |Destination unreachable (Port unreachable)

Somehow jsSIP is not receiving these packets and I don’t know why I’m having this port shift and ‘Destination unreachable’ error.

rafaelpierri · September 10, 2013, 11:43am

Great, now it works.

I’ve based my sip.conf file on some internet example, installed ALSA drivers and set the VM audio to work with ALSA Audio Driver and ICH AC97 audio controller.

I hate to make changes to my config. files and don’t have a clue on what made everything work. Certainly I will spend some time understanding the contribution of each statement:

[general] context=public allowguest=yes port=5060 udpbindaddr=0.0.0.0 transport=ws,udp srvlookup=yes language=en icesupport=yes nat=force_rport,comedia dtmfmode=rfc2833 [abc] type=friend host=dynamic secret=123 dtmfmode=rfc2833 context=public allow=all encryption=yes avpf=yes

Thank you for your support!

navaismo · September 10, 2013, 4:37pm

Based on your first sip.conf you remove:

Maybe the duplaicate bind address was the problem.