Thanks Jeroen and Dale- I was considering something along the line of the "rport" parameter as I was slowly waking up this morning, but is it OK just to add parameters like that to a header for what seems to me should be a pretty standard operation? My understanding is that the rport is only specified for symmetric response routing over UDP, but I suppose specifying one for TCP wouldn't cause any real issues. Unless, of course, some future spec decides to use a parameter of that name?
I guess this still seems like something that shouldn't require anything remotely along the lines of "hacks". Would you guys consider these hacks, or would you consider these the standard and expected ways to handle this issue? Still seems to me like Henning et al may not have given this one quite as much thought as maybe is warranted. Thanks again. -Adam On 4/28/06, Jeroen van Bemmel <[EMAIL PROTECTED]> wrote: > > My solution was to always add an 'rport' parameter to the received top via > for reliable transports > > Encoding it in the branch parameter conflicts with the recommendation to > copy the topmost branch for stateless forwarding (see SIP bug database, > has > to do with backwards compatibility) > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Dale R. Worley" <[EMAIL PROTECTED]> > To: "Sip-Implementors" <[email protected]> > Sent: Friday, April 28, 2006 3:47 AM > Subject: Re: [Sip-implementors] stateless proxies and transportlayer > responses over reliable transports > > > > On Thu, 2006-04-27 at 18:07 -0400, Adam Fisk wrote: > >> The > >> only solution I can see is actually storing some state using the branch > >> ID > >> at the transport layer of the stateless proxy, but this is not > specified > >> anywhere. > > > > Yes, you can encode quite a bit of information into the branch parameter > > (or other parameters of the Via, I think). > > > >> In fact, how to look up the transport connection for a stateless > >> proxy for reliable transports is not specified anywhere as far as I can > >> tell, as the only explanation involves the use of transactions. > > > > That's true, it doesn't tell you *how* to satisfy the requirement, only > > that you *must do so*. > > > > Dale > > > > --- > > interop.pingtel.com -- the public SIP phone interoperability test server > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
