Re: [asterisk-dev] [Code Review] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-02-12 Thread Matt Jordan 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/
---

(Updated Feb. 12, 2015, 2:33 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Committed in revision 431717


Bugs: ASTERISK-24015 and ASTERISK-24703
https://issues.asterisk.org/jira/browse/ASTERISK-24015
https://issues.asterisk.org/jira/browse/ASTERISK-24703


Repository: Asterisk


Description
---

This patch adds a new feature to ARI to redirect a channel to another server, 
and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With 
this, a channel in a Stasis application can be redirected to another endpoint 
of the same underlying channel technology.

- Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
'transfer' was always kind of a bad name. If the channel isn't answered, we 
aren't transferring, we're forwarding. If it is answered, the type of transfer 
being performed is somewhat vague - is it blind? Is it attended? 'redirect' - 
while also a slightly loaded term - is a bit more generic and yet descriptive 
of what is happening: we're redirecting the channel to somewhere else. 
Answered, not answered, it doesn't matter: your channel is no good here!

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP 
stack:
(1) The existing .transfer channel callback had the limitation that it could 
only transfer channels to a SIP URI, i.e., you had to pass 
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
still supported, it is somewhat unintuitive - particularly in a world full of 
endpoints. As such, we now also support specifying the PJSIP endpoint to 
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by 
updating its Contact header. Alas, that resulted in the forwarding destination 
set by the dialplan application/ARI resource/whatever being rewritten with very 
incorrect information. Hence, we now don't bother updating an outgoing response 
if it is a 302. Since this took a looong time to find, some additional debug 
statements have been added to those modules that update the Contact headers.


Diffs
-

  /branches/13/rest-api/api-docs/channels.json 430839 
  /branches/13/res/stasis/control.c 430839 
  /branches/13/res/res_pjsip_transport_websocket.c 430839 
  /branches/13/res/res_pjsip_nat.c 430839 
  /branches/13/res/res_pjsip_multihomed.c 430839 
  /branches/13/res/res_ari_channels.c 430839 
  /branches/13/res/ari/resource_channels.c 430839 
  /branches/13/res/ari/resource_channels.h 430839 
  /branches/13/include/asterisk/stasis_app.h 430839 
  /branches/13/channels/chan_pjsip.c 430839 

Diff: https://reviewboard.asterisk.org/r/4316/diff/


Testing
---

Tests were written both for the PJSIP stack as well as the new ARI operation. 
See https://reviewboard.asterisk.org/r/4352.


Thanks,

Matt Jordan

-- 
_
-- 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] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-21 Thread Mark Michelson 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14263
---

Ship it!


The code changes look good to me. The only additional comments I have are
1) CHANGES should be updated to indicate that the Transfer() dialplan function 
for PJSIP can now refer to endpoints. CHANGES should also be updated to 
indicate the addition of the /redirect ARI resource.
2) Since a new backwards-compatible ARI resource was added, the ARI minor 
version needs to be bumped.

- Mark Michelson


On Jan. 21, 2015, 3:39 a.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 21, 2015, 3:39 a.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
> still supported, it is somewhat unintuitive - particularly in a world full of 
> endpoints. As such, we now also support specifying the PJSIP endpoint to 
> transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect 
> by updating its Contact header. Alas, that resulted in the forwarding 
> destination set by the dialplan application/ARI resource/whatever being 
> rewritten with very incorrect information. Hence, we now don't bother 
> updating an outgoing response if it is a 302. Since this took a looong time 
> to find, some additional debug statements have been added to those modules 
> that update the Contact headers.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/channels.json 430839 
>   /branches/13/res/stasis/control.c 430839 
>   /branches/13/res/res_pjsip_transport_websocket.c 430839 
>   /branches/13/res/res_pjsip_nat.c 430839 
>   /branches/13/res/res_pjsip_multihomed.c 430839 
>   /branches/13/res/res_ari_channels.c 430839 
>   /branches/13/res/ari/resource_channels.c 430839 
>   /branches/13/res/ari/resource_channels.h 430839 
>   /branches/13/include/asterisk/stasis_app.h 430839 
>   /branches/13/channels/chan_pjsip.c 430839 
> 
> Diff: https://reviewboard.asterisk.org/r/4316/diff/
> 
> 
> Testing
> ---
> 
> Tests were written both for the PJSIP stack as well as the new ARI operation. 
> See https://reviewboard.asterisk.org/r/4352.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-- 
_
-- 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] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-20 Thread Matt Jordan 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/
---

