Summary:ASTERISK-17530: [patch] (Call Completion / SIP) PUBLISH Fails (412 Conditional Request Failed)
Reporter:George Konopacki (georgekonopacki)Labels:
Date Opened:2011-03-09 09:16:32.000-0600Date Closed:2011-03-10 09:28:57.000-0600
Versions:1.8.3 Frequency of
Environment:Attachments:( 0) 18946.patch
Description:Tested with release version of 1.8.0.

When the asterisk server receives a PUBLISH message for call completion, the function ‘cc_esc_publish_handler’ gets called in ‘chan_sip.c’.

This function then calls ‘find_sip_cc_agent_by_notify_uri’. This function always fails to find the agent so a response of ‘412 Conditional Request Failed’ is sent.

By replacing ‘find_sip_cc_agent_by_notify_uri’ with ‘find_sip_cc_agent_by_subscribe_uri’ then everything then works as expected.

This bug also appears to be in 1.8.3 (not tested, only looked at the source code).
Comments:By: Mark Michelson (mmichelson) 2011-03-09 11:03:05.000-0600

Which URI are you putting in the R-URI when you send the PUBLISH? The NOTIFY that said the target was ready contained a new URI, and that's what Asterisk is expecting the PUBLISH to use. If you're re-using the URI from the SUBSCRIBE, that would be why the bug is occurring.

I think the best solution to this would be for Asterisk to expect the URI from the NOTIFY to be used, but fall back to trying the URI from the SUBSCRIBE if the first try does not succeed. Does this sound reasonable to you? I can re-read the call completion draft just to be certain we didn't misinterpret which URI the PUBLISH is supposed to use.

By: Mark Michelson (mmichelson) 2011-03-09 11:05:27.000-0600

From section 6.5:

 "Each PUBLISH SHOULD be sent to the URI as received in the NOTIFY, or
  within the corresponding SUBSCRIBE dialog, or if that is not
  possible, to the corresponding monitor URI as received in the Call-
  Info header, ..."

It sounds like Asterisk should be tolerant of PUBLISH requests using either URI.

EDIT: Expanded the quote from the draft.

By: Mark Michelson (mmichelson) 2011-03-09 13:17:42.000-0600

I've uploaded a patch that was made against revision 306356 of the 1.8 branch. See if it does the trick. Thanks!

By: George Konopacki (georgekonopacki) 2011-03-10 03:09:33.000-0600

Thanks for your quick response. I will try your fix and let you know.

From one of your previous questions, we are using the URI provided in the call-info header.


I call you and get 180 Ringing, so I clear the call and request for call completion using SUBSCRIBE. We then receive a 200 OK and a NOTIFY (cc-state: queued).

Note: this NOTIFY does NOT contain a cc-uri in its message body.

I now become unavailable e.g I am going into a meeting or going home, so I wish to suspend my call completion callbacks. That is why we are using the URI provided in the call-info header.

Only the NOTIFY(cc-state: ready) contains a cc-uri in its message body.

By: George Konopacki (georgekonopacki) 2011-03-10 07:17:42.000-0600

The fix works, thank you.

By: Digium Subversion (svnbot) 2011-03-10 09:17:06.000-0600

Repository: asterisk
Revision: 310231

U   branches/1.8/channels/chan_sip.c

r310231 | mmichelson | 2011-03-10 09:17:05 -0600 (Thu, 10 Mar 2011) | 9 lines

Be more tolerant of what URI we accept for call completion PUBLISH requests.

(closes issue ASTERISK-17530)
Reported by: GeorgeKonopacki
     18946.patch uploaded by mmichelson (license 60)
Tested by: GeorgeKonopacki



By: Digium Subversion (svnbot) 2011-03-10 09:28:56.000-0600

Repository: asterisk
Revision: 310238

_U  trunk/
U   trunk/channels/chan_sip.c

r310238 | mmichelson | 2011-03-10 09:28:56 -0600 (Thu, 10 Mar 2011) | 15 lines

Merged revisions 310231 via svnmerge from

 r310231 | mmichelson | 2011-03-10 09:17:04 -0600 (Thu, 10 Mar 2011) | 9 lines
 Be more tolerant of what URI we accept for call completion PUBLISH requests.
 (closes issue ASTERISK-17530)
 Reported by: GeorgeKonopacki
       18946.patch uploaded by mmichelson (license 60)
 Tested by: GeorgeKonopacki