<div style='font-family:Times New Roman, Times, serif;font-size:12pt;color:#000000;'><div style="font-family: Times New Roman,Times,serif; font-size: 12pt; color: rgb(0, 0, 0);">Bogdan <br>I'm sorry - I commited the cardinal cut/paste sin (copying stuff incorrectly :-( )<br>Anyhow, I've *correctly* cut/paste the INVITE and BYE headers below, and it looks to me like the route headers *are* being rewritten correctly.<br>So, it doesn't look like that was the issue - unless you are referring to something else?<br><br>cheers<br><br><br>--- Original Message -----<br>From: Bogdan-Andrei Iancu <bogdan@voice-system.ro><br>To: mahesh@aptela.com<br>Cc: users@openser.org<br>Sent: Thursday, February 8, 2007 3:29:26 AM GMT-0600<br>Subject: Re: [Users] Corrupted 'To' after uac_restore_from<br><br>Hi Mahesh,<br><br>I suspect you have a client that does not preserve the <br>Route/Record-Route parameters. According to RFC326, the parameters must <br>not be altered at al, but I saw UAC doing lowercase on the param's <br>value. Most probably this is your case also - the uac module use B64 <br>encoding of the old uri in RR param, so this is case sensitive.<br><br>Get the full trace of the call and check the original RR param (inserted <br>by openser in INVITE) against the one in put in the BYE.<br><br>regards,<br>bogdan<br><br><br>---- CORRECTED MESSAGE-----<br><br><span style="color: rgb(0, 0, 0);"><font size="3">I'm seeing this *very* weird error where uac_restore_from is ending up with a corrupted 'From' header.<br>The weird thing is that it happens with only one end point (a Televantage SIP Trunk).<br>With
virtually *everything* else - and I am talking about tens of thousands
of end points, spanning all sorts of sip devices, we are having *no*
problems.<br>The call is set up as follows -> the endpoint sends the INVITE, which is forwarded to a PSTN gateway<br>The ACKs and the 200 OK all have their From/To headers appropriately rewritten<br>The problem arises when the PSTN gateway initiates the BYE As you can see below, the 'To' header gets corrupted<br><br>The *only* thing I can think of is that it has something to do with the structure of the Televantage tags (the '+' signs?).<br><br>Any ideas?<br><br>FYI, Openser 1.1.0 (latest CVS checkout), and <br>modparam("uac","from_restore_mode","auto")<br>modparam("uac","rr_store_param","aptelavsf")</font></span><br><br><div style="margin-left: 40px;"><font style="color: rgb(51, 102, 255);" size="2">--INVITE-- UAC->proxy<br>INVITE sip:17038677006@69.25.47.136 SIP/2.0.<br>Via: SIP/2.0/UDP 10.10.35.100;rport;branch=z9hG4bK+ec6a2a20436621337016546fa4dc9e87+10.10.35.100+1.<br>Allow-Events: message-summary.<br>Allow-Events: presence.<br>Allow-Events: refer.<br>Max-Forwards: 70.<br>Call-ID: 56796C1E@10.10.35.100.<br>From: "Member service"<sip:user100.crunchhq@69.25.47.136>;tag=10.10.35.100+1+8c020003+dd5437f3.<br>To: <sip:17038677006@69.25.47.136>.<br>CSeq: 132610708 INVITE.<br>Expires: 180.<br>Supported: replaces.<br>Supported: 100rel.<br>Contact: <sip:6462174165@10.10.35.100>.<br>Content-Type: application/sdp.<br>Content-Length: 242.<br>.<br>User-Agent: TeleVantage-UA/7.50.4817.<br>.<br>v=0.<br>o=TeleVantage 10671 0 IN IP4 10.10.35.100.<br>s=phone-call.<br>c=IN IP4 10.10.35.100.<br>t=0 0.<br>m=audio 6036 RTP/AVP 0 18 101.<br>a=rtpmap:0 pcmu/8000/1.<br>a=rtpmap:18 g729/8000/1.<br>a=fmtp:18 annexb=no.<br>a=rtpmap:101 telephone-event/8000/1.<br>a=ptime:20.<br><br>---INVITE--- proxy->gateway<br>INVITE sip:17038677006@65.91.91.16:5060;transport=udp SIP/2.0.<br>Record-Route: <sip:69.25.47.136;lr;ftag=10.10.35.100+1+8c020003+dd5437f3;nat=yes;aptelavsf=dGVzdDciIDR0YndrISJGfHtsaWBbPWQ7NiQ4LCJlISgv>.<br>Via: SIP/2.0/UDP 69.25.47.136;branch=z9hG4bKf67d.2d31dbb.0.<br>Via: SIP/2.0/UDP 10.10.35.100;rport=5060;branch=z9hG4bK+ec6a2a20436621337016546fa4dc9e87+10.10.35.100+1.<br>Allow-Events: message-summary.<br>Allow-Events: presence.<br>Allow-Events: refer.<br>Max-Forwards: 69.<br>Remote-Party-ID: "Membersevice Queue" <sip:6462174165@flareon.aptela.com>;party=calling;id-type=subscriber;screen=yes;privacy=off.<br>Supported: replaces.<br>Call-ID: 56796C1E@10.10.35.100.<br>From: "Membersevice Queue"<sip:6462174165@flareon.aptela.com>;tag=10.10.35.100+1+8c020003+dd5437f3.<br>To: <sip:17038677006@69.25.47.136>.<br>CSeq: 132610708 INVITE.<br>Expires: 180.<br>Contact: <sip:6462174165@10.10.35.100:5060>.<br>Content-Type: application/sdp.<br>Content-Length: 262.<br>User-Agent: TeleVantage-UA/7.50.4817.<br>.<br>v=0.<br>o=TeleVantage 10671 0 IN IP4 10.10.35.100.<br>s=phone-call.<br>c=IN IP4 66.150.122.23.<br>t=0 0.<br>m=audio 59520 RTP/AVP 0 18 101.<br>a=rtpmap:0 pcmu/8000/1.<br>a=rtpmap:18 g729/8000/1.<br>a=fmtp:18 annexb=no.<br>a=rtpmap:101 telephone-event/8000/1.<br>a=ptime:20.<br>a=nortpproxy:yes.<br><br>---BYE---gateway->proxy<br>BYE sip:6462174165@10.10.35.100:5060 SIP/2.0.<br>Via: SIP/2.0/UDP 66.52.236.25:5060;branch=z9hG4bKd8orpb20eg2hais2c2g1sd0000g00.1.<br>To: "Membersevice Queue"<sip:6462174165@69.25.47.136>;tag=10.10.35.100+1+8c020003+dd5437f3.<br>From: <sip:17038677006@66.52.236.25>;tag=1386496.<br>Call-ID: 56796C1E@10.10.35.100.<br>CSeq: 1 BYE.<br>Content-Length: 0.<br>Route: <sip:69.25.47.136;lr;ftag=10.10.35.100+1+8c020003+dd5437f3;nat=yes;aptelavsf=dGVzdDciIDR0YndrISJGfHtsaWBbPWQ7NiQ4LCJlISgv>.<br>Max-Forwards: 70.<br><br>---BYE--- proxy->UAC<br>BYE sip:6462174165@10.10.35.100:5060 SIP/2.0.<br>Record-Route: <sip:69.25.47.136;lr;ftag=1386496>.<br>Via: SIP/2.0/UDP 69.25.47.136;branch=z9hG4bK7791.48e0e2f5.0.<br>Via: SIP/2.0/UDP 66.52.236.25:5060;branch=z9hG4bKd8orpb20eg2hais2c2g1sd0000g00.1.<br>To: "Membersevice Queue"<sip:user100.cru>6'(!.l asr}XV.R\[>;tag=10.10.35.100+1+8c020003+dd5437f3.<br>From: <sip:17038677006@66.52.236.25>;tag=1386496.<br>Call-ID: 56796C1E@10.10.35.100.<br>CSeq: 1 BYE.<br>Content-Length: 0.<br>Max-Forwards: 69.</font><br></div><br><br>-- <br>*******************************************<br>Mahesh Paolini-Subramanya (703) 386-1500 x9100<br>CTO mahesh@aptela.com<br>Aptela, Inc. http://www.aptela.com<br>"Aptela: How Business Answers The Call"<br>*******************************************<br></div>