Jump to content

duggyk

Members
  • Posts

    5
  • Joined

  • Last visited

Posts posted by duggyk

  1. Maybe we can take the insecure offer out. I believe this was for an old firmware version of a phone, today it should not be relevant any more. What OS are you on?

     

    I'm using openSUSE 10.3

     

    any suggestions welcome ;) !

  2. There is no option. This behavior is neccessary because there are (buggy) user-agents out there which offer SRTP keys over insecure transport layer and if the PBX does not answer the crypto-line in a response then the call would not establish.

     

    A UA that does not support SRTP should silently ignore this.

     

    If there's no way to remove the crypto line from the SDP when using UDP or TCP connections i'll have to find an alternative solution (end of trial) :rolleyes:

     

    In my case the UA isn't offering any capabilities in the initial INVITE (no SDP).

     

    PBXNSIP is offering SDP in the 200OK (with crypto line even though the transport layer is UDP/TCP).

  3. There is no option. This behavior is neccessary because there are (buggy) user-agents out there which offer SRTP keys over insecure transport layer and if the PBX does not answer the crypto-line in a response then the call would not establish.

     

    A UA that does not support SRTP should silently ignore this.

     

     

    Is sending cryptographic information over a non-secure transport a good idea? I see that the a=crypto lines are sent whatever the transport layer (TCP/UDP/TLS)

  4. I'm making calls whereby an INVITE without SDP is sent to PBXNSIP to initiate a call.

     

    PBXNSIP always seems to respond with a 200OK containing and SDP which contains a 'crypto' line (initiating SRTP when the calling device sends an ACK which contains the SDP).

     

    How can I stop PBXNSIP sending any crypto lines in SDP's (i.e. turn off SRTP) ???

  5. I'm attempting to setup an auto attendant to work alongside a peer proxy ring-group application..... with no success yet......

     

    Call flow goes a little like this..........

     

    itsp >>> proxy >>> pbxnsip autoattendant

     

    caller dials an extenstion, call is routed back to proxy.....

     

    proxy <<< pbxnsip

     

    registered device (to proxy) rings :)....... feature on proxy routes call back to pbxnsip if the call isn't answered......

     

    proxy >>> pbxnsip

     

    call dies :P get strange error messages:

     

    [5] 2009/04/14 12:13:15: Received loopback request without tag

    [5] 2009/04/14 12:13:15: Received incoming call without trunk information and user has not been found

     

    what header declares the 'trunk information'?

    why is the user found when the same request URI is used (and the user is called directly)?

     

    make any sense?

×
×
  • Create New...