Summary:ASTERISK-07911: ACK's transmitted by a SIP channel that is not outgoing can have To and From headers switched.
Reporter:stephen dredge (stephen_dredge)Labels:
Date Opened:2006-10-10 20:36:08Date Closed:2006-12-27 10:04:04.000-0600
Versions:Frequency of

A new sip channel is created by a incomming invite request, the call is established and the channel is up.

The channel now sends a reinvite and the remote party responds with 200 , the channel will send a ACK with the To and From headers switched.  


Function reqprep adds the To and From headers to a request from the stored basis request p->initreq, swapping them if the channel is not outgoing.(  SIP_OUTGOING is not set ). Because SIP_OUTGOING is only set at the creation of the channel, does not change afterwards and pvt->initrequest can be a request received or transmitted by the channel this logic will fail if a UAS channel sends requests or a UAC channel receives them.

One way to handle this would be to set a flag when pvt->initreq is updated to indicate whether the request was sent of received by the channel. Reqprep can then switch the headers if the basis request was recieved.
Comments:By: Serge Vecher (serge-v) 2006-10-13 12:46:05

stephen: can you please upload the change in the patch_file form please?

By: Olle Johansson (oej) 2006-10-17 07:04:29

I have a branch for working with this now. Need to test before committing.

By: Olle Johansson (oej) 2006-10-25 15:00:41

Please try the "siptransdirection" branch, based on 1.2. Thanks.

svn checkout http://svn.digium.com/svn/asterisk/team/oej/siptransdirection bugfix

By: Olle Johansson (oej) 2006-10-29 03:04:58.000-0600

Please re-try with latest svn trunk. Thanks.

By: Anthony LaMantia (alamantia) 2006-11-09 13:47:58.000-0600

stephen_dredge any updates? we need to know if this issue still requires work

By: stephen dredge (stephen_dredge) 2006-11-10 01:51:12.000-0600

I had a very quick look at the bugfix when it was posted (doesn't look like it still up) but have been  too busy to actually test it sorry. It looked like it might work but didn't really solve the underlying problem of using the base request without knowing it's origin. It also looked like there could be a race condition if you recieved a  new request just before a reply.

To illustrate the problem I am using this code to fix it for myself:

+ if ( pedanticsipchecking ) {
+ /* we don't know if the current initial request is one we received or sent so compare it's from tag with the channel */
+ /* tags to find out, then reverse the to & from headers for our new request if the basis request was not sent by this channel */
+ if (gettag(orig, "To", init_req_totag, sizeof(init_req_totag)) && gettag(orig, "From", init_req_fromtag, sizeof(init_req_fromtag))) {
+ if (!strcmp( init_req_fromtag, p->tag )) {
+ req_from = get_header(orig, "From");
+ req_to = get_header(orig, "To");
+ } else if (!strcmp( init_req_fromtag, p->theirtag )) {
+ req_from = get_header(orig, "To");
+ req_to = get_header(orig, "From");

messy but works reliably but is messy. we really just need a base request is ours/theirs flag. Should be a simple fix, soory i don't have the time to post a patch for this myself.

By: Olle Johansson (oej) 2006-11-10 07:14:06.000-0600

Well, we really need you to test the trunk to test what code we really have before we make a decision about applying more fixes... I would be very, very, very greatful if you could test as soon as possible - please, please!


By: Olle Johansson (oej) 2006-11-12 09:43:01.000-0600

Can we get a reply here? Thanks.

By: stephen dredge (stephen_dredge) 2006-11-13 07:31:41.000-0600

I'll be happy to try the bug fix, but the transdirection branch doesn't seem to be up any more. Where can I find the changes ?

By: Anthony LaMantia (alamantia) 2006-11-13 10:27:09.000-0600

It looks like from the message oej sent on 10-29-06 03:04, he wants to you try the latest svn trunk with his recent modifaction

grab it with the following:
svn co http://svn.digium.com/svn/asterisk/trunk asterisk-trunk

By: stephen dredge (stephen_dredge) 2006-11-14 07:04:03.000-0600

Missed that somehow. I wil test today.

By: Olle Johansson (oej) 2006-11-15 15:42:35.000-0600

Any feedback?

By: stephen dredge (stephen_dredge) 2006-11-16 07:42:35.000-0600

Sorry oej I' sure you would likt to close this bug but iwas unable to test today - boss hadsomething more urgent for me to do.

By: Olle Johansson (oej) 2006-12-05 12:54:33.000-0600

...and many days later the test result was...

By: Olle Johansson (oej) 2006-12-27 10:03:52.000-0600

Assuming this is resolved. No answer from reporter.