[Home]

Summary:ASTERISK-16735: bad dialog-info remote information
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2010-09-26 15:52:44Date Closed:2012-05-08 10:48:19
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Subscriptions
Versions:Frequency of
Occurrence
Related
Issues:
is the original version of this clone:ASTERISK-20604 CLONE - bad dialog-info remote information
is related toASTERISK-20709 Asterisk sends wrong Caller IDs in first SIP NOTIFY message
is related toASTERISK-22939 [patch] Missing/wrong local party in dialog-info NOTIFY body
Environment:Attachments:( 0) 16735-tweak1.diff
( 1) 16735-tweak2.diff
( 2) local_remote_hint.diff
( 3) local_remote_hint2.diff
Description:Enabling "notifycid" to "yes" is making asterisk to send NOTIFY information about callid in dialog-info section. In this dialog, asterisk also sends information about local and remote side. I found that data about remote side are the same as in the local side, witch is obviously wrong, according to RFC4235.
Beneath is an example of such dialog.

****** ADDITIONAL INFORMATION ******

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="6" state="full"
entity="sip:test001@10.0.0.12">
<dialog id="test001" call-id="pickup-ca245a55-3b1618d9@172.16.0.84" direction="recipient">
<remote>
<identity display="test001">sip:test001@10.0.0.12</identity>
<target uri="sip:test001@10.0.0.12"/>
</remote>
<local>
<identity>sip:test001@10.0.0.12</identity>
<target uri="sip:test001@10.0.0.12"/>
</local>
<state>early</state>
</dialog>
</dialog-info>
Comments:By: Steven Wheeler (swheeler) 2011-02-23 14:15:04.000-0600

I am also experiencing this issue.  I am fairly new to reading the Asterisk source, but I think the problem is with chan_sip.c line 11613.

The variable mto holds the contents of the to header which should be used for the target information.  However, I don't think that mto should be used for the local identity information.  I think that mfrom, which holds the contents of the from header, should be used in the local identity field.

So line 11613 becomes:
local_display, local_target, local_target, mfrom, mto);

Hope this helps.

By: Niccolò Belli (darkbasic) 2011-12-21 07:28:25.927-0600

I do not agree with the severity assigned, this behaviour prevents call pickup: http://forum.snom.com/index.php?showtopic=8481
Please provide a fix.

By: Matt Jordan (mjordan) 2011-12-21 15:55:23.589-0600

Your issue is in queue, please be patient, and we will get to it as time permits and developer resources become available.



By: Niccolò Belli (darkbasic) 2012-01-27 07:50:51.328-0600

Is there any news? I'm sorry if I'm a bit persistent but I really need this fix.

By: Mark Michelson (mmichelson) 2012-02-14 15:54:35.228-0600

I'm not sure if anyone is still paying attention to this issue, but I've uploaded local_remote_hint.diff that improves things for me. The problem is that I'm not 100% sure if I have the remote and local parties correct here. They may need to be swapped, but I believe I have it correct.

By: Walter Doekes (wdoekes) 2012-02-14 16:18:58.424-0600

{quote}
+ need = strlen(connected_num) + strlen(p->fromdomain) + sizeof("sip:@");
+ remote_target = alloca(need);
+ snprintf(remote_target, need, "sip:%s@%s", connected_num, p->fromdomain);
{quote}

need = ... + 1; /* trailing nul? */





By: Richard Mudgett (rmudgett) 2012-02-14 18:49:54.346-0600

sizeof("sip:@") includes the nul terminator just as
char a[] = "sip:@";
includes the nul terminator.


By: Walter Doekes (wdoekes) 2012-02-15 01:01:47.208-0600

(@strlen vs sizeof: Right. Reading error on my part)

{quote}
direction: This attribute is either initiator or recipient, and
        indicates whether the observed user was the initiator of the
        dialog, or the recipient of the INVITE that created it.
{quote}
{quote}
  The "local" and "remote" elements are sub-elements of the dialog
  element that contain information about the local and remote
  participants, respectively.  They both have a number of optional
  sub-elements that indicate the identity conveyed by the participant,
  the target URI, the feature-tags of the target, and the
  session-description of the participant.
{quote}

I read that the observed/watched user is <local> and the direction
specifies who calls who.

But, as far as I can see, direction is always recipient in chan_sip.c.

