Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
3484
Views
0
Helpful
7
Replies

PAP2T Remote-Party-ID: wrong interpretation

Mogilevtsev
Level 1
Level 1

‎01-10-2012 12:41 PM - edited ‎03-21-2019 09:41 AM

My PAP2T works with YouMagic SIP Service (http://www.youmagic.com/index.php?lang=en)

It displays wrong Caller ID - it displays MY number (+7499709xxxx) not calling party number (+7916xxxxxxx)

Wiresharked INVITE request

INVITE sip:7499709xxxx@a.b.c.d:34148;rinstance=2e75e33eb1045b0e;transport=udp SIP/2.0

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-675ee40795ee140c-1---d8754z-;rport
Via: SIP/2.0/UDP 80.75.132.203:5061;branch=z9hG4bK-ycj2xzrf7q2zddvi;rport=5061
Max-Forwards: 69
Record-Route: <sip:80.75.132.203:5060;lr;transport=udp>
Record-Route: <sip:80.75.132.203:5060;lr;transport=UDP>
Contact: "Anonymous"<sip:80.75.132.203:5061>
To: <sip:7499709xxxx@80.75.132.203>
From: <sip:+7916xxxxxxx@80.75.132.203>;tag=746xthzxk5k2hezs.o
Call-ID: 1859003111212012142710@10.128.30.61~o
CSeq: 227 INVITE
Expires: 300
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
Remote-Party-ID: <sip:7916xxxxxxx@10.128.30.15>;npi=1;screen-ind=3;privacy=off;screen=yes;ton=2;party=calling
Remote-Party-ID: <sip:7499709xxxx@10.128.30.15>;party=called;npi=1;ton=0
h323-conf-id: 3893114048-424627567-1494110603-1129003007
cisco-GUID: 3893114048-424627567-1494110603-1129003007
Content-Length: 322

Config files

pap2t.cfg:

<flat-profile>

     <Time_Zone>GMT+04:00</Time_Zone>
     <Daylight_Saving_Time_Enable>no</Daylight_Saving_Time_Enable>
     <Caller_ID_Method>ETSI FSK</Caller_ID_Method>

     <Resync_Periodic>3600</Resync_Periodic>
     <Resync_Error_Retry_Delay>3600</Resync_Error_Retry_Delay>
     <Profile_Rule_C>/Linksys/profile/$PN/$SN.cfg</Profile_Rule_C>

     <Upgrade_Rule>/Linksys/firmware/$PN/pap2t-5-1-6.bin</Upgrade_Rule>
</flat-profile>

$SN.cfg:

<flat-profile>

     <Hook_Flash_Timer_Min>.07</Hook_Flash_Timer_Min>
     <User_ID_1_>7499709xxxx</User_ID_1_>
     <Proxy_1_>voip.mtt.ru</Proxy_1_>
     <Use_DNS_SRV_1_>yes</Use_DNS_SRV_1_>
     <Password_1_>xxxxxxxx</Password_1_>
     <Dial_Plan_1_>(8[3-9]xxxxxxxxxS0|&lt;:+&gt;7[3-9]xxxxxxxxxS0)</Dial_Plan_1_>

</flat-profile>

All rest parameters are factory default

SIP Remote-Party-ID is No. T tried turn ty Yes - no changes.

Initially I tried firmware version 5.1.6(ls) (factory default) and later I tried firmware versions pap2t-03-01-10-LS-c.bin, pap2t-3-1-15-LS.bin, pap2t-3-1-16-LS.bin, pap2t-5-1-1-LS.bin, pap2t-5-1-3.bin - no changes

Anyone can explain this phenomena? Thank you.

0 Helpful
7 Replies 7

Daniele Giordano
Level 8
Level 8

‎01-11-2012 06:49 AM

A SIP user agent should use one of these fields to get the calling number (in theory in this order):

P-Preferred-Identity/P-Asserted-Identity

Remote-Party-ID

From Header

Your issue sounds like a bug.

To be sure you should add the PAP log.

Can you post the log of incoming calls?

Regards.

0 Helpful

Daniele Giordano
Level 8
Level 8
In response to Daniele Giordano

‎01-11-2012 07:05 AM

Hi, I investigate the problem with my SPA2102. I replicated your call with the attached INVITE and I confirm the issue.

After that, I removed the second Remote-Party-ID from the INVITE:

Remote-Party-ID: <7499709XXXX>;party=called;npi=1;ton=0

In this case the Calling number displayed is correct.

The new INVITE is:

INVITE sip:7499709xxxx@a.b.c.d:34148;rinstance=2e75e33eb1045b0e;transport=udp SIP/2.0

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-675ee40795ee140c-1---d8754z-;rport
Via: SIP/2.0/UDP 80.75.132.203:5061;branch=z9hG4bK-ycj2xzrf7q2zddvi;rport=5061
Max-Forwards: 69
Record-Route: <80.75.132.203:5060>
Record-Route: <80.75.132.203:5060>
Contact: "Anonymous"<80.75.132.203:5061>
To: <>7499709xxxx@80.75.132.203>
From: <>;tag=746xthzxk5k2hezs.o" style="border-collapse: collapse; list-style-type: none; outline-style: none; color: #2f6681; text-decoration: none;">@80.75.132.203>;tag=746xthzxk5k2hezs.o
Call-ID: 1859003111212012142710@10.128.30.61~o
CSeq: 227 INVITE
Expires: 300
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
Remote-Party-ID: <7916XXX>xxxx@10.128.30.15>;npi=1;screen-ind=3;privacy=off;screen=yes;ton=2;party=calling

h323-conf-id: 3893114048-424627567-1494110603-1129003007
cisco-GUID: 3893114048-424627567-1494110603-1129003007
Content-Length: 322

I tested a second case. Remote-Party-ID swapped. The new INVITE is:

INVITE sip:7499709xxxx@a.b.c.d:34148;rinstance=2e75e33eb1045b0e;transport=udp SIP/2.0

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-675ee40795ee140c-1---d8754z-;rport
Via: SIP/2.0/UDP 80.75.132.203:5061;branch=z9hG4bK-ycj2xzrf7q2zddvi;rport=5061
Max-Forwards: 69
Record-Route: <80.75.132.203:5060>
Record-Route: <80.75.132.203:5060>
Contact: "Anonymous"<80.75.132.203:5061>
To: <>7499709xxxx@80.75.132.203>
From: <>;tag=746xthzxk5k2hezs.o" style="border-collapse: collapse; list-style-type: none; outline-style: none; color: #2f6681; text-decoration: none;">@80.75.132.203>;tag=746xthzxk5k2hezs.o
Call-ID: 1859003111212012142710@10.128.30.61~o
CSeq: 227 INVITE
Expires: 300
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy

Remote-Party-ID: <7499709XXXX>;party=called;npi=1;ton=0

Remote-Party-ID: <7916XXX>xxxx@10.128.30.15>;npi=1;screen-ind=3;privacy=off;screen=yes;ton=2;party=calling
h323-conf-id: 3893114048-424627567-1494110603-1129003007
cisco-GUID: 3893114048-424627567-1494110603-1129003007
Content-Length: 322

Also in this case the Calling number displyed is correct.

CONCLUSION:

The Linksys SIP stack uses the last Remote-Party-ID to get the CLI even if it specifies the party=called option.

This is a BUG present also on SPA2102.

Please open a case with the support.

Regards.

0 Helpful

Mogilevtsev
Level 1
Level 1
In response to Daniele Giordano

‎01-11-2012 09:05 AM

PAP2T Log.

however log is not informative. For example here is no INVITE Message. Does enyone knows how to make log better?

Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:21:55 192.168.0.139 local4.debug Jan 11 20:21:55 687F745AF4EB SIP/2.0 100 Trying

To: <7499709XXXX>

From: <>;tag=lblcdv2q2z2vkxwt.o

Call-ID: 20002511051112012202154@10.128.30.61~o

CSeq: 648 INVITE

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-79a2ff2b70f39e12-1---d8754z-

Via: SIP/2.0/UDP 80.75.132.203:5061;branch=z9hG4bK-kk3eqtulwm3ysee4;rport=5061

Record-Route: <80.75.132.203:5060>

Record-Route: <80.75.132.203:5060>

Server: Linksys/PAP2T-5.1.6(LS)

Content-Length: 0

Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:55 192.168.0.139 local2.debug Jan 11 20:21:55 687F745AF4EB [0:0]AUD ALLOC CALL (port=16462)
Jan 11 20:21:55 192.168.0.139 local2.debug Jan 11 20:21:55 687F745AF4EB [0:0]RTP Rx Up
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:21:55 192.168.0.139 local4.debug Jan 11 20:21:55 687F745AF4EB SIP/2.0 180 Ringing

To: <7499709XXXX>;tag=7a865923ad03a99i0

From: <>;tag=lblcdv2q2z2vkxwt.o

Call-ID: 20002511051112012202154@10.128.30.61~o

CSeq: 648 INVITE

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-79a2ff2b70f39e12-1---d8754z-

Via: SIP/2.0/UDP 80.75.132.203:5061;branch=z9hG4bK-kk3eqtulwm3ysee4;rport=5061

Record-Route: <80.75.132.203:5060>

Record-Route: <80.75.132.203:5060>

Server: Linksys/PAP2T-5.1.6(LS)

Content-Length: 0

Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:55 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:56 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:21:56 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:21:56 192.168.0.139 local4.debug Jan 11 20:21:55 687F745AF4EB Jan 11 20:21:56 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:56 192.168.0.139 local0.info Jan 11 20:21:55 687F745AF4EB
Jan 11 20:21:56 192.168.0.139 local2.debug Jan 11 20:21:55 687F745AF4EB TP Parser error: 34
Jan 11 20:21:57 192.168.0.139 local3.debug Jan 11 20:21:57 687F745AF4EB IDBG:sc-0
Jan 11 20:21:57 192.168.0.139 local3.debug Jan 11 20:21:57 687F745AF4EB IDBG:rs:12
Jan 11 20:21:58 192.168.0.139 local3.debug Jan 11 20:21:58 687F745AF4EB IDBG:sc-0
Jan 11 20:21:58 192.168.0.139 local3.debug Jan 11 20:21:58 687F745AF4EB IDBG:rs:12
Jan 11 20:22:04 192.168.0.139 local3.debug Jan 11 20:22:04 687F745AF4EB IDBG:sc-0
Jan 11 20:22:04 192.168.0.139 local3.debug Jan 11 20:22:04 687F745AF4EB IDBG:rs:12
Jan 11 20:22:04 192.168.0.139 local3.debug Jan 11 20:22:04 687F745AF4EB IDBG:sc-0
Jan 11 20:22:04 192.168.0.139 local3.debug Jan 11 20:22:04 687F745AF4EB IDBG:rs:12
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local4.debug Jan 11 20:22:04 687F745AF4EB CANCEL sip:7499709xxxx@a.b.c.d:12890 SIP/2.0

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-79a2ff2b70f39e12-1---d8754z-;rport

Max-Forwards: 70

To: <7499709XXXX>

From: <>;tag=lblcdv2q2z2vkxwt.o

Call-ID: 20002511051112012202154@10.128.30.61~o

CSeq: 648 CANCEL

Content-Length: 0

Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local4.debug Jan 11 20:22:04 687F745AF4EB SIP/2.0 487 Request Terminated

To: <7499709XXXX>;tag=7a865923ad03a99i0

From: <>;tag=lblcdv2q2z2vkxwt.o

Call-ID: 20002511051112012202154@10.128.30.61~o

CSeq: 648 INVITE

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-79a2ff2b70f39e12-1---d8754z-

Via: SIP/2.0/UDP 80.75.132.203:5061;branch=z9hG4bK-kk3eqtulwm3ysee4;rport=5061

Record-Route: <80.75.132.203:5060>

Record-Route: <80.75.132.203:5060>

Server: Linksys/PAP2T-5.1.6(LS)

Content-Length: 0

Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]->80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local4.debug Jan 11 20:22:04 687F745AF4EB SIP/2.0 200 OK

