ASTERISK-02641: [patch] ACK sent to wrong address

[Home]

Summary: ASTERISK-02641: [patch] ACK sent to wrong address

Reporter: salvatoregiudice (salvatoregiudice) Labels:

Date Opened: 2004-10-20 16:48:27 Date Closed: 2011-06-07 14:10:26

Priority: Minor Regression? No

Status: Closed/Complete Components: Channels/chan_sip/Interoperability

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) Asterisk_Sip_Debug_badv2.txt
( 1) plaintext.zip
( 2) sipack.txt

Description: In the course of testing a vendor solution for NAT Firerwall traversal, we have discovered that Asterisk is not compliant with RFC 3261 with regard to ACK's generated by the UAC core in response to a 200ok. Please reference the following dialog:

* ----INVITE----> UAS
* <------100----- UAS
* <------180----- UAS
* <------200----- UAS (with session description)
* -------ACK----> UAS

At this point, the call fails because Asterisk is placing the original SIP URI in the REUEST-URI. According to RFC 3261 - section 12.2.1.1, Asterisk should be placing the remote target URI in the REQUEST-URI when the route set is not empty and the first URI in the route set contains the lr parameter.

SUMMARY:

17.1.1.3's rules do not apply to the ACK being sent from Asterisk (UAC) to the UAS following a UAS's 200 response. This is clearly stated in the second sentence of section 17.1.1.3. 17.1.1.3 states that generation of this ACK falls under the guidelines of Section 13. Section 13.1 makes the distinction that ACK requests to final responses between 300 - 699 are processed in the transaction layer (section 17), while ACK responses to 2xx responses are processed by the UAC core. In section 13.2.2.4, the RFC states that the UAC Core must construct the ACK header fields following the UAS's 2xx response in accordance with a request sent within a dialog. ACK's to 2xx responses must follow the guidelines of section 12. In section 12.2.1.1, the RFC defines how a UAC is supposed to generate a request. This section states that the UAC must place the target URI into the Request URI when the route set is not empty and the first URI in the route set contains the lr parameter.

In section 6 (definitions):

User Agent Client (UAC): A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction.

UAC Core: The set of processing functions required of a UAC that reside above the transaction and transport layers.

User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction.

UAS Core: The set of processing functions required at a UAS that resides above the transaction and transport layers.

In section 17.1.1.3, paragraph 1 (Transactions - Client Transaction - INVITE Client Transaction - Construction of the ACK Request):

This section specifies the construction of ACK requests sent within the client transaction. A UAC core that generates an ACK for 2xx MUST instead follow the rules described in Section 13.

In section 13.1, paragraph 2 (Initiating a Session - Overview):

After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response.

Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests (like OPTIONS).

Once it receives a final response, the UAC needs to send an ACK for every final response it receives. The procedure for sending this ACK depends on the type of response. For final responses between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See Section 17). For 2xx responses, the ACK is generated by the UAC core.

In section 13.2.2.4, paragraph 2 (Initiating a Session - 2xx Responses):

The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately.

In section 12.2.1.1, paragraph 7 (Dialogs - UAC Behavior - Generating the Request):

If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.

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

Sample SIP messages showing bad request line: 200ok and ACK only

All relevant IP's have been changed:
Sip Express Router: 111.111.111.111
UAS: 222.222.222.222
Asterisk: 10.3.3.3

The architecture these messages were captured from was constructed as follows:
Asterisk(non-routable DMZ) <--> SER (Routable DMZ) <--> INTERNET <--> UAS (B2BUA) <--> Xten/CSCO client

(200 OK from DMZ UAS to UAC)
Internet Protocol, Src Addr: 222.222.222.222 (222.222.222.222), Dst Addr: 111.111.111.111 (111.111.111.111)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 Ok Message Header
Via: SIP/2.0/UDP 111.111.111.111;branch=z9hG4bK827.1ae57743.0
Via: SIP/2.0/UDP 10.3.3.3:5060;rport=5060;branch=z9hG4bK1622c5f3
From: "6175551111" <sip:6175551111@10.3.3.3>;tag=as2a380c16
To: <sip:6175552222@sbc1.mycompany.com>;tag=1670967076
Contact: <sip:eP8Ed1Ne4W80N3Np2WLJY6FwYMUA2e1KUprkUHjUXhGcMn9MrEZqwB2ITFsVbEMuz00hyhLbtUlp_OLePVf_CwtSyrVCcubv3sltiP0DKVn_sA5in1v1fKYFFWpWOtqrj@222.222.222.222>
Record-Route: <sip:euqnru5yguRgMX0doElT-PrnQVapPaz-hgzx6uYYXKye8YyMPo2l4q41D24AN9fp4@222.222.222.222;lr>, <sip:a26480b@222.222.222.222;lr>, <sip:6175552222@111.111.111.111;ftag=as2a380c16;lr=on>
Call-ID: 776de48458f201852a46e5fd6b4bd982@10.3.3.3
CSeq: 102 INVITE
Content-Type: application/sdp
Server: X-Lite release 1103m
Content-Length: 286

