Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
Issue 2840 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 30 Nov 2014 at 11:34
Issue 2840 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 30 Nov 2014 at 11:59
Issue 2840 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 30 Nov 2014 at 12:00
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
Original comment by r3gis...@gmail.com
on 22 Jun 2015 at 11:31
Original issue reported on code.google.com by
barrymercer
on 18 Sep 2014 at 11:34