(Updated Jan. 20, 2015, 9:39 p.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Addressed Mark's findings:
1) We now make sure it is a SIP response before checking the status code
2) We now ignore all 3xx responses in the multihomed module

Tests still pass, including the multihomed tests added recently.


Bugs: ASTERISK-24015 and ASTERISK-24703
https://issues.asterisk.org/jira/browse/ASTERISK-24015
https://issues.asterisk.org/jira/browse/ASTERISK-24703


Repository: Asterisk


Description
---

This patch adds a new feature to ARI to redirect a channel to another server, 
and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With 
this, a channel in a Stasis application can be redirected to another endpoint 
of the same underlying channel technology.

- Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
'transfer' was always kind of a bad name. If the channel isn't answered, we 
aren't transferring, we're forwarding. If it is answered, the type of transfer 
being performed is somewhat vague - is it blind? Is it attended? 'redirect' - 
while also a slightly loaded term - is a bit more generic and yet descriptive 
of what is happening: we're redirecting the channel to somewhere else. 
Answered, not answered, it doesn't matter: your channel is no good here!

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP 
stack:
(1) The existing .transfer channel callback had the limitation that it could 
only transfer channels to a SIP URI, i.e., you had to pass 
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
still supported, it is somewhat unintuitive - particularly in a world full of 
endpoints. As such, we now also support specifying the PJSIP endpoint to 
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by 
updating its Contact header. Alas, that resulted in the forwarding destination 
set by the dialplan application/ARI resource/whatever being rewritten with very 
incorrect information. Hence, we now don't bother updating an outgoing response 
if it is a 302. Since this took a looong time to find, some additional debug 
statements have been added to those modules that update the Contact headers.


Diffs (updated)
-

  /branches/13/rest-api/api-docs/channels.json 430839 
  /branches/13/res/stasis/control.c 430839 
  /branches/13/res/res_pjsip_transport_websocket.c 430839 
  /branches/13/res/res_pjsip_nat.c 430839 
  /branches/13/res/res_pjsip_multihomed.c 430839 
  /branches/13/res/res_ari_channels.c 430839 
  /branches/13/res/ari/resource_channels.c 430839 
  /branches/13/res/ari/resource_channels.h 430839 
  /branches/13/include/asterisk/stasis_app.h 430839 
  /branches/13/channels/chan_pjsip.c 430839 

Diff: https://reviewboard.asterisk.org/r/4316/diff/


Testing
---

Tests were written both for the PJSIP stack as well as the new ARI operation. 
See https://reviewboard.asterisk.org/r/4352.


Thanks,

Matt Jordan

-- 
_
-- 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] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-20 Thread Matt Jordan 


> On Jan. 20, 2015, 3:39 p.m., Mark Michelson wrote:
> > /branches/13/res/ari/resource_channels.c, lines 169-172
> > 
> >
> > Should this send an ARI response?

Nope! That's what I thought too. However, find_control, in its off nominal 
paths, already constructs the appropriate 404 or 409 error responses.


> On Jan. 20, 2015, 3:39 p.m., Mark Michelson wrote:
> > /branches/13/res/res_pjsip_multihomed.c, lines 149-150
> > 
> >
> > I think there are a couple of problems with this change:
> > 
> > 1) You may be trying to access a union member within tdata->msg->line 
> > that doesn't make sense here. tdata->msg could be a request or a response. 
> > If it is a request, then accessing tdata->msg->line.status is going to get 
> > you some goofy values.
> > 
> > 2) Adding an exception for 302 responses is not always going to be 
> > correct. If we are redirecting to another resource on the same Asterisk 
> > server, then we want to rewrite the contact to use the publicly addressable 
> > host and port. However, if we are redirecting to a "foreign" URI, then we 
> > don't want to rewrite the contact to point back to us.
> 
> Mark Michelson wrote:
> Oh, forgot one more thing
> 
> 3) If you are going to apply an exception for a 302 response, the same 
> should be done for all 300-class responses as well.
> 
> Mark Michelson wrote:
> I've been thinking about this more, and you can scrap my finding number 
> 2) here. If people want to "redirect" a device to a resource on the same 
> Asterisk system, they can do that with a Goto in the dialplan, or with the 
> /continue resource in ARI. So anytime you're using an ARI redirect, you 
> should be redirecting to a non-local URI.

