I have an ITSP we are trying to work with that has an "Unusual" way of
working, but that said my understanding of their behaviour is that it
is fully RFC compliant. Can someone suggest how I might be able to
interoperate under these circumstances:
We register fine with them, and send the default asterisk Contact: header of:
Contact: <sip:s...@x.x.x.x>
This then causes ALL calls from the ITSP inbound to us to be addressed:
INVITE sip:s...@x.x.x.x:5060;transport=udp SIP/2.0
To: <sip:44123456...@x.x.x.x:5060;transport=udp>
[other headers omitted]
In fact, whatever we send in the Contact: header is reflected in the
INVITE for inbound calls, and the actual number dialled is always
placed in the To: header. What 99.9% of our ITSPs would send is:
INVITE sip:44123456...@x.x.x.x:5060;transport=udp SIP/2.0
To: <sip:44123456...@x.x.x.x:5060;transport=udp>
[other headers omitted]
As you can see, the correct destination number is placed into the
INVITE header AND the To: header, and Asterisk routes it correctly
based on the INVITE.
My questions:
- Is there a way of telling chan_sip to register with multiple
Contact: headers in the registration request, so that all of the
acceptable DDI numbers can be presented to the ITSP (This is what the
RFC seems to suggest is the "correct" way to operate.)
- Alternatively, has anyone encountered this previously, and perhaps
created an "s" extension that then digs into the To: header, and
routes according to that? Examples, workarounds and solutions are all
welcome!
Help?
Thanks,
Steve
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
