bridge transfer on SIP server

[peters]

Hello,

we are running SIP server 7.6 behind acmepacket gateway. If i receive inbound call and would like to transfer it to DN outside the SIP server (PSTN), the call is dropped by our telecom provider, because in the From: header of transferrig INVITE the caller number is present, which of course doesn't exist on our SIP server.
Is there a way, how to make a bridge transfer, that SIP server would stay in the signalling path and the transfer would be possible?

If i make the same scenario, but using GAD, the transfer is succesfull.

We would like to use it in another scenario as well, where inbound calls arrives to URS, but no agent is logged in, so the call should be transferred to external number (gsm). In our current configuration it's not possible. We were using Troute function.

Thanks,

Peter

[René]

Hi Peter,

I'm pretty sure it's possible as that is very common request and one of the basic features.

If I'm not wrong AcmePacket does support REFER so SIP Server should just generate REFER message to AcmePacket to transfer call to PSTN. Rest of the "job" should be done by AcmePacket - based on your description I assume AcmePacket plays role of PSTN gateway. If SIP Server uses INVITE message instead of REFER then it remains in signalling path = it's kind of bridged transfer.

Hopefully, I tell you what is wrong if you post here your SIP Server log (debug level).

R.

[peters]

Hi Rene,

theoretically it should be as you write. We use acmepacket as sip-sip gateway, so to the provider we are connected via sip. Although on the trunk in CME we enable REFER, new dialog via INVITE is made. The from header contains pstn number and not the genesys extension number. Therefore, provider terminates the call with SIP/2.0 604 Does not exist anywhere, because really, this number does't exist on our sip switch.
Has anyone tried something similar, is it working?

here is debug level from sipserver:

16:10:58.796 Received [440,UDP] 807 bytes from 192.168.50.20:5060 <<<<<
REFER sip:192.168.50.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.20:5060;branch=z9hG4bKbe50ca87cf3de571a.7c879420806b856bd
Max-Forwards: 70
From: "Aastra53i-201" <sip:201@192.168.50.10:5060>;tag=49b1f3722b
To: "266650763" <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-230
Call-ID: dc5238779f290757
CSeq: 16304 REFER
Allow:  INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Contact: "Aastra53i-201" <sip:201@192.168.50.20:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1A4E35>"
Refer-To: 66650765 <sip:66650765@192.168.50.10:5060>
Referred-By: <sip:201@192.168.50.10>
Supported: gruu, path, timer
User-Agent: Aastra 53i/2.5.0.82
Content-Length: 0


16:10:58.796 SIPDLG[231]: register TRN[527]
16:10:58.796 SipDialog: event CONNECTED_REQUEST, t=527, s=7, r=5, m=01cb4e74
16:10:58.796 SIPCONN(201): HandleSipDialogEvent(CONNECTED_REQUEST)
16:10:58.796 SIPCONN(201): new transaction
16:10:58.796 SIPCONN(201): 1pcc event CONNECTED_REQUEST
16:10:58.796 TRNMNGR: internal domain 192.168.50.10
16:10:58.796 Number:[66650765] is not internal, looking for service
16:10:58.796 Selected for Dn 66650765(): Service TrunkToTCOM (geo-loc , priority 0, capacity 0 (0% of -2))
16:10:58.796 SIPCONN(201): REFER - execute sst.
16:10:58.796 SIPCONN(201): SendResponse(202,527)
16:10:58.796 add party '201' state
16:10:58.796 Sending  [440,UDP] 530 bytes to 192.168.50.20:5060 >>>>>
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 192.168.50.20:5060;branch=z9hG4bKbe50ca87cf3de571a.7c879420806b856bd;received=192.168.50.20
From: "Aastra53i-201" <sip:201@192.168.50.10:5060>;tag=49b1f3722b
To: "266650763" <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-230
Call-ID: dc5238779f290757
CSeq: 16304 REFER
Contact: <sip:192.168.50.10:5060>
X-Genesys-CallUUID: UAIJCRMSBT7CFATLR3V9UGGTRG000078
Allow: INVITE, ACK, PRACK, CANCEL, BYE, REFER, INFO, UPDATE, MESSAGE, NOTIFY
Content-Length: 0


