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-0600 | Date Closed: | 2011-06-07 14:08:21 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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. |