[Home]

Summary:ASTERISK-19560: broken CANCEL is record routes are added to ringing
Reporter:Daniel Marohn (dcamillo)Labels:
Date Opened:2012-03-19 10:34:35Date Closed:2012-03-26 09:38:09
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:10.1.0 Frequency of
Occurrence
Related
Issues:
Environment:debian 6.0Attachments:
Description:It seems that CANCEL requests are build wrong, if Record-Routes are added to ringing.

Original invite:
INVITE sip:xxx@xxx.xxx SIP/2.0
Via: SIP/2.0/UDP 217.x.x.x:5060;branch=z9hG4bK3ecbcbe4;rport
Max-Forwards: 70
From: "021xxxx" <sip:021xxx@x.x>;tag=as11111b29
To: <sip:x@x.x>
Contact: <sip:021x@x.x.x.x:5060>
Call-ID: 4ed3cfc64c1a15407fa6d4dc4a3ecdfb@x.x
CSeq: 103 INVITE
...

--some foo--

ringing:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 217.x.120.5:5060;branch=z9hG4bK3ecbcbe4;rport=5060
Record-Route: <sip:217.x.x.x;lr;ftag=as11111b29>
Record-Route: <sip:172.x.x.x;lr>
Record-Route: <sip:217.x.x.x:5060;r2=on;lr;ftag=as11111b29>
Record-Route: <sip:217.x.x.x;r2=on;lr;ftag=as11111b29>
From: "021xxxx" <sip:021x@x.x>;tag=as11111b29
To: <sip:x@x.x>;tag=20d7caf358f07611
Call-ID: 4ed3cfc64c1a15407fa6d4dc4a3ecdfb@x.x
CSeq: 103 INVITE
Contact: <sip:x@217.x.x.x:6230;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Length: 0

Cancel:
CANCEL sip:x@x.x SIP/2.0
Via: SIP/2.0/UDP 217.x.x.x:5060;branch=z9hG4bK3ecbcbe4;rport
Route: <sip:217.x.x.x;r2=on;lr;ftag=as11111b29>,<sip:217.x.x.x:5060;r2=on;lr;ftag=as11111b29>,<sip:172.x.x.x;lr>,<sip:217.x.x.x;lr;ftag=as11111b29>
Max-Forwards: 70
From: "021xxxx" <sip:021xxxx@x.x>;tag=as11111b29
To: <sip:x@x.x>
Call-ID: 4ed3cfc64c1a15407fa6d4dc4a3ecdfb@x.x
CSeq: 103 CANCEL
Content-Length: 0

See the Route Header? There was no one in the invite, so it must not be in the cancel. This cancel is rejected by openSER (even IF the route is correct for some reason, without the to tag it cannot get routed).

Quick fix, that works for me:

static void initreqprep(struct sip_request *req, struct sip_pvt *p, int sipmetho
* NOTIFY messages will use this function for preparing the request and should
* have Route headers present.
*/
- add_route(req, p->route);
+ if(sipmethod != SIP_CANCEL) {
+ add_route(req, p->route);
+ }

I guess this will not work, IF there is a route inside the INVITE. Sorry, for not really fixing the problem (first time I have seen the sources and 10 years since my last c coding).
Comments:By: Matt Jordan (mjordan) 2012-03-20 11:53:35.964-0500

A number of changes were made to the handling of INVITE, CANCEL, and ACK request/responses in 10.1.3.  Please re-test with that version.
By: Daniel Marohn (dcamillo) 2012-03-23 03:02:37.765-0500

Not that easy to deploy the new version into my test enviroment, so I cannot test it right now.

But I see in Sources for 10.2.1 that the problem is more or less handled as in my quickfix, so I guess it will work.

thx for looking into it.
By: Matt Jordan (mjordan) 2012-03-26 09:38:00.774-0500

I'll close this issue for now, since it looks like it was fixed in later versions of 1.8/10.  If you retest with a later version and that's not the case, just contact a bug marshal in #asterisk-bugs or on the mailing list and we'll reopen this issue.

Thanks

Matt