[Home]

Summary:ASTERISK-20282: Call pickup incompatibility with Cisco 1760V + RPID
Reporter:Jeremy Kister (jkister)Labels:
Date Opened:2012-08-20 16:50:01Date Closed:2017-07-25 13:50:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General Channels/chan_sip/Interoperability
Versions:1.8.15.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) cisco-group-with-rpid.txt
( 1) extensions.conf
( 2) features.conf
( 3) group-without-rpid.txt
( 4) group-with-rpid.txt
( 5) group-with-rpid-and-debug.txt
( 6) group-with-rpid-and-debug-tofile.txt
( 7) single-with-rpid.txt
( 8) sip.conf
Description:I have a Cisco 1760V with FXO ports hooked to POTS lines talking SIP to
asterisk 1.8.15.0.

imagining in extensions.conf:
exten => 1,1,Dial(SIP/121)
exten => 2,1,Dial(SIP/121&SIP/122)

When a caller dials extension 2 /and/ I have
 trustrpid=yes
 generaterpid=yes
 sendrpid=yes
in sip.conf and I use the pickup exten, the caller is disconnected.

if i set the rpid generate/send = no for the cisco peer, the user is
connected.

calls to exten 1 work regardless of rpid settings.
Comments:By: Matt Jordan (mjordan) 2012-08-27 07:23:42.540-0500

I'm trying to figure out how this is a bug in Asterisk.  During the pickup attempt, Asterisk appears to be sending the Remote-Party-ID header you've specified.

{noformat}
Remote-Party-ID: "testing" <sip:139@192.168.1.7>;party=calling;privacy=off;screen=no
{noformat}

It looks like your Cisco 1760V is disconnecting the call immediately thereafter.  That isn't Asterisk's fault.  Is there a particular formatting of the Remote-Party-ID header that the Cisco 1760V needs?
By: Jeremy Kister (jkister) 2012-08-27 21:02:08.578-0500

will need a couple of days to experiment.

in the interim, is the ip address in the rpid field correct?

192.168.1.7  = cisco 1760
192.168.1.10 = linux/asterisk

the field sent from asterisk to cisco is:
Remote-Party-ID: "testing" <sip:139@192.168.1.7>;party=calling;privacy=off;screen=no

By: Jeremy Kister (jkister) 2012-08-27 23:32:47.596-0500

<adding cisco debug, haven't reviewed it yet, just adding for information's sake.>
By: Rusty Newton (rnewton) 2012-09-28 18:41:33.190-0500

Are you still having this issue or gathering debug? Did you find any other reason to suspect a bug in Asterisk?
By: Rusty Newton (rnewton) 2012-10-19 17:06:19.518-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines


By: Matt Jordan (mjordan) 2012-10-19 21:50:36.688-0500

{quote}
in the interim, is the ip address in the rpid field correct?
{quote}

Yes, Asterisk should be providing the Remote-Party-ID of the called party to the calling party.  This allows the calling party to make decisions about the remote called party (see this [draft|http://tools.ietf.org/html/draft-ietf-sip-privacy-04] for reference - as it turns out, Remote-Party-ID is not an RFC).

In your particular case, Asterisk is sending a re-INVITE followed by an UPDATE request to 9910@192.168.1.7 when the call pickup is initiated, as this is the first time it "knows" who the remote party should be.  The problem here is that Asterisk initially sends a Remote-Party-ID of {{"Sales Desk 2" <sip:112@192.168.1.7>;party=called;privacy=off;screen=no}} (re-INVITE) followed by {{"testing" <sip:139@192.168.1.7>;party=calling;privacy=off;screen=no}} (UPDATE).  It appears as if it is the UPDATE request that throws the Cisco off.

The UPDATE request here is interesting, as I'm not sure that Asterisk should be sending that one.  Its possible that something weird is happening with a combination of connected line updates; I'll have to dig into that it a bit more.  I'll reopen this issue for now.
By: Matt Jordan (mjordan) 2012-10-30 21:47:41.146-0500

There's a bit of interesting things that go in call pickup that makes this scenario a bit tricky.  Do you mind attaching a DEBUG 5 (or greater) log with 'sip set debug on' illustrating the problem?  I'd like to narrow down the portion in Asterisk that is causing the UPDATE request to be sent to the Cisco phones to figure out why Asterisk is sending it, and whether or not its expected behavior.  Thanks!
By: Jeremy Kister (jkister) 2012-10-31 02:31:55.521-0500

attached.  anything else i can do, please ask - pretty easy for me to change things around.
By: Matt Jordan (mjordan) 2012-11-01 21:40:05.466-0500

Whoops - looks like the CLI log doesn't contain all of the DEBUG messages that are occurring around that time - those should tell me a bit more about what Asterisk is doing when it sends the UPDATE request to the Cisco device.  That means I need the DEBUG messages for everything going on in {{chan_sip}} during that period - which means you'll probably have to either send DEBUG to the console, or else grab the full log.
By: Jeremy Kister (jkister) 2012-11-01 23:44:07.029-0500

mea culpa, didnt notice that.  real debug attached.
By: Rusty Newton (rnewton) 2017-07-25 13:50:56.640-0500

Closing this out since there has been no movement since 2012 and it was filed against a now EOL version of Asterisk.

If the issue exists with a recently supported version please request to reopen the issue and provide debug captured from the newer version.