When I make an Outbound call through VOIP using SIP in ios application I'm
getting this below callback response when the destination app is also using SIP for incoming calls but it is terminated.
**SIP/2.0 100 Telnyx trying
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 192.168.1.94:53286;received=122.170.1.34;rport=53286;branch=z9hG4bKPjg48g7A4emKAh3yi2PH7TiweWaKm1s-1h;alias
Record-Route: sip:10.255.0.1;transport=tcp;r2=on;lr;ftag=GcE.YpQwHKrzR-k8XvmfGu3NTVzCZb8W
Record-Route: sip:192.76.120.10;transport=tcp;r2=on;lr;ftag=GcE.YpQwHKrzR-k8XvmfGu3NTVzCZb8W
From: sip:Call123456789#sip.telnyx.com;tag=GcE.YpQwHKrzR-k8XvmfGu3NTVzCZb8W
To: sip:+12294712105#sip.telnyx.com;tag=N5m65F1pZggyN
Call-ID: 4TzmLtUbjGG5Uz-sUi6gdeZYNfko5YGn
CSeq: 4678 INVITE
Contact: sip:+12294712105#10.15.112.4:5070;transport=tcp
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Supported: path
Allow-Events: talk, hold, conference, refer
Content-Length: 0
--end msg--
18:42:00.954 pjsua_core.c .RX 589 bytes Response msg 480/INVITE/cseq=4678 (rdata0x108a64338) from TCP 192.76.120.10:5060:
SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/TCP 192.168.1.94:53286;received=122.170.1.34;rport=53286;branch=z9hG4bKPjg48g7A4emKAh3yi2PH7TiweWaKm1s-1h;alias
Max-Forwards: 69
From: sip:Call123456789#sip.telnyx.com;tag=GcE.YpQwHKrzR-k8XvmfGu3NTVzCZb8W
To: sip:+12294712105#sip.telnyx.com;tag=N5m65F1pZggyN
Call-ID: 4TzmLtUbjGG5Uz-sUi6gdeZYNfko5YGn
CSeq: 4678 INVITE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Supported: path
Allow-Events: talk, hold, conference, refer
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0
--end msg--
18:42:00.954 pjsua_core.c ..TX 374 bytes Request msg ACK/cseq=4678 (tdta0x1091f6aa8) to TCP 192.76.120.10:5060:
ACK sip:+12294712105#sip.telnyx.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.94:53286;rport;branch=z9hG4bKPjg48g7A4emKAh3yi2PH7TiweWaKm1s-1h;alias
Max-Forwards: 70
From: sip:Call123456789#sip.telnyx.com;tag=GcE.YpQwHKrzR-k8XvmfGu3NTVzCZb8W
To: sip:+12294712105#sip.telnyx.com;tag=N5m65F1pZggyN
Call-ID: 4TzmLtUbjGG5Uz-sUi6gdeZYNfko5YGn
CSeq: 4678 ACK
Content-Length: 0
--end msg--
DISCONNECTED**
Related
I am trying to establish a chat session(MSRP) with two sipclients endpoints by registering to kamailio server(4.0.0), but I am getting 500 Internal server error(Reason: SIP ;text="media stream failed to start" ;cause=500).
What might be the problem?? Does it mean that kamailio can not handle msrp session? If yes how to enable it in the server? Please help me in this regard.
Request-Line: INVITE sip:03271485#172.16.7.82:50666 SIP/2.0
Record-Route: sip:172.16.7.201;lr=on
Via: SIP/2.0/UDP 172.16.7.201;branch=z9hG4bKce48.40d19c96.0
Via: SIP/2.0/UDP 172.16.7.46:45669;rport=45669;
branch=z9hG4bKPj28UvXKngB3PjBBmoyrTFZXoeNcVx4oIm
Max-Forwards: 16
From: sip:511#172.16.7.201;tag=-4TgMXfcfaV0Cj5VnCIxOkL1QmHji8PL
To: sip:411#172.16.7.201
Contact: sip:80945273#172.16.7.46:45669
Call-ID: bpOWizGe-SHsjIZXSLKptnnDBVi7dMnY
CSeq: 3687 INVITE
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: 100rel, replaces, norefersub, gruu
User-Agent: sipsimple 1.3.0
Content-Type: application/sdp
Content-Length:297
v=0
o=- 3612147894 3612147894 IN IP4 172.16.7.46
s=sipsimple 1.3.0
c=IN IP4 172.16.7.46
t= 0 0
m=message 2855 TCP/TLS/MSRP *
a=path:msrps://172.16.7.46:2855/7ad200ec7137e5ed1a58;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
a=setup:active
Status-Line: SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP 172.16.7.201;received=172.16.7.201;branch=z9hG4bKce48.40d19c96
Via: SIP/2.0/UDP 172.16.7.46:45669;rport=45669 branch=z9hG4bKPj28UvXKngB3PjBBmoyrTFZXoeNcVx4oIm
Record-Route: <sip:172.16.7.201;lr>
Call-ID: bpOWizGe-SHsjIZXSLKptnnDBVi7dMnY
From: sip:511#172.16.7.201;tag=-4TgMXfcfaV0Cj5VnCIxOkL1QmHji8PL
To: sip:411#172.16.7.201;tag=XKuUttlVFnfBakd5ATHkw9nhmIEOtCL2
CSeq:3687 INVITE
Server: sipsimple 1.3.0
AllowSUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Reason: SIP ;text=\"media stream failed to start\" ;cause=500
Content-Length: 0
Though I could not establish MSRP session through a relay, I could establish the session between the endpoints. In Sipclients, msrp.connection_model should be set to "acm" for end to end msrp session. So I can say that it is not a problem with kamailio server
For a simple home communication system, I've set up some very simple SIP / Extensions. Go easy on me, I'm very new to this system.
For now the only way I've gotten them to work (in testing) is to take down the firewall. Still, I seem to be getting instant 603's with every try from every phone.
When I make a call, this is what it reports:
<--- SIP read from UDP:192.168.1.8:5060 --->
INVITE sip:103#192.168.1.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.8:5060;rport;branch=z9hG4bKPj43e20551-6dbc-411b-919a-ab117c06ae05
Max-Forwards: 70
From: <sip:0000FFFF004#192.168.1.6>;tag=12e33b02-c7c1-4b83-9ba4-f08c426ece25
To: <sip:103#192.168.1.6>
Contact: <sip:0000FFFF004#192.168.1.8:5060>
Call-ID: 16962f1e-d2e0-4987-af02-dc765ffa793f
CSeq: 6702 INVITE
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE
upported: replaces, 100rel
Content-Type: application/sdp
Content-Length: 361
v=0
o=dinosaur 3611940779 0 IN IP4 192.168.1.8
s=sflphone
c=IN IP4 192.168.1.8
t=0 0
m=audio 37600 RTP/AVP 0 3 8 9 110 111 112
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:110 speex/8000
a=rtpmap:111 speex/16000
a=rtpmap:112 speex/32000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
--- (12 headers 16 lines) ---
Sending to 192.168.1.8:5060 (NAT)
Using INVITE request as basis request - 16962f1e-d2e0-4987-af02-dc765ffa793f
Found peer '0000FFFF004' for '0000FFFF004' from 192.168.1.8:5060
<--- Reliably Transmitting (NAT) to 192.168.1.8:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.8:5060;branch=z9hG4bKPj43e20551-6dbc-411b-919a-ab117c06ae05;received=192.168.1.8;rport=5060
From: <sip:0000FFFF004#192.168.1.6>;tag=12e33b02-c7c1-4b83-9ba4-f08c426ece25
To: <sip:103#192.168.1.6>;tag=as69cdb064
Call-ID: 16962f1e-d2e0-4987-af02-dc765ffa793f
CSeq: 6702 INVITE
Server: Asterisk PBX SVN-branch-1.8-r416150
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="5572b5df"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog '16962f1e-d2e0-4987-af02-dc765ffa793f' in 32000 ms (Method: INVITE)
<--- SIP read from UDP:192.168.1.8:5060 --->
ACK sip:103#192.168.1.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.8:5060;rport;branch=z9hG4bKPj43e20551-6dbc-411b-919a-ab117c06ae05
Max-Forwards: 70
From: <sip:0000FFFF004#192.168.1.6>;tag=12e33b02-c7c1-4b83-9ba4-f08c426ece25
To: <sip:103#192.168.1.6>;tag=as69cdb064
Call-ID: 16962f1e-d2e0-4987-af02-dc765ffa793f
CSeq: 6702 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
<--- SIP read from UDP:192.168.1.8:5060 --->
INVITE sip:103#192.168.1.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.8:5060;rport;branch=z9hG4bKPj7504ac55-fcbe-470a-a5c5-2174a0699d0d
Max-Forwards: 70
From: <sip:0000FFFF004#192.168.1.6>;tag=12e33b02-c7c1-4b83-9ba4-f08c426ece25
To: <sip:103#192.168.1.6>
Contact: <sip:0000FFFF004#192.168.1.8:5060>
Call-ID: 16962f1e-d2e0-4987-af02-dc765ffa793f
CSeq: 6703 INVITE
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE
upported: replaces, 100rel
Authorization: Digest username="0000FFFF004", realm="asterisk", nonce="5572b5df", uri="sip:103#192.168.1.6", response="44810c7fbf0d8a99e34ea07b5e62ee79", algorithm=MD5
Content-Type: application/sdp
Content-Length: 361
v=0
o=dinosaur 3611940779 0 IN IP4 192.168.1.8
s=sflphone
c=IN IP4 192.168.1.8
t=0 0
m=audio 37600 RTP/AVP 0 3 8 9 110 111 112
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:110 speex/8000
a=rtpmap:111 speex/16000
a=rtpmap:112 speex/32000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
--- (13 headers 16 lines) ---
Sending to 192.168.1.8:5060 (NAT)
Using INVITE request as basis request - 16962f1e-d2e0-4987-af02-dc765ffa793f
Found peer '0000FFFF004' for '0000FFFF004' from 192.168.1.8:5060
== Using SIP RTP CoS mark 5
Found RTP audio format 0
Found RTP audio format 3
Found RTP audio format 8
Found RTP audio format 9
Found RTP audio format 110
Found RTP audio format 111
Found RTP audio format 112
Found audio description format PCMU for ID 0
Found audio description format GSM for ID 3
Found audio description format PCMA for ID 8
Found audio description format G722 for ID 9
Found audio description format speex for ID 110
Found audio description format speex for ID 111
Found unknown media description format speex for ID 112
Found audio description format telephone-event for ID 101
Capabilities: us - 0x100e (gsm|ulaw|alaw|g722), peer - audio=0x20000120e (gsm|ulaw|alaw|speex|speex16|g722)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x100e (gsm|ulaw|alaw|g722)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.1.8:37600
Looking for 103 in LocalSets (domain 192.168.1.6)
list_route: hop: <sip:0000FFFF004#192.168.1.8:5060>
<--- Transmitting (NAT) to 192.168.1.8:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.8:5060;branch=z9hG4bKPj7504ac55-fcbe-470a-a5c5-2174a0699d0d;received=192.168.1.8;rport=5060
From: <sip:0000FFFF004#192.168.1.6>;tag=12e33b02-c7c1-4b83-9ba4-f08c426ece25
To: <sip:103#192.168.1.6>
Call-ID: 16962f1e-d2e0-4987-af02-dc765ffa793f
CSeq: 6703 INVITE
Server: Asterisk PBX SVN-branch-1.8-r416150
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:103#192.168.1.6:5060>
Content-Length: 0
<------------>
-- Executing [103#LocalSets:1] Dial("SIP/0000FFFF004-0000001a", "0000FFFF005") in new stack
== Spawn extension (LocalSets, 103, 1) exited non-zero on 'SIP/0000FFFF004-0000001a'
Scheduling destruction of SIP dialog '16962f1e-d2e0-4987-af02-dc765ffa793f' in 32000 ms (Method: INVITE)
<--- Reliably Transmitting (NAT) to 192.168.1.8:5060 --->
SIP/2.0 603 Declined
Via: SIP/2.0/UDP 192.168.1.8:5060;branch=z9hG4bKPj7504ac55-fcbe-470a-a5c5-2174a0699d0d;received=192.168.1.8;rport=5060
From: <sip:0000FFFF004#192.168.1.6>;tag=12e33b02-c7c1-4b83-9ba4-f08c426ece25
To: <sip:103#192.168.1.6>;tag=as165ecdc9
Call-ID: 16962f1e-d2e0-4987-af02-dc765ffa793f
CSeq: 6703 INVITE
Server: Asterisk PBX SVN-branch-1.8-r416150
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
<------------>
<--- SIP read from UDP:192.168.1.8:5060 --->
ACK sip:103#192.168.1.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.8:5060;rport;branch=z9hG4bKPj7504ac55-fcbe-470a-a5c5-2174a0699d0d
Max-Forwards: 70
From: <sip:0000FFFF004#192.168.1.6>;tag=12e33b02-c7c1-4b83-9ba4-f08c426ece25
To: <sip:103#192.168.1.6>;tag=as165ecdc9
Call-ID: 16962f1e-d2e0-4987-af02-dc765ffa793f
CSeq: 6703 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
<--- SIP read from UDP:192.168.1.5:63992 --->
<------------->
Really destroying SIP dialog 'cb7123d1-4244-4673-a200-dc851e1c8415' Method: REGISTER
The phones themselves are not set to decline calls, so I can only assume its happening somewhere in Asterisk.
you should write in your dialplan
exten => 103,1,Dial(SIP/0000FFFF005)
I dumped The following SIP INVITE datagram from Linphone to a file with CR-LF line breaks, using wireshark:
INVITE sip:1002#172.16.76.21 SIP/2.0
Via: SIP/2.0/UDP 172.16.76.21:5060;rport;branch=z9hG4bK1936726928
From: <sip:1555#172.16.76.21>;tag=1350138383
To: <sip:1002#172.16.76.21>
Call-ID: 1393698667
CSeq: 20 INVITE
Contact: <sip:1555#172.16.76.20>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.5.2 (eXosip2/3.6.0)
Subject: Phone call
Content-Length: 205
v=0
o=1555 1125 1125 IN IP4 172.16.76.21
s=Talk
c=IN IP4 172.16.76.21
t=0 0
m=audio 7078 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
I wrote a simple Python script that reads the file binary, puts in a UDP datagram and sends through a a socket bound to port 5060. When I send this to a client running user agent, I get 200 OK. When I try to send it to our SIP proxy, FreeSwitch, I get 400 Bad Session Description.
FreeSwitch responded with 200 OK when this message was originally sent by Linphone.
Apparently FreeSwitch does not tolerate them.
It's not an issue of FreeSwitch. As suggested by #Stanislav in his comment, your "Content-Length" value is wrong. It must be "Content-Length: 213" for your Session Description.
Most of these lines have trailing extra whitespaces. Apparently FreeSwitch does not tolerate them. Removing the trailing spaces works.
Also content-length is wrong. It should be 213.
I am new to MjSip and I use MjUa for creating a client. I want to connect to a asterisk server. it support G.711 but I can not config my app.
I use this config:
media=audio 4000 rtp/avp {audio 0 PCMU 8000 160, audio 8 PCMA 8000 160}
but i still get 488 error
please help me. how change "MjUa" config file?
here is all message log:
INVITE sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK2bfdff77
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 1 INVITE
Contact: <sip:157#192.168.0.57>
Expires: 3600
User-Agent: mjsip 1.7
Content-Length: 141
Content-Type: application/sdp
v=0
o=157 0 0 IN IP4 192.168.0.57
s=-
c=IN IP4 192.168.0.57
t=0 0
m=audio 4000 rtp/avp 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
-----End-of-message-----
1365314026097: 10:23:46.097 Sun 07 Apr 2013, 192.168.0.254:5060/udp (519 bytes) received
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.57:5060;branch=z9hG4bK2bfdff77;received=192.168.0.57;rport=5060
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
Call-ID: 728007708208#192.168.0.57
CSeq: 1 INVITE
Server: FPBX-2.8.1(1.8.11.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="6e640e9a"
Content-Length: 0
-----End-of-message-----
1365314026107: 10:23:46.107 Sun 07 Apr 2013, 192.168.0.254:5060/udp (326 bytes) sent
ACK sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK2bfdff77
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 1 ACK
User-Agent: mjsip 1.7
Content-Length: 0
-----End-of-message-----
1365314026151: 10:23:46.151 Sun 07 Apr 2013, 192.168.0.254:5060/udp (706 bytes) sent
INVITE sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK644461b7
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 2 INVITE
Contact: <sip:157#192.168.0.57>
Expires: 3600
User-Agent: mjsip 1.7
Authorization: Digest username="157", realm="asterisk", nonce="6e640e9a", uri="sip:57#192.168.0.254:5060", algorithm=MD5, response="84ff5e12b8325a153e09ac2e316f5b1f"
Content-Length: 141
Content-Type: application/sdp
v=0
o=157 0 0 IN IP4 192.168.0.57
s=-
c=IN IP4 192.168.0.57
t=0 0
m=audio 4000 rtp/avp 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
-----End-of-message-----
1365314026152: 10:23:46.152 Sun 07 Apr 2013, 192.168.0.254:5060/udp (450 bytes) received
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 192.168.0.57:5060;branch=z9hG4bK644461b7;received=192.168.0.57;rport=5060
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
Call-ID: 728007708208#192.168.0.57
CSeq: 2 INVITE
Server: FPBX-2.8.1(1.8.11.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
-----End-of-message-----
1365314026155: 10:23:46.155 Sun 07 Apr 2013, 192.168.0.254:5060/udp (326 bytes) sent
ACK sip:57#192.168.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK644461b7
Max-Forwards: 70
To: "Alice" <sip:57#192.168.0.254:5060>;tag=as3f160681
From: "aziz" <sip:157#192.168.0.254>;tag=350164683297
Call-ID: 728007708208#192.168.0.57
CSeq: 2 ACK
User-Agent: mjsip 1.7
Content-Length: 0
-----End-of-message-----
A little late, but often times this is related to codec incompatibilities.
For anyone encountering this issue, they should check whether both sides (server and client) have at least one codes they can negotiate.
From the log posted:
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
It appears that G711 is requested but unavailable on the server side. Hence the server rejects the RTP channel.
I had the same error using a Snom 300 phone to contact an Asterisk server. Turning RTP encryption off on the phone worked for me.
On V7 firmware, this is in: "V7: Identities - RTP Settings(Section): RTP Encryption". Apparently, on V7, RTP encryption is turned on by default: http://wiki.snom.com/wiki/index.php/Settings/user_srtp
I don't know if the root cause is that the Asterisk server is misconfigured (I don't run it), but at least this worked around the problem.
For me, it was my VOIP provider's server-side setting expecting only encrypted connections. I forgot about it after I reverted to plaintext connections in the client.
I encountered this error in Zoiper5 Desktop application. The issue was resolved probably by setting RTCP Feedback-> OFF, previously I used "Compatibility mode", hence it is the most probable cause of 488 error. Also, I have changed the order of codecs to: G.711 mulaw; a-law; GSM FR; G.722 whereas moving OPUS codec to the least preferable spot codecs' order.
I'm developing a SIP user agent application that connects to an Asterisk server and tries to do an outgoing call. I'm using the NIST implementation of the JAIN SIP API.
When the application registers itself, a 401 (Unauthorized) response challenges it with a WWW-Authenticate header. The application inserts the Authorization header into the next REGISTER request. This time Asterisk returns a 200 (OK) response - the registration is successful.
When the application transmits an INVITE request, Asterisk responds with a 407 (Proxy Authentication Required) response. This time the response contains a Proxy-Authenticate header. My application sends an INVITE again, but this time with the Authorization header, upon which Asterisk responds with the same 407 (Proxy Authentication Required) response.
Here are the SIP messages that are transmitted ('>>' indicates outgoing messages; '<<' indicates incoming messages):
>>
REGISTER sip:10.0.84.30:5060 SIP/2.0
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
CSeq: 1 REGISTER
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:301#asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Expires: 300
Content-Length: 0
<<
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230;received=10.0.85.3
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:301#asterisk>
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:301#10.0.84.30>
Content-Length: 0
<<
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230;received=10.0.85.3
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:301#asterisk>;tag=as3c458716
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:301#10.0.84.30>
WWW-Authenticate: Digest realm="asterisk",nonce="6fbe5a68"
Content-Length: 0
>>
REGISTER sip:10.0.84.30:5060 SIP/2.0
CSeq: 2 REGISTER
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:301#asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKffb0be254f93f61fa0dc7ac32b9078a43230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Expires: 300
Authorization: Digest username="301",realm="asterisk",nonce="6fbe5a68",response="bc7075e8e241a4109dfa24d6ae95e78c",algorithm=MD5,uri="sip:10.0.84.30:5060",nc=00000001
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
Content-Length: 0
<<
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKffb0be254f93f61fa0dc7ac32b9078a43230;received=10.0.85.3
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:301#asterisk>
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
CSeq: 2 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:301#10.0.84.30>
Content-Length: 0
<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKffb0be254f93f61fa0dc7ac32b9078a43230;received=10.0.85.3
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:301#asterisk>;tag=as3c458716
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
CSeq: 2 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Expires: 300
Contact: <sip:10.0.85.3:5060>;expires=300
Date: Tue, 03 May 2011 06:42:33 GMT
Content-Length: 0
>>
INVITE sip:302#asterisk SIP/2.0
Call-ID: c20df277bb6f9fb69d83000e5255eb86#10.0.85.3
CSeq: 3 INVITE
From: <sip:301#asterisk>;tag=KOZWxg
To: <sip:302#asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKaa0520efde83907b71d1f76315188c413230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Route: <sip:10.0.84.30:5060;lr>
Content-Type: application/sdp
Content-Length: 106
>>
v=0
o=- 3513393083 3513393083 IN IP4 10.0.85.3
s=-
c=IN IP4 10.0.85.3
t=0 0
m=audio 40000 RTP/AVP 3
<<
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKaa0520efde83907b71d1f76315188c413230;received=10.0.85.3
From: <sip:301#asterisk>;tag=KOZWxg
To: <sip:302#asterisk>;tag=as5de9ed83
Call-ID: c20df277bb6f9fb69d83000e5255eb86#10.0.85.3
CSeq: 3 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:302#10.0.84.30>
Proxy-Authenticate: Digest realm="asterisk",nonce="74986b64"
Content-Length: 0
>>
INVITE sip:302#asterisk SIP/2.0
CSeq: 4 INVITE
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:302#asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK86f9dbdff9eeca422fbb67321dd45f7a3230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Route: <sip:10.0.84.30:5060;lr>
Content-Type: application/sdp
Authorization: Digest username="301",realm="asterisk",nonce="74986b64",response="a08b8d7ce96cae00e7d334e132bf7358",algorithm=MD5,uri="sip:302#asterisk",nc=00000001
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
Content-Length: 106
>>
v=0
o=- 3513393083 3513393083 IN IP4 10.0.85.3
s=-
c=IN IP4 10.0.85.3
t=0 0
m=audio 40000 RTP/AVP 3
<<
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK86f9dbdff9eeca422fbb67321dd45f7a3230;received=10.0.85.3
From: <sip:301#asterisk>;tag=2B3n8g
To: <sip:302#asterisk>;tag=as3c458716
Call-ID: acf3c0e9c1338d2c28d9c534ae86cbd8#10.0.85.3
CSeq: 4 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:10.0.85.3:5060>
Proxy-Authenticate: Digest realm="asterisk",nonce="1bd30f50"
Content-Length: 0
The Authorization header is constructed in exactly the same way in both cases (same code that is executed).
I'm using the request's request-URI for "digestURI".
I've tried using a Proxy-Authorization header instead of an Authorization header, but the result is the same.
Can anyone see what I'm doing wrong?
Thanks in advance.
For authenticating to a proxy (in other words you got a 407 Proxy Authentication Required you need a Proxy-Authorization header.
As RFC 2617 says, you construct this in the same way as you would an Authorization header.
You mention using the From URI in your question. RFC 2617 section 3.2.2 says you use the Request-URI (sip:302#asterisk). Watch out for the SIP-specific changes in RFC 3261 section 22.4.
I've solved the problem.
It seems that Asterisk could not associate my second INVITE request to the preceding 407 (Proxy Authentication Required) response, containing the nonce value for the Proxy-Authentication header.
This was because I didn't use the same values for Call-ID and the tag of the From-header for the two INVITE requests. For the second INVITE request, which contains the Proxy-Authentication Header, I've accidentally used the Call-ID and From-header tag values of the first REGISTER request, instead of the first INVITE request.
The INVITE does not yet succeed, though. For the second response I now get 488 (Not acceptable here), but I will try to find out what is wrong now in a different question.
It's s bit strange that your Asterisk server is responding with a 407 I just checked mine and it responds with 401. Asterisk is after all a B2BUA rather than a proxy. I'd recommend trying an Authorization header in the authenticated request rather than Proxy-Authorization as that works with my Asterisk server.
Also you need to use the request URI in the digest and not the From header URI. So in your case it should be uri=sip:302#asterisk.