Menu

Does SIProxd really do masquerading ?

Help
Anonymous
2011-10-12
2013-05-28
  • Anonymous

    Anonymous - 2011-10-12

    Hi,

    I've configured my phone (Siemens Gigaset C470) to authenticate a remote SIP provider throught my SIProxd.
    IP Addres of my Gigaset : A.A.A.A
    IP Addres of my SIP Provider : B.B.B.B

    Using tcdpump and wireshark, i've got a REGISTER frame with two "Via SIP/2.0/UDP" : one with B.B.B.B and one other with A.A.A.A

    why sipproxd does not hide hide A.A.A.A ?

    Thanks !

    Best regards,
    Steph

     
  • Anonymous

    Anonymous - 2011-10-12

    Note : without SIPProxd, i've only got one "via" with A.A.A.A :-/

     
  • Thomas Ries

    Thomas Ries - 2011-10-12

    Hi Steph,

    The additional Via field that you observe is required by siproxd for routing of the SIP telegrams back to the local phone. According to the SIP Standard no other processing entity should actually care about this particular Via.
    The Via headers in a SIP telegram are like a stack. New headers will be added on top of the Stack and only the uppermost Via may have an effect for routing the telegram. The REGISTRAR should not care about that Via - if it does, then likely it is not compliant with RFC3261 (SIP).

    As siproxd uses a mostly stateless approach this Via cannot be avoided (by design).

    Aside from that one Via, all other references to the local UA are hidden behind siproxd. In practice this works fine, so far only one provider is known to me that does not work because of this second Via - this is callcentric.com.
    This is mentioned in the Release Notes of siproxd:

    Known interoperability issues with SIP service providers:
    - callcentric.com      callcentric fails with "500 network failure"
                            during REGISTER if more than one Via header is
                            present in a SIP packet. Having multiple Via headers
                            is completely in compliance with RFC3261. This might
                            be related to their "NAT problem avoidance magic".
                            There is nothing that can be done within siproxd
                            to avoid this issue as callcentric does not comply
                            with the SIP specification.

    I hope this clarifies your question / observation.

    Best regards,
    /Thomas

     

Log in to post a comment.