[Home]

Summary:ASTERISK-24877: Subsequent MWI NOTIFY R-URI truncated
Reporter:Anthony Messina (amessina)Labels:
Date Opened:2015-03-14 12:22:48Date Closed:2015-03-26 09:16:41
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip_mwi
Versions:13.2.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:asterisk-13.2.0-5.fc21.x86_64 (branches/13@432614) pjproject-2.3-6.fc21.x86_64 kernel-3.18.9-200.fc21.x86_64Attachments:( 0) asterisk-NOTIFY-truncate-RURI.txt
Description:When subscribing to Asterisk MWI via Kamailio, I've noticed that after the initial SUBSCRIBE immediately after REGISTER, Asterisk will send a NOTIFY to the proper contact URI in the NOFITY R-URI.  However, when a new voicemail is created, the subsequent NOTIFY attempts truncate the contact URI in the NOFITY R-URI and Asterisk's NOTIFY is retried several times after never reaches the UAC and eventually gets a timeout back from Kamailo.

Initial SUBSCRIBE with immediate NOTIFY from Asterisk:
{code}
m: "Test User" <sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme>;+sip.ice
...
NOTIFY sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme SIP/2.0
...
SIP/2.0 408 Request Timeout
{code}

Subsequent NOTIFY from Asterisk after a new voicemail is left:
{code}
NOTIFY sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84O SIP/2.0
{code}

The subsequent NOTIFY R-URI is truncated, missing the remainder of the original Contact URI:
{code}
C82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme
{code}
Comments:By: Rusty Newton (rnewton) 2015-03-23 08:08:53.856-0500

Thanks Anthony! If you get a chance, can you upload an Asterisk full log with SIP trace and debug cranked up so we can see debug logs around the time the issue occurs.

Probably nothing too helpful in addition to what you have posted, but maybe!

By: Anthony Messina (amessina) 2015-03-24 15:51:39.990-0500

This attachment is the SIP request trace from the example I used to file the original report.

By: Anthony Messina (amessina) 2015-03-24 16:24:25.925-0500

Rusty, I've also got some help from the Kamailio folks on this one, and after looking at the SIP request trace, it looks like my UAC CSipSimple (also PJSIP) may be to blame for truncating the Contact header returned on the 200 OK to the first NOTIFY from Asterisk.  So I have some more digging to do.

By: Joshua C. Colp (jcolp) 2015-03-26 09:16:41.286-0500

After looking at this myself it does indeed to be the remote client. If after further investigation you find that somehow Asterisk is at fault feel free to reopen this. Cheers!