- exten is the watched-user (should then be local)
- direction should switch depending on whether exten does the call
 or gets called?

Or am I reading this wrong?

If exten is the call-recipient, then remote_target should be based
on the caller->caller, right? Not on the caller->connected? Or? Now
I'm confused.


By: Maciej Krajewski (jamicque) 2012-02-15 08:22:39.661-0600

Walter IMHO you are right.

By: Mark Michelson (mmichelson) 2012-02-15 09:31:36.767-0600

The direction should always be recipient in this case because this code specifically only gets called if the watched extension is being called. So it sounds like I need to swap the local and remote. Easy enough. I'll upload a new patch ASAP.

By: Mark Michelson (mmichelson) 2012-02-15 09:39:43.351-0600

I have uploaded local_remote_hint2.diff. This swaps the remote and local information from the first diff.

By: Mark Michelson (mmichelson) 2012-02-20 10:35:05.041-0600

Any word on if the new patch does the right thing?

By: Mark Michelson (mmichelson) 2012-03-02 08:54:26.785-0600

Bump. Is my latest patch doing the right thing? I need to know whether to commit or create another patch.

By: Maciej Krajewski (jamicque) 2012-03-02 09:28:10.334-0600

IMHO it's ok, can anyone else confirm it?

By: Niccolò Belli (darkbasic) 2012-04-15 17:15:14.897-0500

Sorry for the delay, I just tested your patch (on 1.8.11 and 10.4-rc1) and it does break hints!
Even if in the console I see "Extension Changed 152[blf] new state Ringing for Notify User 154" my SNOM 300 BLF do not light anymore! Without RFC4235 (notifycid=no) snom's BLF does work properly.
We should fix this before 1.8.12/10.4 goes stable, otherwise it will be a regression.

By: Niccolò Belli (darkbasic) 2012-04-15 17:15:44.798-0500

How can I reopen this bug? I didn't find how to do it.

By: Maciej Krajewski (jamicque) 2012-04-16 03:34:13.939-0500

I confirm Niccolo's bug,
enabling cid breaks hints.

By: Maciej Krajewski (jamicque) 2012-04-16 03:39:59.023-0500

sorry- It was my mistake during testing, my Yealink phone did not subscribed - for me everything woks fine.

By: Matt Jordan (mjordan) 2012-04-16 08:13:40.065-0500

Niccolo:

I've reopened this issue.  Please attach a SIP DEBUG trace illustrating the SUBSCRIBE/NOTIFY request/responses to/from the SNOM phone that no longer is able to receive notifications for hints.

As an fyi, you can ask to have an issue reopened by contacting a bug marshal in #asterisk-bugs.

Thanks

Matt

By: Mark Michelson (mmichelson) 2012-04-23 13:01:22.373-0500

Niccolo:

I set up a SNOM 820 and had it subscribe to extension 2000@default. I then placed a call to extension 2000 from SIP peer 6000. As soon as 2000 began ringing, the SNOMs display changed to say "6000x2000". So there is apparently some degree of workingness here.

What's a bit odd is the NOTIFYs being sent by Asterisk to the SNOM. As soon as Asterisk sends the INVITE to 2000, Asterisk sends two NOTIFYs to the SNOM. The first NOTIFY has the following body:

{code}
<?xml version="1.0" encoding="ISO-8859-1"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pp="urn:ietf:params:xml:ns:pidf:person"
xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status"
xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person"
entity="sip:8000@10.24.21.180">
<pp:person><status>
<ep:activities><ep:busy/></ep:activities>
</status></pp:person>
<note>Ringing</note>
<tuple id="2000">
<contact priority="1">sip:2000@10.24.20.249</contact>
<status><basic>open</basic></status>
</tuple>
</presence>
{code}

and the second NOTIFY has the following body:

{code}
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="7" state="full" entity="sip:2000@10.24.20.249">
<dialog id="2000" call-id="pickup-3c6b0382395f-0fzyjwz64vtm" local-tag="7ln7qif67w" remote-tag="as19847b24" direction="recipient">
<remote>
<identity display="Bill">sip:6000@10.24.21.180</identity>
<target uri="sip:6000@10.24.21.180"/>
</remote>
<local>
<identity display="Phil">sip:2000@10.24.21.180</identity>
<target uri="sip:2000@10.24.21.180"/>
</local>
<state>early</state>
</dialog>
</dialog-info>
{code}

