[Blink] GRUU-related no ACK problem behind sipX

[Jeff Pyle]

Hi Saúl,

I've heard back from eZuce.  They say the problem is the contact is being
modified with a transport parameter, and thus failing a match.

Specifically, the gruu contact obtained in one registration
is "~~gr~ReZQUTUDuTi@*sip.host.net <http://sip.host.net>*;gr", but the
contact returned in a call's 200 OK is "~~gr~ReZQUTUDuTi@*sip.host.net
<http://sip.host.net>*;*transport=tcp*;gr".

The registration domain has a NAPTR record indicating equal weights for UDP
and TCP SRV records.  I force the registration to TCP with primary proxy
value that includes ;transport=tcp.  Maybe this is relevant, maybe it's not.

Anyway, their interpretation of the RFC is that, and I quote, "The UA must
not modify the GRUU string."

Thoughts?


- Jeff



On Thu, Jul 10, 2014 at 10:13 AM, Saúl Ibarra Corretgé <saul at ag-projects.com
> wrote:

>
> On 10 Jul 2014, at 16:05, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
>
> > Saúl,
> >
> > It does what you say - it now uses the GRUU contact in the 180.  The ACK
> from the originating side still doesn't make it through sipX (openUC,
> really).  I'll open a ticket with educe.
>
> Thanks Jeff! Please keep me posted. I’ll merge the patch anyway, since it
> does make sense to send the correct contact header there too.
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>
> _______________________________________________
> Blink mailing list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/blink
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20140718/44fec1e5/attachment.html>