Re: [Ekiga-list] mem leak and undesired OPTIONS and PUBLISH calls

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

On 02/02/13 02:19, James Cloos wrote:
> ED>  With current code it is like this:
> ED>  OPTIONS sip:eugen dedu 86 64 162 35 SIP/2.0
> ED>  However, in From field there is my posix name, I suppose this is
> ED>  normal, do you know if this is true?
>
> I get:
>
> OPTIONS sip:cloos [REMOTE_IP] SIP/2.0
> ...
> From: "James Cloos"<sip:cloos [IpFromStun]>;tag=[UUID]
>
> The first should be the same address used in the To: header of the
> matching REGISTER:
>
> REGISTER sip:[REMOTE_HOSTNAME] SIP/2.0
> From:<sip:correctname [REMOTE_HOSTNAME]>;tag=[UUID]
> To:<sip:correctname [REMOTE_HOSTNAME]>
>
> The OPTIONS requests should look more like the REGISTER requests.
>
> Whether it should use the IP addresses as it currently does or the
> hostnames as REGSITER does I do not know.  But the local part certainly
> should be the same as REGISTER uses.

Then please send this problem to opalvoip-user lists sourceforge net 
mailing list.  And be prepared to wait one week, until the developer 
comes back...

> ED>  The reason of those OPTIONS is to keep NAT alive, so they should be
> ED>  sent no matter if it gets error or not.
>
> It wouldn't get an error if it were using the correct localpart.
>
> It also needs to send P-Asserted-Identity: or Remote-Party-ID:
> on INVITEs and allow it to be specified per-proxy and overrided
> per-call to ensure accurate outgoing clid.  It looks like opal
> supports them.

Damien, any idea about this?

I would also like to fix 
https://bugzilla.gnome.org/show_bug.cgi?id=599889, since opal has 
support for it.  I however noticed on some Web page that Remote-Party-ID 
is obsolete...

> And thanks for the work on it.  Ekiga has come in handy!

Excellent!

--
Eugen