Phew. I was really hoping I wasn't going to have to try and figure out if the 
URI here was 'local' or 'remote'.


- Matt


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14244
---


On Jan. 19, 2015, 1:17 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 19, 2015, 1:17 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
> still supported, it is somewhat unintuitive - particularly in a world full of 
> endpoints. As such, we now also support specifying the PJSIP endpoint to 
> transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect 
> by updating its Contact header. Alas, that resulted in the forwarding 
> destination set by the dialplan application/ARI resource/whatever being 
> rewritten with very incorrect information. Hence, we now don't bother 
> updating an outgoing response if it is a 302. Since this took a looong time 
> to find, some additional debug statements have been added to those modules 
> that update the Contact headers.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/channels.json 430794 
>   /branches/13/res/stasis/control.c 430794 
>   /branches/13/res/res_pjsip_transport_websock

Re: [asterisk-dev] [Code Review] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-20 Thread Mark Michelson 


> On Jan. 20, 2015, 9:39 p.m., Mark Michelson wrote:
> > /branches/13/res/res_pjsip_multihomed.c, lines 149-150
> > 
> >
> > I think there are a couple of problems with this change:
> > 
> > 1) You may be trying to access a union member within tdata->msg->line 
> > that doesn't make sense here. tdata->msg could be a request or a response. 
> > If it is a request, then accessing tdata->msg->line.status is going to get 
> > you some goofy values.
> > 
> > 2) Adding an exception for 302 responses is not always going to be 
> > correct. If we are redirecting to another resource on the same Asterisk 
> > server, then we want to rewrite the contact to use the publicly addressable 
> > host and port. However, if we are redirecting to a "foreign" URI, then we 
> > don't want to rewrite the contact to point back to us.
> 
> Mark Michelson wrote:
> Oh, forgot one more thing
> 
> 3) If you are going to apply an exception for a 302 response, the same 
> should be done for all 300-class responses as well.

I've been thinking about this more, and you can scrap my finding number 2) 
here. If people want to "redirect" a device to a resource on the same Asterisk 
system, they can do that with a Goto in the dialplan, or with the /continue 
resource in ARI. So anytime you're using an ARI redirect, you should be 
redirecting to a non-local URI.


- Mark


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14244
---


On Jan. 19, 2015, 7:17 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 19, 2015, 7:17 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
> still supported, it is somewhat unintuitive - particularly in a world full of 
> endpoints. As such, we now also support specifying the PJSIP endpoint to 
> transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect 
> by updating its Contact header. Alas, that resulted in the forwarding 
> destination set by the dialplan application/ARI resource/whatever being 
> rewritten with very incorrect information. Hence, we now don't bother 
> updating an outgoing response if it is a 302. Since this took a looong time 
> to find, some additional debug statements have been added to those modules 
> that update the Contact headers.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/channels.json 430794 
>   /branches/13/res/stasis/control.c 430794 
>   /branches/13/res/res_pjsip_transport_websocket.c 430794 
>   /branches/13/res/res_pjsip_nat.c 430794 
>   /branches/13/res/res_pjsip_multihomed.c 430794 
>   /branches/13/res/res_ari_channels.c 430794 
>   /branches/13/res/ari/resource_channels.c 430794 
>   /branches/13/res/ari/resource_channels.h 430794 
>   /branches/13/include/asterisk/stasis_app.h 430794 
>   /branches/13/channels/chan_pjsip.c 430794 
> 
> Diff: https://reviewboard.asterisk.org/r/4316/diff/
> 
> 
> Testing
> ---
> 
> Tests were written both for the PJSIP stack as well as the new ARI operation. 
> See https

Re: [asterisk-dev] [Code Review] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-20 Thread Mark Michelson 


> On Jan. 20, 2015, 9:39 p.m., Mark Michelson wrote:
> > /branches/13/res/res_pjsip_multihomed.c, lines 149-150
> > 
> >
> > I think there are a couple of problems with this change:
> > 
> > 1) You may be trying to access a union member within tdata->msg->line 
> > that doesn't make sense here. tdata->msg could be a request or a response. 
> > If it is a request, then accessing tdata->msg->line.status is going to get 
> > you some goofy values.
> > 
> > 2) Adding an exception for 302 responses is not always going to be 
> > correct. If we are redirecting to another resource on the same Asterisk 
> > server, then we want to rewrite the contact to use the publicly addressable 
> > host and port. However, if we are redirecting to a "foreign" URI, then we 
> > don't want to rewrite the contact to point back to us.