The most odd part, to me, is that the CSeq of the two NOTIFY requests are the same.

What I want to see is a SIP debug from before my patch (where BLF works) and a SIP debug from after my patch (where BLF does not work). I also would like to see your sip.conf file so I can see if there is a specific option that is affecting your setup. I'm having a real difficult time figuring out how my patch could have changed the behavior so drastically since all that I changed is what appears in the <remote> and <local> XML sections. In my setup, the identities are what I would expect them to be, too.

By: Mark Michelson (mmichelson) 2012-04-23 13:34:31.810-0500

As a final note, I removed my patch (svn diff -c -360862 | patch -p0). I tried again and still saw the bad NOTIFY behavior (two in a row with the same CSeq but different bodies). These were their bodies:

First:
{code}
<?xml version="1.0" encoding="ISO-8859-1"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pp="urn:ietf:params:xml:ns:pidf:person"
xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status"
xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person"
entity="sip:8000@10.24.21.180">
<pp:person><status>
<ep:activities><ep:busy/></ep:activities>
</status></pp:person>
<note>Ringing</note>
<tuple id="2000">
<contact priority="1">sip:2000@10.24.20.249</contact>
<status><basic>open</basic></status>
</tuple>
</presence>
{code}

Second:
{code}
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="full" entity="sip:2000@10.24.20.249">
<dialog id="2000" call-id="pickup-3c6b0ecf6eb0-15gwboo4ogih" local-tag="lowhgy5132" remote-tag="as1c8886a5" direction="recipient">
<remote>
<identity display="Bill">sip:6000@10.24.21.180</identity>
<target uri="sip:6000@10.24.21.180"/>
</remote>
<local>
<identity>sip:2000@10.24.20.249</identity>
<target uri="sip:2000@10.24.20.249"/>
</local>
<state>early</state>
</dialog>
</dialog-info>
{code}

So if the odd NOTIFY sending is what is breaking BLF, it's not my patch that did it. If it really is the changed identities that is somehow breaking BLF, I don't know why that would be happening. So I'll still require both of the SIP debugs and your sip.conf.

By: Niccolò Belli (darkbasic) 2012-04-25 07:41:00.871-0500

This is SIP Trace without your patch (BLF does light with notifycid=yes):

Received from udp:192.168.3.1:5060 at 25/4/2012 14:19:05:705 (571 bytes):

