[asterisk-dev] IAX support for SIP URI as called number

[Olle E. Johansson]

30 aug 2012 kl. 15:05 skrev "Matthew  Jordan" <mjordan at digium.com>:

> 
> 
> ----- Original Message -----
>> From: "Alec Davis" <sivad.a at paradise.net.nz>
>> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
>> Sent: Wednesday, August 29, 2012 11:25:57 PM
>> Subject: [asterisk-dev] IAX support for SIP URI as called number
>> 
>> Just implemented distributed call queues using jabber, and
>> sucessfully
>> distributing device state.
>> With the queue making calls to the remote site over an IAX trunk, but
>> having
>> to use the remote extension number.
>> 
>> queues.conf:
>> ...
>> member => IAX2/server2/8819,0,Test User,SIP/XYZ9000
>> 
>> But the IAX protocol should be able to handle a SIP URI in the
>> CALLED_NUMBER
>> 
>> http://www.rfc-editor.org/rfc/rfc5456.txt
>> 8.6.1.  CALLED NUMBER
>>   The purpose of the CALLED NUMBER information element ...
>>   ...It is possible for a number or extension to include non-numeric
>> characters.  The CALLED
>>   NUMBER IE MAY contain a SIP URI, [RFC3261] or a URI in any other
>>   format.  The ability to serve a CALLED NUMBER is server dependent.
>> 
>> So we should be able to have
>> queues.conf:
>> ...
>> member => IAX2/server2/sip:XYZ9000,0,Test User,SIP/XYZ9000
>> 
>> The first and easy change is in parse_dial_string to look for a ':'in
>> the
>> exten.
>> The other side yet to determine.
>> 
>> The question is. Do we want it?
>> Am I barking up the wrong tree.
>> 
> 
> Well, it'd certainly be interesting.  If you're going to make chan_iax2
> able to parse a SIP URI, you'll probably want to look at using the
> parsing routines in reqresp_parser, rather than rolling anything new.
> Since those are already exposed by reqresp_parser.h, that should keep
> the cross-pollination between chan_iax2 and chan_sip to a minimum - but
> it does feel a little odd to have chan_iax2 including things from
> chan_sip.
> 
> That being said, it sounds like there's no reason why the CALLED NUMBER
> can't be any dial string ("URI in any other format" is rather vague) - so
> this may not have to be SIP specific.

There's a reason that I pushed Mark to make IAX2 Unicode :-)

But we have a greater architecture issue. How do we handle syntaxes
like extension at context that we have in many places - and various parameters 
to SIP uris?

tel:123123123 is a valid SIP uri. sips:oej at edvina.net;transport=tcp is another.

If we go down this path, it's going to be rocky. I've spent many cycles on it,
but have more questions than answers. A first small thing would be to add
domain to the called/caller ID structures and funcitons to set caller ID domains
and handle domains in the dialplan somehow. 

Like  I call Digium's PBX from oej at edvina.net - the caller ID has to remain
oej at edvina.net on the other side regardless if there's an IAX2 trunk in between.
Today that doesn't work without serious hacks in the dialplan and some external 
patches.

/O
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2307 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120830/4b6c51e2/attachment.bin>