Hi all. I am having an issue with calls not being routed correctly in our freeswitch system and I am having trouble figuring out the real cause. We are using the following in our routing plan to determine the number being called on an incoming call, which seems pretty straight forward: <condition break="never"> <action inline="true" application="set" data="dest_num=${destination_number}"/> <action inline="true" application="set" data="did_num=0"/> </condition> Generally speaking it works fine - we have been in production for years now doing many millions of calls. But an issue has cropped up with a call that comes in and is not being routed properly. Below is the SIP INVITE and header we receive (sanitized to protect the guilty). You will note that the INVITE has 15615551234 which is the correct DID on our system being called. However the "To" header specifies 14145241234 which if I understand what I read, is apparently what the caller dialed and it was diverted to our DID. Since my system never heard of 14145241234, it routed it to our default "Not in Service" message. In discussing with my carrier, they are saying its being delivered correctly and my system must be setup improperly for this situation. Since I never heard of the diversion header before this, I am at a bit of a loss (even after reading some articles on it). I thought I had a pretty good handle on this stuff but this is throwing me for a loop as it seems to me that the "To" should have been rewritten on the far end B2BUA (or somewhere before it got to me) to be the same as the INVITE but apparently not? I am trying to figure out what would be the most failsafe variable to use if destination_number is not it (as its what I see in all the FS Doc examples and elsewhere). Seems the INVITE is the only place the real number exists in this situation. I am searching for what that variable would be correct as the Channel Variables docs don't contain a lot of descriptions. I am thinking perhaps it should be sip_req_user? Since it's a production box, I figured I should ask the experts rather than guess on my own and make people grumpy due to some other unintended consequence I don't realize. I appreciate any help/explanation you can/are willing to provide. Thanks! Rick Ewart Session Initiation Protocol (INVITE) Request-Line: INVITE sip:15615551234@123.123.41.36:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 68.232.9.155:5060;branch=z9hG4bK0cB87133736bc4b79bd From: "ABC COMPANY" <sip:15615554162@68.232.9.155>;tag=gK0c5693cd To: <sip:14145241234@123.123.41.36> Call-ID: 191660912_117119432@68.232.9.155 CSeq: 271179 INVITE Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,OPTIONS Accept: application/sdp Contact: "ABC COMPANY" <sip:15615554162@68.232.9.155:5060> Remote-Party-ID: "ABC COMPANY" <sip:15615554162@68.232.9.155:5060>;privacy=off Diversion: <sip:+1414524123@68.232.9.155:5060>;privacy=off;screen=no;reason=unknown;c ounter=1 Supported: replaces Content-Length: 281 Content-Disposition: session; handling=required Content-Type: application/sdp