[Users] subst_body with nated client problem

[Klaus Darilion]

Hi!

The problem is that all rewriting functions (subst_body, replace, 
use_media_proxy ...) work on the original received text message. This 
causes problem if 2 functions rewrite the same part of the SIP message.

A bad hack would be to loop the message to openser again before sending 
it to the B2BUA.

client ---1.---> openser ---3.---> B2Bua
                    ^    \
                    |     \
                    |--2.-|

The first time the request is processed oyu use use_media_proxy, the 
second time the request is processd you use subst_body.

But why doing it at the SIP proxy? Isn't is possible to change codec 
preference on the Asterisk?

regards
klaus

Oleg A Chernov wrote:
> Hello everyone!
> 
> My setup is as follow:
> 
> for local PSTN calls
> UA (with G.711 and G.729) - my Openser - my Asterisk B2BUA for prepaid  - 
> PSTN gateway (G.711 codec only)
> for international calls
> UA (with G.711 and G.729) - my Openser - my Asterisk B2BUA for prepaid - 
> ITSP gateway (G.729 codec only)
> 
> B2BUA on the second leg (B2BUA - gateway) always negotiate the right codec, so 
> no problem, but on the first leg (UA - B2BUA) it always negotiate codec that 
> is more prefered by the client UA side. So we can get situation, when the 
> codecs are different on the both legs.
> Inspired by the 
> http://lists.iptel.org/pipermail/serusers/2006-August/030129.html 
> I decided to normalize codec preference.
> Sorry for such a long introduction, at last here goes my problem.
> I have the following code in my openser.cfg in INVITE section
> 
> # INVITE section
> route[3] {
> ...
> if ( route to G.711 capable gateway) {
> 	subst_body("/^m=audio(.*)RTP\/AVP(.*) 8 (.*)/m=audio\1RTP\/AVP 8 \2 \3/ig");
> 	....
> }
> ...
> }
> 
> and it works like a charm for non-nated clients with real IPs. But when we 
> should fire use_media_proxy() for a nated one client we get the problem.
> SDP body before our substitution (UA-Openser):
>         
>         v=0
>         o=20000 12893 12893 IN IP4 192.168.2.134
>         s=ATA186 Call
>         c=IN IP4 192.168.2.134
>         t=0 0
>         m=audio 16384 RTP/AVP 0 18 8 101
>         a=rtpmap:0 PCMU/8000/1
>         a=rtpmap:18 G729/8000/1
>         a=fmtp:18 annexb=yes
>         a=rtpmap:8 PCMA/8000/1
>         a=rtpmap:101 telephone-event/8000
>         a=fmtp:101 0-15
> 
> 
> After (Openser - B2BUA):
> 
>         v=0
>         o=20000 12893 12893 IN IP4 192.168.2.134
>         s=ATA186 Call
>         c=IN IP4 217.77.208.184
>         t=0 0
>         m=audio 16384 RTP/AVP 8 0 18 101\01560136\012a=rtpmap:0 PCMU/8000/1
>         a=rtpmap:18 G729/8000/1
>         a=fmtp:18 annexb=yes
>         a=rtpmap:8 PCMA/8000/1
>         a=rtpmap:101 telephone-event/8000
>         a=fmtp:101 0-15
> 
> 
> So our subst_body() rearrange codecs as expected, but use_media_proxy() (it 
> her fault, I think) inserted the mediaproxy fixed port number 60136  between 
> symbols with ASCII codes \015 CR and \012 LF.  This behavior was accepted by 
> stable Openser 1.1 and latest cvs 1.2. 
> So the question is :
> What to do and who is guilty ? :-)
> 
> 


-- 
Klaus Darilion
nic.at