[Home]

Summary:ASTERISK-06603: Losing inbound caller ID when call is transfered from one sip phone to another.
Reporter:RT (rtorrey58)Labels:
Date Opened:2006-03-23 10:16:54.000-0600Date Closed:2011-06-07 14:08:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:End-user recieves call and then transfer call to another end-user, new end-user sees callerid of end-user instead of original ID
Comments:By: Olle Johansson (oej) 2006-03-23 11:14:53.000-0600

You need to provide us with more information. Please read the bug guidelines before reporting a bug, to make life simpler for us.

- This should have been reported in the SIP category
- For SIP, you need to add SIP DEBUG output, verbose 4, debug 4 and turn on SIP debug

We need to know whats going on in your PBX. In this case, I also need to know how you are initiating the transfer - by SIP REFER or by Asterisk # builtin transfer?
By: RT (rtorrey58) 2006-03-23 11:31:12.000-0600

Transfer done via softkey on Cisco 79xx phone. Blind Transfer softkey appears works correctly.
By: Olle Johansson (oej) 2006-03-23 11:42:46.000-0600

And where's the debug of this transaction?
By: RT (rtorrey58) 2006-03-23 14:04:43.000-0600

Here is the debug.

-- SIP read from 10.10.13.151:53071:
SIP/2.0 200 OK^M
Via: SIP/2.0/UDP 10.10.10.170:5060;branch=z9hG4bK6c927f7d;rport^M
From: "2156691841" <sip:2156691841@10.10.10.170>;tag=as539edd55^M
To: <sip:2710@10.10.13.151:5060>;tag=000bfd07c0e8700e7d9a9297-6deab740^M
Call-ID: 0921fade6a377bf8377133135d4ddff4@10.10.10.170^M
Date: Thu, 23 Mar 2006 19:52:41 GMT^M
CSeq: 103 NOTIFY^M
Content-Length: 0^M
^M

Mar 23 14:46:55 VERBOSE[19412] logger.c: --- (8 headers 0 lines)Mar 23 14:46:55 VERBOSE[19412] logger.c: --- (8 headers 0 lines)---
Mar 23 14:46:55 VERBOSE[19412] logger.c:
<-- SIP read from 10.10.13.151:50317:
SIP/2.0 200 OK^M
Via: SIP/2.0/UDP 10.10.10.170:5060;branch=z9hG4bK3b538756;rport^M
From: "2156691841" <sip:2156691841@10.10.10.170>;tag=as539edd55^M
To: <sip:2710@10.10.13.151:5060>;tag=000bfd07c0e8700e7d9a9297-6deab740^M
Call-ID: 0921fade6a377bf8377133135d4ddff4@10.10.10.170^M
Date: Thu, 23 Mar 2006 19:52:41 GMT^M
CSeq: 104 BYE^M
Server: Cisco-CP7940G/7.5^M
Content-Length: 0^M
RTP-RxStat: Dur=??,Pkt=??,Oct=??,LatePkt=??,LostPkt=??,AvgJit=??^M
RTP-TxStat: Dur=??,Pkt=??,Oct=??^M
^M

Mar 23 14:46:55 VERBOSE[19412] logger.c: --- (11 headers 0 lines)Mar 23 14:46:55 VERBOSE[19412] logger.c: --- (11 headers 0 lines)---
Mar 23 14:46:55 VERBOSE[19412] logger.c: Destroying call '0921fade6a377bf8377133135d4ddff4@10.10.10.170'
Mar 23 14:46:57 VERBOSE[19412] logger.c: Destroying call '000dbc04-801e0002-1a1fadfe-5ca44703@192.168.1.1'
Mar 23 14:46:57 VERBOSE[19412] logger.c: 12 headers, 3 lines
Mar 23 14:46:57 VERBOSE[19412] logger.c: Reliably Transmitting (no NAT) to 10.10.13.161:5060:
---
Mar 23 14:46:57 VERBOSE[19412] logger.c: Scheduling destruction of call '4d4e71c520ed4f1b41818b67004a808e@10.10.10.170' in 15000 ms
Mar 23 14:46:57 VERBOSE[19412] logger.c:

