I'm trying to configure OpenBTS 4 to use Restcomm for SIP registrar, voice and SMS proxy. Looks like OpenBTS has a minimal SIP stack and expects not to be challenged when registering mobile devices as sip clients. I see this question addressed for FreeSwitch:
http://wiki.freeswitch.org/wiki/OpenBTS
Can Restcomm be configured to accept registration requests without auth challenge?
SIP message log:
21:52:14,743 INFO [gov.nist.javax.sip.stack.UDPMessageChannel] (Mobicents-SIP-Servlets-UDPMessageChannelThread-3) Setting SIPMessage peerPacketSource to: /192.168.1.22:5062
21:52:14,749 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (Mobicents-SIP-Servlets-UDPMessageChannelThread-3) <message
from="192.168.1.22:5062"
to="0.0.0.0:5080"
time="1417931534736"
isSender="false"
transactionId="z9hg4bkobtskvtocsucdsglutmh"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="REGISTER sip:192.168.1.22 SIP/2.0"
>
<![CDATA[REGISTER sip:192.168.1.22 SIP/2.0
To: <sip:IMSI001010000000002#192.168.1.22:5080>
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSiciuwjsxgdqsjsrb
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTSkvtocsucdsglutmh;received=192.168.1.22
Call-ID: 001013e826c0010-e5a7615573939dc7
CSeq: 56410 REGISTER
Contact: <sip:IMSI001010000000002#127.0.0.1:5062>;expires=5400
P-Preferred-Identity: <sip:IMSI001010000000002#127.0.0.1>
P-PHY-Info: OpenBTS; TA=1 TE=0.294483 UpRSSI=-62.603565 TxPwr=20 DnRSSIdBm=-66 time=1417931534.143
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=0010103e8000a
User-Agent: OpenBTS 4.0.0.8025 Build Date Mar 19 2014
Max-Forwards: 70
Content-Length: 0
]]>
</message>
21:52:14,755 INFO [org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher] (Mobicents-SIP-Servlets-UDPMessageChannelThread-3) Request event dispatched to RestComm
21:52:14,765 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (RestComm-akka.actor.default-dispatcher-31) <message
from="0.0.0.0:5080"
to="192.168.1.22:5062"
time="1417931534763"
isSender="true"
transactionId="z9hg4bkobtskvtocsucdsglutmh"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="SIP/2.0 407 Proxy Authentication required"
>
<![CDATA[SIP/2.0 407 Proxy Authentication required
To: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=20906605_eef5d580_57a5b08a_e058ce9c-9ea9-4cad-b6c5-372364a3afa9
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTSkvtocsucdsglutmh;received=192.168.1.22
CSeq: 56410 REGISTER
Call-ID: 001013e826c0010-e5a7615573939dc7
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSiciuwjsxgdqsjsrb
Server: TelScale Sip Servlets 7.0.2-SNAPSHOT
Proxy-Authenticate: Digest realm="192.168.1.22",nonce="36303031356338332d326635622d343"
Content-Length: 0
]]>
</message>
21:52:45,836 INFO [gov.nist.javax.sip.stack.UDPMessageChannel] (Mobicents-SIP-Servlets-UDPMessageChannelThread-4) Setting SIPMessage peerPacketSource to: /192.168.1.22:5062
21:52:45,841 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (Mobicents-SIP-Servlets-UDPMessageChannelThread-4) <message
from="192.168.1.22:5062"
to="0.0.0.0:5080"
time="1417931565828"
isSender="false"
transactionId="z9hg4bkobtscdqcajsutpuenhlc"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="REGISTER sip:192.168.1.22 SIP/2.0"
>
<![CDATA[REGISTER sip:192.168.1.22 SIP/2.0
To: <sip:IMSI001010000000002#192.168.1.22:5080>
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSzyvbgcivyilvjqxe
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTScdqcajsutpuenhlc;received=192.168.1.22
Call-ID: 001013e826c0010-e5a7615573939dc7
CSeq: 56411 REGISTER
Contact: <sip:IMSI001010000000002#127.0.0.1:5062>;expires=5400
P-Preferred-Identity: <sip:IMSI001010000000002#127.0.0.1>
P-PHY-Info: OpenBTS; TA=1 TE=0.385417 UpRSSI=-66.000000 TxPwr=28 DnRSSIdBm=-48 time=1417931565.071
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=0010103e8000a
User-Agent: OpenBTS 4.0.0.8025 Build Date Mar 19 2014
Max-Forwards: 70
Content-Length: 0
]]>
</message>
21:52:45,847 INFO [org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher] (Mobicents-SIP-Servlets-UDPMessageChannelThread-4) Request event dispatched to RestComm
21:52:45,851 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (RestComm-akka.actor.default-dispatcher-31) <message
from="0.0.0.0:5080"
to="192.168.1.22:5062"
time="1417931565849"
isSender="true"
transactionId="z9hg4bkobtscdqcajsutpuenhlc"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="SIP/2.0 407 Proxy Authentication required"
>
<![CDATA[SIP/2.0 407 Proxy Authentication required
To: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=12394044_eef5d580_57a5b08a_5b523e6e-471b-4e99-93c0-ad56b68b2b93
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTScdqcajsutpuenhlc;received=192.168.1.22
CSeq: 56411 REGISTER
Call-ID: 001013e826c0010-e5a7615573939dc7
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSzyvbgcivyilvjqxe
Server: TelScale Sip Servlets 7.0.2-SNAPSHOT
Proxy-Authenticate: Digest realm="192.168.1.22",nonce="32356138316339342d353833652d343"
Content-Length: 0
]]>
</message>
Jean Deruelle provided the answer I needed:
https://github.com/Mobicents/RestComm/issues/29
A new config tag authenticate has been added to the restcomm.xml configuration file.
Set it to false to disable auth for incoming requests (REGISTER,
INVITE, MESSAGE) from SIP Clients If set to true Restcomm will
authenticate users and incoming messages from those users
true
<!-- If set to true Restcomm will authenticate users and incoming messages from those users -->
<authenticate>false</authenticate>
Related
When I run this request using this azure library:
blobURL.PutBlob(ctx, strings.NewReader("Some text"), azblob.BlobHTTPHeaders{}, azblob.Metadata{"Foo": "/愛知県/bar"}, azblob.BlobAccessConditions{})
I get this error:
===== RESPONSE ERROR (ServiceCode=AuthenticationFailed) =====
Description=Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:daf8a672-001e-000e-2f4b-a033f3000000
Time:2018-02-07T19:38:09.6740273Z, Details:
AuthenticationErrorDetail: The MAC signature found in the HTTP request 'REDACTED' is not the same as any computed signature. Server used following string to sign: 'PUT
9
x-ms-blob-cache-control:
x-ms-blob-content-disposition:
x-ms-blob-content-encoding:
x-ms-blob-content-language:
x-ms-blob-content-type:
x-ms-blob-type:BlockBlob
x-ms-client-request-id:f18fd538-3780-4f62-5236-777ac244affa
x-ms-date:Wed, 07 Feb 2018 19:38:09 GMT
x-ms-meta-foo:/愛知県/bar
x-ms-version:2016-05-31
/MYACCOUNT/MYCONTAINER/ReadMe.txt
timeout:61.
PUT https://MYACCOUNT.blob.core.cloudapi.de/MYCONTAINER/ReadMe.txt?timeout=61
Authorization: REDACTED
Content-Length: [9]
User-Agent: [Azure-Storage/0.1 (go1.9.3; darwin)]
X-Ms-Blob-Cache-Control: []
X-Ms-Blob-Content-Disposition: []
X-Ms-Blob-Content-Encoding: []
X-Ms-Blob-Content-Language: []
X-Ms-Blob-Content-Type: []
X-Ms-Blob-Type: [BlockBlob]
X-Ms-Client-Request-Id: [f18fd538-3780-4f62-5236-777ac244affa]
X-Ms-Date: [Wed, 07 Feb 2018 19:38:09 GMT]
X-Ms-Meta-Foo: [/愛知県/bar]
X-Ms-Version: [2016-05-31]
--------------------------------------------------------------------------------
RESPONSE Status: 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
Content-Length: [936]
Content-Type: [application/xml]
Date: [Wed, 07 Feb 2018 19:38:09 GMT]
Server: [Microsoft-HTTPAPI/2.0]
X-Ms-Request-Id: [daf8a672-001e-000e-2f4b-a033f3000000]
exit status 1
Is this because "/愛知県/bar" != "/愛知県/bar"?
Do you see any way to set non-ascii character like "/愛知県/bar" as a metadata value?
Since you mentioned Go in the tag, I assume you are looking for using a transliterator, there is this one in github which you should try
: https://github.com/rainycape/unidecode
I have an int-http:outbound-gateway to a rest service with a custom http header but this header is not mapped to the SI message headers although is set on the mapped-response-headers config
here's my config:
<int-http:outbound-gateway
request-channel="inChannel" reply-channel="outChannel"
url-expression="http://localhost:8080/rest" mapped-request-headers="HTTP_REQUEST_HEADERS"
http-method-expression="GET" expected-response-type="java.lang.String"
charset="UTF-8"
mapped-response-headers="HTTP_RESPONSE_HEADERS,mySpecificHeader"/>
Here's the raw response from the rest service:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Expires: Fri, 28 Oct 2016 02:05:34 GMT
mySpecificHeader: headerInfo
Content-Type: application/json
Transfer-Encoding: chunked
Date: Fri, 28 Oct 2016 02:05:34 GMT
{"surname":"Constantine","phone":"+33 555 666 777","name":"John","id":12345}
I am using PHPMailer.
I added DKIM attributes when sending file.
The code is like:
// $mail is PHPMailer class
$mail->SMTPAuth = true;
$mail->SMTPSecure = "ssl";
$mail->Host = "*******";
$mail->Port = ***;
$mail->Mailer= "SMTP";
//...
$mail->DKIM_domain = 'mydomain.com';
$mail->DKIM_identity = '#mydomain.com';
$mail->DKIM_private = __DIR__ . '/privacy_key_mydomain.txt';
$mail->DKIM_selector = 'default';
$mail->DKIM_passphrase = ''; // only ssl.
//...
(Same as example on: Send mail in phpmailer using DKIM Keys)
When sending to email, such as mine (gmail), I have no problem, and I see that my email is signed by mydomain.com.
I see also, in the email source that DKIM-Signature is sent.
Nevertheless, some of my clients I am sending emails reject my email, with following message (especially for yahoo emails - more that 90% of rejects uses yahoo for their emails).
554 Message not allowed - Headers are not RFC compliant[291]
As I did some workaround, I found this message to be detected as a spam.
I am using CPANEL for my site, which has round-cube - so I test it at round-cube (sending the customer a message with round-cube) - seems OK. No spam detect.
So, I suspect the privacy key file may be incorrect (I have an SSL site - so I use the same privacy key as my own site).
What may be wrong? What shall I check out in order to avoid my emails will be detected as spams?
Here is the email source result:
Delivered-To: myaccount#gmail.com
Received: by 10.114.75.12 with SMTP id y12csp118366ldv;
Tue, 15 Jul 2014 11:44:11 -0700 (PDT)
X-Received: by 10.140.104.49 with SMTP id z46mr36090427qge.74.1405449850437;
Tue, 15 Jul 2014 11:44:10 -0700 (PDT)
Return-Path: <support#mydomain.com>
Received: from lin9.maindomain10.net (lin9.maindomain10.net. [1.2.3.4])
by mx.google.com with ESMTPS id t14si21957304qac.66.2014.07.15.11.44.09
for <myaccount#gmail.com>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Tue, 15 Jul 2014 11:44:10 -0700 (PDT)
Received-SPF: pass (google.com: domain of support#mydomain.com designates 1.2.3.4 as permitted sender) client-ip=1.2.3.4;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of support#mydomain.com designates 1.2.3.4 as permitted sender) smtp.mail=support#mydomain.com;
dkim=pass header.i=#mydomain.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mydomain.com; s=default;
h=Content-Type:Content-Transfer-Encoding:MIME-Version:Message-ID:Subject:Reply-To:From:To:Date:Subject:To; bh=HBLjhR1eb0w5FQ9aVj60Gu0x3jP9XWQ7LQkpzTRHjfQ=;
b=ECWMCs3iPsjuvlT473K9u3skwyNRVunmnv3p440Nk2ZJVrbuWoO0vgzaWM8gjCC503ADKivdfrrOek8TgTSEI7G4B3WMCHI50PWq68W5rcscYJqErWxuqAVcSl4r5tomk88AYPhHiotCugmRTjwQ2K/JBtHsAvMhTlVQMMXsMl0=;
Received: from mainuser by lin9.maindomain10.net with local (Exim 4.82)
(envelope-from <support#mydomain.com>)
id 1X77hp-0001f9-SH; Tue, 15 Jul 2014 14:44:01 -0400
To: myName Mizrahi <myaccount#gmail.com>
Subject: Statistics from Sample Name site
Date: Tue, 15 Jul 2014 14:44:01 -0400
To: myName Mizrahi <myaccount#gmail.com>
From: "donotreply#mydomain.com" <root#localhost>
Reply-To: Sample Name site <donotreply#mydomain.com>
Subject: Statistics from Sample Name site
Message-ID: <d984a2c6308ef2a97cf6ccfe6292263a#mydomain.com>
X-Priority: 3
X-Mailer: PHPMailer 5.2.4 (http://code.google.com/a/apache-extras.org/p/phpmailer/)
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset=UTF-8
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - lin9.maindomain10.net
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [927 895] / [47 12]
X-AntiAbuse: Sender Address Domain - mydomain.com
X-Get-Message-Sender-Via: lin9.maindomain10.net: authenticated_id: mainuser/sender_address_domain
When sending message from round-cube, the email source look like this:
Delivered-To: myaccount#gmail.com
Received: by 10.114.75.12 with SMTP id y12csp118605ldv;
Tue, 15 Jul 2014 11:48:53 -0700 (PDT)
X-Received: by 10.224.161.129 with SMTP id r1mr34110372qax.86.1405450132678;
Tue, 15 Jul 2014 11:48:52 -0700 (PDT)
Return-Path: <support#mydomain.com>
Received: from lin9.maindomain10.net (lin9.maindomain10.net. [1.2.3.4])
by mx.google.com with ESMTPS id x8si13226659qas.81.2014.07.15.11.48.52
for <myaccount#gmail.com>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Tue, 15 Jul 2014 11:48:52 -0700 (PDT)
Received-SPF: pass (google.com: domain of support#mydomain.com designates 1.2.3.4 as permitted sender) client-ip=1.2.3.4;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of support#mydomain.com designates 1.2.3.4 as permitted sender) smtp.mail=support#mydomain.com;
dkim=pass header.i=#mydomain.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mydomain.com; s=default;
h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Bynm51C7RZD/vZ81iEMKjxxLoAJtSmKFcwU/eyFzPs8=;
b=fUX+UKS9Ua0HK35AOBRBJbmqTEuKscCYAsPyxs3If3dhhvb/AvAjl1gR9Rz9AN0EX0mu275wtaN5Y1JWP+8w8VcGebJ9FEWsltCl9nwqL6bos/eEqJxTWjDG6ch9MHo3G0mSE326Pyc13JWa59InSgJyWi8MSstT1POfuEhfe28=;
Received: from localhost.localdomain ([127.0.0.1]:54911 helo=mydomain.com)
by lin9.maindomain10.net with esmtpa (Exim 4.82)
(envelope-from <support#mydomain.com>)
id 1X77mO-0001l7-1O
for myaccount#gmail.com; Tue, 15 Jul 2014 14:48:44 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 15 Jul 2014 14:48:43 -0400
From: support#mydomain.com
To: myaccount#gmail.com
Subject: test
Message-ID: <ed6307c2c9504e8ba9ec21f073d5f863#mydomain.com>
X-Sender: support#mydomain.com
User-Agent: Roundcube Webmail/0.9.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - lin9.maindomain10.net
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mydomain.com
X-Get-Message-Sender-Via: lin9.maindomain10.net: authenticated_id: support#mydomain.com
Round-Cube works with no spam.
What is the main difference that's make the issue?
Thanks :)
5.2.4 is pretty old and buggy - You need to update to the latest PHPMailer from GitHub.
I have implemented ntlmv2 for lync-server login in an custom made lync client.The message that I send to server is .....
(3rd register message)
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TLS 19x.1xx.0.1xx:3246
From: <sip:lynctest8#example.com>;tag=2257063211;epid=22570632
To: <sip:lynctest8#example.com>
Call-ID: A2B000F95CB8XZRikcdYitb4QBvEr4P2
CSeq: 3 REGISTER
Contact: <sip:19x.1xx.0.1xx:3246;transport=tls;ms-opaque=28c9d310c1>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:6b6590c5-2a3f-5dee-ad87-5ab6694cf66d>"
Max-Forwards: 70
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking
Supported: ms-cluster-failover
Supported: ms-userservices-state-notification
Ms-keep-alive: UAC;hop-hop=yes
Event: registration
Ms-subnet: 19x.1xx.0.0
Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="8CEED616", targetname="lyncfe.example.com", version=4, gssapi-data="TlRMTVNTUAADAAAAGAAYAKgAAADGAMYAwAAAABAAEABYAAAALAAsAGgAAAAUABQAlAAAABAAEACGAQAAVYKQYgYBsR0AAAAPAAAAAAAAAAAAAAAAAAAAAG4AZQB5AGUAYgBhAGwAbABsAHkAbgBjAHQAZQBzAHQAOABAAG4AZQB5AGUAYgBhAGwAbAAuAGMAbwBtAEUAWQBFAEIAQQBMAEwALQBQAEMA9jYBMVaneo2SEFBrg1/YnLPWl4gGzCyjeTg+SJIb99jnRvh/xOM1KQEBAAAAAAAAAD9j2kfbzAGz1peIBswsowAAAAACABAATgBFAFkARQBCAEEATABMAAEADABMAFkATgBDAEYARQAEABgAbgBlAHkAZQBiAGEAbABsAC4AYwBvAG0AAwAmAGwAeQBuAGMAZgBlAC4AbgBlAHkAZQBiAGEAbABsAC4AYwBvAG0ABQAYAG4AZQB5AGUAYgBhAGwAbAAuAGMAbwBtAAcACABjQk/rRdvMAQAAAAAAAAAAGL4kYo+YoVBEmij7AkIylQ==" , crand="becdaa89", cnum ="1", response="0100000024A95BA08AA3947964000000"
Content-Length: 0
The response that I get from server is in log is......
TL_INFO(TF_COMPONENT) [0]05FC.02D0::01/25/2012-08:06:57.900.00000042 (SIPStack,CSIPMessage::CacheConnectionFlags:SIPMessage.cpp(1664))[0]( 00000000039B4DC0 ) From server [lyncfe.example.com] connection, flags [PeerInternal TrafficInternal 0xa0100c], CID [0x12300]
TL_INFO(TF_PROTOCOL) [0]05FC.02D0::01/25/2012-08:06:57.900.00000043 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record
Trace-Correlation-Id: 4074196035
Instance-Id: 000018F0
Direction: incoming;source="internal edge";destination="external edge"
Peer: lyncfe.example.com:5061
Message-Type: response
Start-Line: SIP/2.0 401 Unauthorized
From: <sip:lynctest8#example.com>;tag=1672455111;epid=16724551
To: <sip:lynctest8#example.com>;tag=6E92C85AEBAC66461CD3D9E7FF35D674
CSeq: 3 REGISTER
Call-ID: CDEA0494B083GDXKgQYZ3IuhqvqePNLL
Date: Wed, 25 Jan 2012 08:06:57 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="lyncfe.example.com", version=4
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="lyncfe.example.com", version=4, sts-uri="https://lyncfe.example.com:443/CertProv/CertProvisioningService.svc"
Via: SIP/2.0/TLS 19x.1xx.0.2xx:60027;branch=z9hG4bK72A5FBC9.AAC299504F0761A1;branched=FALSE;ms-received-port=60027;ms-received-cid=16B9100
Via: SIP/2.0/TLS 19x.1xx.0.1xx:3082;received=2xx.xx.1xx.1xx;ms-received-port=3082;ms-received-cid=12700
ms-diagnostics: 1000;reason="Final handshake failed";HRESULT="0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED)";source="lyncfe.example.com"
Server: RTC/4.0
Content-Length: 0
Message-Body: –
$$end_record
What is the problem here? Can you give any hints/solutions to solve it?
It most likely due to SSL handshake while end point "https://lyncfe.example.com:443/CertProv/CertProvisioningService.svc". Please check your client certs and also enable SSL debug to see what's happening during handshake.
Thanks, Everyone. My problem has been solved. It was GSS-API-data and auth-token generation problem.
I have deleted my previous question and post this updated:
I have a an issue with my SIP UAC, once I received a ringing from the B2BUA on both the caller and callee, and the caller hangs up the call while the call is ringing (I send cancel request and receive "request terminated" on the caller side), the callee does not get any notification that the call has been terminated by the caller.
But when the callee declines the call, the caller gets a busy here.
Here is the Callee side:
/----------------------- MEDIA SESSION ------------------------/
--- Multimedia-Session: Composed Audio ---
1. Media Session: "Audio" enabled=true
States:
[Disconnected]
Capturers: (1 in total)
Stream 1: audio device - DirectSoundCapture
Formats:
[PCMU/8000]
Connection Details:
My address: 10.0.0.2:52044
Participants: (1 in total)
Address 1: HostAddress:17364
/-------------------- END OF MEDIA SESSION --------------------/
/------------------------- BEGINNING --------------------------/
-------------------------------- Request: Test 2-->Me: INVITE#102 --------------------------------
INVITE sip:430#Host SIP/2.0
Via: SIP/2.0/UDP HostAddress:5060;branch=z9hG4bK1fd06834;rport=5060;received=HostAddress
From: "Test 2" <sip:410#HostAddress>;tag=as2b22eddf
To: <sip:430#Host>
Contact: <sip:410#HostAddress>
Call-ID: 35e0e8655b20ad886f137a0c0e563809#HostAddress
CSeq: 102 INVITE
User-Agent: Freeswitch 1.2.3
Max-Forwards: 70
Date: Sun, 11 Jul 2010 02:44:43 GMT
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 264
v=0
o=root 27669 27669 IN IP4 HostAddress
s=session
c=IN IP4 HostAddress
t=0 0
m=audio 17364 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
------------------------ Response: Me ==> Test 2: INVITE#102: 180 Ringing ------------------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP HostAddress:5060;branch=z9hG4bK1fd06834;rport=5060;received=HostAddress
From: "Test 2" <sip:410#HostAddress>;tag=as2b22eddf
To: <sip:430#Host>;tag=e125be76
Call-ID: 35e0e8655b20ad886f137a0c0e563809#HostAddress
CSeq: 102 INVITE
Content-Length: 0
------------------------ Response: Me ==> Test 2: INVITE#102: 603 Decline ------------------------
SIP/2.0 603 Decline
Via: SIP/2.0/UDP HostAddress:5060;branch=z9hG4bK1fd06834;rport=5060;received=HostAddress
From: "Test 2" <sip:410#HostAddress>;tag=as2b22eddf
To: <sip:430#Host>;tag=e125be76
Call-ID: 35e0e8655b20ad886f137a0c0e563809#HostAddress
CSeq: 102 INVITE
Content-Length: 0
/---------------------------- END -----------------------------/
I must decline at the callee end, because if I don't respond to the request, the callee account get stuck in a loop and then the client returns busy forever, and requests does not reach that client, or at least until the account is deleted.
And there is another thing, the B2BUA does not send anything back to the decline response, shouldn't I get an ACK from the server?
And here is the Caller side:
/----------------------- MEDIA SESSION ------------------------/
--- Multimedia-Session: Audio ---
1. Media Session: "Audio" enabled=true
States:
[Disconnected]
Capturers: (1 in total)
Stream 1: audio device - DirectSoundCapture
Formats:
[PCMU/8000]
[GSM/8000]
[G723/8000]
[DVI4/8000]
[MPA/-1]
[DVI4/11025]
[DVI4/22050]
Connection Details:
My address:
Participants: (0 in total)
/-------------------- END OF MEDIA SESSION --------------------/
/------------------------- BEGINNING --------------------------/
-------------------------- Request: Client 410-->Client 430: INVITE#81 --------------------------
INVITE sip:430#host SIP/2.0
Subject: Session Name: Nu-Art Software
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK4dd6bdf707a85fb5a73faec9ff648f703236
Contact: "Client 410" <sip:410#host>
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>
Organization: Future Earth
Max-Forwards: 32
CSeq: 81 INVITE
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS
Expires: 60
Content-Type: application/sdp
Content-Length: 324
v=0
o=Client 410 699719 699719 IN IP4 MyAddress
s=Audio
i=Made by: Nu-Art Software 07-2010
c=IN IP4 MyAddress
t=0 0
m=audio 2871 RTP/AVP 0 3 4 5 14 16 17
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:4 G723/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:14 MPA/-1
a=rtpmap:16 DVI4/11025
a=rtpmap:17 DVI4/22050
------- Response: Client 430 ==> Client 410: INVITE#81: 407 Proxy Authentication Required -------
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK4dd6bdf707a85fb5a73faec9ff648f703236;received=MyAddress
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>;tag=as78e28f4d
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
CSeq: 81 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5,realm="asterisk",nonce="574b3d49"
Content-Length: 0
---------------------------- Request: Client 410-->Client 430: ACK#81 ----------------------------
ACK sip:430#host SIP/2.0
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK4dd6bdf707a85fb5a73faec9ff648f703236
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>
Max-Forwards: 32
CSeq: 81 ACK
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
Content-Length: 0
-------------------------- Request: Client 410-->Client 430: INVITE#82 --------------------------
INVITE sip:430#host SIP/2.0
Subject: Session Name: Nu-Art Software
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK34c52041066f24c6ac4499af25a948b63236
Contact: "Client 410" <sip:410#host>
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>;tag=as78e28f4d
Organization: Future Earth
Max-Forwards: 32
CSeq: 82 INVITE
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS
Expires: 60
Content-Type: application/sdp
Proxy-Authorization: Digest username="410",nonce="574b3d49",realm="asterisk",uri="sip:410#host",algorithm=MD5,response="e674e15de7b6dd05c7fe6da6c155befd"
Content-Length: 324
v=0
o=Client 410 699719 699719 IN IP4 MyAddress
s=Audio
i=Made by: Nu-Art Software 07-2010
c=IN IP4 MyAddress
t=0 0
m=audio 2871 RTP/AVP 0 3 4 5 14 16 17
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:4 G723/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:14 MPA/-1
a=rtpmap:16 DVI4/11025
a=rtpmap:17 DVI4/22050
------------------- Response: Client 430 ==> Client 410: INVITE#82: 100 Trying -------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK34c52041066f24c6ac4499af25a948b63236;received=MyAddress
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>;tag=as78e28f4d
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
CSeq: 82 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Contact: <sip:430#HostAddress>
Content-Length: 0
------------------ Response: Client 430 ==> Client 410: INVITE#82: 180 Ringing ------------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK34c52041066f24c6ac4499af25a948b63236;received=MyAddress
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>;tag=as78e28f4d
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
CSeq: 82 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Contact: <sip:430#HostAddress>
Content-Length: 0
-------------------------- Request: Client 410-->Client 430: CANCEL#82 --------------------------
CANCEL sip:430#host SIP/2.0
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
To: "Client 430" <sip:430#host>;tag=as78e28f4d
CSeq: 82 CANCEL
From: "Client 410" <sip:410#host>;tag=8f7b94cb
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK34c52041066f24c6ac4499af25a948b63236
Max-Forwards: 32
Content-Length: 0
--------------------- Response: Client 430 ==> Client 410: CANCEL#82: 200 OK ---------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK34c52041066f24c6ac4499af25a948b63236;received=MyAddress
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>;tag=as78e28f4d
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
CSeq: 82 CANCEL
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Content-Length: 0
------------- Response: Client 430 ==> Client 410: INVITE#82: 487 Request Terminated -------------
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK34c52041066f24c6ac4499af25a948b63236;received=MyAddress
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>;tag=as78e28f4d
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
CSeq: 82 INVITE
User-Agent: Freeswitch 1.2.3
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Content-Length: 0
---------------------------- Request: Client 410-->Client 430: ACK#82 ----------------------------
ACK sip:430#host SIP/2.0
Via: SIP/2.0/UDP host:5060;branch=z9hG4bK34c52041066f24c6ac4499af25a948b63236
From: "Client 410" <sip:410#host>;tag=8f7b94cb
To: "Client 430" <sip:430#host>
Max-Forwards: 32
CSeq: 82 ACK
Call-ID: 97ee019923d6a6d11a9476d71880e289#10.0.0.1
Content-Length: 0
/---------------------------- END -----------------------------/
Frank, I tried to pay attention to your details, perhaps I missed something, since the other side still does not receives notification on an early hang up.
Any idea why?
Thanks in advance,
Adam.
1) 6xx is unusual; normally rejecting a call is done with a 4xx (usually "Busy Here")
2) The lack of cancel to the destination is a bug in the sip server. (Ok, they're not required to send a CANCEL if you cancel, but they really should.)