[asterisk-dev] uncached realtime sip friends cannot set transport-protocol in sipregs

Wed Sep 7 02:13:32 CDT 2011

6 sep 2011 kl. 22:28 skrev Walter Doekes:

>>> However, when asterisk calls the user, it always uses the "preferred"
>>> transport, namely the first option: UDP, *even* though the user
>>> registered with transport=tcp in the Contact header.
>> Was it in the URI or in the header parameter? Can you please copy the
>> contact here. If it's in the URI, it should be stored in the reg database.
> 
> Contact from REGISTER:
> 
>  Contact: <sip:200 at 127.0.1.1:1234;transport=TCP>
THis is clearly part of the URI and should NOT be stripped off when saving the fullcontact any where.

> 
>>> The cause of this simple: the sipregs table has no place to store the
>>> transport -- except for the fullcontact column, see below -- ergo, it
>>> does not know that the client prefers (and in many cases, *only* does)
>>> TCP.
> 
>> It should at least be stored in the peer structure, if not cached to
>> astdb and/or realtime.
> 
> The peer structure is destroyed automatically when not needed, right? Hence the rtcachefriends=no.
> 
> As my report below shows:
> - cached peer structure does store the transport
> - astdb does store fullcontact (but doesn't use it)
> - realtime (sipregs) doesn't store fullcontact
That's a bug.

> 
>> I can't comment on the TCP/TLS part of the code since that's been having
>> a lot of issues (it's still marked experimental for a reason). If we go
>> ahead and change the astdb structure, we should add
>> - expiry time for the registration
>> - asterisk version (to avoid issues when upgrading and make it possible
>> to change the data structure in the future).
> 
> If possible, I don't want to touch the astdb at all. See below.
> 
> ========================================================================
> 
> Tests done below with Asterisk PBX SVN-branch-1.8-r334453M
> (with patches of ASTERISK-18354, ASTERISK-18355 and ASTERISK-18356, but
> they are irrelevant for the outcome)
> 
> sip.conf:
> 
> [general]
> allow=all
> allowguest=no
> nat=no
> tcpenable=yes
> transport=udp,tcp
> 
> ========================================================================
> rtcachefriends=yes
> ========================================================================
> 
> <--- SIP read from TCP:127.0.0.1:51806 --->
> REGISTER sip:127.0.0.1:5060 SIP/2.0
> Via: SIP/2.0/TCP 127.0.1.1:1234;branch=z9hG4bK-9155-1-0
> From: <sip:200 at 127.0.0.1:5060>;tag=9155SIPpTag001
> To: <sip:200 at 127.0.0.1:5060>
> Contact: <sip:200 at 127.0.1.1:1234;transport=TCP>
> Expires: 600
> Call-ID: 1-9155 at 127.0.1.1
> CSeq: 1 REGISTER
> Content-Length: 0
> 
> *CLI> sip show peer 200
> ...
>  ToHost       :
>  Addr->IP     : 127.0.1.1:1234
>  Defaddr->IP  : (null)
>  Prim.Transp. : TCP
>  Allowed.Trsp : TCP,UDP
>  Def. Username: 200
> 
> *CLI> channel originate SIP/200 application Answer 1000
> Reliably Transmitting (no NAT) to 127.0.1.1:1234:
> INVITE sip:200 at 127.0.1.1:1234;transport=TCP SIP/2.0
> Via: SIP/2.0/TCP 127.0.1.1:5060;branch=z9hG4bK225249ad
> Max-Forwards: 70
> From: "Anonymous" <sip:Anonymous at anonymous.invalid>;tag=as24c20e82
> To: <sip:200 at 127.0.1.1:1234;transport=TCP>
> Contact: <sip:Anonymous at 127.0.1.1:5060;transport=TCP>
> ...
> 
> ========================================================================
> rtcachefriends=no
> ========================================================================
> 
> <--- SIP read from TCP:127.0.0.1:56794 --->
> REGISTER sip:127.0.0.1:5060 SIP/2.0
> Via: SIP/2.0/TCP 127.0.1.1:1234;branch=z9hG4bK-9218-1-0
> From: <sip:200 at 127.0.0.1:5060>;tag=9218SIPpTag001
> To: <sip:200 at 127.0.0.1:5060>
> Contact: <sip:200 at 127.0.1.1:1234;transport=TCP>
> Expires: 600
> Call-ID: 1-9218 at 127.0.1.1
> CSeq: 1 REGISTER
> Content-Length: 0
> 
> *CLI> sip show peer 200
> Peer 200 not found.
> 
> *CLI> sip show peer 200 load
> ...
>  ToHost       :
>  Addr->IP     : 127.0.1.1:1234
>  Defaddr->IP  : (null)
>  Prim.Transp. : UDP
>  Allowed.Trsp : TCP,UDP
>  Def. Username: 200
> 
> *CLI> channel originate SIP/200 application Answer 1000
> Reliably Transmitting (no NAT) to 127.0.1.1:1234:
> INVITE sip:200 at 127.0.1.1:1234;transport=TCP SIP/2.0
> Via: SIP/2.0/UDP 127.0.1.1:5060;branch=z9hG4bK20bd6397
> Max-Forwards: 70
> From: "Anonymous" <sip:Anonymous at anonymous.invalid>;tag=as4c5be1c5
> To: <sip:200 at 127.0.1.1:1234;transport=TCP>
> Contact: <sip:Anonymous at 127.0.1.1:5060>
> ...
> 
> ========================================================================
> 
> Observe that we see "sip:200 at 127.0.1.1:1234;transport=TCP" in the R-URI.
> But that's completely useless, as it's attempting to connect over UDP.
ha ha. Funny and tragic.

> 
> If the 'fullcontact' column is set in sipregs, which is *only* written
> rtcachefriends=yes, this value is *read* from the db. If it is
> empty it uses the value stored from the astdb, if available.
> 
> Your question did reveal that the behaviour is different on my
> production system than on a clean install. But it's broken in both
> cases.
> 
> In my case, I disabled the writing to astdb, so I don't get the nice
> R-URI with transport=TCP.
> https://issues.asterisk.org/jira/browse/ASTERISK-17294
> 
> But that's logical. If it's going to store the fullcontact, it better
> well do it in the database and not in the astdb of the UA that the
> REGISTER request happened to land on.
> 
> In either case, the transport from the R-URI is *not* used to determine
> transport protocol.
> 
Thank you for a very detailed mail. The only part missing is to document what's actually stored in the database, but since the INVITE actually had the parrameter, I think you are wrong with the assumption above that the full URI is not stored in realtime. I think it is. The problem is that when loading the peer, the transport parameter is not parsed and used.

/O