Oh good grief. Yer right. Turns out that this particular upstream gateway merrily insists on *always* sending 200 OK to the IP address.
Thanx for yer help! cheers ----- Original Message ----- From: Bogdan-Andrei Iancu <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: users <[email protected]> Sent: Thursday, February 8, 2007 11:53:09 AM GMT-0600 Subject: Re: [Users] Corrupted 'To' after uac_restore_from Hi Mahesh, actually my guess was correct - something used for restoring the old FROM uri was change. OK, it wasn't the Route parameter, but it is worst - it is the FROM new URI. the UAS receives : From: "Membersevice Queue"<sip:[EMAIL PROTECTED]>;tag=10.10.35.100+1+8c020003+dd5437f3 but when generating the BYE, it sends: To: "Membersevice Queue"<sip:[EMAIL PROTECTED]>;tag=10.10.35.100+1+8c020003+dd5437f3 changing the FROM/TO uris and tags is against RFC3261. regards, bogdan Mahesh Paolini-Subramanya wrote: > Bogdan > I'm sorry - I commited the cardinal cut/paste sin (copying stuff > incorrectly :-( ) > 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. > So, it doesn't look like that was the issue - unless you are referring > to something else? > > cheers > > > --- Original Message ----- > From: Bogdan-Andrei Iancu <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [email protected] > Sent: Thursday, February 8, 2007 3:29:26 AM GMT-0600 > Subject: Re: [Users] Corrupted 'To' after uac_restore_from > > Hi Mahesh, > > I suspect you have a client that does not preserve the > Route/Record-Route parameters. According to RFC326, the parameters must > not be altered at al, but I saw UAC doing lowercase on the param's > value. Most probably this is your case also - the uac module use B64 > encoding of the old uri in RR param, so this is case sensitive. > > Get the full trace of the call and check the original RR param (inserted > by openser in INVITE) against the one in put in the BYE. > > regards, > bogdan > > > ---- CORRECTED MESSAGE----- > > I'm seeing this *very* weird error where uac_restore_from is ending up > with a corrupted 'From' header. > The weird thing is that it happens with only one end point (a > Televantage SIP Trunk). > 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. > The call is set up as follows -> the endpoint sends the INVITE, which > is forwarded to a PSTN gateway > The ACKs and the 200 OK all have their From/To headers appropriately > rewritten > The problem arises when the PSTN gateway initiates the BYE As you > can see below, the 'To' header gets corrupted > > The *only* thing I can think of is that it has something to do with > the structure of the Televantage tags (the '+' signs?). > > Any ideas? > > FYI, Openser 1.1.0 (latest CVS checkout), and > modparam("uac","from_restore_mode","auto") > modparam("uac","rr_store_param","aptelavsf") > > --INVITE-- UAC->proxy > INVITE sip:[EMAIL PROTECTED] SIP/2.0. > Via: SIP/2.0/UDP > 10.10.35.100;rport;branch=z9hG4bK+ec6a2a20436621337016546fa4dc9e87+10.10.35.100+1. > Allow-Events: message-summary. > Allow-Events: presence. > Allow-Events: refer. > Max-Forwards: 70. > Call-ID: [EMAIL PROTECTED] > From: "Member > service"<sip:[EMAIL PROTECTED]>;tag=10.10.35.100+1+8c020003+dd5437f3. > To: <sip:[EMAIL PROTECTED]>. > CSeq: 132610708 INVITE. > Expires: 180. > Supported: replaces. > Supported: 100rel. > Contact: <sip:[EMAIL PROTECTED]>. > Content-Type: application/sdp. > Content-Length: 242. > . > User-Agent: TeleVantage-UA/7.50.4817. > . > v=0. > o=TeleVantage 10671 0 IN IP4 10.10.35.100. > s=phone-call. > c=IN IP4 10.10.35.100. > t=0 0. > m=audio 6036 RTP/AVP 0 18 101. > a=rtpmap:0 pcmu/8000/1. > a=rtpmap:18 g729/8000/1. > a=fmtp:18 annexb=no. > a=rtpmap:101 telephone-event/8000/1. > a=ptime:20. > > ---INVITE--- proxy->gateway > INVITE sip:[EMAIL PROTECTED]:5060;transport=udp SIP/2.0. > Record-Route: > <sip:69.25.47.136;lr;ftag=10.10.35.100+1+8c020003+dd5437f3;nat=yes;aptelavsf=dGVzdDciIDR0YndrISJGfHtsaWBbPWQ7NiQ4LCJlISgv>. > Via: SIP/2.0/UDP 69.25.47.136;branch=z9hG4bKf67d.2d31dbb.0. > Via: SIP/2.0/UDP > 10.10.35.100;rport=5060;branch=z9hG4bK+ec6a2a20436621337016546fa4dc9e87+10.10.35.100+1. > Allow-Events: message-summary. > Allow-Events: presence. > Allow-Events: refer. > Max-Forwards: 69. > Remote-Party-ID: "Membersevice Queue" > <sip:[EMAIL > PROTECTED]>;party=calling;id-type=subscriber;screen=yes;privacy=off. > Supported: replaces. > Call-ID: [EMAIL PROTECTED] > From: "Membersevice > Queue"<sip:[EMAIL PROTECTED]>;tag=10.10.35.100+1+8c020003+dd5437f3. > To: <sip:[EMAIL PROTECTED]>. > CSeq: 132610708 INVITE. > Expires: 180. > Contact: <sip:[EMAIL PROTECTED]:5060>. > Content-Type: application/sdp. > Content-Length: 262. > User-Agent: TeleVantage-UA/7.50.4817. > . > v=0. > o=TeleVantage 10671 0 IN IP4 10.10.35.100. > s=phone-call. > c=IN IP4 66.150.122.23. > t=0 0. > m=audio 59520 RTP/AVP 0 18 101. > a=rtpmap:0 pcmu/8000/1. > a=rtpmap:18 g729/8000/1. > a=fmtp:18 annexb=no. > a=rtpmap:101 telephone-event/8000/1. > a=ptime:20. > a=nortpproxy:yes. > > ---BYE---gateway->proxy > BYE sip:[EMAIL PROTECTED]:5060 SIP/2.0. > Via: SIP/2.0/UDP > 66.52.236.25:5060;branch=z9hG4bKd8orpb20eg2hais2c2g1sd0000g00.1. > To: "Membersevice > Queue"<sip:[EMAIL PROTECTED]>;tag=10.10.35.100+1+8c020003+dd5437f3. > From: <sip:[EMAIL PROTECTED]>;tag=1386496. > Call-ID: [EMAIL PROTECTED] > CSeq: 1 BYE. > Content-Length: 0. > Route: > <sip:69.25.47.136;lr;ftag=10.10.35.100+1+8c020003+dd5437f3;nat=yes;aptelavsf=dGVzdDciIDR0YndrISJGfHtsaWBbPWQ7NiQ4LCJlISgv>. > Max-Forwards: 70. > > ---BYE--- proxy->UAC > BYE sip:[EMAIL PROTECTED]:5060 SIP/2.0. > Record-Route: <sip:69.25.47.136;lr;ftag=1386496>. > Via: SIP/2.0/UDP 69.25.47.136;branch=z9hG4bK7791.48e0e2f5.0. > Via: SIP/2.0/UDP > 66.52.236.25:5060;branch=z9hG4bKd8orpb20eg2hais2c2g1sd0000g00.1. > To: "Membersevice Queue"<sip:user100.cru>6'(!.l > asr}XV.R\[>;tag=10.10.35.100+1+8c020003+dd5437f3. > From: <sip:[EMAIL PROTECTED]>;tag=1386496. > Call-ID: [EMAIL PROTECTED] > CSeq: 1 BYE. > Content-Length: 0. > Max-Forwards: 69. > > > -- > ******************************************* > Mahesh Paolini-Subramanya (703) 386-1500 x9100 > CTO [EMAIL PROTECTED] > Aptela, Inc. http://www.aptela.com > "Aptela: How Business Answers The Call" > ******************************************* -- ******************************************* Mahesh Paolini-Subramanya (703) 386-1500 x9100 CTO [EMAIL PROTECTED] Aptela, Inc. http://www.aptela.com "Aptela: How Business Answers The Call" ******************************************* _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
