[ previous ] [ next ] [ threads ]
 To :  "dave" <dave@d...>
 From :  "G.Jacobsen" <g_jacobsen@y...>
 Subject :  Re: [yate] T38 dirty hack ?
 Date :  Thu, 15 Oct 2009 13:13:24 +0300
Hi Dave,

do you mind sharing your patch ? I would highly appreciate it since I have been stuck on the re-invite problem.

Can you please explain which specific case it addresses ?

I think we should put up a separte yate wiki page to keep all T38 thought / patches there in concentrated form.

Cheers

Gerry

  ----- Original Message ----- 
  From: dave 
  To: G.Jacobsen 
  Cc: Dome Charoenyost ; yate@v... 
  Sent: Thursday, October 15, 2009 12:03 AM
  Subject: Re: [yate] T38 dirty hack ?


  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





      









Hi Dave,
 
do you mind sharing your patch ? I would highly appreciate it since I have been stuck on the re-invite problem.
 
Can you please explain which specific case it addresses ?
 
I think we should put up a separte yate wiki page to keep all T38 thought / patches there in concentrated form.
 
Cheers
 
Gerry
 
----- Original Message -----
From: dave
Sent: Thursday, October 15, 2009 12:03 AM
Subject: Re: [yate] T38 dirty hack ?

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