[Home]

Summary:ASTERISK-01476: Record-Route not being properly handled
Reporter:gdalgliesh (gdalgliesh)Labels:
Date Opened:2004-04-27 13:44:13Date Closed:2008-01-15 14:53:28.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Asterisk doens't seem to be properly handling Record-Route processing. When asterisk recieves a SIP message with a Record-Route the message in response doesn't seem to be properly formatted and in the end causes the Asterisk bypass the Proxies and send messages directly to the UA.

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

Example:

xxx.yyy.154.243(PSTN-GW) <--sip--> xxx.yyy.77.23(Asterisk) <--sip-->
xxx.yyy.91.74(SNOM or SER proxy) <--sip----> xxx.yyy.165.201(ATA186)

1) Call place from PSTN to xxx9931211
2) Asterisk via rules in extension.conf sends call to xxx.yyy.91.74
3) xxx.yyy.91.74 sends call to xxx.yyy.165.201 which is registered as
xxx9931211
4) Call completes fine and audio works
5) PSTN Hangs up and the sends a BYE to Asterisk
6) Asterisk recieves the bye and sends BYE directly to the UA skipping the
proxy
7) Results is that the proxy never recieves a BYE

Complete SIP Trace
http://www.routerboy.com/sip2004041902.html

Example of actual Record-Route issue:
-Message 9 the Proxy sends a Record-Route to Asterisk and Message 10 seems
to be built are return to the Proxy but not with the infomation from the
Record-Route Statement.)

    SIP MESSAGE 9        xxx.yyy.91.74:5060(4) -> xxx.yyy.77.23:5060(2)
    UDP Frame 9        19/Apr/04 18:17:49.9304
TimeFromPreviousSipFrame=0.3592 TimeFromStart=2.1462
SIP/2.0 200 OK
Via: SIP/2.0/UDP xxx.yyy.77.23:5060;branch=z9hG4bK019f067c
Record-Route: <sip:proxy.abccorp.net:5060;maddr=xxx.yyy.91.74>
From: "xxx3427216" <sip:xxx3427216@xxx.yyy.77.23>;tag=as5304af8c
To: <sip:xxx9931211@proxy.abccorp.net>;tag=1841513983
Call-ID: 58d4bd4e5e29ff254db520665915ac83@xxx.yyy.77.23
CSeq: 102 INVITE
Contact: <sip:xxx9931211@xxx.yyy.165.201:5060;user=phone;transport=udp>
Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER
Server: Cisco ATA 186  v3.0.0 atasip (031210A)
Content-Type: application/sdp
Content-Length: 205

v=0
o=xxx9931211 18172 18172 IN IP4 xxx.yyy.165.201
s=ATA186 Call
c=IN IP4 xxx.yyy.165.201
t=0 0
m=audio 16384 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


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

    SIP MESSAGE 10       xxx.yyy.77.23:5060(2) -> xxx.yyy.91.74:5060(4)
UDP Frame 10       19/Apr/04 18:17:49.9310 TimeFromPreviousSipFrame=0.0006
TimeFromStart=2.1468 ACK sip:xxx9931211@xxx.yyy.165.201:5060 SIP/2.0 Via:
SIP/2.0/UDP xxx.yyy.77.23:5060;branch=z9hG4bK50c814eb Route:
<sip:xxx9931211@xxx.yyy.165.201:5060;user=phone;transport=udp> From:
"xxx3427216" <sip:xxx3427216@xxx.yyy.77.23>;tag=as5304af8c To:
<sip:xxx9931211@proxy.abccorp.net>;tag=1841513983 Contact:
<sip:xxx3427216@xxx.yyy.77.23> Call-ID:
58d4bd4e5e29ff254db520665915ac83@xxx.yyy.77.23 CSeq: 102 ACK User-Agent:
Asterisk PBX Content-Length: 0
Comments:By: gdalgliesh (gdalgliesh) 2004-04-27 13:47:17

