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

1 Like

see, some response below, but maybe its already fixed in a newer asterisk version like 20 ? i’m using a 18.x build now…

[2](https://www.rfc-editor.org/rfc/rfc2976#section-2). INFO Method

   The INFO method is used for communicating mid-session signaling
   information along the signaling path for the call.

Now Asterisk is sending INFO when session has not been established.

That statement is only informative,not normative, so I don’t think a recipient can rely on i t. See my post number 7. The whole RFC is badly drafted, but the 481 response is definitely not allowed, here. Returning 200 OK and ignoring the INFO would seem to have been the only sensible, and legal, thing to do if it didn’t like it, at the time, but did understand the payload type. The only time it can return 481 is if the call-ID/from tag/to tag combination didn’t exist.

Given the number of people wanting video doorbells as early media, you probably also need to look closely at the RFCs on video media updates, as a careful reading might well imply that INFO should be used in early media states.

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