I'm trying to bind Asterisk 11 and GoIP 32 Easy Phone with sip trunk.
XXX.XXX.XXX.XXX Asterisk
YYY.YYY.YYY.YYY GoIP
<--- SIP read from UDP:YYY.YYY.YYY.YYY:5106 --->
PUBLISH sip:goip-1#XXX.XXX.XXX.XXX SIP/2.0
Via: SIP/2.0/UDP 192.168.2.100:5106;branch=z9hG4bK1758989526
From: sip:goip-1#XXX.XXX.XXX.XXX;tag=1774677406
To: sip:goip-1#XXX.XXX.XXX.XXX
CSeq: 41 PUBLISH
Event: capability-change
<--- Transmitting (NAT) to YYY.YYY.YYY.YYY:5106 --->
SIP/2.0 489 Bad Event
Via: SIP/2.0/UDP 192.168.2.100:5106;branch=z9hG4bK1758989526;received=185.66.87.244;rport=5106
From: sip:goip-1#XXX.XXX.XXX.XXX;tag=1774677406
To: sip:goip-1#8XXX.XXX.XXX.XXX;tag=as147ef74c
Call-ID: 774522878#192.168.2.100
CSeq: 41 PUBLISH
Server: Asterisk PBX 11.25.3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Why Asterisk answered "Bad Event" to PUBLISH Event: capability-change?
Most likely it does not support this event type, at least not in default configuration.
Related
We are trying to work with Asterisk to deploy a solution and ran in to an issue.
To allow SIP OPTIONS (and calls) to pass correctly, we need to be able to update the contact host URI.
Is it possible to do this using CHAN_SIP instead of PJSIP and if so, can you please advise how we can do it?
Example of OPTIONS request as follows:
---
Reliably Transmitting (NAT) to X.X.X.X:5061:
OPTIONS sip:domain.tld SIP/2.0
Via: SIP/2.0/TLS X.X.X.X:5061;branch=z9hG4bK1d3f350b;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk#domain.tld>;tag=as55b84229
To: <sip:sip.domain.tld>
Contact: <sip:asterisk#X.X.X.X:5061;transport=tls>
Call-ID: 6813394b6314406170a8ea175d11ef8c#domain.tld
CSeq: 102 OPTIONS
User-Agent: Wishful thinking
Date: Mon, 16 Mar 2020 12:43:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0
No, not possible.
Possible on kamailio or opensips.
I am trying to send DTMFs through SIPp. Since the play_pcap_audio action was not 100% reliable, I wanted to construct SIP INFO messages to make my tests more robust, however when I send INFO packets I get 501 - Not implemented response from Asterisk.
If I set my softphone to use SIP INFO for sending DTMFs, that works fine, so I am assuming it has to do with the messages I am sending. However comparing the actual messages did not reveal any difference.
The INVITE I send:
INVITE sip:*203#192.168.200.208:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.2:5060;branch=z9hG4bK-234-1-7;rport
From: sipp <sip:2018005#192.168.200.208>;tag=1
To: <sip:*203#192.168.200.208:5060>
Call-ID: 1-234#172.17.0.2
CSeq: 4 INVITE
Contact: sip:2018005#172.17.0.2:5060
Authorization: //auth header omitted
Max-Forwards: 70
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO
Content-Type: application/sdp
Content-Length: 195
v=0
o=user1 53655765 2353687637 IN IP4 172.17.0.2
s=-
c=IN IP4 172.17.0.2
t=0 0
m=audio 8192 RTP/AVP 0
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
and the INFO message:
INFO sip:192.168.200.208:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.2:5060;branch=z9hG4bK-234-1-16
Max-Forwards: 70
Contact: <sip:2018005#172.17.0.2:5060;transport=UDP>
To: <sip:*203#192.168.200.208:5060>
From: "sipp" <sip:2018005#192.168.200.208>;tag=1
Call-ID: 1-234#172.17.0.2
CSeq: 5 INFO
User-Agent: SIPp docker
Authorization: // auth header omitted
Content-Length: 22
Signal=1
Duration=160
I have made sure it's not to do with the dtmfmode configuration in Asterisk.
One thing I noticed is when Asterisk responds to INVITE, it contains the following header:
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
I would expect INFO to be here - but again, it's the same when using the softphone and it all works.
What other areas could affect the processing of SIP INFOs?
Any help would be much appreciated on further debugging.
Turned out to be a problem with SIP dialogs.
The tags (+ a call-id) identify a dialog. After an INVITE is sent the UAS responds with an OK, sticking a remote tag to the To: field. Every subsequent request has to use the same tags (local and remote + call-id) to refer to the same dialog. This can be achieved by sticking [last_To:] into the header when using a SIPp scenario, so that we get the correct remote tag:
<send>
<![CDATA[
ACK sip:[field3]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: <sip:[field0]#[field1]>;tag=[call_number]
[last_To:]
Call-ID: [call_id]
CSeq: [cseq] ACK
Contact: sip:[field0]#[local_ip]:[local_port]
Max-Forwards: 10
Content-Length: 0
]]>
</send>
In the above case an ACK is sent back from the UAC and the dialog is established. Now when we send the INFO, we have to refer to the same dialog (by setting the correct tags) and it all works.
Interestingly, when not setting these values properly, pjsip gives 501 Not Implemented, whereas chan_sip responds with 481 Call/Transaction Does Not Exist which is much more accurate.
Not sure if it's the place where I should ask this question.
I'm developing a simple voip application. I can call to other users, but can't hang up. When client sends BYE request, server answers with 481 - call leg transaction does not exist.
Here are client logs:
INVITE sip:2#172.20.4.7:51110;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.20.4.7:5060;branch=z9hG4bK06952c7a;rport
Max-Forwards: 70
From: "First" <sip:1#172.20.4.7>;tag=as746cc61d
To: <sip:2#172.20.4.7:51110;transport=UDP>
Contact: <sip:1#172.20.4.7:5060>
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 INVITE
User-Agent: FPBX-AsteriskNOW-12.0.76.4(11.16.0)
Date: Tue, 07 Mar 2017 11:52:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: "First" <sip:1#172.20.4.7>
Content-Type: application/sdp
Content-Length: 310
v=0
o=root 2015785808 2015785808 IN IP4 172.20.4.7
s=Asterisk PBX 11.16.0
c=IN IP4 172.20.4.7
t=0 0
m=audio 13952 RTP/AVP 0 8 3 111 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bKnCqg
Contact: <sip:2#172.20.4.7:51110;transport=UDP>
To: <sip:2#172.20.4.7;transport=UDP>;tag=YU2R
From: <sip:2#172.20.4.7;transport=UDP>;tag=as746cc61d
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 INVITE
Allow-Events: presence, kpml, talk
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bK06952c7a;rport
Contact: <sip:2#172.20.4.7:51110;transport=UDP>
To: <sip:2#172.20.4.7;transport=UDP>;tag=YU2R
From: "First" <sip:1#172.20.4.7;transport=>;tag=as746cc61d
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Accept: application/sdp, application/sdp
Accept-Language: en
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri
Allow-Events: presence, kpml, talk
Content-Length: 247
v=0
o=Z 13 13 IN IP4 95.86.129.80
s=Test
c=IN IP4 95.86.129.80
t=0 0
m=audio 50000 RTP/AVP 3 110 8 0 97 101
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode = 30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
ACK sip:2#172.20.4.7:51110;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.20.4.7:5060;branch=z9hG4bK54ba94a0;rport
Max-Forwards: 70
From: "First" <sip:1#172.20.4.7>;tag=as746cc61d
To: <sip:2#172.20.4.7:51110;transport=UDP>;tag=YU2R
Contact: <sip:1#172.20.4.7:5060>
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 ACK
User-Agent: FPBX-AsteriskNOW-12.0.76.4(11.16.0)
Content-Length: 0
BYE sip:1#172.20.4.7;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bKAZsQ
Max-Forwards: 70
From: <sip:2#172.20.4.7;transport=UDP>;tag=as746cc61d
To: <sip:1#172.20.4.7;transport=UDP>;tag=YU2R
Contact: <sip:2#172.20.4.7:51110;transport=UDP>
CSeq: 2 BYE
User-Agent: TestSoftphone
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
Content-Length: 0
SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bKAZsQ;received=172.20.1.40;rport=51110
From: <sip:2#172.20.4.7;transport=UDP>;tag=as746cc61d
To: <sip:1#172.20.4.7;transport=UDP>;tag=YU2R
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 2 BYE
Server: FPBX-AsteriskNOW-12.0.76.4(11.16.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
I read that 481 can occur if To tag or From tag or Call-ID is outside of dialog, but looks like tags and ids are ok. I don't receive a tag for To, so I generate Ringing packet where To tag is set, that may be the problem.
EDIT. I added "pedantic=no" to sip_custom.conf, and it works now. Though I don't know what's wrong with this dialog.
I'm pretty sure that Contact header is not necessary in BYE. Fastest way to understand what is wrong is check full dialog with some other SIP client. As you sad this is probably related with To or From headers
Please compare the content of Via headers in initial INVITE and BYE messages - values are different: Via: SIP/2.0/UDP 172.20.4.7:5060 and Via: SIP/2.0/UDP 172.20.4.7:51110 respectively. Asterisk created dialog and marked it internally (inside its mind) according to combination of address and port in Via header. It expects actual dialog to be canceled from the same address and port, hence all the requests came from different source are considered as "out-of-dialog" and rejected.
Actual problem is widespread and caused by incorrect behavior of the routers/firewalls installed on the edge of client networks. Try to disable ALG feature on mentioned device.
I am building a basic SIP UA. I am sending the following INVITE, as seen in Asterisk console (only headers relevant to authentication are shown):
INVITE sip:104#192.168.1.92 SIP/2.0
From: "110"<sip:110#192.168.1.92>;tag=80859256
To: <sip:104#192.168.1.92>
Call-ID: 80859256
CSeq: 80859256 INVITE
Via: SIP/2.0/UDP 192.168.1.92:6000;branch=z9hG4bK-80859256
Contact: <sip:110#192.168.1.92>
In response, I get the following challenge:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.92:6000;branch=z9hG4bK- 80859256;received=127.0.0.1
From: "110"<sip:110#192.168.1.92>;tag=80859256
To: <sip:104#192.168.1.92>;tag=as25af7f49
Call-ID: 80859256
CSeq: 80859256 INVITE
Server: Asterisk PBX 13.7.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="20e95772"
Content-Length: 0
I reply with the following:
ACK sip:104#192.168.1.92 SIP/2.0
From: "110"<sip:110#192.168.1.92>;tag=80859256
To: <sip:104#192.168.1.92>;tag=as25af7f49
Call-ID: 80859256
CSeq: 80859256 ACK
Via: SIP/2.0/UDP 192.168.1.92:6000;rport;branch=z9hG4bK-80859256
Contact: <sip:110#192.168.1.92>
Content-Length: 0
INVITE sip:104#192.168.1.92 SIP/2.0
From: "110"<sip:110#192.168.1.92>;tag=80859256
To: <sip:104#192.168.1.92>
Call-ID: 80859256
CSeq: 80859257 INVITE
Via: SIP/2.0/UDP 192.168.1.92:6000;rport;branch=z9hG4bK-80859257
Max-Forwards:5
Allow: REGISTER, INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, INFO, OPTIONS, PRACK, SUBSCRIBE
Contact: <sip:110#192.168.1.92>
Authorization: Digest
username="110",realm="asterisk", nonce="20e95772",uri="sip:104#192.168.1.92",response="ed2de012b2255e85ddb0ee724b9a3ffd"
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
I have not included above the actual SDP sent with the invites. The password for extension 110 is 110 as defined in sip.conf.
QUESTION:
I am getting this error:
WARNING...: chan_sip.c:16702 check_auth: username mismatch, have <110>, digest has <>
NOTICE...: chan_sip.c:25603 handle_request_invite: Failed to authenticate device "110"<sip:110#192.168.1.92>;tag=76981187
This is followed by a "SIP/2.0 403 Forbidden" message.
I do not believe that my digest calculation as sent in the second INVITE is wrong.
What needs to be changed? I have spent a lot of time in debugging this...
Any help would be HIGHLY appreciated.
The username in the response is being parsed by Asterisk as empty because the Authorization header field ends after the CR+LF between the words "Digest" and "username". In order for a header field to be continued on a new line, the line needs to start with whitespace; from RFC3261:
Header fields can be extended over multiple lines by preceding each extra line with at least
one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the
next line are treated as a single SP character.
Either removing the CR+LF, or inserting whitespace at the beginning of the new line should correct the problem.
I was trying to setup instant messaging in asterisk server. For the client i'm using Blink Softphone. I did add to my sip.conf
[general]
accept_outofcall_message=yes
outofcall_message_context=dialplan_name
auth_message_requests=yes
and to my extensions.conf
[dialplan_name]
exten => _XXX,1,MessageSend(sip:${EXTEN},"${CALLERID(name)}"${MESSAGE(from)})
So this is a simple extension for testing. But when i try and send the message from user1 to user2 i get in the asterisk log:
[Jan 30 21:17:47] WARNING[6420][C-00000005]: chan_sip.c:10515 process_sdp: Insufficient information in SDP (c=)...
What can be wrong here? I'am sure that the clients are on the nat, so i do have both nat=force_rport,comedia for all my users in sip.conf
My asterisk version is 13 (latest).
[UPDATED]
I turned on the sip debug log, and tried to send the message (first i get some weird retransmission):
Retransmitting #9 (no NAT) to 14.228.14.150:5070: <- weird ip here
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 14.228.14.150:5070;branch=z9hA4cA-abcdef613aca8b1x3124abb0z3e1bc8;received=14.228.14.150;rport=5070
From: 2014<sip:2014#(server_ip_here)>;tag=a312facc
To: 0009735466221178<sip:0009735466221178#(server_ip_here)>;tag=bb62441233
Call-ID: abcdef613aca8b1x3124abb0z3e1bc8
CSeq: 1 INVITE
Server: Asterisk PBX 13.1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2222abcf"
Content-Length: 0
Then
<--- SIP read from TLS:(my_ip_here):49312 --->
INVITE sip:123#(server_ip_here) SIP/2.0
Via: SIP/2.0/TLS (my_ip_here):49312;rport;branch=b4ae88b115be15a5n9244;alias
Max-Forwards: 70
From: "user1" <sip:user1#server_ip_here>;tag=39e388fd5f616b7
To: <sip:123#(server_ip_here)>
Contact: <sip:12313560#(server_ip_here):49311;transport=tls>
Call-ID: ac48128192za12a2f432e24c18aabc7q
CSeq: 28982 INVITE
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: 100rel, replaces, norefersub, gruu
User-Agent: Blink 0.9.1.2 (Windows)
Content-Type: application/sdp
Content-Length: 308
v=0
o=- 3211422221 3211422221 IN IP4 (my_ip)
s=Blink 0.9.1.2 (Windows)
t=0 0
m=message 2855 TCP/TLS/MSRP *
c=IN IP4 (my_ip)
a=path:msrps://(my_ip):2855/37a1cc82ab315e21b222;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
a=setup:active
<------------->
--- (13 headers 10 lines) ---
Sending to (my_ip):49312 (NAT)
Sending to (my_ip):49312 (NAT)
Using INVITE request as basis request - ad72cd1681aff769721af12c21aaea7c
Found peer 'user1' for 'user1' from (my_ip):49312
== Using SIP VIDEO CoS mark 6
== Using SIP RTP CoS mark 5
[Jan 31 21:02:17] WARNING[27265][C-00000118]: chan_sip.c:10515 process_sdp: Insufficient information in SDP (c=)...
arheops was right! Using INVITE request as basis request <- here it is. Instead of MESSAGE for some reason INVITE request is used.
Looks like your softphone use INVITE instead of MESSAGE for messaging.
You can get more info by enable sip debug in asterisk console
asterisk -r
sip set debug on