[Home]

Summary:ASTERISK-13135: The caller id is ignored when transferring the call
Reporter:Private Name (falves11)Labels:
Date Opened:2008-11-29 02:02:34.000-0600Date Closed:2011-06-07 14:02:43
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I need to replace the caller id before I do the transfer, so the new call has a new caller id, bit my efforts are completely ignored. Additionally, I try to use the function sip_addheader to add a "From:" header and that gets ignored as well. When the call gets tranfered the "From" header has the exact value that it had when it arrived to the Asterisk.

****** ADDITIONAL INFORMATION ******

<--- SIP read from 208.78.161.194:5060 --->
INVITE sip:19544447408@208.78.161.254:5060 SIP/2.0
Via: SIP/2.0/UDP 208.78.161.194:5060;branch=z9hG4bK2B4DD1B6F
Remote-Party-ID: "800 " <sip:72.187.243.97:sip:800@208.78.161@208.78.161.194>;party=calling;screen=no;privacy=off
From: "800 " <sip:72.187.243.97%3Asip%3A800%40208.@208.78.161.194>;tag=9A9E2B88-1141
To: <sip:19544447408@208.78.161.254>
Date: Sat, 29 Nov 2008 07:51:57 GMT
Call-ID: 6E5EA4BA-BD2111DD-8FABAB6B-E667B24F@208.78.161.194
Supported: 100rel,timer,resource-priority,replaces
Min-SE:  1800
Cisco-Guid: 1851616362-3173061085-2410064747-3865555535
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1227945117
Contact: <sip:72.187.243.97%3Asip%3A800%40208.@208.78.161.194:5060>
Expires: 1800
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 262
...etc, etc

my code:
Executing [19544447408@defaultproc:3] Set("SIP/208.78.161.194-0ab1f4f0", "CALLERID(num)=6465727883") in new stack
   -- Executing [19544447408@defaultproc:4] SIPAddHeader("SIP/208.78.161.194-0ab1f4f0", "From: "6465727883" < 6465727883>") in new stack
[Nov 29 02:51:57] DEBUG[8443]: chan_sip.c:18357 sip_addheader: SIP Header added "From: "6465727883" < 6465727883>" as __SIPADDHEADER01
   -- Executing [19544447408@defaultproc:10] Transfer("SIP/208.78.161.194-0ab1f4f0", "612919544447408") in new stack
<--- Reliably Transmitting (NAT) to 208.78.161.194:5060 --->
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 208.78.161.194:5060;branch=z9hG4bK2B4DD1B6F;received=208.78.161.194
From: "800 " <sip:72.187.243.97%3Asip%3A800%40208.@208.78.161.194>;tag=9A9E2B88-1141
To: <sip:19544447408@208.78.161.254>;tag=as4e06705c
Call-ID: 6E5EA4BA-BD2111DD-8FABAB6B-E667B24F@208.78.161.194
CSeq: 101 INVITE
User-Agent: CiscoSystemsSIP-GW-UserAgent
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: Transfer <sip:612919544447408@208.78.161.254>
Content-Length: 0
Comments:By: Jason Parker (jparker) 2008-12-04 17:05:59.000-0600

Use the 'o' Dial() option.
By: Private Name (falves11) 2008-12-04 20:06:13.000-0600

Is this a joke, right? The solution provided has nothing to do with the issue, at all. I need the Transfer function to send a "302 Moved.." message, and I need a new caller id, in the From header. The Dial option keeps Asterisk in the loop, and that is exactly what I am trying to avoid.
Digium already acknowledged that this is a bug and will fix it, at least in ABE. That's why I bought a license. I think that we should apply the same fix here.
By: Leif Madsen (lmadsen) 2008-12-05 10:18:03.000-0600

This actually seems like a bit of a feature request to me, so I'm marking it as such.
By: Private Name (falves11) 2008-12-05 10:22:07.000-0600

It seems to me that if this simple dialplan fails, it is a bug. Once the caller id for the call has been updated, any function after that must consider the new caller id, never the old one.

exten =>_X.,1,Set(CALLERID(all)=9544447408)
exten =>_X!,n,Tranfer(12564286000)
By: Mark Michelson (mmichelson) 2008-12-09 17:39:04.000-0600

This is not nearly as easy to implement as you have made it seem. The Transfer application sends a channel-specific message to the phone which prompts the phone to send another call elsewhere. If the call is directed to somewhere outside of Asterisk, then the phone has absolutely no way of knowing what its caller id should be for placing the new call. If the call is directed back into Asterisk, then using the Transfer app seems like an odd choice, considering Dial will handle the job in a much better, more direct way.


By: Mark Michelson (mmichelson) 2008-12-09 17:47:51.000-0600

I re-read note ~95825. This confirms that you are trying to transfer the call away from Asterisk. In this case, it is absolutely impossible for the caller id to be propagated to the new call. I know of no way to do that based on any of the SIP RFCs or drafts that I have read. This is most definitely a feature request and not a bug.

If you need the caller id to be changed for outbound calls that do not go through Asterisk, the only way that I can think to do so would be to add a SIP proxy to the path to do the job for you.

Closing.
By: Private Name (falves11) 2008-12-09 18:12:11.000-0600

I you just change the From field in the
302 moved temporarily packet, it will be upto the other endpoint to reflect or not the new caller id supplied. I cannot see why Asterisk cannot do it. Please try harder.
By: Leif Madsen (lmadsen) 2008-12-11 15:51:25.000-0600

I'm closing this issue as this is a feature request that does not have a patch associated with it from the original reporter. In addition, I'm concerned that by changing the From header being changed in an INVITE transaction could cause other end points to basically freak out. In addition, they may not even use it.

If you can provide some code that will provide the functionality you desire, then I would encourage you to submit it here for review and possible inclusion in future versions of Asterisk. If you are unable to do the coding yourself, there are various consultants who can perform this for you, or via the bounty system.

If you still feel this is incorrect, then please join #asterisk-bugs on the IRC network irc.freenode.net to discuss, at which point if it is deemed required, the issue will be reopened. Please do not reopen prior to discussing. Thanks!