16:10:58.796 SipDialog: event CONNECTED_SEND_RESOK, t=527, s=7, r=8, m=01cb4e74
16:10:58.796 SIPCONN(201): HandleSipDialogEvent(CONNECTED_SEND_RESOK) - filtered
16:10:58.796 SIPCONN(266650763): re-invite-connected
16:10:58.796 transfer re-INVITE
16:10:58.796 SIPCONN(66650765): set monitor 01cba888, 01d009ac
16:10:58.796 SIPCALL(77): add party '66650765'
16:10:58.796  -- created party_info_tspp 01C462A8
16:10:58.796  -- created aTmParty 01646ED8
16:10:58.796  SetRole: Destination for 66650765.01646ED8-01D41780:1
16:10:58.796  -- AddParty to 01D41780: 66650765.01646ED8-01D41780:1
16:10:58.796  -- new TSCP call leg 3
16:10:58.796  -- call leg created leg_id=3
16:10:58.796 CreateParty new external: 66650765.01646ED8-01D41780:1
16:10:58.796 SIPTR(614): Begin step 0 - SipTransactionDetachMediaService(615)
16:10:58.796 SIPCONN(moh): DetachMediaPeer
16:10:58.796 SIPCONN(266650763): ClrMediaPeer
16:10:58.796 SIPCONN(moh): set monitor 01cada18, 00000000
16:10:58.796 SIPCONN(moh): state e:1,p:3,s:0,c:0,rc:0,m:0
16:10:58.796 SipDialog: ClearCall(phone=0,state=7)
16:10:58.796 SipDialog::Terminate(state=7)
16:10:58.796 SIPDLG[233]: register TRN[528]
16:10:58.796 Sending  [440,UDP] 431 bytes to 192.168.50.10:5070 >>>>>
BYE sip:192.168.50.10:5070 SIP/2.0
From: <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-232
To: <sip:annc@192.168.50.10:5070;play=music/on_hold>;tag=8C42A983-2D20-4889-BC87-6C6EA06EFEFC-105
Call-ID: 6E9DD01A-D55B-4C27-80BA-E2FA3DC2AA91-126@192.168.50.10
CSeq: 2 BYE
Content-Length: 0
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-387
Max-Forwards: 69


16:10:58.796 SipDialog: event SEND_BYE, t=528, s=8, r=5, m=01cada8c
16:10:58.796 SIPCONN(moh): HandleSipDialogEvent(SEND_BYE) - filtered
16:10:58.796 SipDialog: set monitor 00000000
16:10:58.796 SIPCONN(moh): DetachMediaPeer
16:10:58.796 SIPCONN(201): ClrMediaPeer
16:10:58.796 SIPTR(615): complete
16:10:58.796 SIPTR(614): Step 0 - SipTransactionDetachMediaService(615) complete
16:10:58.796 SIPTR(614): Begin step 1 - SipTransactionTransferCall(616)
16:10:58.796 SIPCONN(66650765): re-invite-null
16:10:58.796 SipDialog: set monitor 01cba8fc
16:10:58.796 SIPCONN(66650765): main dialog 0 created
16:10:58.796 SIPCONN(66650765): Local contact: '<sip:266650763@192.168.50.10:5060>'
16:10:58.796 add party '66650765' state
16:10:58.796 SIPDLG[234]: register TRN[529]
16:10:58.796 SIPDLG[234]: TRN[529] flags set to 0x6
16:10:58.796 Sending  [440,UDP] 676 bytes to 192.168.50.1:5060 >>>>>
INVITE sip:66650765@192.168.50.1:5060 SIP/2.0
From: <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-233
To: sip:201@192.168.50.10:5060
Call-ID: 6E9DD01A-D55B-4C27-80BA-E2FA3DC2AA91-127@192.168.50.10
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-388
Contact: <sip:266650763@192.168.50.10:5060>
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
X-ISCC-CofId: location=SwitchSIPCS;cofid=158
Max-Forwards: 69
X-Genesys-CallUUID: UAIJCRMSBT7CFATLR3V9UGGTRG000078
Session-Expires: 180;refresher=uac
Min-SE: 90
Supported: timer


