Issue i think with: PJSIP/trunk-xxx requested media update control 18, passing it to PJSIP/xxx

Hey, i have a verry easy dialplan below, i’m trying to make an outbound call with a trunk…

exten => 5555,1,NoOp()
 same => n,Set(CALLERID(num)=1234)
 same => n,Set(CALLERID(name)=xxx)
 same => n,Dial(PJSIP/5555@trunk-basip)

I have setup 2 extensions, one configured with linphone (6000) and one configured with baresip (7000)

calling from 6000 to 5555 works (linphone)
calling from 7000 to 5555 doesnt work (baresip client)

The only difference i see in the log is this line below, is that the culprint? where is it coming from?

[Nov 24 14:01:17] -- PJSIP/trunk-basip-00000003 requested media update control 18, passing it to PJSIP/7000-00000002

full log:

### working from 6000 to 5555
[Nov 24 14:00:47]     -- Executing [5555@default:1] NoOp("PJSIP/6000-00000000", "") in new stack
[Nov 24 14:00:47]     -- Executing [5555@default:2] Set("PJSIP/6000-00000000", "CALLERID(num)=64668") in new stack
[Nov 24 14:00:47]     -- Executing [5555@default:3] Set("PJSIP/6000-00000000", "CALLERID(name)=Deurbel") in new stack
[Nov 24 14:00:47]     -- Executing [5555@default:4] Dial("PJSIP/6000-00000000", "PJSIP/5555@trunk-basip") in new stack
[Nov 24 14:00:47]     -- Called PJSIP/5555@trunk-basip
[Nov 24 14:00:47]     -- PJSIP/trunk-basip-00000001 is making progress passing it to PJSIP/6000-00000000
[Nov 24 14:00:58]     -- PJSIP/trunk-basip-00000001 answered PJSIP/6000-00000000
[Nov 24 14:00:58]     -- Channel PJSIP/trunk-basip-00000001 joined 'simple_bridge' basic-bridge <a3d37184-eb7e-4bdc-82ee-397abe480ae2>
[Nov 24 14:00:58]     -- Channel PJSIP/6000-00000000 joined 'simple_bridge' basic-bridge <a3d37184-eb7e-4bdc-82ee-397abe480ae2>
[Nov 24 14:01:05]     -- Channel PJSIP/trunk-basip-00000001 left 'native_rtp' basic-bridge <a3d37184-eb7e-4bdc-82ee-397abe480ae2>
[Nov 24 14:01:05]     -- Channel PJSIP/6000-00000000 left 'native_rtp' basic-bridge <a3d37184-eb7e-4bdc-82ee-397abe480ae2>

#### non working 7000 to 5555
[Nov 24 14:01:05]   == Spawn extension (default, 1, 4) exited non-zero on 'PJSIP/6000-00000000'
[Nov 24 14:01:17]     -- Executing [5555@default:1] NoOp("PJSIP/7000-00000002", "") in new stack
[Nov 24 14:01:17]     -- Executing [5555@default:2] Set("PJSIP/7000-00000002", "CALLERID(num)=1234") in new stack
[Nov 24 14:01:17]     -- Executing [5555@default:3] Set("PJSIP/7000-00000002", "CALLERID(name)=xxx") in new stack
[Nov 24 14:01:17]     -- Executing [5555@default:4] Dial("PJSIP/7000-00000002", "PJSIP/5555@trunk-basip") in new stack
[Nov 24 14:01:17]     -- Called PJSIP/5555@trunk-basip
[Nov 24 14:01:17]     -- PJSIP/trunk-basip-00000003 is making progress passing it to PJSIP/7000-00000002
[Nov 24 14:01:17]     -- PJSIP/trunk-basip-00000003 requested media update control 18, passing it to PJSIP/7000-00000002
[Nov 24 14:01:17]   == Spawn extension (default, 1, 4) exited non-zero on 'PJSIP/7000-00000002'

