Re: [reSIProcate-users] ACK being sent to the contact instead of the place it received it from

[Kennard White <kennard_white@xxxxxxxxxxxx>]

Hi Dan,

Is the problem that (a) the caller resip is not sending to ACK request to repro, or (b) that repro is not properly sending it to the callee. If (a), then you haven't setup repro to properly record-route. If (b), then repro isn't properly using flow tokens. To address (b) either turn on flow-tokens (--flow-tokens, I think) or turn on outbound support in your client. Resip as a client doesn't directly support outbound, but you can fake it (sort-of) by appending an "ob" parameter to your contact when registering.

Kennard

On Mon, Jan 24, 2011 at 9:30 AM, Dan Weber <dan@xxxxxxxxxxxxxx> wrote:

Hi Kennard,

My topology is recon/dum <-> repro <-> recon/dum for the moment.  I
managed to workaround the issue last night by using
setOverrideHostandPort on the registration handle's userProfile with the
new information provided by the rport info.  However, it would be nice
if repro could take an ACK from a transaction and forward it properly
even if the contact is set wrong..

Dan

On 01/24/2011 09:47 AM, Kennard White wrote:
> Hi Dan,
>
> Could you describe your topology? Also which form of record-routing are
> you using (which option)?
>
> For reference, I've had the following working:
>   DUM client  <>  repro gateway <> core server <> repro gateway<> DUM client
> In my configuration, both repro and core record route (as you
> discovered, without record-routing they drop out of the signaling path
> -- this is the basic design of SIP).
>
> Note that repro doesn't "fix" the contact. Instead it adds an additional
> token to the Record-route header. This is a flow-token, and it is
> encoded in the username portion of the record-route uri. For REGISTER
> requests, it it is encoded in a Path header. The contact header is left
> unmolested.
>
> Regards,
> Kennard
>
> On Mon, Jan 24, 2011 at 12:02 AM, Dan Weber <dan@xxxxxxxxxxxxxx

> <mailto:dan@xxxxxxxxxxxxxx>> wrote:
>
>
>     Ok, I got through this and I've worked around it by forcing record route
>     on repro, and it is now sending the ACK back to repro, but repro isn't
>     sending it to the right destination after it receives it... (e.g.
>     sending back to the private address that is listed in the 200 OK).
>     Eerily enough, it appears that even though with rport and TCP the
>     contact is fixed on the registrations, nothing seems to fix the contact
>     in on going dialogs that are created after that with DUM.  I suspect
>     repro is reading the contact in the 200 OK instead of processing it back
>     through itself.  In either case, if there is a way to fix both pieces so
>     that dum puts the right contact, and repro properly routes back the ACK,
>     I think this would be much better.
>
>     Dan
>
>
>
>
>
>     On 01/24/2011 12:27 AM, Dan Weber wrote:
>     > Hi guys,
>     >
>     > I'm trying to debug an issue where a dialog is created over TCP
>     through
>     > repro or such, and the INVITE and 200 make it to the respective
>     > locations properly, but the ACK from the sender goes directly to the
>     > contact in the 200.  I've even set outbound proxy settings.  How do I
>     > make it so that the ACK gets sent back through repro?
>     >
>     > Dan
>     >
>     > _______________________________________________
>     > resiprocate-users mailing list
>     > resiprocate-users@xxxxxxxxxxxxxxx

>     <mailto:resiprocate-users@xxxxxxxxxxxxxxx>

>     > List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>
>
>     _______________________________________________
>     resiprocate-users mailing list
>     resiprocate-users@xxxxxxxxxxxxxxx

>     <mailto:resiprocate-users@xxxxxxxxxxxxxxx>

>     List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>
>


_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/