Krom Posted December 10, 2007 Report Share Posted December 10, 2007 Testing 2.1.2.2292 (Win32) for deployment and attempting to setup an external call forwarding gateway trunk without 100% success. Trunk created as a SIP Gateway trunk so that we can blind transfer incoming calls to external cell phones. In the trunk definition I have place the $f pseudo variable in the Trunk DID field and selected RFC 3325 (P-Asserted-Identity) in the Remote Party/Privacy Indication field. Each time I forward a call externally using this Trunk the call completes properly but the extension of the answering party is placed in the P-Asserted-Identity SIP header field instead of the $f = "will insert the caller-ID of the other side of the call, if it is not coming from an extension. This way, redirected calls can present the original caller ID for incoming calls." Read the wiki on outbound call trunks - http://wiki.pbxnsip.com/index.php/Outbound_Calls_on_Trunk Any suggestions or direction? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 11, 2007 Report Share Posted December 11, 2007 Do you have the SIP INVITE that is sent to the gateway? Quote Link to comment Share on other sites More sharing options...
Krom Posted December 12, 2007 Author Report Share Posted December 12, 2007 [7] 20071211162440: SIP Rx udp:10.1.1.21:5060: REFER sip:269@10.1.1.245:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.1.1.21:5060;branch=z9hG4bKc71e850a9CDD4873 From: "Jan Doe" <sip:269@10.1.1.254>;tag=B2AC285D-D30FAAB4 To: <sip:+12225555555@10.4.1.144:5060>;tag=3483 CSeq: 2 REFER Call-ID: a13bf5be@pbx Contact: <sip:269@10.1.1.21:5060> User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.0.3.0127 Refer-To: sip:003335555555@10.1.1.254 Referred-By: <sip:269@10.1.1.254> Max-Forwards: 70 Content-Length: 0 [7] 20071211162440: SIP Tx udp:10.1.1.21:5060: SIP/2.0 202 Accepted Via: SIP/2.0/UDP 10.1.1.21:5060;branch=z9hG4bKc71e850a9CDD4873 From: "Jan Doe" <sip:269@10.1.1.254>;tag=B2AC285D-D30FAAB4 To: <sip:+12225555555@10.4.1.144:5060>;tag=3483 Call-ID: a13bf5be@pbx CSeq: 2 REFER Contact: <sip:269@10.1.1.245:5060;transport=udp> User-Agent: pbxnsip-PBX/2.1.2.2292 Content-Length: 0 [5] 20071211162440: Redirecting call to 003335555555 [7] 20071211162440: SIP Tx udp:10.1.1.21:5060: BYE sip:269@10.1.1.21:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1.1.245:5060;branch=z9hG4bK-75a2025cbb9f149ef6b5676473710cf1;rport From: <sip:+12225555555@10.4.1.144:5060>;tag=3483 To: "Jan Doe" <sip:269@10.1.1.254>;tag=B2AC285D-D30FAAB4 Call-ID: a13bf5be@pbx CSeq: 10506 BYE Max-Forwards: 70 Contact: <sip:269@10.1.1.245:5060;transport=udp> RTP-RxStat: Dur=22,Pkt=194,Oct=33368,Underun=0 RTP-TxStat: Dur=18,Pkt=198,Oct=33048 Content-Length: 0 [7] 20071211162440: fcd68b7c291ae13f1a211d4983a97584#608b460159: RTP pass-through mode [5] 20071211162440: Dialplan: Match 003335555555@10.1.1.254 to <sip:+13335555555@10.2.1.28> on trunk TEST EXT FORWARD [5] 20071211162440: Using <sip:+12225555555@10.4.1.144:5060>;tag=35ba1245 as redirect from [8] 20071211162440: Play audio_moh/noise.wav [7] 20071211162440: UDP: Opening socket on port 50750 [7] 20071211162440: UDP: Opening socket on port 50751 [7] 20071211162440: SIP Tx udp:10.2.1.28:5060: INVITE sip:+13335555555@10.2.1.28 SIP/2.0 Via: SIP/2.0/UDP 10.3.1.130:5060;branch=z9hG4bK-bcf48998571afdb4b6269e7c5fc9760f;rport From: <sip:+12225555555@10.4.1.144:5060>;tag=11350 To: <sip:+13335555555@10.2.1.28> Call-ID: cca65755@pbx CSeq: 29182 INVITE Max-Forwards: 70 Contact: <sip:4445555555@10.3.1.130:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: pbxnsip-PBX/2.1.2.2292 P-Asserted-Identity: "Jan Doe" <sip:269@10.1.1.254> Content-Type: application/sdp Content-Length: 270 v=0 o=- 12637 12637 IN IP4 10.3.1.130 s=- c=IN IP4 10.3.1.130 t=0 0 m=audio 50750 RTP/AVP 0 8 2 3 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 12, 2007 Report Share Posted December 12, 2007 [7] 20071211162440: SIP Tx udp:10.2.1.28:5060:INVITE sip:+13335555555@10.2.1.28 SIP/2.0 From: <sip:+12225555555@10.4.1.144:5060>;tag=11350 To: <sip:+13335555555@10.2.1.28> P-Asserted-Identity: "Jan Doe" <sip:269@10.1.1.254> ... That makes sense to me - the gateway should present the +12225555555 to the caller and use the 269@10.1.1.254 for authentication. Quote Link to comment Share on other sites More sharing options...
Krom Posted December 13, 2007 Author Report Share Posted December 13, 2007 Not exactly. The Gateway Trunk uses the configured information for authenticating with the outbound proxy when challenged. The P-Asserted-Identity: header field is for passing the number that you wish to have presented to the called party. And per the wiki documentation and how it is working in previous version, this is not working properly. $f "will insert the caller-ID of the other side of the call, if it is not coming from an extension. This way, redirected calls can present the original caller ID for incoming calls." Read the wiki on outbound call trunks - http://wiki.pbxnsip.com/index.php/Outbound_Calls_on_Trunk So we should be seeing the 2225555555 number in that header field. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 13, 2007 Report Share Posted December 13, 2007 The P-Asserted-Identity: header field is for passing the number that you wish to have presented to the called party. As far as RFC3325 says, that is IMHO not correct. In previous versions of the PBX was was a little bit "messy". The idea of RFC3325 is that the From header can go through all proxies unchanged, and the authentication part is done on other headers. I know that the support out there for this is weak. Probably the biggest problem is that many ITSP are using SER, which did not support this for a long time. But somehow we have to get started with the standard, that is why the latest and the greatest is strictly according to the RFC. Quote Link to comment Share on other sites More sharing options...
Krom Posted March 28, 2008 Author Report Share Posted March 28, 2008 OK - getting back to this after a break from testing. Agree with moving towards the hardened standard and support the effort. Working with 2.1.6.2450 in preparation for upgrading I have a question about the documentation and configuration of my Outbound SIP Gateway trunks. http://wiki.pbxnsip.com/index.php/Outbound..._2.1_and_higher Bullet one works great and my PTSN ITSP accepts RPID while the LD ITSP only accepts P-Asserted so setting up two Gateways trunks work for defining in the dial-plan which trunk to use based on the digits dialed. The question I have is the second bullet. "If the parameter of the calling extension is set, the PBX uses that parameter as the Caller-ID. Having this as the first option makes it always possible to override the following steps. However, usually using this parameter is not necessary." Can someone provide a clearer explanation? Where is this parameter set. It is apparent that it is set since my extension has a tel: alias set with my DID, but when I dial out my three digit extension is put in the From field. I am needing the tel: alias in the From field or the SIP Gateway Account in the From field. The call is being rejected since the number in the From field is not a NANP 10-digit number. What am I doing wrong? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 28, 2008 Report Share Posted March 28, 2008 "If the parameter of the calling extension is set, the PBX uses that parameter as the Caller-ID. Having this as the first option makes it always possible to override the following steps. However, usually using this parameter is not necessary." No, this is the "Parameter 2". It is in the registrations tab of the extension. Using the tel: alias is problematic because then different users cannot share the same outgoing identity. Quote Link to comment Share on other sites More sharing options...
Krom Posted March 28, 2008 Author Report Share Posted March 28, 2008 Thank you and understood. Parameter 2 is empty as this time. My strategy is to lower the number of SIP Registration Trunks by utilizing SIP Gateway Trunks. I have a SIP Gateway Trunk created that as user that has a DID that that when dialing out needs to be presented in the From Header. When extension 269 Dials a PSTN call the dial-plan associated with that extension is used utilizing the SIP Gateway trunks for outbound PSTN dialing. When the INVITE is placed on the wire it has the extension number in the From header field. The call is rejected because my ITSP reads that as an invalid TN. i.e. a billable TN of record within their switch. INVITE sip:15552223333@10.10.10.10;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.11.11.11:5060;branch=z9hG4bK-2fc13508d3a9552ec8655cc241a737f0;rport From: "269" <sip:269@10.11.11.11>;tag=1849938551 To: <sip:15552223333@10.10.10.10;user=phone> Call-ID: 198e9ff2@pbx CSeq: 21466 INVITE Max-Forwards: 70 ... no relevent P-Asserted-Identity: <sip:5554448888@15552223333@10.10.10.10> With that said - when extension 269 blind transfers an incoming call to the PSTN, it too is rejected because in this release the From field is replaced with the inbound calling party number. Again - another number that is invalid to the ITSP in the From field. I am trying to figure out how to get the same functionality in the SIP Gateway trunk as I have in 2.0. When I place that in the Trunk DID section it doesn't do what I expect. From field being SIP Gateway account number and the P-Asserted field being used. Any suggestions? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 28, 2008 Report Share Posted March 28, 2008 The call is rejected because my ITSP reads that as an invalid TN. i.e. a billable TN of record within their switch. Well, then the ITSP may want to see the number in a different way. What about trying out the few modes (RFC 3325, None, Remote-Party-ID)? Usually one of them gives usable results. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.