Summary: | ASTERISK-24877: Subsequent MWI NOTIFY R-URI truncated | ||
Reporter: | Anthony Messina (amessina) | Labels: | |
Date Opened: | 2015-03-14 12:22:48 | Date Closed: | 2015-03-26 09:16:41 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | 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_64 | Attachments: | ( 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! |