| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
I tried the following setup:
UA without RFC5626 support
|
Edge Proxy (repro), EnableFlowTokens = true, AssumePath = true
|
SBC (reConServer)
|
Registration proxy (repro), AssumeFirstHopSupportsOutbound = true
The Edge proxy is correctly adding the Path headers
The reConServer does REGISTER forwarding, it adds a Path header for itself
The registration server sees the REGISTER requests and complains "Trying
to use TLS with an IP-address in your Contact header won't work if you
don't have a flow. Consider implementing outbound, or putting an FQDN in
your contact header.". The message comes from dum/ServerRegistration[1]
I temporarily disabled that code and observed that:
a) the repro registration is able to read the Path headers and store them
b) when I send an INVITE, it correctly constructs Route headers for
reaching the UA and forwards the INVITE to the SBC, the call is successful
Should AssumeFirstHopSupportsOutbound be more generous and help suppress
this error?
When the flow-token hack is enabled in the edge proxy, should it add
";ob" to the Path header, is there a way to make it do so for
non-outbound clients?
Or should the SBC do something to the Contact header to make repro
accept it? I tried that too and it is an effective workaround, but I
felt this was a bit ugly and prefer to use Path rather than modifying
Contact.
Regards,
Daniel
1.
https://github.com/resiprocate/resiprocate/blob/ master/resip/dum/ ServerRegistration.cxx#L535
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate- devel