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

[Olle E. Johansson]

5 sep 2011 kl. 08:54 skrev Walter Doekes:

> Hi,
> 
> before filing a bug report and writing a patch, I wanted some input on the following:
> 
> When using uncached realtime friends with transport=UDP,TCP users are allowed to register/call using either TCP or UDP. This works fine.
> 
> 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.

> 
> 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.
> 
> I see two easy solutions here:
> 
> (a) Add an extra column `transport` to the sipregs table where we store the "current" preferred protocol.
> 
> (b) Adjust chan_sip to store/read the fullcontact header if available. This is currently only written when rtcachefriends=yes, but I see no reason why we cannot use this for uncached friends. From the fullcontact, asterisk can read and use the transport= uri parameter.
It should at least be stored in the peer structure, if not cached to astdb and/or realtime.
> 
> 
> Both have their disadvantages:
> 
> (a) Needs extra backward compatibility code to check at runtime whether this extra column exists.
> 
> (b) I do not know why fullcontact is not already used for uncached friends. If it was deliberately not used for uncached friends, we can break things if we start using it. (It also suffers from the drawback of (a), but we get to remove some code at the same time, leaving the lines added/removed more balanced.)
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).

/O
> 
> 
> Does anyone familiar with the fullcontact/sipregs code in chan_sip have anything to say about this?
> 
> Regards,
> Walter Doekes
> OSSO B.V.
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-dev

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110905/188b5628/attachment.htm>