Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated April 11, 2014, 9:27 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Committed in revision 412292 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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.
Olle E Johansson wrote:
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.)
Geert Van Pamel wrote:
So I understand that Olle proposes to create a new variable
${TELPHONECONTEXT} that contains the TEL URI phone-context which can be
either the global number, or a global number prefix, or the related routing
domain or any other unique routing identifier, or would be empty in case
there is just a local number (as specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable
${TELPHONECONTEXT} ?
Olle E Johansson wrote:
Just grep for SIPDOMAIN in the chan_sip source code :-)
Matt Jordan wrote:
So I'd hate for this patch to stall out on the channel variable - which
would be a very helpful addition but is not strictly necessary for Geert's
functionality.
Olle - what do you think if this goes in as is, and we add the
TELPHONECONTEXT channel variable in a subsequent patch? It should be
relatively trivial, and I don't mind helping Geert with that work (so long as
Geert is willing to test said patch, as I don't have anything that emulates
tel URIs handy).
Geert - what do you think?
Geert Van Pamel wrote:
Matt, I agree with you... the variable ${TELPHONECONTEXT} is indeed not
needed for TEL URI INVITE to work. Actually, I a uncertain how to implement
this variable. If anybody else can code the variable later, I am willing to
test it...
Matt Jordan wrote:
Geert - I can take a look at adding that variable in a subsequent patch.
I'll definitely need you to test it!
I'll confirm with Olle that he's okay with this - if so, we'll get this
committed.
wdoekes wrote:
That's a negative:
14:26 wdoekes whether we can ship it without the TELURICONTEXT var
14:26 @oej Did they get the channel variable?
14:26 wdoekes for another rainy day, it was said
14:28 @oej Why is that? Only sending incomplete information to the
dialplan is not a good implementation.
14:28 @oej It's a simple change, nothing much to discuss. Many examples
in the source code of chan_sip
14:29 @oej I guess I should have discussed this with Matt last week.
14:30 wdoekes not sure it's that trivial, since the info has to get
out of the parser functions: a bit of refactoring
14:31 @oej It can't be that hard. Ignoring it would be bad and an
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 22, 2014, 10:39 a.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.
Olle E Johansson wrote:
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.)
Geert Van Pamel wrote:
So I understand that Olle proposes to create a new variable
${TELPHONECONTEXT} that contains the TEL URI phone-context which can be
either the global number, or a global number prefix, or the related routing
domain or any other unique routing identifier, or would be empty in case
there is just a local number (as specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable
${TELPHONECONTEXT} ?
Olle E Johansson wrote:
Just grep for SIPDOMAIN in the chan_sip source code :-)
Matt Jordan wrote:
So I'd hate for this patch to stall out on the channel variable - which
would be a very helpful addition but is not strictly necessary for Geert's
functionality.
Olle - what do you think if this goes in as is, and we add the
TELPHONECONTEXT channel variable in a subsequent patch? It should be
relatively trivial, and I don't mind helping Geert with that work (so long as
Geert is willing to test said patch, as I don't have anything that emulates
tel URIs handy).
Geert - what do you think?
Geert Van Pamel wrote:
Matt, I agree with you... the variable ${TELPHONECONTEXT} is indeed not
needed for TEL URI INVITE to work. Actually, I a uncertain how to implement
this variable. If anybody else can code the variable later, I am willing to
test it...
Matt Jordan wrote:
Geert - I can take a look at adding that variable in a subsequent patch.
I'll definitely need you to test it!
I'll confirm with Olle that he's okay with this - if so, we'll get this
committed.
wdoekes wrote:
That's a negative:
14:26 wdoekes whether we can ship it without the TELURICONTEXT var
14:26 @oej Did they get the channel variable?
14:26 wdoekes for another rainy day, it was said
14:28 @oej Why is that? Only sending incomplete information to the
dialplan is not a good implementation.
14:28 @oej It's a simple change, nothing much to discuss. Many examples
in the source code of chan_sip
14:29 @oej I guess I should have discussed this with Matt last week.
14:30 wdoekes not sure it's that trivial, since the info has to get
out of the parser functions: a bit of refactoring
14:31 @oej It can't be that hard. Ignoring it would be bad and an
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 22, 2014, 3: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.
Olle E Johansson wrote:
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.)
Geert Van Pamel wrote:
So I understand that Olle proposes to create a new variable
${TELPHONECONTEXT} that contains the TEL URI phone-context which can be
either the global number, or a global number prefix, or the related routing
domain or any other unique routing identifier, or would be empty in case
there is just a local number (as specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable
${TELPHONECONTEXT} ?
Olle E Johansson wrote:
Just grep for SIPDOMAIN in the chan_sip source code :-)
Matt Jordan wrote:
So I'd hate for this patch to stall out on the channel variable - which
would be a very helpful addition but is not strictly necessary for Geert's
functionality.
Olle - what do you think if this goes in as is, and we add the
TELPHONECONTEXT channel variable in a subsequent patch? It should be
relatively trivial, and I don't mind helping Geert with that work (so long as
Geert is willing to test said patch, as I don't have anything that emulates
tel URIs handy).
Geert - what do you think?
Geert Van Pamel wrote:
Matt, I agree with you... the variable ${TELPHONECONTEXT} is indeed not
needed for TEL URI INVITE to work. Actually, I a uncertain how to implement
this variable. If anybody else can code the variable later, I am willing to
test it...
Matt Jordan wrote:
Geert - I can take a look at adding that variable in a subsequent patch.
I'll definitely need you to test it!
I'll confirm with Olle that he's okay with this - if so, we'll get this
committed.
That's a negative:
14:26 wdoekes whether we can ship it without the TELURICONTEXT var
14:26 @oej Did they get the channel variable?
14:26 wdoekes for another rainy day, it was said
14:28 @oej Why is that? Only sending incomplete information to the dialplan
is not a good implementation.
14:28 @oej It's a simple change, nothing much to discuss. Many examples in
the source code of chan_sip
14:29 @oej I guess I should have discussed this with Matt last week.
14:30 wdoekes not sure it's that trivial, since the info has to get out of
the parser functions: a bit of refactoring
14:31 @oej It can't be that hard. Ignoring it would be bad and an issue
report is on the mail in a very nearby future
14:31 @oej The
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 22, 2014, 10:39 a.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.
Olle E Johansson wrote:
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.)
Geert Van Pamel wrote:
So I understand that Olle proposes to create a new variable
${TELPHONECONTEXT} that contains the TEL URI phone-context which can be
either the global number, or a global number prefix, or the related routing
domain or any other unique routing identifier, or would be empty in case
there is just a local number (as specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable
${TELPHONECONTEXT} ?
Olle E Johansson wrote:
Just grep for SIPDOMAIN in the chan_sip source code :-)
Matt Jordan wrote:
So I'd hate for this patch to stall out on the channel variable - which
would be a very helpful addition but is not strictly necessary for Geert's
functionality.
Olle - what do you think if this goes in as is, and we add the
TELPHONECONTEXT channel variable in a subsequent patch? It should be
relatively trivial, and I don't mind helping Geert with that work (so long as
Geert is willing to test said patch, as I don't have anything that emulates
tel URIs handy).
Geert - what do you think?
Geert Van Pamel wrote:
Matt, I agree with you... the variable ${TELPHONECONTEXT} is indeed not
needed for TEL URI INVITE to work. Actually, I a uncertain how to implement
this variable. If anybody else can code the variable later, I am willing to
test it...
Matt Jordan wrote:
Geert - I can take a look at adding that variable in a subsequent patch.
I'll definitely need you to test it!
I'll confirm with Olle that he's okay with this - if so, we'll get this
committed.
wdoekes wrote:
That's a negative:
14:26 wdoekes whether we can ship it without the TELURICONTEXT var
14:26 @oej Did they get the channel variable?
14:26 wdoekes for another rainy day, it was said
14:28 @oej Why is that? Only sending incomplete information to the
dialplan is not a good implementation.
14:28 @oej It's a simple change, nothing much to discuss. Many examples
in the source code of chan_sip
14:29 @oej I guess I should have discussed this with Matt last week.
14:30 wdoekes not sure it's that trivial, since the info has to get
out of the parser functions: a bit of refactoring
14:31 @oej It can't be that hard. Ignoring it would be bad and an
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11559 --- Ship it! Either way, the variable will go in with this functionality into trunk - it's really just an order of operations problem. Let's ship it then and get it over with. - wdoekes On March 22, 2014, 1: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, 1: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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 22, 2014, 10:39 a.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.
Olle E Johansson wrote:
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.)
Geert Van Pamel wrote:
So I understand that Olle proposes to create a new variable
${TELPHONECONTEXT} that contains the TEL URI phone-context which can be
either the global number, or a global number prefix, or the related routing
domain or any other unique routing identifier, or would be empty in case
there is just a local number (as specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable
${TELPHONECONTEXT} ?
Olle E Johansson wrote:
Just grep for SIPDOMAIN in the chan_sip source code :-)
Matt Jordan wrote:
So I'd hate for this patch to stall out on the channel variable - which
would be a very helpful addition but is not strictly necessary for Geert's
functionality.
Olle - what do you think if this goes in as is, and we add the
TELPHONECONTEXT channel variable in a subsequent patch? It should be
relatively trivial, and I don't mind helping Geert with that work (so long as
Geert is willing to test said patch, as I don't have anything that emulates
tel URIs handy).
Geert - what do you think?
Geert Van Pamel wrote:
Matt, I agree with you... the variable ${TELPHONECONTEXT} is indeed not
needed for TEL URI INVITE to work. Actually, I a uncertain how to implement
this variable. If anybody else can code the variable later, I am willing to
test it...
Geert - I can take a look at adding that variable in a subsequent patch. I'll
definitely need you to test it!
I'll confirm with Olle that he's okay with this - if so, we'll get this
committed.
- Matt
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3349/#review11323
---
On March 22, 2014, 8:08 a.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, 8:08 a.m.)
Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt
Jordan, and wdoekes.
Bugs: ASTERISK-17179
https://issues.asterisk.org/jira/browse/ASTERISK-17179
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 22, 2014, 10:39 a.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.
Olle E Johansson wrote:
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.)
Geert Van Pamel wrote:
So I understand that Olle proposes to create a new variable
${TELPHONECONTEXT} that contains the TEL URI phone-context which can be
either the global number, or a global number prefix, or the related routing
domain or any other unique routing identifier, or would be empty in case
there is just a local number (as specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable
${TELPHONECONTEXT} ?
Olle E Johansson wrote:
Just grep for SIPDOMAIN in the chan_sip source code :-)
So I'd hate for this patch to stall out on the channel variable - which would
be a very helpful addition but is not strictly necessary for Geert's
functionality.
Olle - what do you think if this goes in as is, and we add the TELPHONECONTEXT
channel variable in a subsequent patch? It should be relatively trivial, and I
don't mind helping Geert with that work (so long as Geert is willing to test
said patch, as I don't have anything that emulates tel URIs handy).
Geert - what do you think?
- Matt
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3349/#review11323
---
On March 22, 2014, 8:08 a.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, 8:08 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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?
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.
- 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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.
Olle E Johansson wrote:
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.)
So I understand that Olle proposes to create a new variable ${TELPHONECONTEXT}
that contains the TEL URI phone-context which can be either the global number,
or a global number prefix, or the related routing domain or any other unique
routing identifier, or would be empty in case there is just a local number (as
specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable ${TELPHONECONTEXT} ?
- Geert
---
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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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.
Olle E Johansson wrote:
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.)
Geert Van Pamel wrote:
So I understand that Olle proposes to create a new variable
${TELPHONECONTEXT} that contains the TEL URI phone-context which can be
either the global number, or a global number prefix, or the related routing
domain or any other unique routing identifier, or would be empty in case
there is just a local number (as specified in RFC 3966).
Currently this variable is not available yet in Asterisk. In the dialplan
treating incoming calls currently I do not use nor do not need this
information, as the local number in ${CALLERID} is sufficient (for the time
being)... Still this phone context identifier could be needed for subsequent
outgoing calls (return calls, callbacks, etc.).
I agree that ${SIPDOMAIN} will remain reserved for SIP invites, and is
untouched for TEL URI invites.
I perfectly understand that this TEL URI context has nothing to do with
dialplan context.
Who could us further advise how to create the new variable
${TELPHONECONTEXT} ?
Just grep for SIPDOMAIN in the chan_sip source code :-)
- 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 21, 2014, 7:01 p.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 130 https://reviewboard.asterisk.org/r/3349/diff/7-8/?file=56285#file56285line130 This needs to blank both variables: userinfo = uri = ; Geert Van Pamel wrote: We return the local number anyway when an incoming RFC 3966 TEL URI INVITE call does not contain a global number nor a phone-context. Corey Farrell wrote: First sentence of 3rd paragraph of section 5.1.5: Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity. Note the word MUST, this has specific meaning in RFC's. I will not approve this review if it's going to contradict the RFC it's claiming to implement. Olle E Johansson wrote: You have to be strict in what you send, but open for receiving stuff that doesn't always follow the RFC. We can add an option that sets strictness. I haven't seen many implementations of Tel: uri's sadly, but many of the few did not follow the RFC. Corey Farrell wrote: If that is the case then should we not return error = -1? As for optional strictness maybe use sip_settings.pedanticsipchecking? Geert Van Pamel wrote: I do return both the local number, and throw the error -1: ast_debug(1, No RFC 3966 global number or context found in '%s'; returning local number anyway\n, uri); userinfo = uri; /* Return local number anyway */ error = -1; This would take care of both alerting the non RFC-compliance, and allowing some openness for receiving stuff that doesn't follow strictly the RFC... No, please do not add more to the pedantic variable. - Olle E --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11314 --- 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 21, 2014, 6:01 p.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 130 https://reviewboard.asterisk.org/r/3349/diff/7-8/?file=56285#file56285line130 This needs to blank both variables: userinfo = uri = ; Geert Van Pamel wrote: We return the local number anyway when an incoming RFC 3966 TEL URI INVITE call does not contain a global number nor a phone-context. Corey Farrell wrote: First sentence of 3rd paragraph of section 5.1.5: Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity. Note the word MUST, this has specific meaning in RFC's. I will not approve this review if it's going to contradict the RFC it's claiming to implement. Olle E Johansson wrote: You have to be strict in what you send, but open for receiving stuff that doesn't always follow the RFC. We can add an option that sets strictness. I haven't seen many implementations of Tel: uri's sadly, but many of the few did not follow the RFC. Corey Farrell wrote: If that is the case then should we not return error = -1? As for optional strictness maybe use sip_settings.pedanticsipchecking? Geert Van Pamel wrote: I do return both the local number, and throw the error -1: ast_debug(1, No RFC 3966 global number or context found in '%s'; returning local number anyway\n, uri); userinfo = uri; /* Return local number anyway */ error = -1; This would take care of both alerting the non RFC-compliance, and allowing some openness for receiving stuff that doesn't follow strictly the RFC... Olle E Johansson wrote: No, please do not add more to the pedantic variable. Indeed, don't touch the pedantic var, and don't create new variables. Being generous in what you accept is what we do in the rest of chan_sip anyway. - wdoekes --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11314 --- On March 22, 2014, 1: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, 1: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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11335 --- Ship it! Ship It! - Corey Farrell On March 22, 2014, 9:08 a.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, 9:08 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 21, 2014, 2:01 p.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 130 https://reviewboard.asterisk.org/r/3349/diff/7-8/?file=56285#file56285line130 This needs to blank both variables: userinfo = uri = ; Geert Van Pamel wrote: We return the local number anyway when an incoming RFC 3966 TEL URI INVITE call does not contain a global number nor a phone-context. Corey Farrell wrote: First sentence of 3rd paragraph of section 5.1.5: Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity. Note the word MUST, this has specific meaning in RFC's. I will not approve this review if it's going to contradict the RFC it's claiming to implement. Olle E Johansson wrote: You have to be strict in what you send, but open for receiving stuff that doesn't always follow the RFC. We can add an option that sets strictness. I haven't seen many implementations of Tel: uri's sadly, but many of the few did not follow the RFC. Corey Farrell wrote: If that is the case then should we not return error = -1? As for optional strictness maybe use sip_settings.pedanticsipchecking? Geert Van Pamel wrote: I do return both the local number, and throw the error -1: ast_debug(1, No RFC 3966 global number or context found in '%s'; returning local number anyway\n, uri); userinfo = uri; /* Return local number anyway */ error = -1; This would take care of both alerting the non RFC-compliance, and allowing some openness for receiving stuff that doesn't follow strictly the RFC... Olle E Johansson wrote: No, please do not add more to the pedantic variable. wdoekes wrote: Indeed, don't touch the pedantic var, and don't create new variables. Being generous in what you accept is what we do in the rest of chan_sip anyway. Thanks for correcting/clarifying this for me. My concerns are addressed. - Corey --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11314 --- On March 22, 2014, 9:08 a.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, 9:08 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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... So it ends up in the SIPDOMAIN variable in the dial plan? It has to be reachable in the dial plan somehow. - 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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.
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?
- Geert
---
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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- 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. Changes --- When an incoming RFC 3966 TEL URI INVITE call does not contain a global number nor a phone-context, we still return the local number, but we issue a warning message. This could incur that local calls could be possible, but outgoing return calls might fail because there might be no route to the (original) caller. 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11323 --- I don't see what happens with the phone-context argument. Shouldn't we pass that on as a channel variable? - Olle E Johansson 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 21, 2014, 7:01 p.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 130 https://reviewboard.asterisk.org/r/3349/diff/7-8/?file=56285#file56285line130 This needs to blank both variables: userinfo = uri = ; Geert Van Pamel wrote: We return the local number anyway when an incoming RFC 3966 TEL URI INVITE call does not contain a global number nor a phone-context. Corey Farrell wrote: First sentence of 3rd paragraph of section 5.1.5: Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity. Note the word MUST, this has specific meaning in RFC's. I will not approve this review if it's going to contradict the RFC it's claiming to implement. You have to be strict in what you send, but open for receiving stuff that doesn't always follow the RFC. We can add an option that sets strictness. I haven't seen many implementations of Tel: uri's sadly, but many of the few did not follow the RFC. - Olle E --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11314 --- 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 21, 2014, 2:01 p.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 130 https://reviewboard.asterisk.org/r/3349/diff/7-8/?file=56285#file56285line130 This needs to blank both variables: userinfo = uri = ; Geert Van Pamel wrote: We return the local number anyway when an incoming RFC 3966 TEL URI INVITE call does not contain a global number nor a phone-context. Corey Farrell wrote: First sentence of 3rd paragraph of section 5.1.5: Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity. Note the word MUST, this has specific meaning in RFC's. I will not approve this review if it's going to contradict the RFC it's claiming to implement. Olle E Johansson wrote: You have to be strict in what you send, but open for receiving stuff that doesn't always follow the RFC. We can add an option that sets strictness. I haven't seen many implementations of Tel: uri's sadly, but many of the few did not follow the RFC. If that is the case then should we not return error = -1? As for optional strictness maybe use sip_settings.pedanticsipchecking? - Corey --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11314 --- On March 22, 2014, 9:08 a.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, 9:08 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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? We return this into the hostport. - Geert --- 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
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. 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... - Geert --- 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 15, 2014, 7:04 p.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 111 https://reviewboard.asterisk.org/r/3349/diff/3/?file=56070#file56070line111 scheme is the input parameter listing acceptable schemes, we don't need to see it here. The other ast_debug included scheme since the problem was a failure to match the uri with any scheme. I fixed this - Geert --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11227 --- 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 21, 2014, 8:32 a.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Return userinfo when RFC 3966 does not include neither global number, nor context. In this case hostport will not be available. Avoid NULL string reference segmentation fault by adding explicit test (userinfo != NULL) before strstr test. The function strstr cannot handle NULL strings. 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 21, 2014, 6:05 a.m., Corey Farrell wrote:
/trunk/channels/sip/reqresp_parser.c, line 131
https://reviewboard.asterisk.org/r/3349/diff/7/?file=56285#file56285line131
I'm getting a segfault with the test tel:911. userinfo == NULL
causes strchr to segfault on Ubuntu x86_64 (eglibc 2.17). I believe we
need to add:
userinfo = uri = ;
blank userinfo to prevent the segfault, blank uri to prevent 911 from
being returned in residue.
Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
32 ../sysdeps/x86_64/multiarch/../strchr.S: No such file or
directory.
(gdb) bt full
#0 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
No locals.
#1 0x7fff88f2e52a in parse_uri_full (uri=0x7fffb7d4 911,
scheme=0x7fff88f5661e sip:,sips:,tel:, user=0x7fffb7a0,
pass=0x7fffb7a8, hostport=0x7fffb7b0, params=0x7fffb730,
headers=0x7fffb728, residue=0x0) at sip/reqresp_parser.c:149
userinfo = 0x0
parameters = 0x0
endparams = 0x0
c = 0x0
error = -1
teluri_scheme = 1
__PRETTY_FUNCTION__ = parse_uri_full
#2 0x7fff88f2f90e in parse_uri (uri=0x7fffb7d0 tel:911,
scheme=0x7fff88f5661e sip:,sips:,tel:, user=0x7fffb7a0,
pass=0x7fffb7a8, hostport=0x7fffb7b0, transport=0x7fffb7b8)
at sip/reqresp_parser.c:524
ret = -1
headers = 0x7fff88f55f57
params = {transport = 0x7fff88f55f57 , user = 0x7fff88f55f57
, method = 0x29e88f55f57 Address 0x29e88f55f57 out of bounds,
ttl = 0x7fff88f583a0 __PRETTY_FUNCTION__.27916
sip_parse_uri_test, maddr = 0x7fff88f55e24 sip/reqresp_parser.c, lr =
-1997185193}
Return userinfo when RFC 3966 does not include neither global number, nor
context.
In this case hostport will not be available.
Avoid NULL string reference segmentation fault by adding explicit test
(userinfo != NULL) before strstr test.
- Geert
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3349/#review11312
---
On March 21, 2014, 8:32 a.m., Geert Van Pamel wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3349/
---
(Updated March 21, 2014, 8:32 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11314 --- /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20959 This needs to blank both variables: userinfo = uri = ; /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20958 This is not needed, your error code path was the only one that didn't set userinfo. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20960 !ast_strlen_zero(name) was correct. - Corey Farrell On March 21, 2014, 3:32 a.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 21, 2014, 3:32 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11291 --- /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20917 What happened to residue and params.transport? We really should test expected results for parameters after phone-context. This would ensure the code does what is expected now, and that future changes do not cause unexpected changes. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20913 This name is exposed through asterisk CLI, so say don't change it (especially since this has nothing to do with your change). If you want to cleanup test names that should be a separate review, and cleanup all chan_sip test names. I'm not sure anyone will want to bother changing the names, it is of little benefit and could possibly break someone's test script. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20918 Why change this from !ast_strlen_zero(name)? - Corey Farrell On March 19, 2014, 5:01 a.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 19, 2014, 5:01 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 20, 2014, 10:59 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- * Enhanced the description of the TEL URI parameter parsing algorithm * Corrected regression tests: - Added a 3rd (complex) TEL URI invite with parameters and headers - Rolled back to test case name sip_uri_parse_test - Rolled back to ast_strlen_zero check on invalid TEL URI check 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 20, 2014, 7:37 a.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 525 https://reviewboard.asterisk.org/r/3349/diff/6/?file=56222#file56222line525 This name is exposed through asterisk CLI, so say don't change it (especially since this has nothing to do with your change). If you want to cleanup test names that should be a separate review, and cleanup all chan_sip test names. I'm not sure anyone will want to bother changing the names, it is of little benefit and could possibly break someone's test script. Rolled back to test case name sip_uri_parse_test. Although it looks strange to me because the function is named sip_parse_uri_test? On March 20, 2014, 7:37 a.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, line 653 https://reviewboard.asterisk.org/r/3349/diff/6/?file=56222#file56222line653 Why change this from !ast_strlen_zero(name)? Rolled back to my previous change. On March 20, 2014, 7:37 a.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, lines 411-419 https://reviewboard.asterisk.org/r/3349/diff/6/?file=56222#file56222line411 What happened to residue and params.transport? We really should test expected results for parameters after phone-context. This would ensure the code does what is expected now, and that future changes do not cause unexpected changes. Added a 3rd (complex) TEL URI invite with parameters and headers. Documented clearly that currently the ext= or isub= parameters remain unparsed; but should be further parsed from userinfo when the RFC 3966 will be fully implemented (with ISDN or PSTN local extensions). - Geert --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11291 --- On March 20, 2014, 10:59 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 20, 2014, 10:59 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3349/#review11312
---
/trunk/channels/sip/reqresp_parser.c
https://reviewboard.asterisk.org/r/3349/#comment20956
I'm getting a segfault with the test tel:911. userinfo == NULL causes
strchr to segfault on Ubuntu x86_64 (eglibc 2.17). I believe we need to add:
userinfo = uri = ;
blank userinfo to prevent the segfault, blank uri to prevent 911 from
being returned in residue.
Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
32 ../sysdeps/x86_64/multiarch/../strchr.S: No such file or directory.
(gdb) bt full
#0 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
No locals.
#1 0x7fff88f2e52a in parse_uri_full (uri=0x7fffb7d4 911,
scheme=0x7fff88f5661e sip:,sips:,tel:, user=0x7fffb7a0,
pass=0x7fffb7a8, hostport=0x7fffb7b0, params=0x7fffb730,
headers=0x7fffb728, residue=0x0) at sip/reqresp_parser.c:149
userinfo = 0x0
parameters = 0x0
endparams = 0x0
c = 0x0
error = -1
teluri_scheme = 1
__PRETTY_FUNCTION__ = parse_uri_full
#2 0x7fff88f2f90e in parse_uri (uri=0x7fffb7d0 tel:911,
scheme=0x7fff88f5661e sip:,sips:,tel:, user=0x7fffb7a0,
pass=0x7fffb7a8, hostport=0x7fffb7b0, transport=0x7fffb7b8)
at sip/reqresp_parser.c:524
ret = -1
headers = 0x7fff88f55f57
params = {transport = 0x7fff88f55f57 , user = 0x7fff88f55f57 ,
method = 0x29e88f55f57 Address 0x29e88f55f57 out of bounds,
ttl = 0x7fff88f583a0 __PRETTY_FUNCTION__.27916
sip_parse_uri_test, maddr = 0x7fff88f55e24 sip/reqresp_parser.c, lr =
-1997185193}
- Corey Farrell
On March 20, 2014, 5:59 p.m., Geert Van Pamel wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3349/
---
(Updated March 20, 2014, 5:59 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 19, 2014, 10:01 a.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- parse_uri_full: do not quote RFC 3966 - only referring; corrected multi-line comment format. AST_TEST_DEFINE: Corrected sip_parse_uri_full_test (added missing tel: schema). Corrected sip_parse_uri_test: testing results. 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11268 --- Ship it! The changes make me happy. - wdoekes On March 17, 2014, 7:01 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 17, 2014, 7:01 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11266 --- /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20894 Link to the RFC is fine, I'd say don't quote the syntax. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20896 Please follow the same format as the first comment in this procedure for multiline comments. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20895 You are checking for the wrong result from parse_uri, this will still fail. You should give the tests a try, ./configure --enable-dev-mode, then enable TEST_FRAMEWORK in 'make menuselect'. In asterisk CLI run: test execute category /channels/chan_sip/ - Corey Farrell On March 17, 2014, 3:01 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 17, 2014, 3:01 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11241 --- /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20876 I don't like it that we skip past the parameters. If we have: tel:123;param1=X;phone-context=Y;param2=Z Then *parameters will lose out on param1. Lose the uri=c+15. - wdoekes On March 15, 2014, 10:02 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 10:02 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 17, 2014, 8:39 a.m., wdoekes wrote: /trunk/channels/sip/reqresp_parser.c, lines 100-105 https://reviewboard.asterisk.org/r/3349/diff/4/?file=56142#file56142line100 I don't like it that we skip past the parameters. If we have: tel:123;param1=X;phone-context=Y;param2=Z Then *parameters will lose out on param1. Lose the uri=c+15. But obviously that would break because of the *c='\0'. In that case: - does the tel uri ever get any parameters other than ;phone-context? - if it doesn't, I'd rather drop all parameters than only take those that come *before* the phone-context. I don't mind a shortcut in this case, but at least the source should clearly document what we're silently ignoring. - wdoekes --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11241 --- On March 15, 2014, 10:02 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 10:02 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 17, 2014, 8:01 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Moved the test section for invalid TEL URI to sip_uri_parse_test (solving the remark from Corey). Parameters before ;phone-context= will currently make part of *userinfo. Normally they will be only used for local dialling (i.e. ;isub= or ;ext= are used for ISDN or PSTN subaddressing). All other parameters should be encoded after the ;phone-context= parameter, to arrive into *parameters. We believe that RFC 3966 has been implemented correctly. For more info, see http://www.ietf.org/rfc/rfc3966.txt 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 17, 2014, 9:39 a.m., wdoekes wrote: /trunk/channels/sip/reqresp_parser.c, lines 100-105 https://reviewboard.asterisk.org/r/3349/diff/4/?file=56142#file56142line100 I don't like it that we skip past the parameters. If we have: tel:123;param1=X;phone-context=Y;param2=Z Then *parameters will lose out on param1. Lose the uri=c+15. wdoekes wrote: But obviously that would break because of the *c='\0'. In that case: - does the tel uri ever get any parameters other than ;phone-context? - if it doesn't, I'd rather drop all parameters than only take those that come *before* the phone-context. I don't mind a shortcut in this case, but at least the source should clearly document what we're silently ignoring. Parameters before ;phone-context= will currently make part of *userinfo. Normally they will be only used for local dialling (i.e. ;isub= or ;ext= are used for ISDN or PSTN subaddressing). All other parameters should be encoded after the ;phone-context= parameter, to arrive into *parameters. We believe that RFC 3966 has been implemented correctly. For more info, see http://www.ietf.org/rfc/rfc3966.txt - Geert --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11241 --- On March 17, 2014, 8:01 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 17, 2014, 8:01 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
On March 17, 2014, 3:43 a.m., Corey Farrell wrote: /trunk/channels/sip/reqresp_parser.c, lines 422-433 https://reviewboard.asterisk.org/r/3349/diff/4/?file=56142#file56142line422 This will cause sip_uri_full_parse_test to fail, as the test loop requires non-error result from all tests. Currently all tests for expected failures are in sip_uri_parse_test. Moved the test section for invalid TEL URI to sip_uri_parse_test (solving the remark from Corey). - Geert --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11237 --- On March 17, 2014, 8:01 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 17, 2014, 8:01 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11236 --- Ship it! Ship It! - Paul Belanger On March 15, 2014, 10:02 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 10:02 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11237 --- /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20865 This will cause sip_uri_full_parse_test to fail, as the test loop requires non-error result from all tests. Currently all tests for expected failures are in sip_uri_parse_test. - Corey Farrell On March 15, 2014, 6:02 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 6:02 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 1:12 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Implemented remarks from Corey and Jonathan. How to ship it? 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 1:42 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Typing error in error message 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11228 --- /trunk/channels/chan_sip.c https://reviewboard.asterisk.org/r/3349/#comment20860 space between t and + since you are here. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20861 might be worth adding a unit test for this code path. Something like tel:911 - Paul Belanger On March 15, 2014, 12:42 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 12:42 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11227 --- Ship it! One very minor tweak, this looks good. Geert you had asked about how to ship it. The general agreement is we wait atleast 24 hours to commit after Ship It. So if nobody objects by Monday afternoon I will commit this to trunk. I know 24 hours would be this afternoon but this is chan_sip, so I'm giving it longer. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20859 scheme is the input parameter listing acceptable schemes, we don't need to see it here. The other ast_debug included scheme since the problem was a failure to match the uri with any scheme. - Corey Farrell On March 15, 2014, 8:42 a.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 8:42 a.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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 11:02 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Corrected remarks from Paul and Corey 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 (updated) - /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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 13, 2014, 7:41 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Correct reference to JIRA + Reviewer asterisk-dev group 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
