Adam B. Roach ([EMAIL PROTECTED]):
> > Right now, my NAPT SIP code (http://www.siphappens.com/masquerade/)
> >doesn't re-modify the topmost Via on responses. This is because I
> >figured that end devices wouldn't bother checking if the message is
> >actually for them if they got a response.
>
> Actually, I just checked, and our client does (part of the "sanity
> checking" routing) -- so it's not necessarily a good assumption.
Brutal. Can you think of any time where this sanity check would pay
off? I mean, in my opinion, you should fail only when the call leg
match fails...
> > Should I bother remodifying it, or expect that proxies will just
> > check the parameters (branch), if anything?
>
> I forget if your NAPT acts as a proxy, or just a NAT which modifies
> the SDP.
Just modifying the SDP is no good if you can't masquerade the SIP. My
current code is basically a transparent SIP proxy.
> If the former, it should be inserting its own Via, which should
> obviate the problem. If not, I'd say that you should be able to send
> the message forward with the Via unchanged in the first place, and let
> the receipient tag it with a "received" parameter (isn't this
> *precisely* the situation that "received" is intended for?).
I change the address in the Via for safety if the far end doesn't put
in a received tag. It's really easy to change it since I also have to
add in a port.
The real reason I'm not adding my own Via header (and also not
demasquerading the via header) is because if I don't, I can get away
without modifying incoming SIP messages from the Internet. Otherwise, I
have to find out if the request is a response, and if it is, strip out
the Via.
But I guess what you're saying is that doing this is worth it, since
otherwise I won't work with your code.
--
Billy Biggs, 3Com Email: [EMAIL PROTECTED]
http://www.div8.net/billy/ Phone: [EMAIL PROTECTED]
