Inaki, You have misunderstood what I have said: The flow token is generated and added to the route header by the edge proxy. The flow token that edge proxy should put in the route header should be constructed in such a way that can be used to locate the registration from this particular user agent from this user. One way of doing this is to generate it in a manner similar to permanent or temporary GRUU. If flow token can be used to determine the registration it is referring to, for the subsequent requests you should be able to send it over any flow associated with this registration. Technically speaking, client is not forced in any way to be registered with anybody to use SIP outbound, or to use the flow associated with its registration to send its requests, so what I propose might not work in some cases. On the other hand, sip-outbound does not work for almost any common call scenario.
The more I think about it, the more I am convinced that SIP Outbound should be rewritten. The way SIP Outbound should work is that every time a new flow is created from the client, a SIP registration should be send over this flow to associate it with an AOR. Response to this registration should include a flow token, that can be used by the edge proxy to reference data associated with the AOR and UID in the registration server. All subsequent requests sent by user agent over this flow should include an additional parameter in the VIA header that includes this flow token. It should be legal to send responses or new SIP messages to the user agent over any flow that is associated with the same AOR and UID. The continuation of this discussion should probably take in sipcore. _____________ Roman Shpount On Fri, Jul 27, 2012 at 7:34 AM, Iñaki Baz Castillo <[email protected]> wrote: > Hi Roman, sorry for the late response: > > > 2012/6/18 Roman Shpount <[email protected]>: > > You can work around the issue you mention by putting the public GRUU in > the > > route header instead of flow token. For all the subsequent requests proxy > > will look up if the flow exists for this GRUU and send the request over > this > > flow. > > This is not safe. The outbound id token must be safely generated by > the Outbound proxy (and not by the UA), in fact, the proxy should be > able to check whether a outbound id token in a Route header has been > created by the proxy itself. > > > > > Overall I do agree with you that SIP Outbound is fairly raw, almost > > unimplementable spec which needs to be either updated or replaced (maybe > > with sip over websockets :). > > I have an idea in mind (which would be an extension to Outbound > mechanism) so after a disconnection the UAC could re-register by > asking the proxy to set the previous Outbound id token to the new > connection (in this way incoming in-dialog requests would reach the > UAC without the need of using GRUU). > > > Regards. > > > -- > Iñaki Baz Castillo > <[email protected]> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
