ice_mismatch, but direct connection can be establish

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for answer.
You are right, I have found this in
http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#section-15
I see that ICE can work via TSL, but this is not deal.

But I can not understand this position of authors of ICE standard:

  "Unfortunately, many ALG are known to work poorly in these corner
   cases.  ICE does not try to work around broken ALGs, as this is
   outside the scope of its functionality.  ICE can help diagnose these
   conditions, which often show up as a mismatch between the set of
   candidates and the m and c lines and rtcp attributes.  The ice-
   mismatch attribute is used for this purpose."

ICE can work, why not allow this?
I think many SIP providers modifies the SDP, probably for better compatibility.

What can do? I propose to add option in pjsua, for disable address
check. I can not see problems and security issues that can be here.
Also ICE in draft currently.

Something like this:
pjsua_media_config media_cfg;
media_cfg.ice_address_check = PJ_TRUE | PJ_FALSE;


2011/9/21 Benny Prijono <bennylp at teluu.com>:
> Hi,
>
> If you see the IP address in the c= line (212.53.40.77) and port
> number in the SDP m= line (25684), they are not mentioned as any of
> the candidates, and that's what caused the ICE mismatch condition. I
> assume your server modifies the SDP? So despite the possibility that
> connectivity may be possible, unfortunately ICE spec says that we
> should not continue the negotiation because of this.
>
> Best regards,
> ?Benny
>
> On Wed, Sep 21, 2011 at 3:38 PM, Dmitry (MicroSIP) <info at microsip.org.ua> wrote:
>> I have a situation, where transport_ice.c works incorrectly or I do
>> something wrong?
>>
>> In my network exists a route to direct connection between sip clients.
>> - ICE is enabled.
>> - STUN is disabled
>>
>>
>> PC1(2 IPs: 192.168.11.6, 10.119.191.2) ? ? ? PC2(1 IP: 192.168.1.3)
>> 192.168.11.0/24 ---------[router]-------------------- 192.168.1.0/24
>> -------------[NAT]-------------Internet1-------------------SIP
>> Registrar
>> 10.119.191.0/24----------[NAT]-------------Internet2--------------------------------------------------------------------------------------SIP
>> Registrar
>>
>> Possible ICE route is:192.168.11.6 <-----> 192.168.1.3
>>
>> But transport_ice.c ?make sdp_state->ice_mismatch = PJ_TRUE; so there
>> are no attempts to check candidates.
>>
>> With modified transport_ice.c code (forsed ice_mismatch into false)
>> and voice traffic goes directly without mediagateway! So it is realy
>> possible.
>> Please look into it.
>>
>> I have read https://trac.pjsip.org/repos/wiki/IceNegotiationFailure
>> but there is no information about ice_mismatch.
>>
>> Benny said that transport_ice.c is ok, but what in now ok ???
>>
>>
>>
>> =======original code===========================================
>>
>> ?/* Check matched component count and ice_mismatch */
>> ? ?if (comp1_found && (tp_ice->comp_cnt==1 || !has_rtcp)) {
>> ? ?sdp_state->match_comp_cnt = 1;
>> ? ?sdp_state->ice_mismatch = PJ_FALSE;
>> ? ?} else if (comp1_found && comp2_found) {
>> ? ?sdp_state->match_comp_cnt = 2;
>> ? ?sdp_state->ice_mismatch = PJ_FALSE;
>> ? ?} else {
>> ? ?sdp_state->match_comp_cnt = (tp_ice->comp_cnt > 1 && has_rtcp)? 2 : 1;
>> ? ?sdp_state->ice_mismatch = PJ_TRUE;
>> ? ?}
>>
>> ==========my code==========================================
>>
>> ?/* Check matched component count and ice_mismatch */
>> ? ?if (comp1_found && (tp_ice->comp_cnt==1 || !has_rtcp)) {
>> ? ?sdp_state->match_comp_cnt = 1;
>> ? ?sdp_state->ice_mismatch = PJ_FALSE;
>> ? ?} else if (comp1_found && comp2_found) {
>> ? ?sdp_state->match_comp_cnt = 2;
>> ? ?sdp_state->ice_mismatch = PJ_FALSE;
>> ? ?} else {
>> ? ?sdp_state->match_comp_cnt = (tp_ice->comp_cnt > 1 && has_rtcp)? 2 : 1;
>> ? ?if (!comp2_found)
>> ? ?{
>> ? ? ? ?sdp_state->ice_mismatch = PJ_TRUE;
>> ? ?} else
>> ? ?{
>> ? ? ? ?sdp_state->ice_mismatch = PJ_FALSE;
>> ? ?}
>> ? ?}
>> ======================================================
>>
>>
>> ?02:43:43.828 ? pjsua_core.c ?RX 1924 bytes Request msg
>> INVITE/cseq=19859 (rdata00C69CCC) from UDP 212.53.40.40:5060:
>> INVITE sip:mmmmmmmmmmmm at 192.168.1.3:5060;ob SIP/2.0
>> Via: SIP/2.0/UDP
>> 212.53.40.40:5060;branch=z9hG4bK199210-kmbdctp;cgp=etc.tario.ru;rport
>> P-Asserted-Identity: <sip:ccccccccccccccc at sipnet.ru>
>> P-CGP-Redirector: mmmmmmmmmmmm at sipnet.ru
>> Record-Route: <sip:212.53.40.40:5060;lr>
>> Record-Route: <sip:192.168.40.77:5060;lr>
>> Record-Route: <sip:rev.5662709-192.168.40.77.dialog.cgatepro;lr>
>> Via: SIP/2.0/TCP
>> 10.119.191.2:2256;rport=2256;branch=z9hG4bKPj1d9f93bc29f04fbdb5c5908fccefba91;received=193.151.105.53
>> Record-Route: <sip:tcp-193.151.105.53-2256C192.168.40.77.nat.cgatepro;lr>
>> Max-Forwards: 69
>> From: <sip:ccccccccccccccc@xxxxxxxxx>;tag=408f214a3958484f9b1b8a8f91837bd3
>> To: <sip:mmmmmmmmmmmm at sipnet.ru>
>> Call-ID: e47485b7c61949f8a144d1405a8c32db
>> Contact: <sip:ccccccccccccccc at 10.119.191.2:5060;ob>;+sip.ice
>> CSeq: 19859 INVITE
>> Supported: replaces,100rel,timer,norefersub
>> Allow: PRACK,INVITE,ACK,BYE,CANCEL,UPDATE,SUBSCRIBE,NOTIFY,REFER,MESSAGE,OPTIONS
>> User-Agent: PJSIP/2.0.0-alpha-svn (win32) MicroSIP/1.7.2
>> Session-Expires: 1800
>> Min-SE: 90
>> Content-Type: application/sdp
>> Content-Length: 833
>>
>>
>> v=0
>> o=- 3525561821 3525561821 IN IP4 10.119.191.2
>> s=pjmedia
>> c=IN IP4 212.53.40.77
>> t=0 0
>> a=mediagateway:etc.tario.ru:5662709:192.168.40.77
>> a=X-nat:0
>> m=audio 25684 RTP/AVP 98 97 99 104 3 0 8 9 96
>> c=IN IP4 212.53.40.77
>> a=rtpmap:98 speex/16000
>> a=rtpmap:97 speex/8000
>> a=rtpmap:99 speex/32000
>> a=rtpmap:104 iLBC/8000
>> a=fmtp:104 mode=30
>> a=rtpmap:3 GSM/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:9 G722/8000
>> a=rtpmap:96 telephone-event/8000
>> a=fmtp:96 0-15
>> a=sendrecv
>> a=candidate:Ha77bf02 1 UDP 2130706431 10.119.191.2 3234 typ host
>> a=candidate:Hc0a80b06 1 UDP 2130706431 192.168.11.6 3234 typ host
>> a=candidate:Ha77bf02 2 UDP 2130706430 10.119.191.2 3238 typ host
>> a=candidate:Hc0a80b06 2 UDP 2130706430 192.168.11.6 3238 typ host
>> a=ice-pwd:18074614
>> a=ice-ufrag:651945de
>> a=rtcp:3238 IN IP4 10.119.191.2
>>
>> ======================================================
>>
>> comp1_found 0
>> comp2_found 1
>> has_rtcp 1
>> => sdp_state->ice_mismatch = PJ_TRUE;
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux