asterisk users - Apr 2009 - SIP Registration and INVITE question

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 at x.x.x.x>

This then causes ALL calls from the ITSP inbound to us to be addressed:

     INVITE sip:s at x.x.x.x:5060;transport=udp SIP/2.0
     To: <sip:44123456789 at 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:44123456789 at x.x.x.x:5060;transport=udp SIP/2.0
     To: <sip:44123456789 at 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

Have you looked at the syntax of register => keyword ?

register => [transport://]user[:secret[:authuser]]@host[:port][/extension]
; If no extension is given, the 's' extension is used.

There you have it ... Contact: <sip:s ....

set the extension and you should be fine

Martin

On Mon, Apr 6, 2009 at 7:45 AM, Steve Davies <davies147 at gmail.com>
wrote:
> 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 at x.x.x.x>
>
> This then causes ALL calls from the ITSP inbound to us to be addressed:
>
> ? ? INVITE sip:s at x.x.x.x:5060;transport=udp SIP/2.0
> ? ? To: <sip:44123456789 at 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:44123456789 at x.x.x.x:5060;transport=udp SIP/2.0
> ? ? To: <sip:44123456789 at 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
>