asterisk users - Aug 2018 - PJSIP redirect_method=uri_core and header modifications

With chan_sip there is the variable SIP_MAX_FORWARDS to set
Max-Forwards. This counter is persistant after a redirect. I can't find
the equivalent for PJSIP, so I went the way of header manipulation. Only
to find out that any headers added to the outbound leg are lost after a
redirect (with redirect_method=uri_core (didn't try any other since in
the past they didn't work for me)).

Am I missing something? Or is this a PJSIP feature?

chan_sip example:

[macro-maxforwards]
exten => s,1,NoOp()
exten => s,n,Set(mf=${SIP_HEADER(Max-Forwards)})
exten => s,n,Set(mf=$[ ${mf} - 1 ])
exten => s,n,ExecIf($[ ${mf} < 1 ]?Hangup(19))
exten => s,n,Set(__SIP_MAX_FORWARDS=${mf})
exten => s,n,SipAddHeader(X-Foo: bar)
exten => s,n,MacroExit()

[route]
...
exten => _+.,n,Macro(maxforwards)
exten => _+.,n,Dial(SIP/${EXTEN}@redirector)

An incomig INVITE will look like:
> INVITE sip:+number at asterisk;user=phone SIP/2.0
> Max-Forwards: 70
To the redirector:
> INVITE sip:+number at asterisk;user=phone SIP/2.0
> Max-Forwards: 69
> X-Foo: bar
< SIP/2.0 302 Redirect
< Contact: <sip:+number at somewhereelse:5060;transport=udp>

To somewhereelse:
> INVITE sip:+number at somewhereelse;user=phone SIP/2.0
> Max-Forwards: 69
> X-Foo: bar

PJSIP example (where the add strangely overrides the default
Max-Forwards: 70).

[setoutgoinglegvars]
exten => add,1,Set(PJSIP_HEADER(add,Max-Forwards)=60)
exten => add,1,Set(PJSIP_HEADER(add,X-Foo)=bar)
exten => add,n,Return()

[route]
...
exten => _+.,n,Macro(maxforwards)
exten => _+.,n,Dial(PJSIP/${EXTEN}@redirector,,b(setoutgoinglegvars,add,1))
> INVITE sip:+number at asterisk;user=phone SIP/2.0
> Max-Forwards: 70
To the redirector:
> INVITE sip:+number at asterisk;user=phone SIP/2.0
> Max-Forwards: 60
> X-Foo: bar
< SIP/2.0 302 Redirect
< Contact: <sip:+number at somewhereelse:5060;transport=udp>

To somewhereelse:
> INVITE sip:+number at somewhereelse;user=phone SIP/2.0
> Max-Forwards: 70
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180802/892e051a/attachment.sig>

On Thu, Aug 02, 2018 at 05:29:23PM +0200, Daniel Tryba
wrote:
> With chan_sip there is the variable SIP_MAX_FORWARDS to set
> Max-Forwards. This counter is persistant after a redirect. I can't find
> the equivalent for PJSIP, so I went the way of header manipulation. Only
> to find out that any headers added to the outbound leg are lost after a
> redirect (with redirect_method=uri_core (didn't try any other since in
> the past they didn't work for me)).
> 
> Am I missing something? Or is this a PJSIP feature?
Forgot to mention this is tested on Debian/stable its Asterisk:
13.14.1~dfsg-2+deb9u3 (so 13.14.x with some fixes).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180802/97f76357/attachment.sig>

On Thu, Aug 02, 2018 at 05:29:23PM +0200, Daniel Tryba
wrote:
> With chan_sip there is the variable SIP_MAX_FORWARDS to set
> Max-Forwards. This counter is persistant after a redirect. I can't find
> the equivalent for PJSIP, so I went the way of header manipulation. Only
> to find out that any headers added to the outbound leg are lost after a
> redirect (with redirect_method=uri_core (didn't try any other since in
> the past they didn't work for me)).
redirect_method=uri_pjsip works as expected with regard to the header
manipulation stuff.

Also I can't remember why, in the past, I decided to not use uri_pjsip
other than having the redirected host in CDRs with uri_core and the
original with uri_pjsip (which I don't really care about).

I still think header manipulation should work with uri_core though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180803/02f34ffe/attachment.sig>

On Fri, Aug 03, 2018 at 04:24:06PM +0200, Daniel Tryba
wrote:
> redirect_method=uri_pjsip works as expected with regard to the header
> manipulation stuff.
> 
> Also I can't remember why, in the past, I decided to not use uri_pjsip
> other than having the redirected host in CDRs with uri_core and the
> original with uri_pjsip (which I don't really care about).
I found that out after going live with uri_pjsip:
the domain in the to header with uri_pjsip is the hostname/ip of the
redirector. With uri_core the domain will be the hostname/ip of the
contact header in the 302 response.

Reading the redirect_method description (version 13):
"If this option is set to uri_core the target URI is returned to the
dialing application which dials it using the PJSIP channel driver and
endpoint originally used. If this option is set to uri_pjsip the
redirect occurs within chan_pjsip itself and is not exposed to the core
at all."

The wording for uri_core is that the original endpoint context will be
used, that would make changing the to domain a bug IMHO. But since I
need this behavior it is a nice feature.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180806/b4ba40a7/attachment.sig>