asterisk users - Nov 2017 - pjsip Transfer 'Failed to parse destination uri'

Hi Richard

Thank you
> You need to set more redirecting information [1].
> 
> In sip.conf send_diversion=yes needs to be in effect.  You also need
> to setup
> the from party id information (at least the from number) to indicate
> where you
> are redirecting from.  You should also increment the redirecting
> count.
> 
> Richard
> 
> [1]
>
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
I'm back to chan_sip to get quicker progress in our test scenario as I
know this better than pjsip :-)

send_diversion=yes is the default if it is not set, so that's correctly
set.

I altered my test dialplan and got some success but also another weird
problem now:

exten => XX,1,NoOp(Call to ${EXTEN} from ${CALLERID(all)})
exten => XX,n,Progress
exten => XX,n,Ringing
exten => XX,n,Wait(10)
exten => XX,n,set(REDIRECTING(from-num)=${EXTEN})
exten => XX,n,set(REDIRECTING(reason)=cfnr)
exten => XX,n,Transfer(SIP/ZZ)

How everytime REDIRECTING is called, this causes a 181 call is being
forwarded to the caller, but containing no diversion information.

The Transfer (302 Moved Temporarily) contains two Diversion: headers,
one with reason=unknown and one with reason=no-answer which would be the
correct one.

I start to think I stumbled over a bug. Maybe using REDIRECTING() would
set the correct headers if I used DIAL to forward the call. But I don't
want to create a second call leg. So maybe Transfer already is setting
a Diversion: header with hardcoded reason 'unknown'.

-Beno?t Panizzon-
-- 
I m p r o W a r e   A G    -    Leiter Commerce Kunden
______________________________________________________

Zurlindenstrasse 29             Tel  +41 61 826 93 00
CH-4133 Pratteln                Fax  +41 61 826 93 01
Schweiz                         Web  http://www.imp.ch
______________________________________________________

On Tue, Nov 21, 2017 at 5:04 AM, Benoit Panizzon <benoit.panizzon at
imp.ch>
wrote:
> Hi Richard
>
> Thank you
>
> > You need to set more redirecting information [1].
> >
> > In sip.conf send_diversion=yes needs to be in effect.  You also need
> > to setup
> > the from party id information (at least the from number) to indicate
> > where you
> > are redirecting from.  You should also increment the redirecting
> > count.
> >
> > Richard
> >
> > [1]
> > https://wiki.asterisk.org/wiki/display/AST/Manipulating+
> Party+ID+Information
>
> I'm back to chan_sip to get quicker progress in our test scenario as I
> know this better than pjsip :-)
>
> send_diversion=yes is the default if it is not set, so that's correctly
> set.
>
> I altered my test dialplan and got some success but also another weird
> problem now:
>
> exten => XX,1,NoOp(Call to ${EXTEN} from ${CALLERID(all)})
> exten => XX,n,Progress
> exten => XX,n,Ringing
> exten => XX,n,Wait(10)
> exten => XX,n,set(REDIRECTING(from-num)=${EXTEN})
>
You need to use the 'i' option of REDIRECTING here as described in the
manipulating
party id wiki page.

> exten => XX,n,set(REDIRECTING(reason)=cfnr)
> exten => XX,n,Transfer(SIP/ZZ)
>
> How everytime REDIRECTING is called, this causes a 181 call is being
> forwarded to the caller, but containing no diversion information.
>
> The Transfer (302 Moved Temporarily) contains two Diversion: headers,
> one with reason=unknown and one with reason=no-answer which would be the
> correct one.
>
> I start to think I stumbled over a bug. Maybe using REDIRECTING() would
> set the correct headers if I used DIAL to forward the call. But I don't
> want to create a second call leg. So maybe Transfer already is setting
> a Diversion: header with hardcoded reason 'unknown'.
>
That could be possible and would be a bug in chan_sip.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20171121/6ccfad7e/attachment.html>

Hi Richard
> That could be possible and would be a bug in chan_sip.
Ok, so I switched to PJSIP to see if this behaves differently

So ip do a

Transfer(PJSIP/${DESTNUMBER}@trunk)

And this results in:

Failed to parse destination URI '[destnumber scrubber]' for channel
PJSIP/trunk-00000011

Do I have to specify the destination number differently when using
Transfer with pjsip that I used it in chan_sip?

-Beno?t Panizzon-
-- 
I m p r o W a r e   A G    -    Leiter Commerce Kunden
______________________________________________________

Zurlindenstrasse 29             Tel  +41 61 826 93 00
CH-4133 Pratteln                Fax  +41 61 826 93 01
Schweiz                         Web  http://www.imp.ch
______________________________________________________