[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Trying to make BLF (presence) work between lin

From: Jehan Monnier
Subject: Re: [Linphone-developers] Trying to make BLF (presence) work between linphone 3.12 and asterisk
Date: Thu, 9 Apr 2020 08:44:00 +0200

Hi John,

Le 8 avr. 2020 à 16:48, John Hughes <address@hidden> a écrit :


linphone decides to terminate and restart the SUBSCRIBE dialog with asterisk which seems to have a bug where it doesn't notice that it's a new dialog so it gives a 500 INTERNAL SERVER error and everything goes to hell.

It's pretty clear that the 500 INTERNAL SERVER ERROR from asterisk is purest nonsense, but the asterisk code is vile and there are *two* asterisk implementations of SIP, so I'm going to have to try configuring my asterisk with the "new" "enhanced" version, pjsip.

So while I'm working on that I thought I'd have a look to see why linphone (actually belle-sip) decides to terminate the SUBSCRIBE dialog.  I get to here:

message: 2020-04-08 15:46:12:204 Auth info found for [john] realm [asterisk]
message: 2020-04-08 15:46:12:204 Dialog [0x5591269c1200]: now updated by transaction [0x55912642ddc0].
message: 2020-04-08 15:46:12:204 belle_sip_dialog_schedule_expiration() dialog=0x5591269c1200 expires_value=600
message: 2020-04-08 15:46:12:204 Changing [client] [SUBSCRIBE] transaction [0x55912642ddc0], from state [INIT] to [TRYING]
message: 2020-04-08 15:46:12:204 channel [0x5591267edbc0]: message sent to [UDP://], size: [708] bytes
SUBSCRIBE sip:jacques@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK.uqUmHRum-;rport
From: <sip:address@hidden>;tag=vE-hfEwSx
To: <sip:address@hidden>;tag=as4927b86b
Call-ID: EP3owvMfzb
Max-Forwards: 70
Supported: replaces, outbound
Event: presence
Expires: 600
Accept: application/pidf+xml
Contact: <sip:john@;transport=udp>;+sip.instance="<urn:uuid:abcdf51a-82e0-49b9-a8ab-2461011f25ec>"
User-Agent: Linphone/3.12.0 (belle-sip/1.6.3)
Authorization:  Digest realm="asterisk", nonce="4d5ef118", algorithm=MD5, username="john",  uri="sip:jacques@", response="0303ba30b59b2e5130b1d018307753a6"

message: 2020-04-08 15:46:12:235 channel [0x559126864970]: received [542] new bytes from [UDP://::ffff:]:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP;branch=z9hG4bK.uqUmHRum-;received=;rport=5060
From: <sip:address@hidden>;tag=vE-hfEwSx
To: <sip:address@hidden>;tag=as4927b86b
Call-ID: EP3owvMfzb
Server: Asterisk PBX 13.14.1~dfsg-2+deb9u4
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="62900e07", stale=true
Content-Length: 0

message: 2020-04-08 15:46:12:239 channel [0x559126864970] [542] bytes parsed
message: 2020-04-08 15:46:12:240 channel message ready
message: 2020-04-08 15:46:12:240 message is response
message: 2020-04-08 15:46:12:240 learn_public_ip_port
message: 2020-04-08 15:46:12:240 set_public_ip_port (0x559126864970,, 5060)
message: 2020-04-08 15:46:12:240 Found transaction matching response.
message: 2020-04-08 15:46:12:240 Changing [client] [SUBSCRIBE] transaction [0x55912642ddc0], from state [TRYING] to [COMPLETED]
message: 2020-04-08 15:46:12:240 Dialog [0x5591269c1200]: now updated by transaction [0x55912642ddc0].
message: 2020-04-08 15:46:12:240 belle_sip_dialog_schedule_expiration() dialog=0x5591269c1200 expires_value=600
message: 2020-04-08 15:46:12:240 Dialog [0x5591269c1200]: SUBSCRIBE refresh rejected or unanswered code=401
message: 2020-04-08 15:46:12:240 Dialog [0x5591269c1200] deleted (is_expired=0)
error: 2020-04-08 15:46:12:240 Unexpected dialog state [BELLE_SIP_DIALOG_TERMINATED] for dialog [0x5591269c1200], cannot refresh [SUBSCRIBE]

Does linphone actually have to delete the dialog just because it got a stale nonce?  Can't it just use the new nonce and continue?

No, that’s probably the matter. This 401 should not trigger dialog destruction. It should be passed to the refresher to retry subscription refresh with new Authorization header.
An option to investigate this issue is to modify the belle-sip tester « SUBSCRIBE » from suite « Refresher" at line
by adding: server->max_nc_count=3; 

It should more or less simulate the Asterix behavior you described. Next step will be to understand why this dialog is delete instead of being refreshed with new Authorization header

Linphone-developers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]