[Home]

Summary:ASTERISK-25741: res_pjsip: "Contact" contains UUID for user portion
Reporter:Oliver Nauliv (nauliv)Labels:
Date Opened:2016-02-03 00:53:29.000-0600Date Closed:2016-02-13 11:36:43.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip
Versions:13.1.0 Frequency of
Occurrence		Constant
Related
Issues:
duplicatesASTERISK-23791 PJSIP use UUID in Contact header when Dial
Environment:CentOS 2.6.32-504.23.4.el6.i686Attachments:
Description:Hello,

Using Asterisk 13.1-cert2 and PJSIP, with Nextiva as the SIP Trunk provider. The carrier says that there are 2 reasons why dialing out is not working :

1) If you look at the SIP trace below, the carrier is indicating that the reason for not working is because the "Contact:" line has a cryptic-randomized number in there, instead of the actual contact.

It sends:
Contact: <sip:ec89dc3e-90df-4fbd-99bd-f5b225f8da3d@107.207.90.90:5060>

Instead of sending:
Contact: <sip:7143861212@107.207.90.90:5060>


2) We are unable to send the X-P-Asserted-Identity, because while the dialplan runs PJSIP_HEADER without error, the option doesn't make it into the SIP packet.

h2. SIP TRACE FOR OUTBOUND CALL
{noformat}
<--- Transmitting SIP request (891 bytes) to UDP:208.73.140.70:5060 --->
INVITE sip:9492345566@208.73.140.70:5060 SIP/2.0
Via: SIP/2.0/UDP 107.207.90.90:5060;rport;branch=z9hG4bKPja-5qMYTknEobutnWKzOTPpSrCg3swCz
From: "Manager Office"
<sip:7143861212@107.207.90.90>;tag=slIrplpaQV6S.tpB64u4BEbK-.7HBEis
To: <sip:9492345566@208.73.140.70>
Contact: <sip:ec89dc3e-90df-4fbd-99bd-f5b225f8da3d@107.207.90.90:5060>
Call-ID: QmF69h0tpNPtZhE6IrwYqtoQ67kcJ5pn
CSeq: 9147 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE,
PRACK, REFER, REGISTER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 237
v=0
o=- 455864548 455864548 IN IP4 107.207.90.90
s=Asterisk
c=IN IP4 107.207.90.90
t=0 0
m=audio 19628 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
{noformat}

h2. DIALPLAN FOR OUTBOUND CALL
{noformat}
[dial-out]
exten => _X.,1,NoOp()
same => n,Set(PJSIP_HEADER(add,X-P-Asserted-Identity)=sip:7147890101)
same => n,Set(CALLERID(num)=7143861212)
same => n,Dial(PJSIP/${EXTEN}@nextiva1,45,r)
same => n,Hangup()
{noformat}

h2. PJSIP CONFIGURATION FOR SIP TRUNK
{noformat}
[nextiva1]
type=endpoint
transport=transport-udp
context=from-nextiva
disallow=all
allow=ulaw
aors=nextiva1-aor

[nextiva1-auth]
type=auth
auth_type=userpass
username=7143861212
password=NotMyRealPassword

[nextiva1-reg]
type=registration
outbound_auth=nextiva1-auth
server_uri=sip:bt.voipdnsservers.com
client_uri=sip:7143861212@bt.voipdnsservers.com


[nextiva1]
type=identify
endpoint=nextiva1
match=208.73.140.70

[nextiva1-aor]
type=aor
contact=sip:bt.voipdnsservers.com:5060
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2016-02-03 00:53:32.573-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Joshua C. Colp (jcolp) 2016-02-03 06:35:19.793-0600

According to the SIP RFC:

The Contact header field provides a SIP or SIPS URI that can be used
  to contact that specific instance of the UA for subsequent requests.
  The Contact header field MUST be present and contain exactly one SIP
  or SIPS URI in any request that can result in the establishment of a
  dialog.  For the methods defined in this specification, that includes
  only the INVITE request.  For these requests, the scope of the
  Contact is global.  That is, the Contact header field value contains
  the URI at which the UA would like to receive requests, and this URI
  MUST be valid even if used in subsequent requests outside of any
  dialogs.

