> On March 22, 2014, 4:39 p.m., Olle E Johansson wrote:
> > I don't see what happens with the phone-context argument. Shouldn't we pass
> > that on as a channel variable?
>
> Geert Van Pamel wrote:
> We return this into the hostport.
>
> Geert Van Pamel wrote:
> According to RFC 3966 phone-context is either a domain-name, or (part of)
> an international telephone number (indicated with +prefix).
> It is used by a gateway to know how to dial the "local" number... the
> local number must be unique within its context...
>
> Olle E Johansson wrote:
> So it ends up in the SIPDOMAIN variable in the dial plan? It has to be
> reachable in the dial plan somehow.
>
> Geert Van Pamel wrote:
> The variable ${SIPDOMAIN} contains the local IP address of the Asterisk
> server.
> The userinfo arrives in ${CALLERID} and is displayed on the display of
> the called device, and arrives in the CDR file.
> Actually I do not know into which variable the incoming hostport info is
> copied to?
> Could somebody else answer this question?
>
> Olle E Johansson wrote:
> If I place a normal call to sip:ge...@example.com to my Asterisk server.
> "geert" will be the extension I'm looking for, "example.com" ends up in
> SIPDOMAIN. It's not the local IP address, it's the domain/host part of the
> request URI in the INVITE.
>
> I would prefer if phone context ended up in TELPHONECONTEXT so I could
> use it the same way as SIPDOMAIN in the dial plan. It should not end up in
> SIPDOMAIN as it is not a SIP uri. That way an extension in a local context
> can be routed differently than an extension in a global context.
Just to make sure it's documented: The phone-context should NOT be matched to a
context in the dial plan. From a security standpoint, that would be horrific.
We need the information to be able to route correctly in the dial plan, but no
automatic selection. (I am not suggesting you where going down that path,
Geert. Just wanted to close that way of thinking since the word "context" could
lead there.)
- Olle E
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3349/#review11323
-----------------------------------------------------------
On March 22, 2014, 2:08 p.m., Geert Van Pamel wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3349/
> -----------------------------------------------------------
>
> (Updated March 22, 2014, 2:08 p.m.)
>
>
> Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt
> Jordan, and wdoekes.
>
>
> Bugs: ASTERISK-17179
> https://issues.asterisk.org/jira/browse/ASTERISK-17179
>
>
> Repository: Asterisk
>
>
> Description
> -------
>
> Implements RFC-3966 TEL URI incoming INVITE.
>
> See https://issues.asterisk.org/jira/browse/ASTERISK-17179 for a description
> of the original isssue.
>
> I have been patching all versions since Asterisk 1.6. I would like to include
> the code into the main trunk for version 13.
>
> Previously Asterisk was failing with error on incoming IMS call:
>
> Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: From address
> missing 'sip:', using it anyway
>
> Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a
> SIP header (tel:0987654321;phone-context=+32987654321)?
>
> Reason: tel: protocol was not recognized.
>
>
> Diffs
> -----
>
> /trunk/channels/sip/reqresp_parser.c 410429
> /trunk/channels/chan_sip.c 410429
>
> Diff: https://reviewboard.asterisk.org/r/3349/diff/
>
>
> Testing
> -------
>
> Executed an incoming TEL URI INVITE connection.
> CLI was present on the display and in the CDR file.
> No errors on SIP debug output.
>
>
> File Attachments
> ----------------
>
> RFC-3966 tel URI patch
>
> https://reviewboard.asterisk.org/media/uploaded/files/2014/03/13/cad7a996-88c1-47fe-a2a9-cc6987af3b75__rfc-3966-tel-uri-patch-diff.txt
>
>
> Thanks,
>
> Geert Van Pamel
>
>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