Oh, forgot one more thing

3) If you are going to apply an exception for a 302 response, the same should 
be done for all 300-class responses as well.


- Mark


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14244
---


On Jan. 19, 2015, 7:17 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 19, 2015, 7:17 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
> still supported, it is somewhat unintuitive - particularly in a world full of 
> endpoints. As such, we now also support specifying the PJSIP endpoint to 
> transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect 
> by updating its Contact header. Alas, that resulted in the forwarding 
> destination set by the dialplan application/ARI resource/whatever being 
> rewritten with very incorrect information. Hence, we now don't bother 
> updating an outgoing response if it is a 302. Since this took a looong time 
> to find, some additional debug statements have been added to those modules 
> that update the Contact headers.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/channels.json 430794 
>   /branches/13/res/stasis/control.c 430794 
>   /branches/13/res/res_pjsip_transport_websocket.c 430794 
>   /branches/13/res/res_pjsip_nat.c 430794 
>   /branches/13/res/res_pjsip_multihomed.c 430794 
>   /branches/13/res/res_ari_channels.c 430794 
>   /branches/13/res/ari/resource_channels.c 430794 
>   /branches/13/res/ari/resource_channels.h 430794 
>   /branches/13/include/asterisk/stasis_app.h 430794 
>   /branches/13/channels/chan_pjsip.c 430794 
> 
> Diff: https://reviewboard.asterisk.org/r/4316/diff/
> 
> 
> Testing
> ---
> 
> Tests were written both for the PJSIP stack as well as the new ARI operation. 
> See https://reviewboard.asterisk.org/r/4352.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-- 
_
-- 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] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-20 Thread Mark Michelson 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14244
---



/branches/13/res/ari/resource_channels.c


Should this send an ARI response?



/branches/13/res/res_pjsip_multihomed.c


I think there are a couple of problems with this change:

1) You may be trying to access a union member within tdata->msg->line that 
doesn't make sense here. tdata->msg could be a request or a response. If it is 
a request, then accessing tdata->msg->line.status is going to get you some 
goofy values.

2) Adding an exception for 302 responses is not always going to be correct. 
If we are redirecting to another resource on the same Asterisk server, then we 
want to rewrite the contact to use the publicly addressable host and port. 
However, if we are redirecting to a "foreign" URI, then we don't want to 
rewrite the contact to point back to us.


- Mark Michelson


On Jan. 19, 2015, 7:17 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 19, 2015, 7:17 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
> still supported, it is somewhat unintuitive - particularly in a world full of 
> endpoints. As such, we now also support specifying the PJSIP endpoint to 
> transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect 
> by updating its Contact header. Alas, that resulted in the forwarding 
> destination set by the dialplan application/ARI resource/whatever being 
> rewritten with very incorrect information. Hence, we now don't bother 
> updating an outgoing response if it is a 302. Since this took a looong time 
> to find, some additional debug statements have been added to those modules 
> that update the Contact headers.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/channels.json 430794 
>   /branches/13/res/stasis/control.c 430794 
>   /branches/13/res/res_pjsip_transport_websocket.c 430794 
>   /branches/13/res/res_pjsip_nat.c 430794 
>   /branches/13/res/res_pjsip_multihomed.c 430794 
>   /branches/13/res/res_ari_channels.c 430794 
>   /branches/13/res/ari/resource_channels.c 430794 
>   /branches/13/res/ari/resource_channels.h 430794 
>   /branches/13/include/asterisk/stasis_app.h 430794 
>   /branches/13/channels/chan_pjsip.c 430794 
> 
> Diff: https://reviewboard.asterisk.org/r/4316/diff/
> 
> 
> Testing
> ---
> 
> Tests were written both for the PJSIP stack as well as the new ARI operation. 
> See https://reviewboard.asterisk.org/r/4352.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-- 
_
-- 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] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-19 Thread Matt Jordan 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/
---