Within Asterisk this holds true, and the provider in question shouldn't derive any meaning from the Contact header itself. The fact that we use a UUID for the Contact user portion shouldn't matter. Have they provided any reasoning?

As for your second thing that's not a bug, and has been answered on http://community.asterisk.org/
By: Oliver Nauliv (nauliv) 2016-02-05 23:09:05.573-0600

Hello Joshua,

Thank you very much for your response. The carrier says they have to have the 3 pieces of the puzzle

1) From: "xyz" sip:7143861234@107.207.97.98>;tag=aI7sblablabla
2) To: <sip:8005556255@bt.voipdnsservers.com>
3) Contact: <sip:7143861234@107.207.97.98:5060>

The carrier invoques the following SIP RFC:

|  
|  10.2.1.2 Preferences among Contact Addresses
|  
|     If more than one Contact is sent in a REGISTER request, the
|     registering UA intends to associate all of the URIs in these Contact
|     header field values with the address-of-record present in the To
|     field.  This list can be prioritized with the "q" parameter in the
|     Contact header field.  The "q" parameter indicates a relative
|     preference for the particular Contact header field value compared to
|     other bindings for this address-of-record.  Section 16.6 describes
|     how a proxy server uses this preference indication.
|  

I have to say this is the first time I have ever seen Asterisk doing this... no other version of Asterisk used to do that... Is the fact that you are sending a UUID because of SIPS ? Can this be disabled ? I tried to add "trust_id_outbound=yes" in pjsip.conf to the carrier registration and/or the desk phone registration... it didn't help... still getting the UUID string... Any way to disable that ?

Thank you very much again, and long life to Asterisk !!
By: Joshua C. Colp (jcolp) 2016-02-06 06:21:20.088-0600

The RFC part they've quoted is not applicable to this. This issue is about a call, and thus INVITE, not a REGISTER request. Completely different things.

As for controlling it - there's no way to disable or change it because within SIP you're not supposed to really use it for identification or such. You'd have to modify the code. And as for being different - res_pjsip and chan_sip are two completely implementations and thus can have different results.
By: Joshua C. Colp (jcolp) 2016-02-07 18:19:10.728-0600

Additionally the full SIP log of a failing call would also be useful.
By: Oliver Nauliv (nauliv) 2016-02-09 16:53:34.296-0600

Hello Joshua,

Thanks again for responding to the message. Here are 2 short questions, taking aside the SIP RFC for just a moment.

1) Why do all the other Asterisk PBX (not using PJSIP) don't garble the Contact field ? And can we just have an option to keep the Contact field intact the way it has always been ?

2) Why is the P-Asserted-Identity not working? I did everything suggested on https://community.asterisk.org/t/asterisk-13-pjsip-contact-field-in-sip-is-randomized/65044 and packaging it into a pre-dialer, but the field is still not showing up.

Please advise. The carrier and I have been working on this issue for 20+ combined hours... we are both willing to work with the Asterisk team to help get this resolved and help the community, as apparently other people are reporting similar issues on the forums.

Is there an e-mail I can send the full unedited SIP trace, as it contains private information ?

Thanks!
By: Joshua C. Colp (jcolp) 2016-02-09 17:03:07.437-0600

1) PJSIP isn't "garbling" the Contact header, it generates it. The way it generates it is apparently not how your carrier would like. This in itself isn't a bug, they shouldn't care. The code could potentially be changed to do otherwise though.

2) I don't know why it's not working, may be something rather specific. I just checked and confirmed that the tests which confirm the underlying PJSIP_HEADER functionality are working and passing which is odd.

As there is currently noone working on this issue there is noone to send such a SIP trace to.
By: Rusty Newton (rnewton) 2016-02-13 11:36:43.506-0600

Closing since this is not a bug and a duplicate of https://issues.asterisk.org/jira/browse/ASTERISK-23791

[~nauliv] I'm going to open a new issue for your second issue "Unable to add X-P-Asserted-Identity header". I'll set you as the reporter once I create it. We don't want to track two separate issues in this one ticket.