ACK from UAC to UAS
Internet Protocol, Src Addr: 10.3.3.3 (10.3.3.3), Dst Addr: 111.111.111.111 (111.111.111.111)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol
Request-Line: ACK sip:6175552222@sbc1.mycompany.com SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.3.3.3:5060;branch=z9hG4bK41b0d825
Route: <sip:a26480b@222.222.222.222;lr>,<sip:euqnru5yguRgMX0doElT-PrnQVapPaz-hgzx6uYYXKye8YyMPo2l4q41D24AN9fp4@222.222.222.222;lr>
From: "6175551111" <sip:6175551111@10.3.3.3>;tag=as2a380c16
To: <sip:6175552222@sbc1.mycompany.com>;tag=1670967076
Contact: <sip:6175551111@10.3.3.3>
Call-ID: 776de48458f201852a46e5fd6b4bd982@10.3.3.3
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0

------------
Patch submitted by oej. Disclaimer on file.

Comments: By: Brian West (bkw918) 2004-10-20 22:00:21

This is not a major bug. Please read the bug guidlines. Granted its an issue but its far from a show stopper. Have you tried pedantic=yes in sip.conf ...

;pedantic=yes ; Enable slow, pedantic checking for Pingtel
; and multiline formatted headers for strict
; SIP compatibility (defaults to "no")
By: salvatoregiudice (salvatoregiudice) 2004-10-21 11:17:57

It is a show stopper if you have a outbound proxy such as Ingate,Jasomi, etc deployed on your firewall perimeter for enterprise-level employee access to external sip services. It effectively prevents users on the intranet from recieving calls from external sip services based on asterisk. The audio will never setup properly if asterisk does not follow the rules when handling requests within a dialog.

Pedantic checking does not alleviate the situation. Asterisk needs to follow the guidelines set forth in rfc3261, section 12 instead of section 17.
By: Brian West (bkw918) 2004-10-21 23:59:20

Also remember asterisk isn't a proxy its a b2bua... not sure if that is going to change the rules any. Oh the joys of SIP....
By: salvatoregiudice (salvatoregiudice) 2004-10-22 10:53:58

It doesn't matter how you classify the software. When constructing a SIP channel, the party that issues the INVITE is the UAC. The party that receives the INVITE is the UAS. It doesn't matter whether the software is passing a call from another channel or if the call comes from the console. The reality is that a new sip session is being established and, as such, is covered by RFC3261.

I'm very sure that labelling Asterisk as a B2BUA doesn't change the rules any.
By: Brian West (bkw918) 2004-10-27 19:26:06

Any response?
By: Olle Johansson (oej) 2004-10-28 01:57:51

This is a bug in Asterisk. Could we please get some complete SIP dialogues on REGISTER and INVITEs added to this report, not just the two packets.
By: salvatoregiudice (salvatoregiudice) 2004-10-28 19:30:08

I will put together a textual trace tomorrow of the call flow. Unfortunately, I can not provide raw tcpdumps due to our internal information disclosure policies. I will try to have it posted by friday night.
By: chadbrown (chadbrown) 2004-10-29 20:50:03

I found the same bug in my environment:

This bug was found while testing a device by INGATE called the SIParator for the purposes of traversing NAT.

The Siparator's job is to help SIP traverse NATs. In our scenerio it's function is rather simple:

Asterisk <--------------> Siparator <-------------->Broadvox (Any UA really)

10.10.0.6 --------- 10.10.0.5/67.136.5.30 ------- 66.243.109.210

Both inbound and outbound sip traffic was routed through the siparator without any problems on Asterisk Stable from 09/16/04.

However, something changed in chan_sip shortly after that time which broke our solution. All current CVS head and Stable builds have the same problem described below.

Please note that I uploaded an output from sip debug. I also have comparison logs of both a good and bad call for both Asterisk and SIParator. If needed I can provide them. In fact...I will provide whatever logs or access you need as this is a major bug and show stopper for our company.

-----------------------------------------------------------------------------

