[Home]

Summary:ASTERISK-11390: The "contact" section of the invite is wrong and many gateways reject the invite
Reporter:Private Name (falves11)Labels:
Date Opened:2008-02-06 13:07:20.000-0600Date Closed:2011-06-07 14:02:37
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If you look at this invite, the contact section has a port=0
"Contact: <sip:7864335989@67.110.179.252:0>", and that causes the call to fail with error SIP/2.0 400 Invalid Contact
It started with the latest version, it did not happen before.

INVITE sip:18183868429@67.203.64.22 SIP/2.0
Via: SIP/2.0/UDP 67.110.179.252:5060;branch=z9hG4bK4703c6d5;rport
Max-Forwards: 70
From: "7864335989" <sip:7864335989@minixel.com>;tag=as5d7e4f92
To: <sip:18183868429@67.203.64.22>
Contact: <sip:7864335989@67.110.179.252:0>
Call-ID: 17eccf585f82e1ef7f4017bb06dad2ec@minixel.com
CSeq: 102 INVITE
User-Agent: AsteriskSystemsSIP-GW-UserAgent
Date: Wed, 06 Feb 2008 19:02:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 361

Call-ID: 17eccf585f82e1ef7f4017bb06dad2ec@minixel.com
CSeq: 102 INVITE
User-Agent: AsteriskSystemsSIP-GW-UserAgent
Date: Wed, 06 Feb 2008 19:02:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 361

v=0
o=root 235140376 235140376 IN IP4 67.110.179.252
s=Asterisk
c=IN IP4 67.110.179.252
t=0 0
m=audio 30630 RTP/AVP 18 4 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
   -- Called 18183868429@67.203.64.22
Sipserver*CLI>
<--- SIP read from UDP://67.203.64.22:5060 --->
SIP/2.0 400 Invalid Contact
Via: SIP/2.0/UDP 67.110.179.252:5060;received=67.110.179.252;branch=z9hG4bK4703c6d5;rport=5060
From: "7864335989" <sip:7864335989@minixel.com>;tag=as5d7e4f92
To: <sip:18183868429@67.203.64.22>;tag=aprqngfrt-nk2e7630000c6
Call-ID: 17eccf585f82e1ef7f4017bb06dad2ec@minixel.com
CSeq: 102 INVITE


****** ADDITIONAL INFORMATION ******

I am using the Trunk version plus patch
http://bugs.digium.com/file_download.php?file_id=17596&type=bug

I neef some help urgently since I don't know what version to go back to, and I need the current advanced memory fixes, for my density is in the hundreds of simultaneous calls
Comments:By: Mark Michelson (mmichelson) 2008-02-06 13:12:36.000-0600

This is the same issue as reported in 11938. Do you have "insecure=very" in your sip.conf?

Edit: Wow I couldn't have been more wrong...oops.



By: Joshua C. Colp (jcolp) 2008-02-06 13:13:39.000-0600

This is a duplicate of 11916. Follow progress there.

By: Private Name (falves11) 2008-02-06 13:22:16.000-0600

I looked at the two isses metioned, 11916 and 11938 and I can not see how they issues are related to mine. I beg the bug marshalls to look closer. The only thing wrong in my invite is the contact field. It should not have a port section or it should be :5060
Besides, my sip.conf did not change lately.


By: Private Name (falves11) 2008-02-06 18:26:29.000-0600

I did a painstaking regression analysis and the last version that works is 99082, when you jump to 99085, the contact field is malformed and asterisk can not talk to many sip end-points. I think that I am the only one in the world that is using Trunk for business on a high density wholesale model, otherwise, somebody else must have found out about this issue. The change happenned in the jump from 99082 to 99085. Since we are now in 102726+, I think that we should stop here and fix this issue. I had to go back and use a previous version, but I want to use the latest memory fixes. Please help.

By: Joshua C. Colp (jcolp) 2008-02-06 19:13:11.000-0600

As I said... this is a duplicate of 11916. The issue in both cases is that the Contact header contains a port of 0 instead of the proper one.