juniorlm87 / csipsimple

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

Secure dialog requires SIPS scheme in Contact and Record-Route headers, ending the session #2776

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
With the latest nightly I can no longer use TLS. Calls appear to complete but 
are immediately cancelled by csipsimple with "BYE".

I get the error - "Secure dialog requires SIPS scheme in Contact and 
Record-Route headers, ending the session" in the logs. As you can see the 
"contact" header below is "sip" and not "sips". I'm assuming that is what the 
issue is?

The version in the Play Store appears to work correctly despite it using "sip" 
in the contact field. Either that or it's failing TLS silently...

SIP stuff

D/libpjsip(32650): From: "123456789" 
<sips:106@mysipserver.co.uk>;tag=phJypCtGfWY.9g-4mggggggg-Ll
D/libpjsip(32650): To: <sips:*43@sip.sovoip.co.uk>;tag=asgggg1d
D/libpjsip(32650): Call-ID: 21jpTFa3-ECxgggxIhMO
D/libpjsip(32650): CSeq: 3030 INVITE
D/libpjsip(32650): Server: yes
D/libpjsip(32650): Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, 
NOTIFY, INFO, PUBLISH, MESSAGE
D/libpjsip(32650): Supported: replaces, timer
D/libpjsip(32650): Session-Expires: 1800;refresher=uas
D/libpjsip(32650): Contact: <sip:*43@xxxxx:5061;transport=TLS>
D/libpjsip(32650): Content-Type: application/sdp
D/libpjsip(32650): Require: timer
D/libpjsip(32650): Content-Length: 224
D/libpjsip(32650): 
D/libpjsip(32650): v=0
D/libpjsip(32650): o=aaaa 2087277993 2087277993 IN IP4 xxxxx
D/libpjsip(32650): s=aaaa
D/libpjsip(32650): c=IN IP4 xxxxxx
D/libpjsip(32650): t=0 0
D/libpjsip(32650): m=audio 17462 RTP/AVP 9 101
D/libpjsip(32650): a=rtpmap:9 G722/8000
D/libpjsip(32650): a=rtpmap:101 telephone-event/8000
D/libpjsip(32650): a=fmtp:101 0-16
D/libpjsip(32650): a=ptime:20
D/libpjsip(32650): a=sendrecv

Original issue reported on code.google.com by barrymercer on 18 Sep 2014 at 11:34

GoogleCodeExporter commented 9 years ago
Hi,

Thanks for the report.
The problem should not be present in nightly build version as a "default 
scheme" option is available in expert wizard.
To get the nightly build version :
http://nightlies.csipsimple.com/trunk/

Original comment by r3gis...@gmail.com on 19 Sep 2014 at 3:51

GoogleCodeExporter commented 9 years ago
Hi,

I've just installed the nightly. Do you mean the "deafult uri scheme" option? 
It's set to sips and the issue remains.

Original comment by barrymercer on 19 Sep 2014 at 4:01

GoogleCodeExporter commented 9 years ago
Ok, so it sounds a bug in what builds the uri. I will check that.
Just one last check if you have time (I don't think it's the problem but worth 
to check) :
in "SIP ID" field, is there sips protocol too?

Original comment by r3gis...@gmail.com on 19 Sep 2014 at 4:08

GoogleCodeExporter commented 9 years ago
I have the same problem:
----------
D/libpjsip( 5479): 20:34:45.189   pjsua_core.c  .RX 1388 bytes Response msg 
200/INVITE/cseq=24415 (rdata0xaf9fb1e0) from TLS 1.2.3.4:5061:
D/libpjsip( 5479): SIP/2.0 200 OK
D/libpjsip( 5479): Via: SIP/2.0/TLS 
192.168.1.100:38864;rport=38864;branch=z9hG4bKPjxSjjmQgV9gcEA1CvxY-NexS8mHIGLjjc
;alias;received=5.5.5.5
D/libpjsip( 5479): From: "+9050711122219" 
<sips:1000@sip.xxx.net>;tag=bq0B0QayH20CpMJmPW9hzslR5WBHdbRz
D/libpjsip( 5479): To: <sips:4000@sip.xxx.net>;tag=0514yU7Q7yN0c
D/libpjsip( 5479): Call-ID: -mHGBIejhRDCbUgaiWMC4TL0PrzyGgYZ
D/libpjsip( 5479): CSeq: 24415 INVITE
D/libpjsip( 5479): Contact: <sip:4000@1.2.3.4:5061;transport=tls>
D/libpjsip( 5479): User-Agent: 
FreeSWITCH-mod_sofia/1.2.11-n20130827T081601Z-1~squeeze+1+git~20130826T225725Z~4
990a541bf
D/libpjsip( 5479): Accept: application/sdp
D/libpjsip( 5479): Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, 
UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
D/libpjsip( 5479): Require: timer
D/libpjsip( 5479): Supported: timer, precondition, path, replaces
D/libpjsip( 5479): Allow-Events: talk, hold, conference, presence, dialog, 
line-seize, call-info, sla, include-session-description, presence.winfo, 
message-summary, refer
D/libpjsip( 5479): Session-Expires: 120;refresher=uac
D/libpjsip( 5479): Min-SE: 120
D/libpjsip( 5479): Content-Type: application/sdp
D/libpjsip( 5479): Content-Disposition: session
D/libpjsip( 5479): Content-Length: 315
D/libpjsip( 5479): Remote-Party-ID: "4000" 
<sip:4000@sip.xxx.net>;party=calling;privacy=off;screen=no
--------------------

