I'm sorry in advance that I am not posting tcpdump packets. It's 11:20 and I'm tired.<br>
<div><br></div><div>I have a strange issue.</div><div><br></div><div>Scenario:</div><div><br></div><div>A has DID A</div><div>B has DID B</div><div><br></div><div>Both A and B reside on the same UAS. HOWEVER, when A calls B using DID B - the call should be routed to the carrier (and it comes right back in - but that's how it's supposed to work so please just accept this part crazy as it seems - yes you literally are being charged per minute to calls to your own DIDs...).</div>
<div><br></div><div>A calls DID B</div><div><br></div><div>We send a packet to carrier - it has FROM domain = THEIR domain (not ours) for a special reason. This part is fine but please remember it.</div><div><br></div><div>
Carrier sends us an INVITE for DID B - their packet has the FROM domain = OUR domain.</div><div><br></div><div>bork.</div><div><br></div><div>They don't know about our domain. It's a fake domain. It doesn't exist. Ping it and it wouldn't resolve. There's no way they could have our domain information EXCEPT that in the outbound packet, in the Call-ID header - our DOMAIN is listed as part of the Call-ID string (consisten with RFC3261 - I checked).</div>
<div><br></div><div>WHY would they change the FROM domain #1</div><div><br></div><div>HOW do they even find out about the FROM domain unless they specifically expect the Call-ID field to be formatted string@domain per the RFC (and not all CALL-ID fields are formatted this way)?</div>
<div><br></div><div>Has anyone ever seen anything like this?</div><div><br></div><div>In order for "is_from_local" to FAIL - I need their FROM domain NOT to be us. Otherwise we try to authenticate them - but we shouldn't be.</div>