10-12-2011 01:01 AM - edited 03-16-2019 07:27 AM
Hello,
We have a SIP trunk which is connected through a SIP proxy. Our carrier did some testing yesterday to see if everything is working as it should. There was one problem, which was when forwarding/transfering a call. The problem is that the transferee's phonenumber is shown in the SIP INVITE FROM section. This should be our phonenumber. We must fix this because it causes problem with the billing.
Example:
Transferee = 1000
Transferor = 2000 (Our company)
Transfer-to = 3000
1000 is shown instead of 2000. These are just examples, we used full E.164 numbers when testing.
Is my configuration doing a blind transfer for some reason? Because it should do a consulvative transfer.
Below my configuration. What am I doing wrong?
IOS: Version 12.4(15)T9
CME: 4.1
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
redirect ip2ip
sip
dial-peer voice 2001 voip
description **Outgoing Call to SIP Trunk**
destination-pattern .T
voice-class codec 100
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
session transport udp
dtmf-relay rtp-nte
no vad
telephony-service
transfer-system full-consult
transfer-pattern .T
10-12-2011 03:06 AM
I applied a voice translation rule. It only translates the below in the INVITE to the transfer-to.
Contact:
The FROM still remains with the transferee's phone number.
10-12-2011 06:23 AM
Hi Grant,
It's working as expected.
Pls refer below SIP call flows and refer Call transfer with both types (Blind and Consultative transfer). In both cases, the transferee sends final INVITE which is why 1000 is reflecting as FROM.
I am not sure whether any solution available. If available, it works only when 1000 also uses the same Voice GW as 2000.
Regards...
-Ashok.
10-12-2011 11:49 PM
Thank you for that document. It will come in handy in the future.
I managed to fix it using the calling-number local secondary under telephony-service.
I tried with two scenarios:
1) VXML app under a dial-peer which transfers.
2) Call foward all under an ephone-dn.
Though the weird thing is that the display name in the From header is still showing 1000 when I use the VXML, but 2000 in the <2000>. Our carrier is probably after what's in the <>.>2000>
10-13-2011 12:50 AM
Hi Grant,
Very happy to know that you could able to find a solution for your requirement.
Shall I request more information about your setup for the following queries to get clarity about the solution?
1. Is 1000 and 2000 using same Voice GW?
2. The releavnt GW config
3. SIP Headers change capture if you have...
As per the Cisco doc shared with you, the final INVITE should have been sent from 1000 (as requested by 2000) in the consultative call transfer so I am not clear how "sip:2000@..." created because of "call secondary" option?
Regards...
-Ashok.
10-28-2011 05:06 AM
Hi Grant,
The solution you provided is still not clear to me.
As per the given call flows (Cisco doc) above, the transferree (in your case, 1000) originates final invite for both consultative and blind transfers. Then, how did your change in the CME configuration affect the transferee behavior?
Regards...
-Ashok.
11-10-2011 12:31 AM
Hello,
I'm sorry for my late reply. I've been very busy.
1000 and 2000 use different GWs, but are both ours.
Below the config of our 3825 which has the SIP Trunk:
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
redirect ip2ip
h323
sip
!
!
voice class codec 100
codec preference 1 g711alaw
codec preference 2 g711ulaw bytes 80
codec preference 3 g723ar53
codec preference 4 g723ar63 bytes 144
codec preference 5 g723r53
codec preference 6 g723r63 bytes 120
codec preference 7 g726r16
codec preference 8 g726r24
codec preference 9 g726r32
codec preference 10 g728
codec preference 11 g729br8
codec preference 12 g729r8 bytes 50
interface GigabitEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$$ES_LAN$$FW_INSIDE$
ip address 172.0.0.1 255.255.255.0
dial-peer voice 2000 voip
description **Incomming Call to SIP Trunk**
service voiceforwarding
voice-class codec 100
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number xxxxxxxxxx
dtmf-relay rtp-nte
no vad
dial-peer voice 2001 voip
description **Outgoing Call to SIP Trunk**
destination-pattern .T
voice-class codec 100
voice-class sip dtmf-relay force rtp-nte
no voice-clas sip authenticate redirecting-number
session protocol sipv2
session target sip-server
session transport udp
dtmf-relay rtp-nte
no vad
sip-ua
no remote-party-id
timers connect 100
mwi-server ipv4:192.0.0.1 expires 3600 port 5060 transport udp unsolicited
registrar ipv4:172.0.0.1 expires 3600
sip-server ipv4:192.0.0.1:5060
host-registrar
!
telephony-service
calling-number local secondary
SIP INVITE from 1000 to 2000
Received:
INVITE sip:2000@xxxxxx:5060 SIP/2.0
Max-Forwards: 68
Session-Expires: 3600;refresher=uac
Min-SE: 600
Supported: timer, 100rel
To: <2000>2000>
From: "1000" <1000>;tag=3529902009-7590891000>
Remote-Party-Id: <1000>;screen=yes;privacy=off1000>
Call-ID: 1180-3529902009-759085@xxxxxxx
CSeq: 1 INVITE
Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Via: SIP/2.0/UDP xxxxxxxx:5060;branch=z9hG4bKde4dc8605c808cfe18a610dafdfa1e2f
Contact: <1000>1000>
Expires: 180
Call-Info:
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 296
SIP INVITE FROM 2000 to 3000
Sent:
INVITE sip:3000@xxxxxxx:5060 SIP/2.0
Via: SIP/2.0/UDP xxxxxxx:5060;branch=z9hG4bK250F498
From: "1000" <2000>;tag=1EB42AAC-1CF22000>
To: <3000>3000>
Date: Thu, 10 Nov 2011 10:24:36 GMT
Call-ID: 5DFF26C-ABD11E1-9B4DF927-20F9F0A9@xxxxxxx
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 98562668-180163041-2605381927-553250985
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1320920676
Contact: <2000>2000>
Diversion: <2000>;privacy=off;reason=follow-me;screen=no2000>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 67
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 307
Regards,
Grant
11-17-2011 12:55 AM
Excellent. I got it.
Thanks a lot, Grant.
Regards...
-Ashok.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide