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-0600 | Date Closed: | 2011-06-07 14:02:37 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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. |