Here's an example of the same UA sending to 2 different UA's.
The first example works.
The 2nd example, there is a 'rxmit_packets' line and the media port
does not change correctly to 49152 :(
Jul 14 16:22:42 INFO:handle_command: new session
6e0023a4-f1b3-409f-bd51-2c45ab72f...@192.168.0.15, tag
IPF_PORT_0001_1091;1 requested, type strong
Jul 14 16:22:42 INFO:handle_command: new session on a port 19288
created, tag IPF_PORT_0001_1091;1
Jul 14 16:22:42 INFO:handle_command: pre-filling caller's address with
8.8.8.15:49200
Jul 14 16:22:42 INFO:handle_command: lookup on ports 19288/13186,
session timer restarted
Jul 14 16:22:42 INFO:handle_command: pre-filling callee's address with
9.9.9.61:14140
Jul 14 16:22:47 INFO:handle_command: adding strong flag to existing
session, new=1/0/0
Jul 14 16:22:47 INFO:handle_command: lookup on ports 19288/13186,
session timer restarted
Jul 14 16:22:47 INFO:handle_command: pre-filling callee's address with
9.9.9.61:14142
Jul 14 16:22:47 INFO:handle_command: lookup on ports 19288/13186,
session timer restarted
Jul 14 16:22:47 INFO:handle_command: pre-filling caller's address with
8.8.8.15:49152
----
Jul 14 16:23:58 INFO:handle_command: new session
c302e635-be7b-4e96-be0c-f69eb9eb5...@192.168.0.15, tag
IPF_PORT_0001_1093;1 requested, type strong
Jul 14 16:23:58 INFO:handle_command: new session on a port 11556
created, tag IPF_PORT_0001_1093;1
Jul 14 16:23:58 INFO:handle_command: pre-filling caller's address with
8.8.8.15:49200
Jul 14 16:24:05 INFO:handle_command: lookup on ports 11556/13594,
session timer restarted
Jul 14 16:24:05 INFO:handle_command: pre-filling callee's address with
8.8.8.123:16456
Jul 14 16:24:07 INFO:handle_command: adding strong flag to existing
session, new=1/0/0
Jul 14 16:24:07 INFO:handle_command: lookup on ports 11556/13594,
session timer restarted
Jul 14 16:24:07 INFO:handle_command: lookup on ports 11556/13594,
session timer restarted
Jul 14 16:24:07 INFO:handle_command: pre-filling caller's address with
8.8.8.15:49152
Jul 14 16:24:07 INFO:rxmit_packets: caller's address filled in:
8.8.8.15:49200 (RTP)
On Wed, Jul 14, 2010 at 4:20 PM, Julian Yap <julianok...@gmail.com> wrote:
> I thought I had things working... But it's really inconsistent :(
>
> Yeah, I am having way too many issues with RTPProxy and the re-invite
> port changing. It's an absolute nightmare. Everything works fine
> when the UA doesn't change media port but when it does, it's really
> inconsistent. When the port changes force_rtpproxy() is invoked but
> sometimes it works, sometimes it doesn't work.
>
> I think I'm going to try out MediaProxy.
>
> - Julian
>
> On Tue, Jul 6, 2010 at 2:00 AM, 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
