[asterisk-users] SIP Registration and INVITE question

[Steve Davies]

Thanks for the reply - Perhaps I was not clear.

On the register=> line, if I set /extension to be /12345, then this
just replaces 's' with 12345, and ALL calls, regardless of their
destination number will be routed on the INVITE line to 12345 at x.x.x.x,
and the actual destination is specified in the To: header.

Not particularly useful, and I'd prefer not to have to go fumbling
through the SIP headers to find what was really dialled :)

Looking at the SIP RFC, the idea is that you specify a set of "What I
will accept" details with each registration in the Contact: headers,
which is intended to include _multiple_ possible destination
addresses. The Registrar will then only ever send calls addressed to
that list of destinations. Sadly, the RFC authors did not think to
consider private point-to-point links where you can usefully say "send
me anything, you know best". Asterisk "fills" by defaulting to a
single s at x.x.x.x, where the 's' can be replaced by any single number.

Most ITSPs work around this by assuming that they know best, and
routing numbers even if they are missing from the registration. The
odd exception does not do this.

I suspect that the solution will be to register with a /extension of
/pedanticitsp, and then have a dialplan which pulls and parses the SIP
To: header. Other suggestions are still welcome.

Regards,
Steve

2009/4/6 Martin <asterisklist at callthem.info>:
> 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
>>
>
> _______________________________________________
> -- 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
>