(Updated Jan. 19, 2015, 1:17 p.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Addressed Josh and Mark's findings.


Bugs: ASTERISK-24015 and ASTERISK-24703
https://issues.asterisk.org/jira/browse/ASTERISK-24015
https://issues.asterisk.org/jira/browse/ASTERISK-24703


Repository: Asterisk


Description
---

This patch adds a new feature to ARI to redirect a channel to another server, 
and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With 
this, a channel in a Stasis application can be redirected to another endpoint 
of the same underlying channel technology.

- Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
'transfer' was always kind of a bad name. If the channel isn't answered, we 
aren't transferring, we're forwarding. If it is answered, the type of transfer 
being performed is somewhat vague - is it blind? Is it attended? 'redirect' - 
while also a slightly loaded term - is a bit more generic and yet descriptive 
of what is happening: we're redirecting the channel to somewhere else. 
Answered, not answered, it doesn't matter: your channel is no good here!

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP 
stack:
(1) The existing .transfer channel callback had the limitation that it could 
only transfer channels to a SIP URI, i.e., you had to pass 
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
still supported, it is somewhat unintuitive - particularly in a world full of 
endpoints. As such, we now also support specifying the PJSIP endpoint to 
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by 
updating its Contact header. Alas, that resulted in the forwarding destination 
set by the dialplan application/ARI resource/whatever being rewritten with very 
incorrect information. Hence, we now don't bother updating an outgoing response 
if it is a 302. Since this took a looong time to find, some additional debug 
statements have been added to those modules that update the Contact headers.


Diffs (updated)
-

  /branches/13/rest-api/api-docs/channels.json 430794 
  /branches/13/res/stasis/control.c 430794 
  /branches/13/res/res_pjsip_transport_websocket.c 430794 
  /branches/13/res/res_pjsip_nat.c 430794 
  /branches/13/res/res_pjsip_multihomed.c 430794 
  /branches/13/res/res_ari_channels.c 430794 
  /branches/13/res/ari/resource_channels.c 430794 
  /branches/13/res/ari/resource_channels.h 430794 
  /branches/13/include/asterisk/stasis_app.h 430794 
  /branches/13/channels/chan_pjsip.c 430794 

Diff: https://reviewboard.asterisk.org/r/4316/diff/


Testing
---

Tests were written both for the PJSIP stack as well as the new ARI operation. 
See https://reviewboard.asterisk.org/r/4352.


Thanks,

Matt Jordan

-- 
_
-- 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] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-19 Thread Matt Jordan 


> On Jan. 19, 2015, 10:25 a.m., Joshua Colp wrote:
> > /branches/13/include/asterisk/stasis_app.h, line 489
> > 
> >
> > Everything else has doxygen. Why not this?

Bad eyesight?


> On Jan. 19, 2015, 10:25 a.m., Joshua Colp wrote:
> > /branches/13/channels/chan_pjsip.c, lines 1394-1400
> > 
> >
> > I think it may be useful to have AOR support here as well.

IRC conversation for posterity:

(01:00:16 PM) mjordan: file: Question! On r4316, when you refer to 'AoR 
support' - can you point me to a parsing example that does what you would like? 
I'm thinking that constructing a dial string isn't quite right, since it 
supports multiple contacts
(01:01:38 PM) file: mjordan, there isn't really one as everything else requires 
an endpoint
(01:07:25 PM) mjordan: file: Nuts.
(01:08:28 PM) file: mjordan, try to find endpoint, then AOR, then treat as URI?
(01:09:30 PM) mjordan: file: what would you have to specify to do that?
(01:09:35 PM) mjordan: PJSIP/foo/foo?
(01:09:58 PM) file: PJSIP// is how a dial string works
(01:10:58 PM) mjordan: Hm.
(01:11:06 PM) mjordan: Except that you then would need a convenience dialplan 
function
(01:11:18 PM) mjordan: And how would you handle multiple contacts on an AoR in 
the redirect case?
(01:11:36 PM) file: use the first one, same as you are doing right now
(01:11:45 PM) file: or return all of them as Contacts and see what the endpoint 
does
(01:11:58 PM) file: HILARITY
(01:12:28 PM) mjordan: heh
(01:12:38 PM) mjordan: I guess I'm trying to see why specifying an AoR would be 
helpful
(01:13:04 PM) mjordan: What does specifying it buy us in this case, since 
(almost 99% likely) we only want to place one URI in the Contact header
(01:13:21 PM) mjordan: (And we can specify any arbitrary URI using 
PJSIP/sip:f...@foo.com)
(01:13:35 PM) file: we allow specifying an explicit AOR elsewhere when dialing 
so consistency - but if you don't want to I'm not going to fight it
(01:13:51 PM) mjordan: well, it's actually what I wanted initially
(01:14:05 PM) mjordan: I just couldn't see what it was buying me, since I could 
specify arbitrary URIs (unlike with dialing)
(01:14:11 PM) mjordan: which, unfortunately, makes sense
(01:14:22 PM) mjordan: as with dialing, I need to have codecs, and dialplan 
contexts, and SRTP, and stuff
(01:14:30 PM) mjordan: but in this case, we're just trying to slap a URI in a 
header on the way out the door
(01:14:57 PM) file: you could argue with the new PJSIP_AOR and PJSIP_CONTACT 
dialplan functions you don't need it at all
(01:15:00 PM) mjordan: I suppose if an endpoint had multiple AoRs it would make 
a difference, but I'm not sure we even look at it
(01:15:03 PM) mjordan: True
(01:15:25 PM) mjordan: shall we punt then?
(01:15:31 PM) file: SURE!


