Jump to content

P-Asserted-Identity SIP Gateway Trunk


Krom
 Share

Recommended Posts

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?

Link to comment
Share on other sites

[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

Link to comment
Share on other sites

[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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 months later...

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?

Link to comment
Share on other sites

"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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...