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

[Olle E. Johansson]

7 sep 2011 kl. 11:43 skrev Walter Doekes:

>>> 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.
> 
> But why would you think that?
> 
> There is absolutely nothing ambiguous about this IF rtcachefriends THEN no fullcontact:
> 
>  realtime_update_peer(p->name, &p->addr, p->username, rtcachefriends ? p->fullcontact : NULL, p->useragent, expire, p->deprecated_username, p->lastms);
That's just wrong.

> 
> And up to this date no one has been able to explain to me why that IF exists...
So where did the transport=tcp in the URI come from after you loaded the SIP peer from realtime?

> 
>> The problem is that when loading the peer, the transport parameter is not parsed and used.
> 
> That's the other problem indeed. And you only notice this one when you have rtcachefriends=yes OR only a single asterisk UA (where you profit from the fullcontact storage in astdb)
> 
> 
> As far as what's stored in the database (sipregs, not astdb): it's ipaddr and port (and fullcontact if rtcachefriends=yes).
> 
> But. Adding a transport-column to sipregs  is starting to seem logical to me (option (a) from my first post). The fullcontact can contain whatever it likes (e.g. a nice RFC1918 address) and the ipaddr+port+transport columns shall contain the actual details that asterisk should use to connect.
We need to always actually use the provided URI. Now in the case of a UA registrering to asterisk over TCP or TLS and not indicating this in the URI, we definitely need to store the connection transport to try that first.

> 
> (This means that astdb should then also get and use that new transport column.)
Absolutely.

If we are going to support SIP Outbound at some time, we need better connection management in this architecture. It's related, since a UA registering with Asterisk will try to keep the connection open and we need to reuse it for outbound calls.

/O