[Users] Corrupted 'To' after uac_restore_from
Mahesh Paolini-Subramanya
mahesh at corp.aptela.com
Mon Feb 12 16:57:14 CET 2007
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 <bogdan at voice-system.ro>
To: mahesh at aptela.com
Cc: users <users at openser.org>
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:6462174165 at flareon.aptela.com>;tag=10.10.35.100+1+8c020003+dd5437f3
but when generating the BYE, it sends:
To: "Membersevice
Queue"<sip:6462174165 at 69.25.47.136>;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 <bogdan at voice-system.ro>
> To: mahesh at aptela.com
> Cc: users at openser.org
> 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:17038677006 at 69.25.47.136 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: 56796C1E at 10.10.35.100.
> From: "Member
> service"<sip:user100.crunchhq at 69.25.47.136>;tag=10.10.35.100+1+8c020003+dd5437f3.
> To: <sip:17038677006 at 69.25.47.136>.
> CSeq: 132610708 INVITE.
> Expires: 180.
> Supported: replaces.
> Supported: 100rel.
> Contact: <sip:6462174165 at 10.10.35.100>.
> 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:17038677006 at 65.91.91.16: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:6462174165 at flareon.aptela.com>;party=calling;id-type=subscriber;screen=yes;privacy=off.
> Supported: replaces.
> Call-ID: 56796C1E at 10.10.35.100.
> From: "Membersevice
> Queue"<sip:6462174165 at flareon.aptela.com>;tag=10.10.35.100+1+8c020003+dd5437f3.
> To: <sip:17038677006 at 69.25.47.136>.
> CSeq: 132610708 INVITE.
> Expires: 180.
> Contact: <sip:6462174165 at 10.10.35.100: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:6462174165 at 10.10.35.100:5060 SIP/2.0.
> Via: SIP/2.0/UDP
> 66.52.236.25:5060;branch=z9hG4bKd8orpb20eg2hais2c2g1sd0000g00.1.
> To: "Membersevice
> Queue"<sip:6462174165 at 69.25.47.136>;tag=10.10.35.100+1+8c020003+dd5437f3.
> From: <sip:17038677006 at 66.52.236.25>;tag=1386496.
> Call-ID: 56796C1E at 10.10.35.100.
> 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:6462174165 at 10.10.35.100: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:17038677006 at 66.52.236.25>;tag=1386496.
> Call-ID: 56796C1E at 10.10.35.100.
> CSeq: 1 BYE.
> Content-Length: 0.
> Max-Forwards: 69.
>
>
> --
> *******************************************
> Mahesh Paolini-Subramanya (703) 386-1500 x9100
> CTO mahesh at aptela.com
> Aptela, Inc. http://www.aptela.com
> "Aptela: How Business Answers The Call"
> *******************************************
--
*******************************************
Mahesh Paolini-Subramanya (703) 386-1500 x9100
CTO mahesh at aptela.com
Aptela, Inc. http://www.aptela.com
"Aptela: How Business Answers The Call"
*******************************************
More information about the sr-users
mailing list