I traced the problem with outbound calls to an improper ACK. After forwarding several logs to INGATE tech support they sent me the following detail:

Chad,

The problem is that the Asterisk server is not following the RFC. Not only is it not following it in the "bad call", but it is not following it in the "good call" either. It just so happens that they are doing it "wrong" differently in each case. In the case of the "good call", things seem to work anyway despite the incorrect format of the ACK.

As you will see in the excerpts from the RFC, assuming that the Asterisk is acting as a loose router, then the the remote target of the route set of this dialog is set by the Contact: header of the 200 OK. That URI should be used by the UA as the Request URI of the ACK, but it isn't. (The Asterisk is populating it Request URI with sip:12534056726@10.10.0.5 rather than sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@10.10.0.5). Therefore, the SIParator is sending the ACK where it is being told. It is just being told the wrong place. If it had received the correct URI, it would have decrypted it and sent it to the correct place.

In the case of the "Good Call", the Asterisk IS populating the Request URI correctly, however, it should then include a Route header with the route set values in order. Instead, it is adding the Route header and populating it with the contents of the Contact field(sip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW@10.10.0.5.) It should be populating it with sip:26998a73@10.10.0.5;lr.

... Several Duplicate quotes already mentioned from RFC ...

In summary, the problem is being caused by the incorrect format of the ACKs coming from the Asterisk. This should be corrected there. Please let me know if you have any questions.

Thanks
Shane Cleckler
Mgr Systems Engineering
Ingate Systems

edited on: 10-30-04 11:10

edited on: 10-30-04 11:12

edited on: 10-30-04 11:13

edited on: 10-30-04 11:16
By: salvatoregiudice (salvatoregiudice) 2004-11-01 17:07:57.000-0600

I attached expanded dump from ethereal as plaintext.zip. Obviously, all the ip's have been replaced.
By: chadbrown (chadbrown) 2004-11-12 10:58:05.000-0600

How much would it cost to get this bug fixed? Send me an e-mail at chad.brown@identitymine.com. I need this problem solved.
By: Russell Bryant (russell) 2004-11-14 23:34:27.000-0600

You can contact someone who does custom development to have this fixed.

An option would be to contact sales@digium.com
By: Olle Johansson (oej) 2004-11-21 12:21:27.000-0600

If I understand reading RFCs 'til my eyes bleed:
* The INVITE is sent to AOR or registred Contact: address
* The 200 OK is a reply, sent to the sender of the INVITE through proxys
* The ACK is sent to the Contact: in the 200 OK
* The BYE is sent to the Contact: in the 200 OK
* I guess that a CANCEL should be sent to the Contact in a 200 OK if we've received one

The messages following the 200 OK should be routed according to routing headers, but addressed to the URI in the Contact: header in the 200 OK.

Today, Asterisk sends ACK and BYE to the same address as we use in the INVITE. If I understand the RFCs and explanations from Ingate and Intertex, we need to change this.

Most Asterisk SIP users seems to have phones connected directly to Asterisk, without a proxy in between. Otherwise we would have discovered this error a long time ago :-)
By: salvatoregiudice (salvatoregiudice) 2004-11-22 10:27:22.000-0600

Our environment actually looks like:

UA <----> Ingate <--- IPSEC ---> Ingate

Basically, an IPSEC tunnel between two B2BUA's allows us to traverse our firewall with a minimal rule set. Many large enterprises are deploying SIP B2BUA's in this fashion to facilitate employee access to external SIP services. Each of these Ingates stores conenction state in the contact URI field.

As more and more large corporations adopt Asterisk for call applications or as a Cisco AS5xxx gateway replacement, the use of SBC's to contruct tiers of SIP termination or protocal validation, or to create SIP gateways for SIP unaware firewalls will become increasingly more common.
By: chr (chr) 2004-12-12 10:52:40.000-0600

The same problem affects asterisk working as a PSTN/VOIP gateway in a Microsoft Life Communcation Server 2005 Environment.
Inbound calls are not properly established, while outbound calls are not affected. Would be great if this problem could be fixed.
By: chr (chr) 2004-12-12 19:38:39.000-0600

SER seems also to be affected by this bug, to an ACK request from asterisk it logs:

DEBUG: RFC3261 transaction matching failed
By: fcs_1 (fcs_1) 2004-12-13 10:01:59.000-0600

Having same failure using a sonicwall dmz. * and sipura 2000 adapter both in the dmz but outgoing calls from the adapter do not stop ringing when called party answers. Voice path is not setup and the last message adapter sees is 180 ringing.

