[Freeswitch-users] Sofia invite issues

Kurtis Heimerl kheimerl at cs.berkeley.edu
Sun Jun 12 23:55:27 MSD 2011 

Just so the robots catch this, Peter was exactly right, and this
resolved the issue.

Thanks!

On Thu, Jun 9, 2011 at 11:54 PM, Peter Olsson
<peter.olsson at visionutveckling.se> wrote:
> In that case, just add the cidr stuff to the global acl "domain" (acl.conf.xml under autoload_configs), this is used by default by the sofia internal profile, or create a new acl the the profile uses.
>
> Something like;
>      <node type="allow" cidr="192.168.1.0/24"/>
>      <node type="allow" cidr="127.0.0.1/32"/>
>
> This will make all calls from these IP's just to pass in. They won't be detected as any user, so the original From will be used when bridging the outgoing call.
>
> /Peter
>
>
> -----Ursprungligt meddelande-----
> Från: freeswitch-users-bounces at lists.freeswitch.org [mailto:freeswitch-users-bounces at lists.freeswitch.org] För Kurtis Heimerl
> Skickat: den 10 juni 2011 05:29
> Till: FreeSWITCH Users Help
> Ämne: Re: [Freeswitch-users] Sofia invite issues
>
> I think you're right. Thanks! Removing IMSI641104278340883 from that
> domain caused FS to fall back to the previous user, 1301.
>
> Unfortunately, I can't lets the agents auth, or use different IPs, all
> are coming from the same application that doesn't support auth.
>
> I'm going to try adding each to their own unique domain, hopefully
> that'll help. It might not though, considering they're all coming from
> the same IP.
>
> Do you have any other idea how to fix this?
>
> On Thu, Jun 9, 2011 at 1:55 PM, Peter Olsson
> <peter.olsson at visionutveckling.se> wrote:
>> I'm guessing your problem might be related to the fact that you use the cidr attribute on the user's - with the same IP's for all of them. If I understand these correctly (never used it this way myself) they're supposed to be used to authenticate a user for a specific IP, instead of challenge auth, and since the same IP is provided for all of them they might overwrite eachother, and the last one will be the one it matches.
>>
>> Also, read more on http://wiki.freeswitch.org/wiki/Acl#Users.
>>
>> Try removing the cidr attribute, and let the agents auth instead, or use different IP's for the users.
>>
>> /Peter
>> ________________________________________
>> Från: freeswitch-users-bounces at lists.freeswitch.org [freeswitch-users-bounces at lists.freeswitch.org] f&#246;r Kurtis Heimerl [kheimerl at cs.berkeley.edu]
>> Skickat: den 9 juni 2011 22:21
>> Till: FreeSWITCH Users Help
>> Ämne: Re: [Freeswitch-users] Sofia invite issues
>>
>> Here you go: http://pastebin.freeswitch.org/16468
>>
>> For this packet trace I decided to have profile "C" in the UA
>> directory. This causes FS to send the second invite (which should be
>> A->B) as C->B, rather than B->B, as it does if that UA is not present.
>>  Neither is correct, this just makes it a little easier to grep.
>>
>> User 1302 first appears in that invite, I don't see any other log
>> items talking about 1302 at all. It's worth noting that 1302's user
>> name (IMSI641104878332498) DOES appear in the SDP packet loaded in the
>> first (A->B) invite, but I'm pretty certain FS should not be using
>> that information for SIP addressing. Again, if I remove user
>> IMSI641104878332498 from the directory, FS just switched to returning
>> with user 1301, it doesn't fix the issue.
>>
>> It's very likely I'm massaging some code that's not commonly used, as
>> I may be making a small mistake here or there in the original SIP
>> invite. These two lines:
>> 2011-06-09 13:11:32.947157 [DEBUG] sofia.c:6674 IP 192.168.1.144
>> Approved by acl "domains[IMSI641104878332498 at 192.168.1.144]". Access
>> Granted.
>> 2011-06-09 13:11:32.947157 [DEBUG] sofia.c:6803 Authenticating user
>> IMSI641104878332498 at 192.168.1.144
>> Are particularly curious. I'm not sure if those are a response to the
>> incoming invite (which would be incorrect) or not. It should be
>> approving user 1300 at 192.168.1.144, if anyone.
>>
>> Thanks!
>>
>> On Thu, Jun 9, 2011 at 12:18 AM, Peter Olsson
>> <peter.olsson at visionutveckling.se> wrote:
>>> Please pastebin a complete debug log, with "sofia global siptrace on", to http://pastebin.freeswitch.org.
>>>
>>> I'm pretty sure this is not a bug in FS, if it was, we would have lots of people complaining...
>>>
>>> /Peter
>>>
>>>
>>> -----Ursprungligt meddelande-----
>>> Från: freeswitch-users-bounces at lists.freeswitch.org [mailto:freeswitch-users-bounces at lists.freeswitch.org] För Kurtis Heimerl
>>> Skickat: den 8 juni 2011 23:32
>>> Till: freeswitch-users at lists.freeswitch.org
>>> Ämne: [Freeswitch-users] Sofia invite issues
>>>
>>> Hello Freeswitch-users!
>>>
>>> I'm currently writing a SIP middlebox that intercepts sip messages and
>>> changes their username. The reasons for this are complicated and
>>> somewhat outside of the scope of this discussion. However, I've come
>>> upon a very strange issue: when making a phone-to-phone call across
>>> freeswitch; it is connecting the wrong user. I'm fairly well convinced
>>> this is a bug, but I thought I'd send the issue here and see if it's
>>> anything I'm obviously doing wrong.
>>>
>>> Basically, FS sees a SIP message from a registered UA (call it A)
>>> inviting another registered user to a call (B). This is acked
>>> correctly (a TRYING message). FS then responds by inviting B into a
>>> call with some OTHER user C. C is not mentioned at any point in the
>>> initial SIP messages (as verified by wireshark). Even more strangely,
>>> if I remove user C from FS (by removing their config file) FS responds
>>> to the invite by inviting B into a call with itself. In each case, the
>>> appropriate from header in the invite should be the original caller A.
>>>  It's worth noting that I am not monkeying with the RTP packets at
>>> all, but my understanding is that SIP signalling shouldn't be affected
>>> by that.
>>>
>>> My general guess is that I'm messing up the naming somehow, and FS is
>>> running an algorithm to guess at who the call originator is. However,
>>> the naming must be roughly correct; Asterisk is able to handle this
>>> call just fine. I've included a sip trace of the second situation (A
>>> calls B, FS invites B to a call with itself)
>>>
>>> For the record A:1300
>>> B:1301
>>> C:IMSI641104878332498
>>>
>>> REGISTER MESSAGE (Which works fine)
>>>
>>> REGISTER sip:192.168.1.144 SIP/2.0
>>> Via: SIP/2.0/UDP 192.168.1.144:5063;branch=z9hG4bK13347
>>> Via: SIP/2.0/UDP 192.168.1.144:5063;branch=z9hG4bK13347
>>> From: 1300 <sip:1300 at 192.168.1.144>;tag=ftoui
>>> To: 1300 <sip:1300 at 192.168.1.144>
>>> Call-ID: 1032827938 at 192.168.1.144
>>> CSeq: 91 REGISTER
>>> Contact: <sip:1300 at 192.168.1.144:5063>;expires=7200
>>> Max-Forwards: 70
>>> Content-Length: 0
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP 192.168.1.144:5063;branch=z9hG4bK13347
>>> Via: SIP/2.0/UDP 192.168.1.144:5063;branch=z9hG4bK13347
>>> From: 1300 <sip:1300 at 192.168.1.144>;tag=ftoui
>>> To: 1300 <sip:1300 at 192.168.1.144>;tag=jU64NXypQc57F
>>> Call-ID: 1032827938 at 192.168.1.144
>>> CSeq: 91 REGISTER
>>> Contact: <sip:1300 at 192.168.1.144:5063>;expires=7200
>>> Date: Wed, 08 Jun 2011 21:02:04 GMT
>>> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-71d64e6 2011-06-07 22-30-16 -0700
>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>>> Supported: timer, precondition, path, replaces
>>> Content-Length: 0
>>>
>>> SIP TRACE (A -> B, B -> B response)
>>>
>>> INITIAL INVITE
>>> INVITE sip:1301 at 192.168.1.144 SIP/2.0
>>> Via: SIP/2.0/UDP 192.168.1.144:5063;branch=z9hG4bK77974
>>> From: 1300 <sip:1300 at 192.168.1.144>;tag=bgdqx
>>> To: <sip:1301 at 192.168.1.144>
>>> Call-ID: 1817795092 at 192.168.1.144
>>> CSeq: 485 INVITE
>>> Contact: <sip:1300 at 192.168.1.144:5063>;expires=3600
>>> Content-Type: application/sdp
>>> Max-Forwards: 70
>>> Content-Length: 143
>>>
>>> INVITE ACK
>>> SIP/2.0 100 Trying
>>> Via: SIP/2.0/UDP 192.168.1.144:5063;branch=z9hG4bK77974
>>> From: 1300 <sip:1300 at 192.168.1.144>;tag=bgdqx
>>> To: <sip:1301 at 192.168.1.144>
>>> Call-ID: 1817795092 at 192.168.1.144
>>> CSeq: 485 INVITE
>>> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-71d64e6 2011-06-07 22-30-16 -0700
>>> Content-Length: 0
>>>
>>> FS INVITE (Note the from address being wrong)
>>> INVITE sip:1301 at 192.168.1.144:5063 SIP/2.0
>>> Via: SIP/2.0/UDP 192.168.1.144;rport;branch=z9hG4bKeeQvcyZ70SDUg
>>> Max-Forwards: 69
>>> From: "1301" <sip:1301 at 192.168.1.144>;tag=rHyS0Z3B61arN
>>> To: <sip:1301 at 192.168.1.144:5063>
>>> Call-ID: 84df47f9-0cb7-122f-13b5-5cff350d9de5
>>> CSeq: 13447852 INVITE
>>> Contact: <sip:mod_sofia at 192.168.1.144:5060>
>>> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-71d64e6 2011-06-07 22-30-16 -0700
>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>>> Supported: timer, precondition, path, replaces
>>> Allow-Events: talk, hold, presence, dialog, line-seize, call-info,
>>> sla, include-session-description, presence.winfo, message-summary,
>>> refer
>>> Content-Type: application/sdp
>>> Content-Disposition: session
>>> Content-Length: 315
>>> X-FS-Support: update_display
>>> Remote-Party-ID: "1301"
>>> <sip:1301 at 192.168.1.144>;party=calling;screen=yes;privacy=off
>>>
>>> USER CONFIGURATIONS
>>>
>>> 1300.xml
>>> <include>
>>>  <user id="1300" cidr="192.168.1.0/24,127.0.0.1/32">
>>>    <params>
>>>      <param name="accept-blind-reg" value="true"/>
>>>      <param name="accept-blind-auth" value="true"/>
>>>      <param name="vm-password" value="1000"/>
>>>    </params>
>>>    <variables>
>>>      <variable name="toll_allow" value="domestic,international,local"/>
>>>      <variable name="accountcode" value="1300"/>
>>>      <variable name="user_context" value="default"/>
>>>      <variable name="effective_caller_id_name" value="1300"/>
>>>      <variable name="effective_caller_id_number" value="1300"/>
>>>      <variable name="outbound_caller_id_name" value="1300"/>
>>>      <variable name="outbound_caller_id_number" value="1300"/>
>>>      <variable name="callgroup" value="techsupport"/>
>>>    </variables>
>>>  </user>
>>> </include>
>>>
>>> 1301.xml
>>> <include>
>>>  <user id="1301" cidr="192.168.1.0/24,127.0.0.1/32">
>>>    <params>
>>>      <param name="accept-blind-reg" value="true"/>
>>>      <param name="accept-blind-auth" value="true"/>
>>>      <param name="vm-password" value="1000"/>
>>>    </params>
>>>    <variables>
>>>      <variable name="toll_allow" value="domestic,international,local"/>
>>>      <variable name="accountcode" value="1301"/>
>>>      <variable name="user_context" value="default"/>
>>>      <variable name="effective_caller_id_name" value="1301"/>
>>>      <variable name="effective_caller_id_number" value="1301"/>
>>>      <variable name="outbound_caller_id_name" value="1301"/>
>>>      <variable name="outbound_caller_id_number" value="1301"/>
>>>      <variable name="callgroup" value="techsupport"/>
>>>    </variables>
>>>  </user>
>>> </include>
>>>
>>> IMSI641104878332498.xml
>>> <include>
>>>  <user id="IMSI641104878332498" cidr="192.168.1.0/24,127.0.0.1/32"
>>> number-alias="1302">
>>>    <params>
>>>      <param name="accept-blind-reg" value="true"/>
>>>      <param name="accept-blind-auth" value="true"/>
>>>      <param name="vm-password" value="1000"/>
>>>    </params>
>>>    <variables>
>>>      <variable name="toll_allow" value="domestic,international,local"/>
>>>      <variable name="accountcode" value="1302"/>
>>>      <variable name="user_context" value="default"/>
>>>      <variable name="effective_caller_id_name" value="IMSI641104878332498"/>
>>>      <variable name="effective_caller_id_number" value="1302"/>
>>>      <variable name="outbound_caller_id_name" value="IMSI641104878332498"/>
>>>      <variable name="outbound_caller_id_number" value="1302"/>
>>>      <variable name="callgroup" value="techsupport"/>
>>>    </variables>
>>>  </user>
>>> </include>
>>>
>>> DIALPLAN
>>>
>>>    <extension name="Local Numbers">
>>>      <condition field="destination_number" expression="^130[0-9]$">
>>>        <!--<action application="bridge"
>>> data="user/${user_data(${destination_number}@${domain_name} attr
>>> id)}"/> -->
>>>        <action application="bridge" data="user/${destination_number}"/>
>>>      </condition>
>>>    </extension>
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
> !DSPAM:4df1916532761203114732!
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>

More information about the FreeSWITCH-users mailing list