[Devel] [ openser-Bugs-1719399 ] TEXTOPS: replace_all() and subst() currupt Contact header

Wed May 16 13:26:06 CEST 2007

Bugs item #1719399, was opened at 2007-05-15 19:06
Message generated for change (Comment added) made by vkc1974
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1719399&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.2.x
>Status: Open
>Resolution: None
Priority: 5
Private: No
Submitted By: Kovalevich Victor (vkc1974)
Assigned to: Nobody/Anonymous (nobody)
Summary: TEXTOPS: replace_all() and subst() currupt Contact header

Initial Comment:
replace_all() and subst() routines of TEXTOPS module corrupt Contact header field value while message processing, see below:

if (proto==TLS)
{
   #
   # Try to replace sips protocol id with sip
   subst("/sips:/sip:/g");
#  or replace_all("sips:", "sip:");
}

rewritehostport("212.98.163.238:5090");
force_send_socket(udp:212.98.163.238:5060);

t_relay();

Initial request message (from openser log file):

May 15 18:56:37 lin-3 openser[11714]: tcp_read_req: last char=0x0A, parsed msg= INVITE sips:01 at 212.98.163.238 SIP/2.0
 From: "%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sips:1446721212 at 212.98.163.238>;tag=1c28887
 To: "%30%31"<sips:01 at 212.98.163.238>
 Call-Id: s_6005_610ad3037405
 Cseq: 1116 INVITE
 Contact: "%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sips:1446721212 at 192.168.6.201:5061>
 Content-Type: application/sdp
 Content-Length: 400
 Max-Forwards: 70
 User-Agent: Glooip 1.2.0.0 (WinNT)
 Accept-Language: 
 Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING, INFO, REGISTER, SUBSCRIBE, NOTIFY, MESSAGE
 Supported: replaces
 Via: SIP/2.0/TLS 192.168.6.201;branch=z9hG4bK-094d50cb5ce8

 v=0
 o=sipX 5 6 IN IP4 192.168.6.201
 s=call
 c=IN IP4 192.168.6.201
 t=0 0
 m=audio 8000 RTP/AVP 96 97 98 99 0 8 100 101
 a=rtpmap:96 ipcmwb/16000/1
 a=rtpmap:97 isac/16000/1
 a=rtpmap:98 eg711u/8000/1
 a=rtpmap:99 eg711a/8000/1
 a=rtpmap:0 pcmu/8000/1
 a=rtpmap:8 pcma/8000/1
 a=rtpmap:100 ilbc/8000/1

May 15 18:56:37 lin-3 openser[11714]: tcp_read_req: end of header part 
May 15 18:56:37 lin-3 openser[11714]: - received from: port 31321 
May 15 18:56:37 lin-3 openser[11714]: - received from: ip 212.98.163.230 

Resulting message (from Asterisk trace where discussed message where sent to):

<-- SIP read from 212.98.163.238:5060:
INVITE sip:01 at 212.98.163.238:5090 SIP/2.0
Record-Route: <sip:212.98.163.238;r2=on;lr=on;ftag=1c28887>
Record-Route: <sip:212.98.163.238;transport=tls;r2=on;lr=on;ftag=1c28887>
From: "%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sip:1446721212 at 212.98.163.238>;tag=1c28887
To: "%30%31"<sip:01 at 212.98.163.238>
Call-Id: s_6005_610ad3037405
Cseq: 1116 INVITE
Contact: "%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sips:1446721212 at 212.98.163.230:31321sip:>
Content-Type: application/sdp
Content-Length: 400
Max-Forwards: 16
User-Agent: Glooip 1.2.0.0 (WinNT)
Accept-Language:
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PING, INFO, REGISTER, SUBSCRIBE, NOTIFY, MESSAGE
Supported: replaces
Via: SIP/2.0/UDP 212.98.163.238;branch=z9hG4bKf23d.bc6416a5.0;i=1
Via: SIP/2.0/TLS 192.168.6.201;rport=31321;received=212.98.163.230;branch=z9hG4bK-094d50cb5ce8

v=0
o=sipX 5 6 IN IP4 192.168.6.201
s=call
c=IN IP4 192.168.6.201
t=0 0
m=audio 8000 RTP/AVP 96 97 98 99 0 8 100 101
a=rtpmap:96 ipcmwb/16000/1
a=rtpmap:97 isac/16000/1
a=rtpmap:98 eg711u/8000/1
a=rtpmap:99 eg711a/8000/1
a=rtpmap:0 pcmu/8000/1
a=rtpmap:8 pcma/8000/1
a=rtpmap:100 ilbc/8000/1
a=fmtp:100 mode=30
a=rtpmap:101 telephone-event/8000/1
a=ptime:30
m=video 90758752 RTP/AVP

Please pay your attention to the value of Contact header field, it is currupted:

<sips:1446721212 at 212.98.163.230:31321sip:>

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

>Comment By: Kovalevich Victor (vkc1974)
Date: 2007-05-16 14:26

Message:
Logged In: YES 
user_id=490489
Originator: YES

Thank you very much for your comment. I really wonder such kind of
internal behavior of openser. It looks like we can to process a SIP
request/answer but cannot be sure our modification really have took a place
(at least by using of openser scripting tools). Probably I do not
understand openser base paradigm how to process a SIP request/answer
properly. I think this is very specific approach openser implements: all
the routines called to process a message do not modify it - they prepare a
set of patches which are applied to original message this one is going to
be sent to different client site. While this process there are no ways to
get know whether any modifications were made or not.
I am not sure this way is so good. I supposed a route process gets its own
copy of original SIP message and can modify it how it (route process) would
like to do while message processing at least.
Really I encountered the situation I cannot understand when some kinds of
message processing can be applied and some of once can cause unexpected and
unexplained results.

Thank you very much for your comment once again.
In any case I get be sure openser is a solution with very limited area to
be applied.

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

Comment By: Bogdan (bogdan_iancu)
Date: 2007-05-16 12:57

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi,

Klaus is right - this is not a bug, but a limitation. The avoid it, try
not to perform more than one change over the same part of the message.

Bogdan

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

Comment By: Klaus Darilion (klaus_darilion)
Date: 2007-05-16 11:21

Message:
Logged In: YES 
user_id=1318360
Originator: NO

Hi!

This is not a bug, but a known limitation of openser. In openser, message
rewriting is done at the end of the routing. All the openser.cfg functions
which manipulates the message generates "lumps". This lumps are applied at
just before sending out the message. Thus, all functions always see the
original received message even if another function already manipulated the
message (added a lump). Thus, if the same part of the message is rewritten
twice, the behavior is undefined. 

In your case, the manipulate the Contact header 2 times:
1. subst()
2. fix_nated_contact() or fix_contact()

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1719399&group_id=139143