[Home]

Summary:ASTERISK-22939: [patch] Missing/wrong local party in dialog-info NOTIFY body
Reporter:Pietro Bertera (pbertera)Labels:
Date Opened:2013-12-04 08:51:44.000-0600Date Closed:2014-01-28 17:21:43.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Subscriptions
Versions:1.8.15.0 1.8.24.0 Frequency of
Occurrence
Related
Issues:
is related toASTERISK-20709 Asterisk sends wrong Caller IDs in first SIP NOTIFY message
is related toASTERISK-16735 bad dialog-info remote information
Environment:Attachments:( 0) ASTERISK-16735-local-dialoginfo.patch
( 1) Asterisk-notifycid.pcap
Description:When Asterisk sends the NOTIFY for dialog-info subscriptions the body must contains local end remote parties informations (if notifycid is enabled in sip.conf).

In latest Asterisk certified (1.8.15-cert3) the local party contained into the XML body is wrong:

Here an example:

{code:xml}
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="full" entity="sip:151@172.16.18.40">
<dialog id="151" call-id="pickup-529f3da7a0f9-kl0tcqsb55r2" local-tag="hd7xevk85l" remote-tag="as5ef372fc" direction="recipient">
<remote>
<identity display="152">sip:152@172.16.18.40</identity>
<target uri="sip:152@172.16.18.40"/>
</remote>
<local>
<identity display="">sip:@172.16.18.40</identity>
<target uri="sip:@172.16.18.40"/>
</local>
<state>early</state>
</dialog>
</dialog-info>
{code}

as you can see the extension part is missing from the local/identiy and local/target tags.
You can see as well in the attached pcap trace [^Asterisk-notifycid.pcap] (packet #8)

You can easy reproduce using the below configuration:

*extensions.conf:*

{noformat}
[general]
static=yes
writeprotect=no
clearglobalvars=no

[globals]


[default]

[from-sip]
exten => _X.,hint,SIP/${EXTEN}
exten => _X.,1,Answer()
exten => _X.,n,Dial(SIP/${EXTEN},30)
{noformat}

*sip.conf:*

{noformat}
[general]
allowsubscribe=yes
notifyringing=yes
notifyhold=yes
call-limit=99
notifycid=ignore-context

counteronpeer=no
progressinband=never
pickupgroup=1
canreinvite=yes

[basic](!)
context=from-sip
subscribecontext=from-sip
call-limit=10
progressinband=never
type=friend

[150](basic)
secret=1234
host=dynamic
type=friend

[151](basic)
secret=1234
host=dynamic
type=friend

[152](basic)
secret=1234
host=dynamic
type=friend
{noformat}

*Reproduction steps:*

- register 3 devices (A,B,C) against defined extensions,
- configure a device (A) to subscribe for dialog-info events against extension B
- device B calls device C

Attached patch (written agains 1.8.15-cert3) [^ASTERISK-16735-local-dialoginfo.patch] provides a fallback mechanism in case of extension part is missing due to caller->connected.id.name.valid = false.
Oldest Asterisk versions are not affected (tested 1.8.11).
Comments:By: Pietro Bertera (pbertera) 2013-12-04 08:56:03.004-0600

pcap trace
By: Matt Jordan (mjordan) 2013-12-07 18:50:28.511-0600

So, this is basically a duplicate of both ASTERISK-16735 (of some sort - that issue became ridiculously confused), as well as ASTERISK-20709. In all cases, multiple patches were proposed.

In all cases, however, we are entering into a situation where we are attempting to send a NOTIFY request to something that *may not* be able to get the connected line information for some aspect of what is subscribed for. In this case, your patch is essentially ignoring (or attempting to work around) the fact that {{connected.id.number.valid}} is {{0}} on the {{caller}} channel. If that's the case, then in {{sip_call}}:

{noformat}
if (!ast_strlen_zero(p->cid_num)
|| (p->callingpres & AST_PRES_RESTRICTION) != AST_PRES_ALLOWED) {
{noformat}

That means we either didn't have a caller ID number, or the presentation of said number said it wasn't allowed. I'm not sure the correct answer here is to ignore that.

What I am curious is why the {{caller}} channel's {{connected.id.number.valid}} is false here.
By: Matt Jordan (mjordan) 2013-12-07 18:51:31.087-0600

Granted, putting {{sip:@xxx.xxx.xxx.xxx}} isn't correct. We should probably be putting "Anonymous" in there if nothing else.
By: Rusty Newton (rnewton) 2014-01-03 18:20:53.191-0600

@Pietro, Did you have any response to Matt's comments? The issue is in Waiting For Feedback status for your feedback.
By: Pietro Bertera (pbertera) 2014-01-05 05:32:08.425-0600

Yes, sorry for my late.
I don't know why {{connected.id.number.valid}} is false here, but the old code (before patch introduced with ASTERISK-16735) was a better behavior except for particular situations (like using queues).
The attached patch reproduces the old behavior in case of {{connected.id.number.valid = 0}}..
By: Rusty Newton (rnewton) 2014-01-28 17:21:29.442-0600

Reverting to previous broken behavior doesn't appear to be the best option. Matt mentioned this is a duplicate of ASTERISK-20709. We are going to close this one out, feel free to comment further on ASTERISK-20709.  Thanks for the report!
By: Volker Kettenbach (vsauer) 2017-03-03 16:26:41.428-0600

This problems seems to be reappeared in recent version of asterisk:
ASTERISK-24488