OPTIONS sip:154@192.168.3.6:2048;line=hrh0tsp2 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK4800dfd9;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@192.168.3.1>;tag=as61996fdc
To: <sip:154@192.168.3.6:2048;line=hrh0tsp2>
Contact: <sip:asterisk@192.168.3.1:5060>
Call-ID: 7dd31531027516747cff49a323dfff80@192.168.3.1:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 10.4.0-rc1
Date: Wed, 25 Apr 2012 12:19:05 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Sent to udp:192.168.3.1:5060 at 25/4/2012 14:19:05:714 (616 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK4800dfd9;rport=5060
From: "asterisk" <sip:asterisk@192.168.3.1>;tag=as61996fdc
To: <sip:154@192.168.3.6:2048;line=hrh0tsp2>
Call-ID: 7dd31531027516747cff49a323dfff80@192.168.3.1:5060                                                                                                                          
CSeq: 102 OPTIONS                                                                                                                                                                  
Contact: <sip:154@192.168.3.6:2048;line=hrh0tsp2>;reg-id=1                                                                                                                          
User-Agent: snom300/8.4.35                                                                                                                                                          
Accept-Language: en                                                                                                                                                                
Accept: application/sdp                                                                                                                                                            
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE                                                                                    
Allow-Events: talk, hold, refer, call-info                                                                                                                                          
Supported: timer, 100rel, replaces, from-change                                                                                                                                    
Content-Length: 0                                                                                                                                                                  

Received from udp:192.168.3.1:5060 at 25/4/2012 14:19:08:862 (984 bytes):

NOTIFY sip:154@192.168.3.6:2048;line=hrh0tsp2 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK54a1f299;rport
Max-Forwards: 70
From: <sip:152@192.168.3.1;user=phone>;tag=as5318288e
To: <sip:154@192.168.3.1>;tag=dv0gj1i01e
Contact: <sip:152@192.168.3.1:5060>
Call-ID: 3c26701c1f9d-fy6gd0g8nnhd
CSeq: 104 NOTIFY
User-Agent: Asterisk PBX 10.4.0-rc1
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 513

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="full" entity="sip:152@192.168.3.1">
<dialog id="152" call-id="pickup-3c26701c1f9d-fy6gd0g8nnhd" local-tag="dv0gj1i01e" remote-tag="as5318288e" direction="recipient">
<remote>
<identity display="152">sip:152@192.168.3.1</identity>
<target uri="sip:152@192.168.3.1"/>
</remote>
<local>
<identity>sip:152@192.168.3.1</identity>
<target uri="sip:152@192.168.3.1"/>
</local>
<state>early</state>
</dialog>
</dialog-info>

Sent to udp:192.168.3.1:5060 at 25/4/2012 14:19:08:898 (257 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK54a1f299;rport=5060
From: <sip:152@192.168.3.1;user=phone>;tag=as5318288e
To: <sip:154@192.168.3.1>;tag=dv0gj1i01e
Call-ID: 3c26701c1f9d-fy6gd0g8nnhd
CSeq: 104 NOTIFY
Content-Length: 0

Received from udp:192.168.3.1:5060 at 25/4/2012 14:19:15:258 (673 bytes):

NOTIFY sip:154@192.168.3.6:2048;line=hrh0tsp2 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK33893bd0;rport
Max-Forwards: 70
From: <sip:152@192.168.3.1;user=phone>;tag=as5318288e
To: <sip:154@192.168.3.1>;tag=dv0gj1i01e
Contact: <sip:152@192.168.3.1:5060>
Call-ID: 3c26701c1f9d-fy6gd0g8nnhd
CSeq: 105 NOTIFY
User-Agent: Asterisk PBX 10.4.0-rc1
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 202

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="full" entity="sip:152@192.168.3.1">
<dialog id="152">
<state>terminated</state>
</dialog>
</dialog-info>

Sent to udp:192.168.3.1:5060 at 25/4/2012 14:19:15:276 (257 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK33893bd0;rport=5060
From: <sip:152@192.168.3.1;user=phone>;tag=as5318288e
To: <sip:154@192.168.3.1>;tag=dv0gj1i01e
Call-ID: 3c26701c1f9d-fy6gd0g8nnhd
CSeq: 105 NOTIFY
Content-Length: 0

.
.
.
.
.
.
.
.

And this is with your patch (no light when ringing):

Received from udp:192.168.3.1:5060 at 25/4/2012 14:33:59:163 (998 bytes):

NOTIFY sip:154@192.168.3.6:2048;line=zuhg6n50 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK749f5ded;rport
Max-Forwards: 70
From: <sip:152@192.168.3.1;user=phone>;tag=as65031181
To: <sip:154@192.168.3.1>;tag=in1qiqy1kn
Contact: <sip:152@192.168.3.1:5060>
Call-ID: 3c26701c5200-imgs6q4hrk06
CSeq: 103 NOTIFY
User-Agent: Asterisk PBX 10.4.0-rc1
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 527

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:152@192.168.3.1">
<dialog id="152" call-id="pickup-3c26701c5200-imgs6q4hrk06" local-tag="in1qiqy1kn" remote-tag="as65031181" direction="recipient">
<remote>
<identity display="152">sip:154@192.168.3.1</identity>
<target uri="sip:154@192.168.3.1"/>
</remote>
<local>
<identity display="152">sip:152@192.168.3.1</identity>
<target uri="sip:152@192.168.3.1"/>
</local>
<state>early</state>
</dialog>
</dialog-info>

Sent to udp:192.168.3.1:5060 at 25/4/2012 14:33:59:188 (257 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK749f5ded;rport=5060
From: <sip:152@192.168.3.1;user=phone>;tag=as65031181
To: <sip:154@192.168.3.1>;tag=in1qiqy1kn
Call-ID: 3c26701c5200-imgs6q4hrk06
CSeq: 103 NOTIFY
Content-Length: 0

Received from udp:192.168.3.1:5060 at 25/4/2012 14:34:07:119 (673 bytes):

NOTIFY sip:154@192.168.3.6:2048;line=zuhg6n50 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK3e9fa259;rport
Max-Forwards: 70
From: <sip:152@192.168.3.1;user=phone>;tag=as65031181
To: <sip:154@192.168.3.1>;tag=in1qiqy1kn
Contact: <sip:152@192.168.3.1:5060>
Call-ID: 3c26701c5200-imgs6q4hrk06
CSeq: 104 NOTIFY
User-Agent: Asterisk PBX 10.4.0-rc1
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 202

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="full" entity="sip:152@192.168.3.1">
<dialog id="152">
<state>terminated</state>
</dialog>
</dialog-info>

Sent to udp:192.168.3.1:5060 at 25/4/2012 14:34:07:131 (257 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK3e9fa259;rport=5060
From: <sip:152@192.168.3.1;user=phone>;tag=as65031181
To: <sip:154@192.168.3.1>;tag=in1qiqy1kn
Call-ID: 3c26701c5200-imgs6q4hrk06
CSeq: 104 NOTIFY
Content-Length: 0

Received from udp:192.168.3.1:5060 at 25/4/2012 14:34:07:949 (571 bytes):

OPTIONS sip:154@192.168.3.6:2048;line=zuhg6n50 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK06fe925c;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@192.168.3.1>;tag=as481b0529
To: <sip:154@192.168.3.6:2048;line=zuhg6n50>
Contact: <sip:asterisk@192.168.3.1:5060>
Call-ID: 7f2399685cf218941be860d1193c723e@192.168.3.1:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 10.4.0-rc1
Date: Wed, 25 Apr 2012 12:34:07 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Sent to udp:192.168.3.1:5060 at 25/4/2012 14:34:07:958 (616 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.3.1:5060;branch=z9hG4bK06fe925c;rport=5060
From: "asterisk" <sip:asterisk@192.168.3.1>;tag=as481b0529
To: <sip:154@192.168.3.6:2048;line=zuhg6n50>
Call-ID: 7f2399685cf218941be860d1193c723e@192.168.3.1:5060
CSeq: 102 OPTIONS
Contact: <sip:154@192.168.3.6:2048;line=zuhg6n50>;reg-id=1
User-Agent: snom300/8.4.35
Accept-Language: en
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Content-Length: 0




Phone is SNOM 300 with firmware 8.4.35.

P.S.
Which tag should did you use for the sip trace?

By: Mark Michelson (mmichelson) 2012-04-25 16:28:15.430-0500

Thanks for the trace. FYI, I used the \{code\} tag for my traces. \{noformat\} would also work, too.

I'm comparing the NOTIFYs, and aside from the obvious differences like Call-ID, tags, and CSeq, the only differences I see are the following:

* The remote SIP URI has changed from sip:152@192.168.3.1 to sip:154@192.168.3.1
* The local SIP identity now has a display value ("152")

Assuming you did the exact same scenario twice here, I must assume that
{code}
ast_channel_callback(find_calling_channel, NULL, p, 0)
{code}
is returning {{NULL}}. The reason I assume this is that within the if block I have not changed how the remote URI and display are obtained, but yet you have a different remote URI in your two test runs. This can fail either because

* The extension being monitored by the SNOM is not the same one being dialed.
* The context of the extension being monitored by the SNOM is not the same one being dialed.

If either of these is the case, then you should not set {{notifycid=yes}} at all because, to quote the sip.conf.sample:

{quote}
Note that this feature will only work properly when the
incoming call is using the same extension and context that
is being used as the hint for the called extension.  This means
that it won't work when using subscribecontext for your sip
user or peer (if subscribecontext is different than context).
{quote}

This is a limitation of the way the {{notifycid}} option works in chan_sip. If your call and your hint use the same extension number but different contexts, you can work around this by setting {{notifycid=ignore-context}}.

This explains why even with my patch not applied, I did not get the same remote and local URIs in my tests. This may also be the piece of information I need to reproduce the broken BLF as well. For now, if either of the two conditions I outlined is true, please do not set {{notifycid=yes}}.

I am going to try an experiment where the extension monitored differs from the extension called and see if I can reproduce the problem and see exactly what piece of information the SNOM phone does not like.

Thank you again for your feedback.

By: Niccolò Belli (darkbasic) 2012-04-25 16:54:11.739-0500

Can please answer my question on this thread? http://lists.digium.com/pipermail/asterisk-users/2012-April/271740.html

I have doubts regarding the meaning of context in Pickup()...

Anyway it doesn't work even with notifycid=ignore-context.

By: Mark Michelson (mmichelson) 2012-04-26 09:19:00.207-0500

I have given a reply to your e-mail.

Now, let's stay on task, because this is veering off into call pickup territory, and this issue had nothing to do with that initially. :)

So when this issue was originally opened, if it had been made clear that the reporter was trying to pick up a ringing channel whose extension and/or context was different from the one the hint exists in, then I suspect this issue would have been closed and no patch would have been provided since this is a known shortcoming of the {{notifycid}} setting. However, I actually like my patch since it seems to work quite nicely *if* notifycid is used in the situation for which it is known to work.

The fact that I have broken hints for the situation where {{notifycid}} should not be used makes me want to say "too bad" and just close this issue out. The problem is that I still have *no idea* which part of my patch has caused your BLF not to work any more since in my experiments, it continues to work with my SNOM 820. My only suspicion is the line

As I've stated before the differences in the NOTIFY you saw were that the remote identity had a new URI and that the local identity now had a display. What I'm going to do is attach two patches to this issue. I will give instructions on what to do with them when I attach them.



By: Mark Michelson (mmichelson) 2012-04-26 09:32:39.224-0500

The first patch I have uploaded is 16735-tweak1.diff. This patch changes the remote target URI to be based on the To header of the original call instead of the From header of the original call. This is how it behaved prior to my patch.

VERY IMPORTANT: In order to apply this patch, you must first apply local_remote_hint2.diff and then apply 16735-tweak1.diff. Please test and let me know if this fixes your BLF.

By: Mark Michelson (mmichelson) 2012-04-26 09:34:59.493-0500

The second patch I am attaching is 16735-tweak2.diff. This removes the display from the local identity.

Just like with 16735-tweak1.diff, you MUST apply local_remote_hint2.diff and then apply 16735-tweak2.diff. If 16735-tweak1.diff did not fix your BLF, try 16735-tweak2.diff and let me know if this works.

If neither patch works individually, try applying both 16735-tweak1.diff and 16735-tweak2.diff and see if that works.

By: Niccolò Belli (darkbasic) 2012-04-26 09:51:05.995-0500

Thanks.
I will also try with local_remote_hint2.diff alone but with the phones in the same context, I'm pretty sure it didn't work even such a way.

By: Niccolò Belli (darkbasic) 2012-04-26 14:45:55.220-0500

As I said it doesn't work even if the phones are in the same context, BUT... I discovered it *does* work when notifying the BUSY state, but *not* the RINGING state! :)

I'm going to test your patches now.

By: Niccolò Belli (darkbasic) 2012-04-26 16:58:02.954-0500

The behaviour is a bit complex so I will show my dialplan:

[phones-metano]
exten => 101,1,Dial(DAHDI/9)
same => n,Hangup()

exten => 102,1,Dial(DAHDI/10)
same => n,Hangup()

exten => _10[356],1,Dial(SIP/${EXTEN})
same => n,Hangup()

exten => 101,hint,DAHDI/9
exten => 102,hint,DAHDI/10
exten => 103,hint,SIP/103
exten => 105,hint,SIP/105
exten => 106,hint,SIP/106



[from-isdn-1]
exten => _X!,1,Answer()
same => n,Goto(sub-metano,menu,1)

[sub-metano]
exten => menu,1,Background(recordings/uffici)
same => n,Background(recordings/magazzino)
same => n,WaitExten()

exten => 1,1,Hangup()

exten => 2,1,Queue(Magazzino,tx,,,180)
same => n,Playback(recordings/nessun-operatore-disponibile)
same => n,Hangup()

exten => t,1,Goto(menu,1)

exten => i,1,Playback(recordings/selezione-non-valida)
same => n,Goto(menu,1)




"Magazzino"'s strategy is ringall.

DAHDI/101, DAHDI/102 and SIP/103 are members of the queue "Magazzino".

In my SNOM 370 phones (firmware 8.7.3.7) I mapped the keys with "dest 101", "dest 102", "dest 103" etc.. instead of "blf 101" etc.. so I don't use the Pickup() app at all.

"dest" uses 1° pickup method: http://wiki.snom.com/Category:HowTo:Call_Pickup
http://wiki.snom.com/Settings/fkey/dest



Case A: I call DAHDI/101 from DAHDI/102. Then I try to pickup 101.
Case B: I receive a call from the ISDN [from-isdn-1], the user press "2". Then I try to pickup 101.

ONLY local_remote_hint2.diff, CASE A: as soon as I raise DAHDI/102's receiver the relative light goes steady, after dialing 101's button starts blinking, *but* 102's light turns off!. Pickup does work.

ONLY local_remote_hint2.diff, CASE B: as soon as the user press "2" to go in the queue I see *nothing*. hints do not work at all. If DAHDI/101 does answer the relative light goes steady (but it didn't blink when ringing!).

PATCH 1, CASE A: as soon as I raise DAHDI/102's receiver the relative light goes steady, after dialing the number 101's button starts blinking. Pickup does work.

PATCH 1, CASE B: as soon as the user press "2" to go in the queue I see 101, 102 and 103 blinking. Unfortunately I can't pickup 101. From the console I see it tries to pickup 101@phones-metano, I think it should try to pickup 2@phones-metano to succeed.

PATCH 2, CASE A: same of ONLY local_remote_hint2.diff, CASE A
PATCH 2, CASE B: same of ONLY local_remote_hint2.diff, CASE B

By: Niccolò Belli (darkbasic) 2012-04-26 17:28:13.339-0500

Please read the edit instead of the original message, I did some more tests!

By: Mark Michelson (mmichelson) 2012-04-30 09:17:56.695-0500

Just so we're 100% clear here, did both Case A and Case B succeed before applying local_remote_hint2.diff?

We really want to push out a release soon, so my plan for now is going to be to revert what was committed (local_remote_hint2.diff) and get the original issue fixed in the next version instead.

By: Niccolò Belli (darkbasic) 2012-05-03 15:31:14.012-0500

Hi, I'm sorry for the delay.

Without local_remote_hint2.diff, CASE A: like PATCH 1.
Without local_remote_hint2.diff, CASE B: like PATCH 1.

So pickup for CASE B *never* worked, but at least hints do work without local_remote_hint2.diff (or with patch 1 which is the same).


Is there any chance to get a working pickup for case B in a few weeks? I'm switching from an old asterisk installation and I really need this working, deadline was on april 27 and I fear I will have to cut some of the planned features :(

By: Mark Michelson (mmichelson) 2012-05-08 10:34:28.059-0500

So in order to get more accurate identification without breaking hints, I need to commit local_remote_hint2.diff with 16735-tweak1.diff. The problem here is that you've latched onto an issue that is in no way related to call pickup in your scenario. What you need to do is to open a separate issue about the situation where your call pickup is not working as you expect. The developers will prioritize it and get around to it when we can. I can give no guarantee on how long that will be though. Thank you very much for testing the patches and helping to narrow what the issue with the first patch was.

By: Stefan Reuter (srt) 2012-11-19 22:26:34.872-0600

Unfortunately what is currently implemented in 11.1.0-rc1 doesn't work with Polycom phones. Asterisk sends two NOTIFY messages where the first contains the incorrect caller ids followed by one with the correct ones. Polycom phones do not update the display however. See http://community.polycom.com/t5/VoIP/Busy-Lamp-Field-Caller-IDs-not-updated/td-p/24080

The following small patch for 11.1.0-rc1 prevents the first incorrect SIP NOTIFY message from being sent if notifycid is set:

[edit - removed inline code - mjordan]

See also: http://community.polycom.com/t5/VoIP/Busy-Lamp-Field-Caller-IDs-not-updated/m-p/24090

By: Matt Jordan (mjordan) 2012-11-20 21:20:04.583-0600

This issue has been closed out.  Given how confused the issue became with multiple problems snowballed together, it'd be far cleaner to open a new issue if you are still experiencing a problem with the NOTIFY requests Asterisk is sending.  Please include a pcap with the issue demonstrating the message traffic, and attach any patches to the code as a unified diff after signing a license contributor agreement.

Thanks!

By: Stefan Reuter (srt) 2012-11-20 21:57:53.108-0600

See ASTERISK-20709

By: Pietro Bertera (pbertera) 2013-12-04 10:24:59.112-0600

Just to keep all watcher aligned, related issue: ASTERISK-22939

By: Volker Kettenbach (vsauer) 2017-03-03 16:27:12.570-0600

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