To: <7499709XXXX>;tag=7a865923ad03a99i0

From: <>;tag=lblcdv2q2z2vkxwt.o

Call-ID: 20002511051112012202154@10.128.30.61~o

CSeq: 648 CANCEL

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-79a2ff2b70f39e12-1---d8754z-

Server: Linksys/PAP2T-5.1.6(LS)

Content-Length: 0

Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB
Jan 11 20:22:04 192.168.0.139 local2.debug Jan 11 20:22:04 687F745AF4EB [0:0]AUD Rel Call
Jan 11 20:22:04 192.168.0.139 local2.debug Jan 11 20:22:04 687F745AF4EB CC:Ended
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB [0:5060]<<80.75.132.203:5060
Jan 11 20:22:04 192.168.0.139 local4.debug Jan 11 20:22:04 687F745AF4EB ACK sip:7499709xxxx@a.b.c.d:12890 SIP/2.0

Via: SIP/2.0/UDP 80.75.132.203:5060;branch=z9hG4bK-d8754z-79a2ff2b70f39e12-1---d8754z-;rport

Max-Forwards: 70

To: <7499709XXXX>;tag=7a865923ad03a99i0

From: <>;tag=lblcdv2q2z2vkxwt.o

Call-ID: 20002511051112012202154@10.128.30.61~o