Mar 23 14:46:57 VERBOSE[19412] logger.c: --- (8 headers 0 lines)Mar 23 14:46:57 VERBOSE[19412] logger.c: --- (8 headers 0 lines)---
Mar 23 14:46:57 VERBOSE[19412] logger.c: Destroying call '4d4e71c520ed4f1b41818b67004a808e@10.10.10.170'
Mar 23 14:47:01 VERBOSE[19418] logger.c:     -- Channel 0/2, span 1 got hangup request
Mar 23 14:47:01 VERBOSE[30994] logger.c: Reliably Transmitting (no NAT) to 10.10.13.156:5060:
CANCEL sip:2717@10.10.13.156:5060 SIP/2.0^M
Via: SIP/2.0/UDP 10.10.10.170:5060;branch=z9hG4bK3c22c95c;rport^M
From: "Marlon Beltz" <sip:6106842710@10.10.10.170>;tag=as6dd88cca^M
To: <sip:2717@10.10.13.156:5060>^M
Contact: <sip:6106842710@10.10.10.170>^M
Call-ID: 604ef1d548d1aff66d15f30d4452dadc@10.10.10.170^M
CSeq: 102 CANCEL^M
User-Agent: Asterisk PBX^M
Max-Forwards: 70^M
Content-Length: 0^M
^M

---
Mar 23 14:47:01 VERBOSE[30994] logger.c: Scheduling destruction of call '604ef1d548d1aff66d15f30d4452dadc@10.10.10.170' in 15000 ms
Mar 23 14:47:01 VERBOSE[30994] logger.c:   == Spawn extension (tpfx, 2717, 1) exited non-zero on 'Zap/2-1'
Mar 23 14:47:01 VERBOSE[30994] logger.c:     -- Hungup 'Zap/2-1'
Mar 23 14:47:01 VERBOSE[19412] logger.c:
<-- SIP read from 10.10.13.156:50457:
SIP/2.0 200 OK^M
Via: SIP/2.0/UDP 10.10.10.170:5060;branch=z9hG4bK3c22c95c;rport^M
From: "Marlon Beltz" <sip:6106842710@10.10.10.170>;tag=as6dd88cca^M
To: <sip:2717@10.10.13.156:5060>;tag=000bfd07b4cb7b5e7d597b98-24f1dad6^M
Call-ID: 604ef1d548d1aff66d15f30d4452dadc@10.10.10.170^M
Date: Thu, 23 Mar 2006 19:52:46 GMT^M
CSeq: 102 CANCEL^M
Server: Cisco-CP7940G/7.5^M
Content-Length: 0^M
^M

Mar 23 14:47:01 VERBOSE[19412] logger.c: --- (9 headers 0 lines)Mar 23 14:47:01 VERBOSE[19412] logger.c: --- (9 headers 0 lines)---
Mar 23 14:47:01 VERBOSE[19412] logger.c:
<-- SIP read from 10.10.13.156:50457:
SIP/2.0 487 Request Cancelled^M
Via: SIP/2.0/UDP 10.10.10.170:5060;branch=z9hG4bK3c22c95c;rport^M
From: "Marlon Beltz" <sip:6106842710@10.10.10.170>;tag=as6dd88cca^M
To: <sip:2717@10.10.13.156:5060>;tag=000bfd07b4cb7b5e7d597b98-24f1dad6^M
Call-ID: 604ef1d548d1aff66d15f30d4452dadc@10.10.10.170^M
Date: Thu, 23 Mar 2006 19:52:46 GMT^M
CSeq: 102 INVITE^M
Server: Cisco-CP7940G/7.5^M
Contact: <sip:2717@10.10.13.156:5060>^M
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE^M
Content-Length: 0^M
^M

Mar 23 14:47:01 VERBOSE[19412] logger.c: --- (11 headers 0 lines)Mar 23 14:47:01 VERBOSE[19412] logger.c: --- (11 headers 0 lines)---
Mar 23 14:47:01 VERBOSE[19412] logger.c: Transmitting (no NAT) to 10.10.13.156:5060:
ACK sip:2717@10.10.13.156:5060 SIP/2.0^M
Via: SIP/2.0/UDP 10.10.10.170:5060;branch=z9hG4bK3c22c95c;rport^M
From: "Marlon Beltz" <sip:6106842710@10.10.10.170>;tag=as6dd88cca^M
To: <sip:2717@10.10.13.156:5060>;tag=000bfd07b4cb7b5e7d597b98-24f1dad6^M
Contact: <sip:6106842710@10.10.10.170>^M
Call-ID: 604ef1d548d1aff66d15f30d4452dadc@10.10.10.170^M
CSeq: 102 ACK^M
User-Agent: Asterisk PBX^M
Max-Forwards: 70^M
Content-Length: 0^M
^M
By: Joshua C. Colp (jcolp) 2006-03-23 16:13:15.000-0600

This is because it's an attended transfer. If you're doing a blind transfer, you're just telling the call to go to a new extension and execute the instructions. If you're doing an attended transfer then you are the one doing that until you're in a call with someone else and thus it uses your callerid. This isn't exactly a bug, and can't exactly be fixed... and yes I know I used the word "exactly" a lot.
By: RT (rtorrey58) 2006-03-24 13:04:51.000-0600

Thanks for the clarification. Close ticket please.