Anthony Minessale napsal(a):
The point of that NDLB-nat-connectile-dysfunction param is to perform a hack on the RFC and ignore the contact given in the packet and replace it in our database with our own contact we formulate by using the IP and PORT the packet was received from. Thus the PORT has to be included because sending invites to that exact IP and PORT is the only way we know will make it back over the NAT translation path.
If you register to me on a public server and you say your contact is foo@10.0.0.1 <mailto:foo@10.0.0.1>. but I see the NAT hack enabled on your account. I notice the packet was received from a valid internet IP:PORT since I cannot reach 10.0.0.1 <http://10.0.0.1> I replace the host from your real contact with the IP you registered from. and I append the PORT the register came from and save that as a contact. Then if i send an invite to that url it will go backwards over your NAT path assuming you are doing keepalives on SIP.
Thank you, Anthony, for your answer! It is clear to me and I think, there is no dispute between us. But I just still don't catch why modifeid contact should be in 200 OK response to REGISTER request. I thought the 200 OK response could contain the same contact you received and you just store modified one for later INVITE/NOTIFY/etc processing. I had looked into sources and than slightly modified sofia_reg.c (5 lines of code :-) and everything works as I want. If someone interested, I send the modified version, but: 1. I accidentaly delete original sofia_reg.c so I can't make a diff. 2. It is simple stupid workaround and I realy don't know what other things I break with it... <off-topic> About our other debate: We both have unmatched view about what I meant in my e-mails. I feel bad about it, but I can do nothing with it. So, if you can, forget the debate please, and make peace together :-) </off-topic> Best regards, kokoska.rokoska