Summary:ASTERISK-14028: invalid value in Remote-Party-ID (RPID)
Reporter:pj (pj)Labels:
Date Opened:2009-04-28 13:18:30Date Closed:2009-10-06 13:15:31
Versions:Frequency of
Environment:Attachments:( 0) callerid.png
( 1) rpid.pcap
( 2) yehavi_debug.txt
( 3) yehavi_extensions.ael
Description:SIP/ringing message contains correct RPID info, but after call is answered, SIP/OK message, contains RPID with incorrect value, look below, or at attached packet dump.
If looking to wrong RPID value: "sw-146-324", I have suspicion, that can be related do dialplan logic - I'm using Dial application from inside switch() statement. This value "sw-146-324" is actually dialplan label, that is constructed from AEL.


Remote-Party-ID: "Pavel Jezek" <sip:324@>;party=called;privacy=off;screen=no

Remote-Party-ID: "sw-146-324" <sip:sw-146-324@>;party=called;privacy=off;screen=no
Comments:By: pj (pj) 2009-04-28 13:27:35

this is fragment from my dialplan:

        switch(${EXTEN}) {
          case 324:
            NoOP(rpid ${CONNECTEDLINE(all)});  <<<-- here still correct RPID

By: pj (pj) 2009-05-22 11:28:05

some hint, possible related to this issue:
wrong caller id "sw-34-324" instead of "324" is also displayed in "core show channels verbose" look at attached picture - callerid.png

By: pj (pj) 2009-06-23 12:26:00

I think, this bug is caused by overwriting exten and callerid number inside switch() dialplan processing. Maybe it will be better to place this bug into Core/PBX category.

By: Mark Michelson (mmichelson) 2009-06-23 17:37:40

Try passing the 'I' option to Dial. This option inhibits further connected line updates from being sent to the caller's phone. If you are using the CONNECTEDLINE function to set connected line information for the call, then I suspect that what is happening is that the caller ID of the outgoing channel is being sent later in a connected line update to the caller. The callerID of the outgoing call is set inside app_dial. The extension number is used for the number and the name is set using the data passed to the Dial application.

By: pj (pj) 2009-06-24 08:18:29

I updated to Asterisk SVN-trunk-r200254 and it seems, that RPID is now OK in my case (even without 'I' or any other dialplan modification). So it seems, that some commit between initial revision 190797 and current 200254 resolved this issue. But please leave this bugreport open some days, until I will have this proven with real phones.

By: Mark Michelson (mmichelson) 2009-06-24 08:40:49

Sure, just let me know when it may be closed.

By: Yehavi Bourvine (yehavi) 2009-06-30 03:12:16

I have a similar problem, but slightly different. I have two routes which behave slightly different.

The first one includes local extensions known to Asterisk:

_806XX => {
Set(CONNECTEDLINE(all)=Test <${EXTEN}>);

When I dial  extension 80621 I first see "Test 80621", and when answered it is change to the CALLERID field saved in user's table. So far - ok.

The other case is extensions not local to Asterisk which are routed via gateway:

_8[1-9]XXX => {
Set(CONNECTEDLINE(all)=Test <${EXTEN}>);

Here the called name is not displayed at all.

When I used patch 8824 on 1.4.21 it worked ok.

I attach the log from Asterisk for both calls.
                Thanks, __Yehavi:

By: Mark Michelson (mmichelson) 2009-06-30 14:47:52

yehavi: The file you uploaded is your extensions.ael file, and not logs of the two calls.

By: Yehavi Bourvine (yehavi) 2009-07-01 23:29:43

Sorry... Uploaded the debug now.


By: pj (pj) 2009-07-03 04:15:25

rpid is working with cisco 7940 (sip firmware) - enabled in phone config "remote_party_id: 1"
rpid currently doesn't work with Cisco 7905/7912 (sip firmware)
even it was working before, when rpid functionality was implemented as "RemoteParty" dialplan application, as I wrote in
in sip.conf I tried to set "sendrpid={yes,rpid,pai}" but no option bring rpid working for Cisco 7912/sip :(
rpid also doesn't work with eyebeam or xlite softphone (but maybe this softphones doesn't support rpid functionality at all)

By: Russell Bryant (russell) 2009-10-06 13:15:30

It looks like we're done with this one.  Let me know if I am mistaken.