- Matt


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14223
---


On Jan. 18, 2015, 9:16 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 18, 2015, 9:16 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:f

Re: [asterisk-dev] [Code Review] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-19 Thread Mark Michelson 


> On Jan. 19, 2015, 4:25 p.m., Joshua Colp wrote:
> > /branches/13/res/res_pjsip_multihomed.c, line 155
> > 
> >
> > There's no guarantee that the host will be NULL terminated.

If you're looking for how we typically go about printing pj_str_t, you can find 
examples in res_pjsip.c. Taking a quick look, there are two examples in 
register_service_noref().


- Mark


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14223
---


On Jan. 19, 2015, 3:16 a.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 19, 2015, 3:16 a.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
> still supported, it is somewhat unintuitive - particularly in a world full of 
> endpoints. As such, we now also support specifying the PJSIP endpoint to 
> transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect 
> by updating its Contact header. Alas, that resulted in the forwarding 
> destination set by the dialplan application/ARI resource/whatever being 
> rewritten with very incorrect information. Hence, we now don't bother 
> updating an outgoing response if it is a 302. Since this took a looong time 
> to find, some additional debug statements have been added to those modules 
> that update the Contact headers.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/channels.json 430751 
>   /branches/13/res/stasis/control.c 430751 
>   /branches/13/res/res_pjsip_transport_websocket.c 430751 
>   /branches/13/res/res_pjsip_nat.c 430751 
>   /branches/13/res/res_pjsip_multihomed.c 430751 
>   /branches/13/res/res_ari_channels.c 430751 
>   /branches/13/res/ari/resource_channels.c 430751 
>   /branches/13/res/ari/resource_channels.h 430751 
>   /branches/13/include/asterisk/stasis_app.h 430751 
>   /branches/13/channels/chan_pjsip.c 430751 
> 
> Diff: https://reviewboard.asterisk.org/r/4316/diff/
> 
> 
> Testing
> ---
> 
> Tests were written both for the PJSIP stack as well as the new ARI operation. 
> See https://reviewboard.asterisk.org/r/4352.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-- 
_
-- 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] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-19 Thread Joshua Colp 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/#review14223
---



/branches/13/channels/chan_pjsip.c


I think it may be useful to have AOR support here as well.



/branches/13/include/asterisk/stasis_app.h


Everything else has doxygen. Why not this?



/branches/13/res/res_pjsip_multihomed.c


There's no guarantee that the host will be NULL terminated.



/branches/13/res/res_pjsip_nat.c


There's no guarantee that host will be NULL terminated.



/branches/13/res/res_pjsip_transport_websocket.c


Etc.


- Joshua Colp


