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@voice-system.ro To: mahesh@aptela.com Cc: users@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@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@10.10.35.100. From: "Member service"sip:user100.crunchhq@69.25.47.136;tag=10.10.35.100+1+8c020003+dd5437f3. To: sip:17038677006@69.25.47.136. CSeq: 132610708 INVITE. Expires: 180. Supported: replaces. Supported: 100rel. Contact: sip:6462174165@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@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@flareon.aptela.com;party=calling;id-type=subscriber;screen=yes;privacy=off. Supported: replaces. Call-ID: 56796C1E@10.10.35.100. From: "Membersevice Queue"sip:6462174165@flareon.aptela.com;tag=10.10.35.100+1+8c020003+dd5437f3. To: sip:17038677006@69.25.47.136. CSeq: 132610708 INVITE. Expires: 180. Contact: sip:6462174165@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@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@69.25.47.136;tag=10.10.35.100+1+8c020003+dd5437f3. From: sip:17038677006@66.52.236.25;tag=1386496. Call-ID: 56796C1E@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@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.cru6'(!.l asr}XV.R[>;tag=10.10.35.100+1+8c020003+dd5437f3. From: sip:17038677006@66.52.236.25;tag=1386496. Call-ID: 56796C1E@10.10.35.100. CSeq: 1 BYE. Content-Length: 0. Max-Forwards: 69.
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@flareon.aptela.com;tag=10.10.35.100+1+8c020003+dd5437f3 but when generating the BYE, it sends: To: "Membersevice Queue"sip:6462174165@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@voice-system.ro To: mahesh@aptela.com Cc: users@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@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@10.10.35.100. From: "Member service"sip:user100.crunchhq@69.25.47.136;tag=10.10.35.100+1+8c020003+dd5437f3. To: sip:17038677006@69.25.47.136. CSeq: 132610708 INVITE. Expires: 180. Supported: replaces. Supported: 100rel. Contact: sip:6462174165@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@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@flareon.aptela.com;party=calling;id-type=subscriber;screen=yes;privacy=off. Supported: replaces. Call-ID: 56796C1E@10.10.35.100. From: "Membersevice Queue"sip:6462174165@flareon.aptela.com;tag=10.10.35.100+1+8c020003+dd5437f3. To: sip:17038677006@69.25.47.136. CSeq: 132610708 INVITE. Expires: 180. Contact: sip:6462174165@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@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@69.25.47.136;tag=10.10.35.100+1+8c020003+dd5437f3. From: sip:17038677006@66.52.236.25;tag=1386496. Call-ID: 56796C1E@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@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.cru6'(!.l asr}XV.R[>;tag=10.10.35.100+1+8c020003+dd5437f3. From: sip:17038677006@66.52.236.25;tag=1386496. Call-ID: 56796C1E@10.10.35.100. CSeq: 1 BYE. Content-Length: 0. Max-Forwards: 69.
--
Mahesh Paolini-Subramanya (703) 386-1500 x9100 CTO mahesh@aptela.com Aptela, Inc. http://www.aptela.com "Aptela: How Business Answers The Call"
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@voice-system.ro To: mahesh@aptela.com Cc: users users@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@flareon.aptela.com;tag=10.10.35.100+1+8c020003+dd5437f3 but when generating the BYE, it sends: To: "Membersevice Queue"sip:6462174165@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@voice-system.ro To: mahesh@aptela.com Cc: users@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@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@10.10.35.100. From: "Member service"sip:user100.crunchhq@69.25.47.136;tag=10.10.35.100+1+8c020003+dd5437f3. To: sip:17038677006@69.25.47.136. CSeq: 132610708 INVITE. Expires: 180. Supported: replaces. Supported: 100rel. Contact: sip:6462174165@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@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@flareon.aptela.com;party=calling;id-type=subscriber;screen=yes;privacy=off. Supported: replaces. Call-ID: 56796C1E@10.10.35.100. From: "Membersevice Queue"sip:6462174165@flareon.aptela.com;tag=10.10.35.100+1+8c020003+dd5437f3. To: sip:17038677006@69.25.47.136. CSeq: 132610708 INVITE. Expires: 180. Contact: sip:6462174165@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@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@69.25.47.136;tag=10.10.35.100+1+8c020003+dd5437f3. From: sip:17038677006@66.52.236.25;tag=1386496. Call-ID: 56796C1E@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@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.cru6'(!.l asr}XV.R[>;tag=10.10.35.100+1+8c020003+dd5437f3. From: sip:17038677006@66.52.236.25;tag=1386496. Call-ID: 56796C1E@10.10.35.100. CSeq: 1 BYE. Content-Length: 0. Max-Forwards: 69.
--
Mahesh Paolini-Subramanya (703) 386-1500 x9100 CTO mahesh@aptela.com Aptela, Inc. http://www.aptela.com "Aptela: How Business Answers The Call"
-
Bogdan-Andrei Iancu -
Mahesh Paolini-Subramanya