[Serusers] UAC UDP to Proxy TCP... Problem

Christian Thomas cthomas at canalwest.com
Wed Feb 15 23:32:20 CET 2006


Sorry here is the attachement
  -----Original Message-----
  From: Christian Thomas [mailto:cthomas at canalwest.com]
  Sent: quarta-feira, 15 de fevereiro de 2006 19:28
  To: Greger V. Teigre; serusers at lists.iptel.org
  Subject: RE: [Serusers] UAC UDP to Proxy TCP... Problem


  Greger,

  Thank you for your response.
  See the attached ethereal trace.
  NOTA:

  66.xxx.xxx.xx is the aterisk UAC
  200.xxx.xxx.xx is my proxy server
  20.196.xxx.xx is the TCP Carrier GW

  The ACK my proxy send to the TCP GW - after have received 200 OK - have
the request line including the transport=tcp indication

  The contact headers are ok in each case.
  The Bye Sent  by my proxy does not have the request line transport=tcp.
But we have already a one way communication before.
  if the asterisk does not send a bye, the call is terminated by the TCP GW.
I think it is because of a time out from the TCP GW.

  Christian

    -----Original Message-----
    From: Greger V. Teigre [mailto:greger at teigre.com]
    Sent: quarta-feira, 15 de fevereiro de 2006 04:35
    To: cthomas at canalwest.com; serusers at lists.iptel.org
    Subject: Re: [Serusers] UAC UDP to Proxy TCP... Problem


    Seems like you have done your research and what you write seems
reasonable. It's difficult to give you an answer without having a complete
ngrep trace. However, you should also look at the Record-Route and Route
headers...
    g-)
      ----- Original Message -----
      From: Christian Thomas
      To: serusers at lists.iptel.org
      Sent: Tuesday, February 14, 2006 6:33 PM
      Subject: [Serusers] UAC UDP to Proxy TCP... Problem


      Hi everybody,

      I have a UDP2TCP problem with Ser. (0.9-4)
      The UACs connected to my SER Proxy are all UDP. When I use some
carriers to connect them to PSTN The Carrier Proxy / GW could talk UDP or
TCP. It depends on the destination.
      Each time the Carrier GW want to talk TCP, the contact field is
correct and contains the 'transport=tcp' mention. all seems to be correct
and, after a complete reading about this subject in the list, I trust that
using t_relay() must do the right translation and send response via TCP to
the Carrier GW when this one is transport=tcp declared.
      If I Check the message for an Ack or a BYE sent to the TCP GW the uri
is correct :
      the transport=tcp is added.
       Request-Line: ACK sip:50033299848400 at 200.1xx.xx.xx:5060;transport=tcp
SIP/2.0
      I have red that this is sufficient to let SER understand that it must
be sent via TCP.
      unfortunately, this message is ent thru UDP.
      May I force with a t_relay_to_tcp ? As this case depends on the
carrier dynamic routing  it could be complicated because of the need to know
the destination to script t_relay_to_tco(uri, port)... If anybody has the
trick or any advice...
      Other thing related, when TCP is the transport mode from the Carrier
GW and I forward staefully to the UAC (Asterisk) the call failed between
Asterisk as UAC and the carrier GW.
      I wondering it was because the Carrier Gw didn't receive an ACK TCP
from my server..

      Well I'm completely lost... as you can feel with my message...
      I need Help.. But don't cal me Harry ;)

      Regards,

      Christian Thomas



--------------------------------------------------------------------------


      _______________________________________________
      Serusers mailing list
      serusers at lists.iptel.org
      http://lists.iptel.org/mailman/listinfo/serusers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060215/0be5509b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serlist.log
Type: application/octet-stream
Size: 37202 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060215/0be5509b/attachment.obj>


More information about the sr-users mailing list