Asterisk B2BUA and Replaces issue

Hi all,

i’ve configured an Asterisk box as B2BUA between VoIP Trunk and our OpenSIPS. It’s quite simple,
two context (from-toip and from-voip), defined as follow using PJSIP:

type = wizard
transport = transport-udp
endpoint/allow_subscribe = no
aor/qualify_frequency = 30
registration/expiration = 1800
ignore_uri_user_options = yes
has_hint = no
allow_transfer = yes
redirect_method = uri_core

;hint_context = from-toip
endpoint/context = from-toip
remote_hosts = [TOIP IP]
sends_registrations = no
accepts_registrations = no
sends_auth = no
accepts_auth = no

;hint_context = from-voip
endpoint/context = from-voip
remote_hosts = [OPENSIPS IP]
sends_registrations = no
accepts_registrations = no
sends_auth = no
accepts_auth = no

and on extensions, just a bypass:

exten => _0X.,1,Noop("Call from TOIP ${EXTEN}")
exten => _0X.,n,Answer()
exten => _0X.,n,Dial(PJSIP/${EXTEN}@voip)

exten => _0X.,1,Noop("Call from VOIP ${EXTEN}")
exten => _0X.,n,Answer()
exten => _0X.,n,Dial(PJSIP/${EXTEN}@toip)

I have to do this because i need to support Replaces, that ToIP SBC doesn’t.

At the moment, calls were passed between ToIP and VoIP, ad expected, but on Replaces by a phone on from-voip side, Asterisk tell me:

NOTICE[156836]: res_pjsip_session.c:3962 new_invite: voip: Call (UDP:[OPENSIPS IP]:5060) to extension 'asterisk' rejected because extension not found in context 'from-voip'.

and, analyzing the flow using sngrep, i saw that the Replaces header is correct, but on the INVITE i got sip:asterisk…:

Obivously, Replaces where ignored and i got a “404 Not Found”.

Any help?

And if you add in a dummy extension named asterisk what happens?

Oh, sh*t, it works!

Just for historical purpouse:

exten => _0X.,1,Noop("Call from VOIP ${EXTEN}")
exten => _0X.,n,Answer()
exten => _0X.,n,Dial(PJSIP/${EXTEN}@toip)
exten => asterisk,1,Noop("Asterisk")


Your log doesn’t include the call being replaced. I wouldn’t expect Asterisk to look at the request URI if the replaced calls was within that Asterisk. At least that is how chan_sip behaved and I can’t think why chan_pjsip would differ.

Also, although possibly not relevant, answering the call goes beyond a minimal back to back user agent.

It shouldn’t care, but the logic is probably checking for the extension early. A bug can be filed, but I don’t see it getting any attention since the workaround is simple and quick to allow it to work.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.