[ previous ] [ next ] [ threads ]
 To :  "G.Jacobsen" <g_jacobsen@y...>
 From :  dave <dave@d...>
 Subject :  Re: [yate] T38 dirty hack ?
 Date :  Thu, 15 Oct 2009 10:03:00 +1300
The function void YateSIPConnection::reInvite(SIPTransaction* t), (when 
not m_rtpForward) just replies with 200 OK.
I think this area of code is sort of 'undeveloped'

I wanted to keep the media on the box, so i had to make some large 
modifications:
YateSIPConnection::reInvite to wait until call.update pushed the INVITE 
out the outgoing leg, and received a response.
NetMedia::update to allow forcing re-adoption of codec's (It kind of 
LOCKS on to a chosen codec. Need to allow it to re-elect t.38)
CreateRtpSDP to allow netmedia to re-elect
CreateSDP to set netmedia as modified for t.38
Build an rtp handler (like yrtpchan) which would handle transport type 
"udptl".

I haven't submitted my patches, because
a) they are tested and useful only for a specific case, and may break 
other functionality
b) last time i submitted a change, it was ignored :)

G.Jacobsen wrote:
> Dome,
>
> usually T38 doesnt work that way because the calling device normally does
> not know before the call is connected that it sends a fax. So yate can also
> not know it until both call legs are connected.
>
> Most gateways have an implementation that they detect the INCOMING fax after
> connect and then announce that they switch to T38 with a re-INVITE
>
> So for T38 to work reliably EVERY device in the call path must be T38 aware.
> (You cannot change gateways in the middle of the call)
>
> I am happy to work with you on this. Do you have access to T38 gateway or
> some SIP device, e.g. Sipura 2102 ? To test it is sufficient to call to the
> device/gateway without actually sending a fax. You just must make sure that
> there is a fax machine connected to the number / device you are calling. The
> receiving gateway/device will then issue a re-INVITE.
>
> Where I am stuck now is that yate does not seem to respond at all to the
> re-INVITE of the outgoing call leg, no message pops up in yate. It seems the
> re-invite is ignored.
>
> Cheers
>
> Gerry
>
>
>
>
>
> ----- Original Message ----- 
> From: "Dome Charoenyost" 
> To: "Gerrit Jacobsen" 
> Cc: 
> Sent: Wednesday, October 14, 2009 9:16 AM
> Subject: Re: [yate] T38 dirty hack ?
>
>
>   
>> Hi,
>>     I'm interested T.38 in yate also. so i'm looking for t.38 detect
>> solution. i mean when call (T.38 Fax)  imcomming to yate  and then
>> yate looking for sip gateway and check they support T.38 or not  if
>> not try next gateway
>>    Can you guide me is posible to hack your ysipchan.cpp to support that
>>
>> BG
>>
>> Dome C.
>>
>> 2009/10/14 Gerrit Jacobsen :
>>     
>>> Hello,
>>>
>>> I have tried to implement a dirty hack for T38.
>>>
>>> Basically I want to implement that when a re-invite from the call
>>>       
> receiving end with udptl media transport arrives then yate should do
> rtp_forward and sdp_forward.
>   
>>> Apparently there is code in ysipchan.cpp, when udptl transport is
>>>       
> detected then rtp is disabled, which I envisaged as a starting point for
> some hacking.
>   
>>> Problem being that Yate seems to ignore the re-invite from the receiving
>>>       
> end completely. Does yate support re-invites from the receiving end ?
>   
>>> In general I think it would be extremely useful if yate had an option to
>>>       
> automatically do rtp_forward and sdp_forward when unknown media transports
> or codecs are used by either end.
>   
>>> Anyone any idea how to proceed on this ?
>>>
>>> Thanks
>>>
>>> Gerry
>>>
>>>
>>>
>>>
>>>
>>>       



The function void YateSIPConnection::reInvite(SIPTransaction* t), (when not m_rtpForward) just replies with 200 OK.
I think this area of code is sort of 'undeveloped'

I wanted to keep the media on the box, so i had to make some large modifications:
YateSIPConnection::reInvite to wait until call.update pushed the INVITE out the outgoing leg, and received a response.
NetMedia::update to allow forcing re-adoption of codec's (It kind of LOCKS on to a chosen codec. Need to allow it to re-elect t.38)
CreateRtpSDP to allow netmedia to re-elect
CreateSDP to set netmedia as modified for t.38
Build an rtp handler (like yrtpchan) which would handle transport type "udptl".

I haven't submitted my patches, because
a) they are tested and useful only for a specific case, and may break other functionality
b) last time i submitted a change, it was ignored :)

G.Jacobsen wrote:
Dome,

usually T38 doesnt work that way because the calling device normally does
not know before the call is connected that it sends a fax. So yate can also
not know it until both call legs are connected.

Most gateways have an implementation that they detect the INCOMING fax after
connect and then announce that they switch to T38 with a re-INVITE

So for T38 to work reliably EVERY device in the call path must be T38 aware.
(You cannot change gateways in the middle of the call)

I am happy to work with you on this. Do you have access to T38 gateway or
some SIP device, e.g. Sipura 2102 ? To test it is sufficient to call to the
device/gateway without actually sending a fax. You just must make sure that
there is a fax machine connected to the number / device you are calling. The
receiving gateway/device will then issue a re-INVITE.

Where I am stuck now is that yate does not seem to respond at all to the
re-INVITE of the outgoing call leg, no message pops up in yate. It seems the
re-invite is ignored.

Cheers

Gerry





----- Original Message ----- 
From: "Dome Charoenyost" <dome@t...>
To: "Gerrit Jacobsen" <g_jacobsen@y...>
Cc: <yate@v...>
Sent: Wednesday, October 14, 2009 9:16 AM
Subject: Re: [yate] T38 dirty hack ?


  
Hi,
    I'm interested T.38 in yate also. so i'm looking for t.38 detect
solution. i mean when call (T.38 Fax)  imcomming to yate  and then
yate looking for sip gateway and check they support T.38 or not  if
not try next gateway
   Can you guide me is posible to hack your ysipchan.cpp to support that

BG

Dome C.

2009/10/14 Gerrit Jacobsen <g_jacobsen@y...>:
    
Hello,

I have tried to implement a dirty hack for T38.

Basically I want to implement that when a re-invite from the call
      
receiving end with udptl media transport arrives then yate should do
rtp_forward and sdp_forward.
  
Apparently there is code in ysipchan.cpp, when udptl transport is
      
detected then rtp is disabled, which I envisaged as a starting point for
some hacking.
  
Problem being that Yate seems to ignore the re-invite from the receiving
      
end completely. Does yate support re-invites from the receiving end ?
  
In general I think it would be extremely useful if yate had an option to
      
automatically do rtp_forward and sdp_forward when unknown media transports
or codecs are used by either end.
  
Anyone any idea how to proceed on this ?

Thanks

Gerry