[asterisk-dev] SIP Secure and Annouced Transfert Asterisk 1.8Trunk.
Alec Davis
sivad.a at paradise.net.nz
Wed Feb 23 16:18:04 CST 2011
Yes the patch bug18837.diff3.txt at
https://issues.asterisk.org/view.php?id=18837 does address the deadlock
issue.
I responded to your initial email as you posted the deadlock file
transferts-bug-lock.txt on https://issues.asterisk.org/view.php?id=18468
which has the same deadlock as in bug report 18837.
Others: I'm now happy with the revised patch 'diff3', Please test and
comment, and hopefully approve.
Alec Davis
> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
> Bernard Merindol(F)
> Sent: Wednesday, 23 February 2011 6:04 a.m.
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] SIP Secure and Annouced Transfert
> Asterisk 1.8Trunk.
>
> Good Morning,
>
> your patch is on deadlock issue ?
>
> In SIPS with branch version don't have deadlock but have no
> media from C to A.
>
> I think is an encryption problem .
>
> This problem is very blocking for me, is not possible to
> deploy my new project.
>
> Best regards
> Bernard
>
>
> On 21 févr. 2011, at 19:12, Alec Davis wrote:
>
> > Bernard: Please check bug
> > https://issues.asterisk.org/view.php?id=18837
> > There you will find bug18837.diff2.txt
> >
> > Others: Please review the patch and comment. It's tested and works,
> > but I don't actually like the unlock and relock of the
> 'pvt' that I've
> > done around the call to 'transmit_reinvite_with_sdp'().
> >
> > It's a simple deadlock between
> > === Thread ID: -1292625008 (do_monitor started at [24470] chan_sip.c
> > restart_monitor())
> > === ---> Lock #0 (chan_sip.c): MUTEX 23964
> handle_request_do &netlock
> > 0xb6796e80 (1) === ---> Lock #1 (channel.c): MUTEX 6211
> > ast_do_masquerade channels
> > 0x8d4e0c8 (1)
> > === ---> Lock #2 (channel.c): MUTEX 6214 ast_do_masquerade original
> > 0xbd98f48 (1)
> > === ---> Lock #3 (channel.c): MUTEX 6234 ast_do_masquerade
> clonechan
> > 0xb24bf7d0 (1) === ---> Waiting for Lock #4 (chan_sip.c):
> MUTEX 6164
> > sip_fixup p 0xb24bab10
> > (1)
> > === --- ---> Locked Here: chan_sip.c line 27632 (sip_set_rtp_peer)
> >
> > ===
> > -------------------------------------------------------------------
> > ===
> > === Thread ID: -1315861616 (pbx_thread started at [ 5035] pbx.c
> > ast_pbx_start())
> > === ---> Lock #0 (chan_sip.c): MUTEX 27632 sip_set_rtp_peer p
> > 0xb24bab10 (1) === ---> Waiting for Lock #1 (pbx.c): MUTEX 9467
> > pbx_builtin_getvar_helper chan 0xb24bf7d0 (1) === --- ---> Locked
> > Here: channel.c line 6234 (ast_do_masquerade)
> >
> > Alec Davis
> >
> >> -----Original Message-----
> >> From: asterisk-dev-bounces at lists.digium.com
> >> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf
> Of Bernard
> >> Merindol(F)
> >> Sent: Tuesday, 22 February 2011 6:09 a.m.
> >> To: Asterisk Mailing List Developers
> >> Subject: [asterisk-dev] SIP Secure and Annouced Transfert Asterisk
> >> 1.8 Trunk.
> >>
> >> Hi All,
> >>
> >> I continue to test Asterisk 1.8 for announced Transfert.
> >>
> >> I works with the Trunk version
> >>
> >> Connected to Asterisk SVN-trunk-r308371 currently running on
> >> c3devsecure
> >>
> >> For normal SIP I have a work around for announced transfert, if I
> >> configure all phones without directmedia
> >> (directmedia=no) the announced transfert works fine. With direct
> >> media not works see
> >>
> >> https://issues.asterisk.org/view.php?id=18468
> >>
> >> But, if I test the same configuration with SIPS and SRTP the
> >> announced transfert not works The tree phones is configured with
> >> encryption=yes directmedia=no transport=tls
> >>
> >> A Call B
> >> B Annouce to C
> >> When B finish Transfert, the channels is connected between
> A to C but
> >> the RTP (SRTP in this case) is not works or works only
> beetwen A to
> >> C. Newer audio form C to A.
> >>
> >> On full we see :
> >>
> >> [Feb 21 17:54:47] DEBUG[15231] chan_sip.c: Sip
> >> transfer:-------------------- [Feb 21 17:54:47] DEBUG[15231]
> >> chan_sip.c: -- Transferer to PBX channel:
> SIP/1001-0000004b State Up
> >> [Feb 21 17:54:47] DEBUG[15231] chan_sip.c: -- Transferer to PBX
> >> second channel (target): SIP/1001-0000004c State Up [Feb
> 21 17:54:47]
> >> DEBUG[15231] chan_sip.c: -- Bridged call to transferee:
> >> SIP/1000-0000004a State Up [Feb
> >> 21 17:54:47] DEBUG[15231] chan_sip.c: -- Bridged call to transfer
> >> target: SIP/1002-0000004d State Up [Feb 21 17:54:47] DEBUG[15231]
> >> chan_sip.c: -- END Sip transfer:--------------------
> >>
> >>
> >> [Feb 21 17:54:47] WARNING[15703] res_srtp.c: SRTP unprotect:
> >> authentication failure [Feb 21 17:54:47] WARNING[15703]
> >> res_srtp.c: SRTP unprotect: authentication failure
> >>
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: SIP response 200 to
> >> RE-invite on outgoing call
> >> 474496ed441d4f0636c4e0c410f10ffe at 192.168.169.60:5061
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing
> session-level
> >> SDP v=0... UNSUPPORTED.
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing
> session-level
> >> SDP o=MxSIP 0 1 IN IP4 192.168.169.211... UNSUPPORTED.
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing
> session-level
> >> SDP s=SIP Call... UNSUPPORTED.
> >> [Feb 21 17:54:47] DEBUG[15227] netsock2.c: Splitting
> >> '192.168.169.211' gives...
> >> [Feb 21 17:54:47] DEBUG[15227] netsock2.c: ...host
> '192.168.169.211'
> >> and port '(null)'.
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing
> session-level
> >> SDP c=IN IP4 192.168.169.211... OK.
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing
> session-level
> >> SDP t=0 0... UNSUPPORTED.
> >> [Feb 21 17:54:47] VERBOSE[15227] chan_sip.c: [Feb 21
> 17:54:47] Found
> >> RTP audio format 8 [Feb 21 17:54:47] DEBUG[15227] rtp_engine.c:
> >> Setting payload 8 based on m type on 0xb50b8fdc [Feb 21 17:54:47]
> >> VERBOSE[15227] chan_sip.c:
> >> [Feb 21 17:54:47] Found RTP audio format 101 [Feb 21 17:54:47]
> >> DEBUG[15227] rtp_engine.c: Setting payload 101 based on m type on
> >> 0xb50b8fdc [Feb 21 17:54:47] VERBOSE[15227] chan_sip.c: [Feb 21
> >> 17:54:47] Found audio description format PCMA for ID 8 [Feb 21
> >> 17:54:47] DEBUG[15227] chan_sip.c: Processing media-level
> (audio) SDP
> >> a=rtpmap:8 PCMA/8000... OK.
> >> [Feb 21 17:54:47] VERBOSE[15227] chan_sip.c: [Feb 21
> 17:54:47] Found
> >> audio description format telephone-event for ID 101 [Feb
> 21 17:54:47]
> >> DEBUG[15227] chan_sip.c: Processing media-level (audio) SDP
> >> a=rtpmap:101 telephone-event/8000... OK.
> >> [Feb 21 17:54:47] DEBUG[15227] res_srtp.c: Policy already
> exists, not
> >> re-adding [Feb 21 17:54:47] WARNING[15227]
> >> sip/sdp_crypto.c: Could not set local SRTP policy [Feb 21
> 17:54:47]
> >> DEBUG[15227] chan_sip.c: Processing media-level
> >> (audio) SDP a=crypto:1 AES_CM_128_HMAC_SHA1_80
> >> inline:SkxXKDBrRzh1YzchbUZnKTk8a1RKUmEjfDNNUWAo... UNSUPPORTED.
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing media-level
> >> (audio) SDP a=fmtp:101 0-15... UNSUPPORTED.
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing media-level
> >> (audio) SDP a=ptime:20... OK.
> >> [Feb 21 17:54:47] DEBUG[15227] chan_sip.c: Processing media-level
> >> (audio) SDP a=sendrecv... OK.
> >>
> >>
> >> [Feb 21 17:54:59] WARNING[15703] res_srtp.c: SRTP unprotect:
> >> authentication failure [Feb 21 17:54:59] WARNING[15703]
> >> res_srtp.c: SRTP unprotect: authentication failure [Feb 21
> 17:54:59]
> >> WARNING[15703] res_srtp.c: SRTP unprotect:
> >> authentication failure [Feb 21 17:54:59] WARNING[15703]
> >> res_srtp.c: SRTP unprotect: authentication failure [Feb 21
> 17:54:59]
> >> WARNING[15703] res_srtp.c: SRTP unprotect:
> >> authentication failure [Feb 21 17:54:59] WARNING[15703]
> >> res_srtp.c: SRTP unprotect: authentication failure [Feb 21
> 17:54:59]
> >> WARNING[15703] res_srtp.c: SRTP unprotect:
> >> authentication failure [Feb 21 17:54:59] WARNING[15703]
> >> res_srtp.c: SRTP unprotect: authentication failure [Feb 21
> 17:54:59]
> >> WARNING[15703] res_srtp.c: SRTP unprotect:
> >> authentication failure
> >>
> >>
> >> I search to get the old version with asterisk 1.6 to tes
> but the svn
> >> not works
> >>
> >> svn co
> >> http://svn.digium.com/svn/asterisk/team/group/srtp_reboot/
> >> asterisk-srtp
> >> svn: URL
> >> 'http://svn.digium.com/svn/asterisk/team/group/srtp_reboot'
> >> doesn't exist
> >>
> >> Thank for your help.
> >>
> >> Best regards
> >> Bernard Merindol
> >>
> >>
> >>
> >> --
> >>
> _____________________________________________________________________
> >> -- Bandwidth and Colocation Provided by
> http://www.api-digital.com --
> >>
> >> asterisk-dev mailing list
> >> To UNSUBSCRIBE or update options visit:
> >> http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> >
> > --
> >
> _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by
> http://www.api-digital.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-dev
mailing list