later in the logs:
D/libpjsip( 5479): 20:34:45.195  inv0xa2c07064  ....Secure dialog requires SIPS 
scheme in Contact and Record-Route headers, ending the session

This must be a bug in CSipSimple. My config has not changed.
I'm using the latest version from playstore (for Android 5) plus CSipSimple 
Codec Pack.

Original comment by can.oezd...@gmail.com on 28 Nov 2014 at 7:51

GoogleCodeExporter commented 9 years ago
I think that the root problem comes with the fact the remote replies with :
Contact: <sip:4000@1.2.3.4:5061;transport=tls>
(which is not sips).

In this situation I suspect that pjsip guys added a protection so that 
subsequent requests remains in sips which is not what the remote requests.

I don't know if this protection is good or not. I'm still investigating. 
However, I guess that a configuration on sip server side could help in 
resolving the problem. Or, alternatively, not using "sips" scheme on csipsimple 
account configuration and just use TLS transport. Which would be coherent with 
what is replied by remote part in its 'contact' header. But obviously does not 
announce anymore that the sip is encrypted all the way toward the remote.

Original comment by r3gis...@gmail.com on 28 Nov 2014 at 9:29

GoogleCodeExporter commented 9 years ago
I circumvented the issue by following your advice:
I'm using the "sip" scheme (as standard-uri-scheme) now instead of the "sips" 
scheme for that account.
I'm forcing TLS protocol just like before.

I hope my change in the standard-uri-scheme has no security implications...
The change made the setup work again.

Original comment by can.oezd...@gmail.com on 29 Nov 2014 at 10:22

GoogleCodeExporter commented 9 years ago
Actually it might have some security implication. However, if you are confident 
in the fact the remote side also receive the call using tls the result should 
be the same in terms of how messages are transmited over network between 
csipsimple/ the server / the remote part.

If somebody here find out how to configure the sip server so that it respond to 
csipsimple with a "sips" contact instead of "sip", it would be welcome. Will 
probably help many people configuring their server.

At the beggining I thought that the message added in comment of this issue was 
produced by CSipSimple/pjsip (in which case would have been a bug in 
csipsimple). But if I correctly understand now, it's something received by the 
app and it seems that recent versions of the sip stack are more strict 
regarding what is received; and in that case, I'm not so sure it's a bug in the 
app but rather something not strict returned by remote side (or the server).

Original comment by r3gis...@gmail.com on 29 Nov 2014 at 2:35

GoogleCodeExporter commented 9 years ago
Issue 2840 has been merged into this issue.

Original comment by r3gis...@gmail.com on 30 Nov 2014 at 11:34

GoogleCodeExporter commented 9 years ago
Issue 2840 has been merged into this issue.

Original comment by r3gis...@gmail.com on 30 Nov 2014 at 11:59

GoogleCodeExporter commented 9 years ago
Issue 2840 has been merged into this issue.

Original comment by r3gis...@gmail.com on 30 Nov 2014 at 12:00

GoogleCodeExporter commented 9 years ago
TBD : allow disable_secure_dlg_check option from pjsip to be supported as it 
allows this weak situation to be considered as a valid one.
ref : https://trac.pjsip.org/repos/changeset/4899 

Original comment by r3gis...@gmail.com on 29 Dec 2014 at 6:15

GoogleCodeExporter commented 9 years ago

Original comment by r3gis...@gmail.com on 22 Jun 2015 at 11:31