Problem appears in Stable, Lastest CVS( Just tired 4/26/04 20:20 EST), and Lastest CVS w/chan_sip2t.c(Just tired 4/26/04 20:20 EST)
By: Mark Spencer (markster) 2004-04-27 20:43:32

I have to vent again.  Every time i read the SIP RFC, my blood pressure rises and I am reminded of what a piece of garbage it is, and how, remarkably, a standards body can take a simple concept like making a phone call -- even one over IP, and somehow turn it into to 253 pages (just counting rfc3261!) of inconsistent, unreliable, "lets ACK an INVITE but oh we need to introduce a new kind of sequence number to reliably deliver a 180 Ringing and oh, lets have Contact, Via and Record-Route all in the header and all specifying, in one way or another, where responses should go" pile of dog excrement.  Okay now I'm done venting, and can continue working.
By: Mark Spencer (markster) 2004-04-29 20:26:15

Find me on IRC.  As bizarre as this sounds, it looks like we're already patched in an effort to be able to support this, so I'll need to ssh in to try to find the real problem.
By: twisted (twisted) 2004-04-29 20:38:09

find us on IRC in #asterisk or #asterisk-bugs on irc.freenode.net.  ask for kram or myself (I'll put you in touch if you can't find him)
By: Olle Johansson (oej) 2004-04-30 07:32:12

I can't find the SIP trace on the URL above
By: gdalgliesh (gdalgliesh) 2004-04-30 13:34:38

Sorry, the harddrive in the server with the url died. It and the url are back up. Thanks
By: Mark Spencer (markster) 2004-04-30 20:14:56

It's hard to tell if this is really an Asterisk bug or not.  The short answer is the reason we send the BYE directly is that when we send the re-invite, the 200 OK that comes back from the reinvite does NOT contain the record-route information.  What I cannot glean from the specification is whether we are supposed to continue to honor the record-route from the original INVITE.  I will try to find out.  If you can find anything in the specification to support an interpretation one way or another, that would be great.
By: Mark Spencer (markster) 2004-05-03 09:58:00

Many thanks to Jonathan Rosenberg of DynamicSoft for clarifying:

Once the route-set is established by the initial INVITE, the only thing
that can be changed from subsequent re-invites is the contact. The bug
here is that asterisk should store the route-set and contact URI from
the initial INVITE, and continue to use them in subsequent signaling. It
is not required for proxies to re-record-route after the initial call is
set up.

-Jonathan R.

So, it genuinely *is* an Asterisk bug.  I'll get it fixed today.
By: Mark Spencer (markster) 2004-05-03 15:58:22

Okay please confirm as soon as possible that this fixes the problem.  If you continue to have trouble, please find me on IRC so I can ssh in and look at it more closely.
By: gdalgliesh (gdalgliesh) 2004-05-03 17:04:10

This shows a current trace.
http://www.routerboy.com/sip2004050300.html
Currently all the packets are going back thru the proxy but because the maddr is being used as the IP layer dest and the SIP messages the proxy can't determine what realm it belongs to. I believe below demonstrates what I think we should be seeing. (Disclamer: I am not RFC expert but from what I can tell this is the what should be returned)

Current packet from Proxy
    SIP MESSAGE 9        xxx.yyy.91.74:5060(2) -> xxx.yyy.77.23:5060(3)     UDP Frame 9        3/May/04 16:09:3.7399 TimeFromPreviousSipFrame=1.1061 TimeFromStart=3.0688 SIP/2.0 200 OK
Via: SIP/2.0/UDP xxx.yyy.77.23:5060;branch=z9hG4bK73c97498
Record-Route: <sip:proxy.abc.net:5060;maddr=xxx.yyy.91.74>
From: "7776662264" <sip:7776662264@xxx.yyy.77.23>;tag=as0e95c093
To: <sip:5556661210@proxy.abc.net>;tag=00055e7cd5590004050ced0d-66b3f109
Record-Route: <sip:proxy.abc.net:5060;maddr=xxx.yyy.91.74>
-----------------------------------------------------------------------------
Current returned packet
    SIP MESSAGE 10       xxx.yyy.77.23:5060(3) -> xxx.yyy.91.74:5060(2)     UDP Frame 10       3/May/04 16:09:3.7404 TimeFromPreviousSipFrame=0.0006 TimeFromStart=3.0694