16:10:58.796 SipDialog: event SEND_INVITE, t=529, s=2, r=7, m=01cba8fc
16:10:58.796 SIPCONN(66650765): HandleSipDialogEvent(SEND_INVITE) - filtered
16:10:58.796 SIPCONN(66650765): sdp state SDP_STATE_NULL, event SDP_OFFER_REQUESTED
16:10:58.796 SIPCONN(66650765): new sdp state SDP_OFFER_REQUESTED, event SDP_OFFER_REQUESTED
16:10:58.796 SIPS:LOGBLOCK:END:SIPDATA:]
16:10:58.796 SIPS:LOGBLOCK:BEGIN:SIPDATA:[
16:10:58.796 Received [440,UDP] 451 bytes from 192.168.50.10:2870 <<<<<
SIP/2.0 200 OK
From: <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-232
To: <sip:annc@192.168.50.10:5070;play=music/on_hold>;tag=8C42A983-2D20-4889-BC87-6C6EA06EFEFC-105
Call-ID: 6E9DD01A-D55B-4C27-80BA-E2FA3DC2AA91-126@192.168.50.10
CSeq: 2 BYE
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-387;received=192.168.50.10
Contact: <sip:192.168.50.10:5070>
Content-Length: 0


16:10:58.796 SipDialog: event TERMINATING_BYE_RES, t=528, s=9, r=4, m=00000000
16:10:58.796 SipDialog: event DESTROY, t=0, s=10, r=4, m=00000000
16:10:58.796 SipDialog[233]:<< Abort ALL <<
16:10:58.796 SIPS:LOGBLOCK:END:SIPDATA:]
16:10:58.796 SIPS:LOGBLOCK:BEGIN:SIPDATA:[
16:10:58.796 Received [440,UDP] 314 bytes from 192.168.50.1:5060 <<<<<
SIP/2.0 100 Trying
From: <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-233
To: sip:201@192.168.50.10:5060
Call-ID: 6E9DD01A-D55B-4C27-80BA-E2FA3DC2AA91-127@192.168.50.10
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-388


16:10:58.796 SipDialog: event CALLING_RESPROV, t=529, s=2, r=5, m=01cba8fc
16:10:58.796 SIPCONN(66650765): HandleSipDialogEvent(CALLING_RESPROV)
16:10:58.796 SIPDLG[231]: register TRN[530]
16:10:58.796 Sending  [440,UDP] 537 bytes to 192.168.50.20:5060 >>>>>
NOTIFY sip:201@192.168.50.20:5060;transport=udp SIP/2.0
From: "266650763" <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-230
To: "Aastra53i-201" <sip:201@192.168.50.10:5060>;tag=49b1f3722b
Call-ID: dc5238779f290757
CSeq: 1 NOTIFY
Content-Length: 20
Content-Type: message/sipfrag
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-389
Contact: <sip:192.168.50.10:5060>
Event: refer
Subscription-State: active;expires=3600
Max-Forwards: 70

SIP/2.0 100 Trying

16:10:58.796 SipDialog: event CONNECTED_SEND_REQUEST, t=530, s=7, r=5, m=01cb4e74
16:10:58.796 SIPCONN(201): HandleSipDialogEvent(CONNECTED_SEND_REQUEST) - filtered
16:10:58.796 SIPCONN(66650765): reliable=0
16:10:58.796 SIPCONN(66650765): store remote content
16:10:58.796 SIPCONN(66650765): store remote content - trying ingored
16:10:58.796 SIPS:LOGBLOCK:END:SIPDATA:]
16:10:58.812 SIPS:LOGBLOCK:BEGIN:SIPDATA:[
16:10:58.812 Received [440,UDP] 380 bytes from 192.168.50.1:5060 <<<<<
SIP/2.0 604 Does not exist anywhere
From: <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-233
To: <sip:201@192.168.50.10:5060>;tag=469320622-1240323368484
Call-ID: 6E9DD01A-D55B-4C27-80BA-E2FA3DC2AA91-127@192.168.50.10
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-388
Content-Length: 0


16:10:58.812 Sending  [440,UDP] 384 bytes to 192.168.50.1:5060 >>>>>
ACK sip:66650765@192.168.50.1:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-388
From: <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-233
To: <sip:201@192.168.50.10:5060>;tag=469320622-1240323368484
Call-ID: 6E9DD01A-D55B-4C27-80BA-E2FA3DC2AA91-127@192.168.50.10
CSeq: 1 ACK
Content-Length: 0


16:10:58.812 SipDialog: event CALLING_RESREJECT, t=529, s=9, r=5, m=01cba8fc
16:10:58.812 SIPCONN(66650765): HandleSipDialogEvent(CALLING_RESREJECT)
16:10:58.812 SIPDLG[231]: register TRN[531]
16:10:58.812 Sending  [440,UDP] 545 bytes to 192.168.50.20:5060 >>>>>
NOTIFY sip:201@192.168.50.20:5060;transport=udp SIP/2.0
From: "266650763" <sip:266650763@192.168.50.10:5060>;tag=7253BA46-1704-488B-895D-E1A77C1EC678-230
To: "Aastra53i-201" <sip:201@192.168.50.10:5060>;tag=49b1f3722b
Call-ID: dc5238779f290757
CSeq: 2 NOTIFY
Content-Length: 37
Content-Type: message/sipfrag
Via: SIP/2.0/UDP 192.168.50.10:5060;branch=z9hG4bKD3CEA320-A6EB-4F99-8AA7-D3CFB2601CB9-390
Contact: <sip:192.168.50.10:5060>
Event: refer
Subscription-State: terminated
Max-Forwards: 70

SIP/2.0 604 Does not exist anywhere

P.

[René]

Hi Peter,

I went through posted log snippet and found something I don't fully understand. I assume that original call comes from PSTN network so the number "266650763" is external one. That number has 9 digits but number the call should be transferred has only 8 digits - "66650765". Is that correct? I'm asking as the numbers seem very similar but have different number of digits.

The fact "From" header contains PSTN number and not extension number is correct because SIP Server doesn't initiate new call. Re-INVITE refers to existing call received originally from the gateway so the header should match that call. Dialled "target" PSTN number is part of first line "INVITE sip:66650765@192.168.50.1:5060 SIP/2.0".

About using re-INVITE instead of REFER - please check SIP Server option "sip-refer-to-sst-enabled". That option is set to "true" by default so SIP Server translates REFER to re-INVITE for single-step transfers.

R.

[peters]

Hi Rene,

both numbers 266650763 and 66650765 are external and if they have the prefix 2 or not doesn't matter, they are routed correctly.

I tried to disable/re-enable refer-to-sst-enabled but still INVITE was sent to provider and not REFER. refer-enabled is set to true on both trunk and DN's.... On the acme i see, INVITE was received from SIPserver.

Is it somehow possible to change the "from" header? Even if URS strategy would be used... In my previous post i was solving problem how to put "diversion" into sip header and i finally did it, but then the same problem occurred as here, that provider didn't accept "from" header, because it wasn't from the range of our DN's.

Thanks, P.

[René]

[quote]I tried to disable/re-enable refer-to-sst-enabled but still INVITE was sent to provider and not REFER. refer-enabled is set to true on both trunk and DN's.... On the acme i see, INVITE was received from SIPserver.[/quote]

Could you post here SIP Server log (debug) covering flow from the time a call arrives to SIP Server from ACME to time of single-step transfer?

[quote]Is it somehow possible to change the "from" header? Even if URS strategy would be used... In my previous post i was solving problem how to put "diversion" into sip header and i finally did it, but then the same problem occurred as here, that provider didn't accept "from" header, because it wasn't from the range of our DN's.[/quote]

I don't think it's possible on SIP Server as it could lead to problem with call handling. Theoretically, it should be possible on ACME but I'm not AcmePacket expert.

R.

[peters]

Hi Rene,

attached is the sip log file. sip-refer-to-sst-enabled is set to false, refer on trunk is enabled.

P.

[Timur Karimov]

HI there

Peters, r u absolutly sure what u ISP did't filter outbound caller id? may be their switch accept from u only allowed ANI and restrict any over?

[peters]

Hi Timur,

yes i can see that ANI is sent to ISP. I also think that ISP is accepting only allowed ANI.
Any ideas, why INVITE is sent instead of REFER even if REFER is enabled?

P.

[Timur Karimov]

Well, can u export and post here config options from u SIP-server? Also please describe more complexy used DN and call-flow with ID description( from, to, ANI, DNIS - which id from u side, which from customer or other side, which from ISP side)

WBR Timur

[peters]

Hi,

ANI: 0266650763 (PSTN)
DNIS 02 60421201 (SIP extension on SIPSerer behind ACMEpacket)
number to transfer to: 266650765 (PSTN) using 1-step transfer

posted log is when was set to refer-to-sst-enabled=false, now it is true.

Peter

[René]

Hi Peter,

I went through provided log "siplogfile_1step_transfer.txt" and there is something I don't understand. Once the inbound call is established on the hardphone (192.168.50.20) Acme sends re-INVITE and hardphone replies with another re-INVITE. Do you know why? I would say that re-INVITE causes SIP Server to translate later REFER to re-INVITE.

Here is outcome of my log analysis:
-------------------------
10:43:0437 INVITE sip:201@Company-tkg1:5060 SIP/2.0 from 192.168.50.1:5060 (ACME -> SIP Server)
10:43:0437 INVITE sip:201@192.168.50.20:5060;transport=udp SIP/2.0 to 192.168.50.20:5060 (fSIP Server -> hardphone)

@10:43:04.6560 [0] 8.0.000.12 distribute_event: message EventRinging
@10:43:06.2960 [0] 8.0.000.12 distribute_event: message EventEstablished

10:43:06.359 [b]INVITE sip:192.168.50.10:5060 SIP/2.0 from 192.168.50.1:5060 (re-INVITE from AMCE - why???)[/b]
10:43:06.359 INVITE sip:201@192.168.50.20:5060;transport=udp SIP/2.0 to 192.168.50.20:5060 (SIP Server passes re-INVITE to hardphone)

10:43:08.718 INVITE sip:0266650763@192.168.50.10:5060 SIP/2.0 from 192.168.50.20:5060 (re-INVITE from hardphone to SIP Server - why???)
10:43:08.812 INVITE sip:0266650763@192.168.50.1:5060;transport=udp SIP/2.0 to 192.168.50.1:5060 (SIP Server passes re-INVITE to ACME)

10:43:08.859 INVITE sip:annc@192.168.50.10:5070;play=music/on_hold SIP/2.0 to 192.168.50.10:5070 (Stream Manager - plays music on hold)

10:43:08.859 INVITE sip:0266650763@192.168.50.1:5060;transport=udp SIP/2.0 to 192.168.50.1:5060 (SIP Server -> hardphone - re-INVITE to Stream Manager)

10:43:14.843 REFER sip:0266650763@192.168.50.10:5060 SIP/2.0 from 192.168.50.20:5060 (hardphone -> SIP Server)
                  Refer-To: 266650765 <sip:266650765@192.168.50.10:5060>

10:43:14.843 INVITE sip:266650765@192.168.50.1:5060 SIP/2.0 to 192.168.50.1:5060 (SIP Server -> ACME)

10:43:14.859 SIP/2.0 604 Does not exist anywhere from 192.168.50.1:5060 (ACME -> SIP Server)
-------------------------

R.

[peters]

Hi Rene,

i captured another call on the acme side to see the communication between ISP an acme with wireshark. To explain more the last log:

1. the first inbound call is established with 200OK with SDP G729, PCMA, PCMU sent from phone to SIPserver
10:43:06.296 Received [440,UDP] 1043 bytes from 192.168.50.20:5060 <<<<<
SIP/2.0 200 OK

2. SIP server resends this 200OK to ISP,
3. RTP session from ISP-> ACME starts with g729
4. ACK to 1. 200OK comes from ISP->ACME
5. right after 4, new INVITE SDP with g729 and telephone event is sent from ISP->ACME->SIP->hardphone
6. this new INVITE is sent to phone and RTP session from hardphone is started.

As far as i understand, this second INVITE is sent to choose the codec g729 for communication... Or do you have some other explanation?

P.

[Timur Karimov]

well , about invite instead refer, i'm not sure but u can try use old option transfer-complete-by-refer. any other option u set propertly, i think.
but i think u problem is u ISP, not in the configure option. If u want  forward inbound call to ISP as u own call  - call to u ISP and check what he accept from u side call with 0266650763 as u number. If u want forward this call with different number - try to change it by rewrite header on sip-server or u acme gateway.