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@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@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Kurtis Heimerl [kheimerl@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@192.168.1.144]". Access Granted. 2011-06-09 13:11:32.947157 [DEBUG] sofia.c:6803 Authenticating user IMSI641104878332498@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@192.168.1.144, if anyone.
Thanks!
On Thu, Jun 9, 2011 at 12:18 AM, Peter Olsson <peter.olsson@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@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] För Kurtis Heimerl Skickat: den 8 juni 2011 23:32 Till: freeswitch-users@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@192.168.1.144>;tag=ftoui To: 1300 <sip:1300@192.168.1.144> Call-ID: 1032827938@192.168.1.144 CSeq: 91 REGISTER Contact: <sip:1300@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@192.168.1.144>;tag=ftoui To: 1300 <sip:1300@192.168.1.144>;tag=jU64NXypQc57F Call-ID: 1032827938@192.168.1.144 CSeq: 91 REGISTER Contact: <sip:1300@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@192.168.1.144 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.144:5063;branch=z9hG4bK77974 From: 1300 <sip:1300@192.168.1.144>;tag=bgdqx To: <sip:1301@192.168.1.144> Call-ID: 1817795092@192.168.1.144 CSeq: 485 INVITE Contact: <sip:1300@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@192.168.1.144>;tag=bgdqx To: <sip:1301@192.168.1.144> Call-ID: 1817795092@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@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@192.168.1.144>;tag=rHyS0Z3B61arN To: <sip:1301@192.168.1.144:5063> Call-ID: 84df47f9-0cb7-122f-13b5-5cff350d9de5 CSeq: 13447852 INVITE Contact: <sip:mod_sofia@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@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@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@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@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:4df12cbe32761899399581!
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org