Same setup using dmz from a SmoothWall Express 2.0 router works fine.
By: chr (chr) 2004-12-13 10:33:35.000-0600

Using the VOVIDA/VOCAL B2BUA between SER and Asterisk worked as a temporary fix for me. Calls can now be sucessfully established between Asterisk and the taget system -a windows messenger connected to a Microsoft LCS2005 server-.
As this bug does not seems to get fixed soon, this may be a solution for people that have serious problem, because of this bug.
By: Olle Johansson (oej) 2004-12-16 13:58:35.000-0600

Added patch. Disclaimer on file.

This patch needs testing! We are changing some significant logic here and I need feedback.
What we do:
* Save contact URI on 200 OK and use that for ACK/BYE
* Parse contact URI and change IP address/port of the other end to this address

You will hopefully not see any difference, unless you have a proxy between yourself and the other end of the call.
By: Olle Johansson (oej) 2004-12-16 14:58:25.000-0600

Btw, the patch is for cvs head.
By: chr (chr) 2004-12-16 15:05:30.000-0600

I would test it, if you could post the complete chan_sip.c for asterisk 1.0.2 ...
By: Brian West (bkw918) 2004-12-16 16:00:31.000-0600

Hand patch it. Earn it for 1.0.2 :P

bkw
By: Olle Johansson (oej) 2004-12-17 02:02:53.000-0600

Todo:
* Fix BYE (easy) - should also be sent to the Contact: address from 200 OK
* Route handling seems wrong with this patch, need to study that part a bit more.
By: Mark Spencer (markster) 2004-12-17 03:05:13.000-0600

Great, just need confirmation this works and I'll put it in CVS head. Thanks oej!
By: geertn (geertn) 2004-12-17 18:22:56.000-0600

User test report:
Applied this to -stable. This does not break anything for me (as expected), and for confirmation I know SER also disregards the recordroute with BYE & ACK.

edited on: 12-17-04 18:32
By: Mark Spencer (markster) 2004-12-18 09:28:44.000-0600

Fixed in CVS, nicely done Olle!
By: Russell Bryant (russell) 2004-12-19 20:37:20.000-0600

geertn: Thanks for the confirmation

fixed in 1.0
By: zoa (zoa) 2004-12-20 03:29:20.000-0600

I dont know if this belongs to this fix or one of the subfixes.

This appeared on the mailinglist this morning:
----

It appears that the problem with the patch that OEJ submitted is in the new parse_ok_contact function. Basically, the function is parsing the "sip:" qualifier out of the contact before storing it in pvt->okcontacturi. This causes the ACK that is generated to be non-compliant. To fix it, within parse_ok_contact, change:

***************
/* Make sure it's a SIP URL */
if (strncasecmp(c, "sip:", 4)) {
ast_log(LOG_NOTICE, "'%s' is not a valid SIP contact (missing sip:) trying to use anyway\n", c);
} else
c += 4;

strncpy(pvt->okcontacturi, c, sizeof(pvt->okcontacturi) - 1);

***************

to:

***************
strncpy(pvt->okcontacturi, c, sizeof(pvt->okcontacturi) - 1);

/* Make sure it's a SIP URL */
if (strncasecmp(c, "sip:", 4)) {
ast_log(LOG_NOTICE, "'%s' is not a valid SIP contact (missing sip:) trying to use anyway\n", c);
} else
c += 4;
***************