CSeq: 648 ACK

Content-Length: 0

Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB
Jan 11 20:22:04 192.168.0.139 local0.info Jan 11 20:22:04 687F745AF4EB

0 Helpful

Mogilevtsev
Level 1
Level 1
In response to Daniele Giordano

‎01-11-2012 10:28 AM

I assume that it's bug too. However here is two bugs.

The first bug is Linksys SIP stack uses the last Remote-Party-ID to get the CLI even if it specifies the party=called.

And the second bug is that PAP2T uses Remote-Party-ID header even if  "SIP Remote-Party-ID" parameter value set to No. (As discribed in Cisco Small Business ATA Administration Guide "SIP Remote-Party-ID" parameter "To use the Remote-Party-ID header instead of the From header, select yes. Otherwise, select no". We can see that ndependently of "SIP Remote-Party-ID" parameter PAP2T uses Remote-Party-ID header nor From header.)

I just tested SPA922. The fist bug take place. Here is no second bug. because instead SIP Remote-Party-ID" parameter "Caller ID Header" introduced in FW version 6+ and setting the parameter value "FROM" works well - phone displays Caller ID of FROM field of INVITE.

0 Helpful

Mogilevtsev
Level 1
Level 1
In response to Mogilevtsev

‎03-28-2012 10:18 AM

Dear Cisco representatives! Halloo! It's elapsed 2,5 month from this post. Can you say anything about this issue?

0 Helpful

Daniele Giordano
Level 8
Level 8
In response to Mogilevtsev

‎03-29-2012 08:14 AM

Try to contact your Country Cisco Small Business Support via telephone and open a ticket. You can provide this post URL to add more informations to the case.

Regards.

0 Helpful

Mogilevtsev
Level 1
Level 1
In response to Daniele Giordano

‎03-30-2012 07:31 AM

Thank you Daniele. Of course I did it at January'12. They say that they will read the post, then they will think about, and then they will answer me. However hire is no sound from them up to now. Probably reading or thinking in progress.

0 Helpful
Customers Also Viewed These Support Documents