[Users] changing SDP session and media attributes in 200 OK

Antanas Masevicius admin at ntt.lt
Tue Apr 25 12:53:04 CEST 2006


thanx,

dev version of nathelper works correctly.

Antanas


----- Original Message ----- 
From: "Klaus Darilion" <klaus.mailinglists at pernau.at>
To: "Antanas Masevicius" <admin at ntt.lt>
Cc: <users at openser.org>
Sent: Tuesday, April 25, 2006 10:45 AM
Subject: Re: [Users] changing SDP session and media attributes in 200 OK


> Antanas Masevicius wrote:
>> Hello,
>>  i am using rtpproxy with openser to act as a RTP bridge to IP-SS7 
>> gateway. IP-SS7 GW should not be exposed to external clients directly. 
>> Architecture diagram is like this:
>>  |UA1|--SIP/RTP---|
>>           |------------------|             |-----------| | 
>> OpenSer+RTPProxy | --SIP/RTP-- | IP-SS7-GW |
>>           |------------------|             |-----------|
>> |UA2|--SIP/RTP---|
>>  Problem is when i try to send fax RTP packets destined for UA2 from 
>> IP-SS7 GW are sent directly.
>> They should go through RTPProxy, otherwise media ports does not  match.
>> onreply route looks like:
>>  onreply_route[1] {
>>     if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
>>          fix_nated_contact();
>>     }
>>     force_rtp_proxy();
>> }
>> each request is record_route()'ed before it is sent to be routed back 
>> through proxy.
>> I noticed that OpenSer removes top most via header in 200 OK  messages:
>
> This is fine - when relaying a request each hop adds a Via header. When 
> relaying responses, each hop removes the Via header which he added to the 
> request.
>
>>  200 OK message for re-Invite received by OpenSer:
>>  SIP/2.0 200 OK\r\n
>>     From: <sip:870000049 at sp2.ntt.lt>;tag=4fbb0552\r\n
>>     To: <sip:70000050 at sp2.ntt.lt>;tag=0-13c4-444c9fc6-f4eac-fdd\r\n
>>     Call-ID: cc36b0-0-13c4-444c9fc6-f4eac-2c87 at sp2.ntt.lt\r\n 
>> <mailto:cc36b0-0-13c4-444c9fc6-f4eac-2c87 at sp2.ntt.lt\r\n>
>>     CSeq: 666497904 INVITE\r\n
>>     Via: SIP/2.0/UDP 84.32.0.18;branch=z9hG4bKf67f.2aeace41.0\r\n
>>     Via: SIP/2.0/UDP 84.32.0.7:5060;branch=z9hG4bK444cbbfca6214604dc9\r\n
>>     Supported: 100rel\r\n
>>     User-Agent: SIP-RG\r\n
>>     Contact: <sip:70000050 at 84.32.134.143>\r\n
>>     Content-Type: application/sdp\r\n
>>     Content-Length: 317\r\n
>>     \r\n
>>     v=0\r\n
>>     o=SIP-N-TA 0 0 IN IP4 84.32.134.143\r\n
>>     s=5420868F 0000 5420868F 0000 01 0\r\n
>>     c=IN IP4 84.32.134.143\r\n
>>     t=0 0\r\n
>>     m=image 4008 udptl t38\r\n
>>     c=IN IP4 84.32.134.143\r\n
>>     a=T38FaxVersion:0\r\n
>>     a=T38MaxBitRate:14400\r\n
>>     a=T38FaxFillBitRemoval:0\r\n
>>     a=T38FaxTranscodingMMR:0\r\n
>>     a=T38FaxTranscodingJBIG:0\r\n
>>     a=T38FaxRateManagement:transferredTCF\r\n
>>  200 OK message sent to IP-SS7 GW by OpenSer:
>>  SIP/2.0 200 OK
>> From: <sip:870000049 at sp2.ntt.lt>;tag=4fbb0552
>> To: <sip:70000050 at sp2.ntt.lt>;tag=0-13c4-444c9fc6-f4eac-fdd
>> Call-ID: cc36b0-0-13c4-444c9fc6-f4eac-2c87 at sp2.ntt.lt 
>> <mailto:cc36b0-0-13c4-444c9fc6-f4eac-2c87 at sp2.ntt.lt>
>> CSeq: 666497904 INVITE
>> Via: SIP/2.0/UDP 84.32.0.7:5060;branch=z9hG4bK444cbbfca6214604dc9
>> Supported: 100rel
>> User-Agent: SIP-RG
>> Contact: <sip:70000050 at 84.32.134.143>
>> Content-Type: application/sdp
>> Content-Length: 333
>>  v=0
>> o=SIP-N-TA 0 0 IN IP4 84.32.134.143
>> s=5420868F 0000 5420868F 0000 01 0
>> c=IN IP4 84.32.134.143
>> t=0 0
>> m=image 39246 udptl t38
>> c=IN IP4 84.32.0.18
>> a=T38FaxVersion:0
>> a=T38MaxBitRate:14400
>> a=T38FaxFillBitRemoval:0
>> a=T38FaxTranscodingMMR:0
>> a=T38FaxTranscodingJBIG:0
>> a=T38FaxRateManagement:transferredTCF
>> a=nortpproxy:yes
>>  In this message there is no indication that is came from SIP proxy (no 
>> record-route, no via header), then IP-SS7 GW sends ACK message directly.
>
> For in-dialog requests Record Route is not necessary, as the route set is 
> constructed from the Record-Route headers in the initial INVITE. Even if 
> there would be Record Route headers the clients must not use them. Maybe 
> one of your clients is buggy and constructs the route set after each 
> in-dialog request new.
>
>> This, i suppose, is normal thing, is it? Problem is that IP-SS7 also 
>> sends RTP traffic to UA2 directly. This probably happens because of two 
>> 'c=' fields in SDP.
>
> Sounds obvious. AFAIK there was recently a patch on the mailinglist which 
> added a feature to modify all c= lines.
>
> regards
> klaus
>
>> OpenSer changes only one in  media part. Is there a way to change 'c=' 
>> field in SDP not only on media part?
>> Which should take precedence if both can't be changed?
>>  regards,
>>  Antanas Masevicius
>>  ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users 





More information about the Users mailing list