(sorry... I can't provide a unified diff... I back-ported the fix into an older copy of CVS...)

----- Original Message ----- From: "Matt Hess" <mhess@livewirenet.com>
To: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
Sent: Monday, December 20, 2004 12:39 AM
Subject: [Asterisk-Dev] stable chan_sip borked

> The latest stable version of chan_sip (1.510.2.27) breaks almost all of
> our stuff.. cisco ata devices no longer work for audio.. most of our
> voip terminators also spit back a lot of errors.. reverted back to cvs
> -D2004-12-10 and things were happy again.
>
> just fyi.
>
>
By: geertn (geertn) 2004-12-20 03:59:11.000-0600

Snom phones seem not to be affected by this. That's why I did not see this problem. Without this fix:
BYE nielsoffice@192.168.1.10:5060;line=pcr5ww3y SIP/2.0

With this fix:
BYE sip:nielsoffice@192.168.1.10:5060;line=pcr5ww3y SIP/2.0
By: Mark Spencer (markster) 2004-12-20 04:36:59.000-0600

Fixed in CVS, sorry about that!
By: Russell Bryant (russell) 2004-12-21 10:21:31.000-0600

fixed in 1.0
By: salvatoregiudice (salvatoregiudice) 2005-03-02 16:29:34.000-0600

We are testing version 1.0.5 stable with the callerid patch with out Ingate Siperator outbound proxy configuration. Although the request uri is now using the last entry in the record route set as the rfc states it should. It seems that the new ACK that is genererated only contains a single record route parameter. According to rfc 3261, the entire record route set should be present, but in reverse order. The result of this problem is that the Ingate proxies recieve the ACK, but do not know where to forward the traffic. This causes the media path to fail.

Please advise if this has been fixed in version 1.0.6 stable or in the CVS head. BTW, here is the 200ok and the subsequent ACk from a SIP to PSTN call for the following setup:

Asterisk(non-routable DMZ) <--> SER (Routable DMZ) <--> INTERNET <--> Ingate (DMZ) <--> Ingate (Intranet) <--> Xten/CSCO/Innomedia client

This is the 200 ok sent from the Ingate Siparator (192.223.123.123) to my SER box (207.252.123.123). This 200 ok is forwarded to the asterisk pbx (10.202.15.4) in the non-routable app domain.
SIP/2.0 200 OK
To: <sip:6173164913@sbc1.mydomain.com>;tag=f9767e5a
From: "6175635595"<sip:6175635595@10.202.15.4>;tag=as6df9c9ab
Via: SIP/2.0/UDP 207.252.123.123;branch=z9hG4bK1bc8.8e575a73.0
Via: SIP/2.0/UDP 10.202.15.4:5060;rport=5060;branch=z9hG4bK00db5bd0
Call-ID: 43e4e25132f0b3c273b684061fa1cfb8@10.202.15.4
CSeq: 102 INVITE
Record-Route: <sip:eCzOne8RyOhnuP9CS3tRHKpCDbbEpHY18lZEbd6LvbgPcaJMwuICkvJNMdTSI3mcO@192.223.123.123;lr>
Record-Route: <sip:715b5e66@192.223.123.123;lr>
Record-Route: <sip:6173164913@207.252.123.123;ftag=as6df9c9ab;lr=on>
Contact: <sip:eHjq9UNdmBJcOsuCM9Zr5F6T_v2tPA1MXl4_Q4zrBoIUKFnXDxKXEEBVX_stJ6RngUdBftNdyAc8jKVLMnt3-RTFD6RFn5Mnsh6Sl8aE9hHvsA5in1v1fKYFFWpWOtqrj@192.223.123.123>
Content-Type: application/sdp
Content-Length: 262

v=0
o=- 949936949 949940845 IN IP4 192.223.123.123
s=eyeBeam
c=IN IP4 192.223.123.123
t=0 0
m=audio 58468 RTP/AVP 0 101
a=alt:1 1 : F72F2BE4 66F0E226 10.47.206.195 6992
a=fmtp:101 0-15
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

ACK sip:6173164913@sbc1.mydomain.com SIP/2.0
Max-Forwards: 10
Record-Route: <sip:6173164913@207.252.123.123;ftag=as6df9c9ab;lr=on>
Via: SIP/2.0/UDP 207.252.123.123;branch=0
Via: SIP/2.0/UDP 10.202.15.4:5060;rport=5060;branch=z9hG4bK0267fbf4
Route: <sip:715b5e66@192.223.123.123;lr>,<sip:eCzOne8RyOhnuP9CS3tRHKpCDbbEpHY18lZEbd6LvbgPcaJMwuICkvJNMdTSI3mcO@192.223.123.123;lr>
From: "6175635595" <sip:6175635595@10.202.15.4>;tag=as6df9c9ab
To: <sip:6173164913@sbc1.mydomain.com>;tag=f9767e5a
Contact: <sip:6175635595@10.202.15.4:5060>
Call-ID: 43e4e25132f0b3c273b684061fa1cfb8@10.202.15.4
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0
P-hint: rr-enforced
By: Olle Johansson (oej) 2005-03-03 01:06:42.000-0600

See my earlier comment on route handling. I agree. Think that there's another bug open on that topic now, and will look into this soon. But don't expect anything for me for a week, since it's the VON expo next week.
By: Olle Johansson (oej) 2005-03-03 01:07:17.000-0600

See bug 3609
By: salvatoregiudice (salvatoregiudice) 2005-03-03 06:41:31.000-0600

Correct me if I am off base here, but as far as I can tell this bug was never fixed. In my capture from version 1.0.5 stable, the request uri in the ACK is still the original target uri: sip:6173164913@sbc1.mydomain.com

Shouldn't it be the first element in the rroute set: sip:eCzOne8RyOhnuP9CS3tRHKpCDbbEpHY18lZEbd6LvbgPcaJMwuICkvJNMdTSI3mcO@192.223.123.123

When this ACK gets to my Ingate, it parses the request-URI and sip:6173164913@sbc1.mydomain.com means nothing to the device. The sip:eCzOne8RyOhnuP9CS3tRHKpCDbbEpHY18lZEbd6LvbgPcaJMwuICkvJNMdTSI3mcO@192.223.123.123 line is what the device is looking for in order to maintain state within the sip dialog. The Ingate device simply doesn't know what to do with the ACK because this request-URI is wrong. The original 200ok/ack pair form the beginning of this bug post illustrates that the same condition that existed in 1.0.2 is still in 1.0.5, etc.

I checked bug 3609 and it does not apply to this problem because all the elements of my route set are loose and not strict.
By: Olle Johansson (oej) 2005-03-17 08:32:26.000-0600

Please test with CVS head and confirm if it works or not.
By: Olle Johansson (oej) 2005-03-22 01:11:57.000-0600

No response.
By: salvatoregiudice (salvatoregiudice) 2005-03-29 14:22:39.000-0600

I can not check the CVS. We only run stable versions in production. I will be upgrading to version 1.0.7 by next Friday. By then, I will tell you if the problem still exists in version 1.0.7.
By: mimmo (mimmo) 2005-03-31 03:05:39.000-0600

I'm trying Asterisk to forward incoming PSTN calls to Microsoft LCS via SER (to convert from UDP to TCP).
I'm trying Debian unstable (1.0.7) but this bug is still present.
Do I need to compile from CVS? I'm not a guru...
Is 'salvatoregiudice' from Italy as me? Could he contact me at dviggiani at tiscali dot it to exchange some experiences?

edited on: 03-31-05 03:11
By: Olle Johansson (oej) 2005-03-31 04:29:03.000-0600

YOu need to test this with current CVS. Please respond.
By: mimmo (mimmo) 2005-03-31 10:54:06.000-0600

I just compiled from CVS but problem still exists.
I'm not so expert to look into details of SIP protocol dialog.
Call is established but external callers (calling on a CAPI driver) are not able to hear internal users (WMessenger on a Microsoft LCS), viceversa yes.
These are latest packets:

SIP MESSAGE 4 10.99.1.9:5060() -> 111.222.64.118:33072()
TCP Frame 214 31/Mar/05 18:57:23.4412 TimeFromPreviousSipFrame=2.7644 TimeFromStart=12.9676
SIP/2.0 200 OK
Contact: <sip:myuser@mydomain.it:2264;maddr=111.222.66.207;transport=tcp;ms-received-cid=6B00>
Via: SIP/2.0/TCP 111.222.64.118;branch=z9hG4bK824d.a7cf63c2.0;ms-received-port=33072;ms-received-cid=bc00
Via: SIP/2.0/UDP 111.222.64.118:5061;branch=z9hG4bK06fb1eba
From: "01238994" <sip:01238994@111.222.64.118:5061>;tag=as5b2eaeac
To: <sip:myuser@mydomain.it>;epid=9db2871c77;tag=8c5c7a009a3747118b2d963a48e24def
Call-ID: 45b2f63c541b7bc54af8f31716323480@111.222.64.118
CSeq: 102 INVITE
Record-Route: <sip:ECO.mydomain.it;transport=tcp;lr>
Record-Route: <sip:myuser@111.222.64.118;transport=tcp;r2=on;ftag=as5b2eaeac;lr=on>
Record-Route: <sip:myuser@111.222.64.118;r2=on;ftag=as5b2eaeac;lr=on>
User-Agent: RTC/1.3
Content-Type: application/sdp
Content-Length: 240

v=0
o=- 0 0 IN IP4 111.222.66.207
s=session
c=IN IP4 111.222.66.207
b=CT:1000
t=0 0
m=audio 24626 RTP/AVP 8 3 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

-----------------------------------------------------------------------------------------

SIP MESSAGE 5 111.222.64.118:33072() -> 10.99.1.9:5060()
TCP Frame 229 31/Mar/05 18:57:23.4628 TimeFromPreviousSipFrame=0.0216 TimeFromStart=12.9891
ACK sip:myuser@mydomain.it:2264;maddr=111.222.66.207;transport=tcp;ms-received-cid=6B00 SIP/2.0
Max-Forwards: 10
Record-Route: <sip:myuser@111.222.64.118;transport=tcp;r2=on;ftag=as5b2eaeac;lr=on>
Record-Route: <sip:myuser@111.222.64.118;r2=on;ftag=as5b2eaeac;lr=on>
Via: SIP/2.0/TCP 111.222.64.118;branch=0
Via: SIP/2.0/UDP 111.222.64.118:5061;branch=z9hG4bK2603e454
Route: <sip:ECO.mydomain.it;transport=tcp;lr>
From: "01238994" <sip:01238994@111.222.64.118:5061>;tag=as5b2eaeac
To: <sip:myuser@mydomain.it>;tag=8c5c7a009a3747118b2d963a48e24def
Contact: <sip:01238994@111.222.64.118:5061>
Call-ID: 45b2f63c541b7bc54af8f31716323480@111.222.64.118
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0

I can confirm that inserting Vovida B2bUA between Asterisk and SER works.

edited on: 03-31-05 11:12

edited on: 04-01-05 06:13
By: mimmo (mimmo) 2005-04-01 03:39:18.000-0600

Reminder sent to chr, oej, salvatoregiudice, zoa

Can someone give me some feedback on this bug? I have serious problems and I'd like to know if there is some chance to solve it.
Mailing-list is extremely noise and noone is giving me some attention.
Can anyone confirm that this bug is still open, according to dump I posted?
I think in the same situation of 'chr' (Asterisk---SER---LCS) and I'd like to exchange some idea about this.

By: salvatoregiudice (salvatoregiudice) 2005-04-11 14:51:32

From what I have seen, the bug is still in version 1.0.7 stable.

Also, why was this bug renamed to 'ACK sent to wrong address'? This is about properly setting the REQUEST-URI properly when the route set is not empty and the first URI in the route set contains the lr parameter

What exactly did OEJ's original patch fix? It didn't address the rfc non-compliance issue outlined in the original bug post.
By: salvatoregiudice (salvatoregiudice) 2005-04-12 12:09:58

In addition, why is this bug no longer as a major bug? Asterisk is not operating as it should. This prevents users inside a corporate network with an Ingate, Jasomi, or other similar session border controller deployed as an outbound proxy from recieving calls from an asterisk-based service. One would expect that phones behind a SBC should recieve calls from an Asterisk-based service. Asterisk should be interoperable with generic SBC's. Users expect that Asterisk will function properly with phones behind an SBC. Currently, there is no work around available. Also most of the enterprise users that have been living with this issue since October would agree that this is more than just a nuisance protocol violation.

From the bug posting guidelines:

MAJOR: A bug which completely prevents Asterisk from operating in a method that it normally is expected to operate -- and particularly if it cannot be reasonably worked around -- is MAJOR. Significant protocol violations that are not simply policy decisions are MAJOR.

MINOR: A bug which is an irritation -- but clearly is still a bug and not just wanting to see something behave differently are MINOR bugs.

If you will, please change the status of this bug back to major. I believe bkw made a mistake when he downgraded this bug to minor with his original bug notes. As a consequence, this issue has not gotten very much traction over the past 6 months.
By: salvatoregiudice (salvatoregiudice) 2005-04-12 12:13:31

Reminder sent to oej

Have you had a chance to revisit this issue lately?
By: mimmo (mimmo) 2005-04-13 03:32:16

I agree with salvatoregiudice.
Asterisk is not fully interoperable with other SIP proxy and it doesn't work at all if phones are not directly connected.
By: purpleguy (purpleguy) 2005-04-22 13:40:05

We have been experiencing this problem since Dec. It's still in the cvs head as of today - 03/23/2005. Is OEJ still actively working on this?
By: salvatoregiudice (salvatoregiudice) 2005-06-16 08:23:49

So I was thinking, maybe in October we could throw a birthday party for this bug.
By: Michael Jerris (mikej) 2005-06-27 23:40:08

Is this a duplicate of the loose\strict routing bug at this point or are there still other issues in head?
By: salvatoregiudice (salvatoregiudice) 2005-07-12 07:53:59

This bug is not a duplicate. Asterisk is supposed to put the "remote target uri" in the request-uri. It wrongfully inserts the "original target uri" into the request-uri.

The impact of this bug is that it causes inbound calls through an SBC like a Jasomi or an Ingate to fail. aka It prevents calls coming from an asterisk-based service from traversing the border of a corporate network.

Please read the original bug post. Mark Spencer is already aware of this bug and OEJ is ether unable or unwilling to fix it.

By: salvatoregiudice (salvatoregiudice) 2005-07-12 07:59:05

If this bug is not fixed soon, I am going to start taking hostages. Who's with me?
By: Michael Jerris (mikej) 2005-07-12 08:25:18

Please understand that for the most part, people voluteer their time to provide fixes. If you are unable to complete this fix on your own, you may find contracting out the work or providing a bounty a more affective way to get this fixed than taking hostages.
By: salvatoregiudice (salvatoregiudice) 2005-07-13 14:44:40

That's nice, I am all for community. However, this project is sponsored by Digium and their ultimate goal is to make money off this product. Until this bug is fixed, there is no realistic chance of Asterisk being adopted by large enterprises. It's in Digium's best interest to fix this if they want to make a significant push into big corporate networks. Appliancizing their product would be also give them a leg up. Until then, large corporate networks will continue to bypass Asterisk and use Cisco Universal gateways, etc.

Out of shear priniciple I would not post a bounty or pay Digium to make their product rfc compliant. Over time they will be architected out of the solution in favor of rfc compliant and easily managed soft switch appliances.

By: Olle Johansson (oej) 2005-07-20 09:40:25

salvatoregiudice: I said earlier that my patch did not fix it all... If you want help, calm down and tell us what needs to be done to fix this.
By: Chris St Denis (cstdenis) 2005-08-26 15:01:23

Having the same problem with asterisk 1.0.8 (or 1.0.9, I'm not certain).

Tried manually applying the sipack.txt patch but it didn't help.

I'm trying to proxy incomming calls through SER. Asterisk is being used here only as a PSTN gateway.
By: Chris St Denis (cstdenis) 2005-08-26 19:29:43

I was able to get the supplied patch to work by removing

else
c += 4;

from the parse_ok_contact function.

By: Olle Johansson (oej) 2005-09-09 08:24:46

Just fyi: This is on the to-do list for 1.2. Someone out there that is willing to help debug patches?
By: Chris St Denis (cstdenis) 2005-09-09 11:54:58

I might be able to debug them on my development server if you send them within the next month or so.
By: Olle Johansson (oej) 2005-09-12 11:17:06

I need a full SIP debug from asterisk cvs head showing the record-route problem that salvatore describes. Set debug =4 and verbose =4 and capture everything.

Please help me with this a.s.a.p. Thank you.
By: Olle Johansson (oej) 2005-09-13 06:54:43

Tried to repeat this with CVS head at SIPit, could not do that. Everything seems to work as expected with routing headers. Please tell me more, Salvatore.
By: Kevin P. Fleming (kpfleming) 2005-09-14 20:32:05

Let's try to get this one solved... if it cannot be replicated at SIPit using the same type of network gear that was originally involved, then it's possible we've already fixed the problem without realizing it :-)
By: Olle Johansson (oej) 2005-09-15 04:48:32

-- Not an issue. If reporter still believes it is an issue and have SIP debug output, PLEASE re-open this issue in the issue tracker. Thank you.
By: Digium Subversion (svnbot) 2008-01-15 15:17:01.000-0600

Repository: asterisk
Revision: 4476

U trunk/channels/chan_sip.c

------------------------------------------------------------------------
r4476 | markster | 2008-01-15 15:17:00 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge olle's amazing ACK fix (bug ASTERISK-2641)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4476
By: Digium Subversion (svnbot) 2008-01-15 15:17:21.000-0600

Repository: asterisk
Revision: 4498

U branches/v1-0/channels/chan_sip.c

------------------------------------------------------------------------
r4498 | russell | 2008-01-15 15:17:20 -0600 (Tue, 15 Jan 2008) | 2 lines

Olle's ACK fix (bug ASTERISK-2641)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4498
By: Digium Subversion (svnbot) 2008-01-15 15:17:26.000-0600

Repository: asterisk
Revision: 4504

U trunk/channels/chan_sip.c

------------------------------------------------------------------------
r4504 | markster | 2008-01-15 15:17:26 -0600 (Tue, 15 Jan 2008) | 2 lines

Minor ACk fix (bug ASTERISK-2641, again)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4504
By: Digium Subversion (svnbot) 2008-01-15 15:17:32.000-0600

Repository: asterisk
Revision: 4511

U branches/v1-0/channels/chan_sip.c

------------------------------------------------------------------------
r4511 | russell | 2008-01-15 15:17:32 -0600 (Tue, 15 Jan 2008) | 2 lines

fix missing "sip:" in ACK (bug ASTERISK-2641)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4511