ACK sip:5556661210@xxx.yyy.165.204:5060 SIP/2.0
Via: SIP/2.0/UDP xxx.yyy.77.23:5060;branch=z9hG4bK25097dcb
----------------------------------------------------------------------------
What I believe we should see in that packet
    SIP MESSAGE 10       xxx.yyy.77.23:5060(3) -> xxx.yyy.91.74:5060(2)     UDP Frame 10       3/May/04 16:09:3.7404 TimeFromPreviousSipFrame=0.0006 TimeFromStart=3.0694
ACK sip:5556661210@proxy.abc.net:5060 SIP/2.0
Via: SIP/2.0/UDP xxx.yyy.77.23:5060;branch=z9hG4bK25097dcb
By: Mark Spencer (markster) 2004-05-03 18:31:53

I don't believe that interpretation is correct.  I see nothing in the spec that suggests that we should rewrite the URI we are requesting due to the proxy.  Record-route just has to do with the routing of the response.  However, if you have host=proxy.abc.net instead of host=xxx.yyy.77.23 in your friend declaration you're using to talk to the proxy I think that should make us use the proxy's name in the invite.
By: gdalgliesh (gdalgliesh) 2004-05-03 19:21:14

You may be right I am trying to make sense of the RFC as are most, but what seems interesting to me is that I do have the host=proxy.abc.net in sip.conf and reference if in the Dial command that starts the call but then at http://www.routerboy.com/sip2004050300.html#FRAME10 all URI's begin to use the IP address of the UI. I also tried Dial proxy.abc.net directly in the extension.conf with the same results.

On the other hand the real issue in the trace is that F29 the PSTN GW(xxx.yyy.154.243) issues a BYE and *(xxx.yyy.77.23) replies OK to PSTN GW(xxx.yyy.154.243) but then sends an INVITE to the proxy(xxx.yyy.91.74). Then the proxy(xxx.yyy.91.74) replies with Trying then with repeating OK but *(xxx.yyy.77.23) doesn't respond. Partially because the call no longer exists. However, *(xxx.yyy.77.23) should have passed on the BYE to the Proxy(xxx.yyy.91.74) but didn't. Instead it seem to send an Invite.
By: Mark Spencer (markster) 2004-05-03 21:25:01

Just find me on IRC.  I don't like these edited scenarios so I'll try to look at them in real life on your system.  After the INVITE we should still send ACK and then BYE.  The INVITE to the opposite after receiving the BYE is still *correct* by asterisk's architecture because it brings the audio path back to Asterisk.   Does it work properly if the hangup is initiated on the other side?  Anwyay find me on IRC.
By: gdalgliesh (gdalgliesh) 2004-05-04 09:52:29

Tried to ping in IRC and I am going to be in and out all day. So, I captured a asterisk sip debug and placed it on the server in /root/AstDebug2004050400.txt.
This has all the real info in it. Hope that helps and I will try to find you when I am at my desk in IRC today. Thanks
By: Mark Spencer (markster) 2004-05-04 10:22:52

I don't have the login information, I'm afriad.  You'll have to find me on IRC.
By: Mark Spencer (markster) 2004-05-04 15:20:17

The request has the IP instead of the name because that's what we see in the Contact that comes back in the 200 OK.  A fix was made for the BYE issue in CVS.
By: Digium Subversion (svnbot) 2008-01-15 14:53:28.000-0600

Repository: asterisk
Revision: 2876

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r2876 | markster | 2008-01-15 14:53:27 -0600 (Tue, 15 Jan 2008) | 2 lines

Don't update route once it's set (bug ASTERISK-1476)

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

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