this is the trunk config below:

[trunk-basip]
type=registration
outbound_auth=trunk-basip
server_uri=sip:domain.com
client_uri=sip:1234@domain.com
retry_interval=30
contact_user=1234
 
[trunk-basip]
type=auth
auth_type=userpass
password=xxxx
username=1234
 
[trunk-basip]
type=aor
contact=sip:1234@domain.com
;default_expiration=1500
;maximum_expiration=3000
;minimum_expiration=60

[trunk-basip]
type=endpoint
context=default
disallow=all
allow=ulaw,alaw
allow=h264
outbound_auth=trunk-basip
aors=trunk-basip
from_domain=domain.com
direct_media=no

[trunk-basip]
type=identify
endpoint=trunk-basip
match=domain.com

and here are the extensions, no difference in 6000 or 7000

[6000]
type=endpoint
context=default
disallow=all
allow=ulaw,alaw
allow=h264
auth=auth6000
aors=6000
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no
max_audio_streams=10
max_video_streams=10
from_domain=domain.com

[auth6000]
type=auth
auth_type=userpass
password=xxxx
username=6000
 
[6000]
type=aor
qualify_frequency=30
max_contacts=1
remove_existing=yes
remove_unavailable=yes

[7000]
type=endpoint
context=default
disallow=all
allow=ulaw,alaw
allow=h264
auth=auth7000
aors=7000
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no
max_audio_streams=10
max_video_streams=10
from_domain=domain.com

[auth7000]
type=auth
auth_type=userpass
password=xxxx
username=7000
 
[7000]
type=aor
max_contacts=1
remove_existing=yes
remove_unavailable=yes

You haven’t stated what “doesn’t work” means. If you mean that the call isn’t answered, you’d need to show a SIP trace using “pjsip set logger on”. The “trunk-basip” endpoint may not have answered the call. The log message you reference is generated based on communication with “trunk-basip”.

ok, i share a log later, when i call, it just doesnt start ringing, its spaw immediately

Hey, here are the logs

log from 6000 = working
log from 7000 = not working, i see indeed “SIP/2.0 481 Call/Transaction Does Not Exist”

but no idea why, the setup is the same, only the softphone client is different

7000.txt (18.1 KB)
6000.txt (22.4 KB)

note1: also the baresip softphone client, runs on same host where asterisk is running (console client) , maybe thats giving issues
note2: it should not give issues, now called from baresip client to a linphone user, that works, so running on same host shouldt give issues

Asterisk sent an INFO request to 7000 before 200 OK. It rejected it with a 481, which indicated it didn’t think the call existed and we hung it up. I believe it is valid for us to send the INFO request at this point, because the underlying SIP dialog will have been established due to us sending a 183 at which point in-dialog requests should be fine to send. This is not a scenario I’ve seen before though. It may be a bug in baresip. Trying another client to verify behavior would probably be wise.

yes, if i test with linphone client, it indeed works
hmm, i should report to baresip , or can i overcome this in Asterisk?

Nothing comes to mind from a “not changing the code” perspective.

It looks to me that the informal part of the INFO RFC says it should only be used within a session, so it look to me as though the spirit is being violated. However, that RFC also says it should, generally be handled the same as BYE, for most purposes, and whilst there is an implication that it can only be used once the final signalling routing is established, BYE is allowed in an early dialog state, even if that is rather unusual.

481 is not a valid way of rejecting it, as the dialogue definitely exists at that point.

So what’s the culprit here? You guys are the SIP experts

We’re not experts on this specific scenario. We’re just reading the specs and trying to interpret them. I’ve never seen this before, maybe because other clients just work.

I’d say the 481 was wrong.

i created an issue on baresip github, but they say its an issue on asterisk side?

You can file an issue[1]. They may be correct. If accepted, there is absolutely no time frame on if or when it would get looked at or resolved.

[1] System Dashboard - Digium/Asterisk JIRA