Re: [Siproxd-users] Via: rport rewriting in siproxd 0.7.1

[Thomas R. <tr...@gm...>]

Hello Peter,

I will have a look at it when I get some time, thanks for reporting.

Currently the use_rport configuration parameter does only tell siproxd
to add an rport header, if does not affect processing of existing
headers. Siproxd does (currently) not honor an existing rport header.

So let's put RFC3581 onto the TODO list...

Regards,
/Thomas

On  4 Feb, Peter Apian-Bennewitz wrote:
> Hi,
> 
> problem:
> login with twinkle via siproxd to callcentric.com fails with "network 
> failure" on callcentric's side. Running twinkle without siproxd works.
> 
> SIP provider's answer:
> callcentric's support says siproxd is not following RFC3581 regarding 
> the rport parameter. As far as I understand RFC3581 this is correct, 
> even if the Via header in question is only the second Via (not the 
> topmost) that callcentric's server sees.
> 
> data:
> The header of the outgoing REQUEST SIP packet with the MD5 hash,
> leaving my gateway, after siproxd processing, looks like:
> 
>     Via: SIP/2.0/UDP
>     84.56.215.75:5060;branch=z9hG4bKb508ec9eb039c974bd1cccba6117cc33
>     Via: SIP/2.0/UDP 192.168.0.11;rport;branch=z9hG4bKcykecwos
>     From: <sip:XX...@ca...>;tag=mkqua
>     To: <sip:XX...@ca...>
>     Call-ID: tmvgrhodrsbtzae@mylocalname
>     CSeq: 935 REGISTER
>     Contact: <sip:XXX@84.56.215.75>
>     Proxy-Authorization: Digest username="XXX", realm="callcentric.com",
>     nonce="88a438c17e962decdb3091df2c300169", uri="sip:callcentric.com",
>     response="XXXX", algorithm=MD5
>     Allow: INVITE
>     Allow: ACK
>     Allow: BYE
>     Allow: CANCEL
>     Allow: OPTIONS
>     Allow: PRACK
>     Allow: REFER
>     Allow: NOTIFY
>     Allow: SUBSCRIBE
>     Allow: INFO
>     Allow: MESSAGE
>     Max-forwards: 69
>     Expires: 1800
>     User-agent: Twinkle/1.2
>     Content-Length: 0
> 
> (with userid details set to XXX). After that there's a 30 second 
> silence, followed by a "network failure" packet.
> 
> My question is specific about the "rport" parameter in the second Via 
> header. RFC3581 says:
> 
> "When a server compliant to this specification (which can be a proxy
>    or UAS) receives a request, it examines the topmost Via header
>    field value.  If this Via header field value contains an "rport"
>    parameter with no value, it MUST set the value of the parameter to
>    the source port of the request."
> 
> Which sounds to me (SIP newbie, UNIX/network veteran) like siproxd 
> should add an rport number to the incoming packet sent by twinkle.
> Furthermore, shouldn't "use_rport = 3" add a string "rport=" before
> the UDP port number ? At least the RFC seems to give that as example.
> - ? Whether callcentric's server should stall at a Via header that
> doesn't matter to it may be another question, but before I nag them I
> would like to be sure that what my siproxd sends them is correct.
> 
> any insight much appreciated,
> (meaculpa if this is RTFM, I tried to check the mail archives on 
> sourceforge)
> 
> thanks
> Peter
> 

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE d s+: a C+++ UL+++ P+++ L++++ E-- W++ N++ o+ K w-- 
O- M- V PS+ PE Y+ PGP++ t+ 5++ X R tv+ b+ DI++ D+ 
G e++ h r+++ y+++
------END GEEK CODE BLOCK------