Hi All,
I managed to get it working by adding a whole lot of debugging and a
whole lot of rtpproxy_offer() and rtpproxy_answer().
Now I need to clean up my config because it's a total mess.
- Julian
On Tue, Jul 6, 2010 at 6:33 AM, Julian Yap <julianok...@gmail.com> wrote:
> Yeah, RTPProxy is being called. It just isn't using the correct port
> when talking to the UA since the port changed. Is this a RTPProxy bug?
> Everything works fine when the UA does not change port.
>
>
> On 7/6/10, Klaus Darilion <klaus.mailingli...@pernau.at> wrote:
>> Flags are only needed in special cases. Just make sure that you call
>> force_rtpproxy() during processing of the reINVITE, and the 200 OK
>> response to the reINVITE.
>>
>> just watch the logfile if the reINVITE also triggers rtpproxy.
>>
>>
>> regards
>> klaus
>>
>> Am 06.07.2010 12:16, schrieb Julian Yap:
>>> Klaus,
>>>
>>> You mean I need to call force_rtpproxy() twice?
>>>
>>> Sorry, I'm full of questions:
>>> - Should I be using any flags with force_rtp_proxy()?
>>> - Should I be calling unforce_rtp_proxy() to tear down the initial G711
>>> media?
>>> - Should I be using rtpproxy_offer() and rtpproxy_answer()?
>>>
>>> Here is my onreply_route. Does it look right?:
>>> onreply_route[2]
>>> {
>>> if(nat_uac_test("1"))
>>> {
>>> fix_nated_contact();
>>> }
>>> if(isbflagset(6)&& status=~"(180)|(183)|2[0-9][0-9]")
>>> {
>>> if(search("Content-Type: application/sdp"))
>>> {
>>> force_rtp_proxy();
>>> }
>>> }
>>> exit;
>>> }
>>>
>>> Here is the initial INVITE that is processed properly:
>>> INVITE sip:18085551...@8.8.178.41 SIP/2.0.
>>> Via: SIP/2.0/UDP 192.168.0.15:5060;branch=z9hG4bK103B.
>>> From: IPFax<sip:8085551...@192.168.0.15>;tag=IPF_PORT_0001_103A.
>>> To:<sip:18085551...@8.8.178.41>.
>>> Call-ID: f17e4c86-448f-4bb4-81b8-e06ce3c15...@192.168.0.15.
>>> CSeq: 1 INVITE.
>>> Max-Forwards: 70.
>>> Contact:<sip:8085551...@192.168.0.15:5060>.
>>> User-Agent: My IP_FAX-8.6.5233.924.
>>> Allow: INVITE, ACK, BYE, CANCEL, REFER, NOTIFY.
>>> Content-Type: application/sdp.
>>> Content-Length: 164.
>>> .
>>> v=0.
>>> o=IPFax 0 0 IN IP4 192.168.0.15.
>>> s=SIP Fax Call.
>>> i=IPFax.
>>> c=IN IP4 192.168.0.15.
>>> t=0 0.
>>> m=audio 49200 RTP/AVP 0.
>>> a=rtpmap:0 PCMU/8000.
>>> a=ptime:20.
>>> a=sendrecv.
>>>
>>> G711 is then established.
>>>
>>> T38 GW then sends the T38 INVITE:
>>> INVITE sip:8085551...@8.7.230.15:5060 SIP/2.0.
>>> Via: SIP/2.0/UDP 8.8.178.61;branch=z9hG4bKac315679218.
>>> Max-Forwards: 70.
>>> From:<sip:18085551...@8.8.178.41>;tag=1c215847348.
>>> To: IPFax<sip:8085551...@192.168.0.15>;tag=IPF_PORT_0001_103A.
>>> Call-ID: f17e4c86-448f-4bb4-81b8-e06ce3c15...@192.168.0.15.
>>> CSeq: 1 INVITE.
>>> Contact:<sip:1...@8.8.178.61>.
>>> Route:<sip:8.8.178.41;lr=on;ftag=IPF_PORT_0001_103A;nat=yes>.
>>> Supported: em,timer,replaces,path,early-session,resource-priority.
>>> Allow:
>>> REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
>>> User-Agent: acm2k/v.5.60A.009.005.
>>> Content-Type: application/sdp.
>>> Content-Length: 294.
>>> .
>>> v=0.
>>> o=AC_GW 215939645 215939274 IN IP4 8.8.178.61.
>>> s=Phone-Call.
>>> c=IN IP4 8.8.178.61.
>>> t=0 0.
>>> m=image 14002 udptl t38.
>>> a=T38FaxVersion:0.
>>> a=T38MaxBitRate:14400.
>>> a=T38FaxMaxBuffer:1024.
>>> a=T38FaxMaxDatagram:122.
>>> a=T38FaxRateManagement:transferredTCF.
>>> a=T38FaxUdpEC:t38UDPRedundancy.
>>>
>>> Here is the 200 OK from the UA with the different port:
>>> SIP/2.0 200 OK.
>>> Via: SIP/2.0/UDP 8.8.178.41;branch=z9hG4bK8e34.13ed1496.0.
>>> Via: SIP/2.0/UDP
>>> 8.8.178.61;rport=5060;received=8.8.178.61;branch=z9hG4bKac315679218.
>>> Record-Route:<sip:8.8.178.41;lr=on;ftag=IPF_PORT_0001_103A;nat=yes>.
>>> From:<sip:18085551...@8.8.178.41>;tag=1c215847348.
>>> To: IPFax<sip:8085551...@192.168.0.15>;tag=IPF_PORT_0001_103A.
>>> Call-ID: f17e4c86-448f-4bb4-81b8-e06ce3c15...@192.168.0.15.
>>> CSeq: 1 INVITE.
>>> Contact:<sip:8085551...@192.168.0.15:5060>.
>>> User-Agent: My IP_FAX-8.6.5233.924.
>>> Content-Type: application/sdp.
>>> Content-Length: 357.
>>> .
>>> v=0.
>>> o=IPFax 0 1 IN IP4 192.168.0.15.
>>> s=SIP Fax Call.
>>> i=IPFax.
>>> c=IN IP4 192.168.0.15.
>>> t=0 0.
>>> m=image 49152 udptl t38.
>>> a=T38FaxVersion:0.
>>> a=T38MaxBitRate:14400.
>>> a=T38FaxRateManagement:transferredTCF.
>>> a=T38FaxMaxBuffer:200.
>>> a=T38FaxMaxDatagram:72.
>>> a=T38FaxFillBitRemoval:0.
>>> a=T38FaxTranscodingMMR:0.
>>> a=T38FaxTranscodingJBIG:0.
>>> a=T38FaxUdpEC:t38UDPRedundancy.
>>>
>>>
>>> - Julian
>>>
>>> On Sun, Jul 4, 2010 at 11:29 PM, Klaus Darilion
>>> <klaus.mailingli...@pernau.at> wrote:
>>>> Are you sure you are calling force_rtpproxy() also in reINVITE and
>>>> correspondig 200 OK.
>>>>
>>>> regards
>>>> Klaus
>>>>
>>>> Am 03.07.2010 09:46, schrieb Julian Yap:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Any help greatly appreciated!
>>>>>
>>>>> I'm having problems with a T38 UA which changes port when negotiating
>>>>> T38 media. All the other UA's I've encountered thus far use the same
>>>>> RTP port throughout.
>>>>>
>>>>> I'm also using RTPProxy invoked by OpenSIPS.
>>>>>
>>>>> In the final 200 OK SDP, the UA changes media port from 49200 to 49152
>>>>> but this changeover isn't detected and the media is sent back to port
>>>>> 49200 so the call then fails to negotiate T38 properly. Not sure how
>>>>> to log the port changes to further debug this issue as well.
>>>>>
>>>>> Here is the flow:
>>>>> | UA | OpenSIPS | T38 GW |
>>>>> | INVITE SDP ( g711U) | |
>>>>> |(5060) ------------------> (5060) | |
>>>>> | 100 Trying| | |
>>>>> |(5060)<------------------ (5060) | |
>>>>> | | INVITE SDP ( g711U) |
>>>>> | |(5060) ------------------> (5060) |
>>>>> | | 100 Trying| |
>>>>> | |(5060)<------------------ (5060) |
>>>>> | | 180 Ringing SDP ( g711U) |
>>>>> | |(5060)<------------------ (5060) |
>>>>> | | 200 OK SDP ( g711U) |
>>>>> | |(5060)<------------------ (5060) |
>>>>> | | RTP (g711U) |
>>>>> | |(11392)<------------------ (14110) |
>>>>> | RTP (g711U) | |
>>>>> |(49200)<------------------ (10878) | |
>>>>> | 180 Ringing SDP ( g711U) | |
>>>>> |(5060)<------------------ (5060) | |
>>>>> | RTP (g711U) | |
>>>>> |(49200) ------------------> (10878) | |
>>>>> | | RTP (g711U) |
>>>>> | |(11392) ------------------> (14110) |
>>>>> | 200 OK SDP ( g711U) | |
>>>>> |(5060)<------------------ (5060) | |
>>>>> | ACK | | |
>>>>> |(5060) ------------------> (5060) | |
>>>>> | RTP (g711U) | |
>>>>> |(49200) ------------------> (10878) | |
>>>>> | RTP (g711U) | |
>>>>> |(49200)<------------------ (10878) | |
>>>>> | | 200 OK SDP ( g711U) |
>>>>> | |(5060)<------------------ (5060) |
>>>>> | | RTP (g711U) |
>>>>> | |(11392) ------------------> (14110) |
>>>>> | | ACK | |
>>>>> | |(5060) ------------------> (5060) |
>>>>> | 200 OK SDP ( g711U) | |
>>>>> |(5060)<------------------ (5060) | |
>>>>> | ACK | | |
>>>>> |(5060) ------------------> (5060) | |
>>>>> | RTP (g711U) | |
>>>>> |(49200) ------------------> (10878) | |
>>>>> | RTP (g711U) | |
>>>>> |(49200)<------------------ (10878) | |
>>>>> | | ACK | |
>>>>> | |(5060) ------------------> (5060) |
>>>>> | | INVITE SDP ( t38) |
>>>>> | |(5060)<------------------ (5060) |
>>>>> | INVITE SDP ( t38) | |
>>>>> |(5060)<------------------ (5060) | |
>>>>> | 200 OK SDP ( t38) | |
>>>>> |(5060) ------------------> (5060) | |
>>>>>
>>>>> This is where it sends the 200 OK with a different media port.
>>>>>
>>>>> - Julian
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@rtpproxy.org
>>>>> http://lists.rtpproxy.org/mailman/listinfo/users
>>>>
>>
>
_______________________________________________
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users