On Jan. 19, 2015, 3:16 a.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> ---
> 
> (Updated Jan. 19, 2015, 3:16 a.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
> https://issues.asterisk.org/jira/browse/ASTERISK-24015
> https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds a new feature to ARI to redirect a channel to another server, 
> and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
> application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With 
> this, a channel in a Stasis application can be redirected to another endpoint 
> of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
> 'transfer' was always kind of a bad name. If the channel isn't answered, we 
> aren't transferring, we're forwarding. If it is answered, the type of 
> transfer being performed is somewhat vague - is it blind? Is it attended? 
> 'redirect' - while also a slightly loaded term - is a bit more generic and 
> yet descriptive of what is happening: we're redirecting the channel to 
> somewhere else. Answered, not answered, it doesn't matter: your channel is no 
> good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP 
> stack:
> (1) The existing .transfer channel callback had the limitation that it could 
> only transfer channels to a SIP URI, i.e., you had to pass 
> 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
> still supported, it is somewhat unintuitive - particularly in a world full of 
> endpoints. As such, we now also support specifying the PJSIP endpoint to 
> transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect 
> by updating its Contact header. Alas, that resulted in the forwarding 
> destination set by the dialplan application/ARI resource/whatever being 
> rewritten with very incorrect information. Hence, we now don't bother 
> updating an outgoing response if it is a 302. Since this took a looong time 
> to find, some additional debug statements have been added to those modules 
> that update the Contact headers.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/channels.json 430751 
>   /branches/13/res/stasis/control.c 430751 
>   /branches/13/res/res_pjsip_transport_websocket.c 430751 
>   /branches/13/res/res_pjsip_nat.c 430751 
>   /branches/13/res/res_pjsip_multihomed.c 430751 
>   /branches/13/res/res_ari_channels.c 430751 
>   /branches/13/res/ari/resource_channels.c 430751 
>   /branches/13/res/ari/resource_channels.h 430751 
>   /branches/13/include/asterisk/stasis_app.h 430751 
>   /branches/13/channels/chan_pjsip.c 430751 
> 
> Diff: https://reviewboard.asterisk.org/r/4316/diff/
> 
> 
> Testing
> ---
> 
> Tests were written both for the PJSIP stack as well as the new ARI operation. 
> See https://reviewboard.asterisk.org/r/4352.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-- 
_
-- 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

[asterisk-dev] [Code Review] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

2015-01-18 Thread Matt Jordan 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4316/
---

Review request for Asterisk Developers and Joshua Colp.


Bugs: ASTERISK-24015 and ASTERISK-24703
https://issues.asterisk.org/jira/browse/ASTERISK-24015
https://issues.asterisk.org/jira/browse/ASTERISK-24703


Repository: Asterisk


Description
---

This patch adds a new feature to ARI to redirect a channel to another server, 
and fixes a few bugs in PJSIP's handling of the Transfer dialplan 
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With 
this, a channel in a Stasis application can be redirected to another endpoint 
of the same underlying channel technology.

- Preemptive question: why 'redirect', and not 'transfer'? Mostly because 
'transfer' was always kind of a bad name. If the channel isn't answered, we 
aren't transferring, we're forwarding. If it is answered, the type of transfer 
being performed is somewhat vague - is it blind? Is it attended? 'redirect' - 
while also a slightly loaded term - is a bit more generic and yet descriptive 
of what is happening: we're redirecting the channel to somewhere else. 
Answered, not answered, it doesn't matter: your channel is no good here!

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP 
stack:
(1) The existing .transfer channel callback had the limitation that it could 
only transfer channels to a SIP URI, i.e., you had to pass 
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is 
still supported, it is somewhat unintuitive - particularly in a world full of 
endpoints. As such, we now also support specifying the PJSIP endpoint to 
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by 
updating its Contact header. Alas, that resulted in the forwarding destination 
set by the dialplan application/ARI resource/whatever being rewritten with very 
incorrect information. Hence, we now don't bother updating an outgoing response 
if it is a 302. Since this took a looong time to find, some additional debug 
statements have been added to those modules that update the Contact headers.


Diffs
-

  /branches/13/rest-api/api-docs/channels.json 430751 
  /branches/13/res/stasis/control.c 430751 
  /branches/13/res/res_pjsip_transport_websocket.c 430751 
  /branches/13/res/res_pjsip_nat.c 430751 
  /branches/13/res/res_pjsip_multihomed.c 430751 
  /branches/13/res/res_ari_channels.c 430751 
  /branches/13/res/ari/resource_channels.c 430751 
  /branches/13/res/ari/resource_channels.h 430751 
  /branches/13/include/asterisk/stasis_app.h 430751 
  /branches/13/channels/chan_pjsip.c 430751 

Diff: https://reviewboard.asterisk.org/r/4316/diff/


Testing
---

Tests were written both for the PJSIP stack as well as the new ARI operation. 
See https://reviewboard.asterisk.org/r/4352.


Thanks,

Matt Jordan

-- 
_
-- 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