Hi Vishal, > Also in no case UAC itself is going to use this data as for all new > INVITE it has to send to same proxy again keeping its contact as > internal IP not NAT IP. Why the contact header in the new INVITE should NOT be used NAT IP? How does the ACK (for INVITE) come back if the UA is behind NAT?
Richard On Fri, 2007-06-22 at 11:06 +0530, Vishal Mathur wrote: > Hi Richard, > > IF both the UAC are behind the NAT then also NAT port will be different > for both of these UAC. So server can store IP and port which will > distinguish both the UAC. Actually proxy should send Contact only of > that UAC not all. That proxy can manage by itself so there is no > confusion for second UAC. > > Also in no case UAC itself is going to use this data as for all new > INVITE it has to send to same proxy again keeping its contact as > internal IP not NAT IP. > > It is ok to use STUN mechanism but if you want to can send NOTIFY (with > event as no event) to UAC to keep NAT connection alive. There are many > heuristic to find alive NAT connection. For example you can keep > difference of small difference in second before sending next notify (say > 10 seconds), and if you are getting any response from UAC that means NAT > connection is alive. Keep adding some second before sending next NOTIFY > (say increase it like 20, 30, 40). At last when you get NO Reply from > the UAC or your maximum limit reached you can use the last successful > difference and keep this as fixed time out after which next NOTIFY has > to be send. Note that you have to careful about other message because > any message will increase NAT timer. So NOTIFY should be send only after > gap of fixed second when no other message has been send or received. > > Regards, > > Vishal Mathur > Symantec Corporation > www.symantec.com > _________________________________ > Office: +91-20-66067655 > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Richard > Sent: Friday, June 22, 2007 7:38 AM > To: [EMAIL PROTECTED] > Subject: [Sip-implementors] Multiple contacts in register 200 OK > response > > > Suppose UA1, which is behind NAT, is registering a public SIP server. > UA1 > (only necessary headers are shown) > REGISTER sip:serviceprovider.com > To: <sip:[EMAIL PROTECTED]> > From: <sip:[EMAIL PROTECTED]> > Contact: <sip:[EMAIL PROTECTED];expires=3600> > > Then UA1 receives the 200 OK response: > 200 OK > Contact: <sip:[EMAIL PROTECTED]:15060;expires=3600> > > Then UA2, which is located in other machine and is also behind NAT, > registers to the same public SIP server using the same AOR. > > REGISTER sip:serviceprovider.com > To: <sip:[EMAIL PROTECTED]> > From: <sip:[EMAIL PROTECTED]> > Contact: <sip:[EMAIL PROTECTED];expires=3600> > > Then UA2 receives the 200 OK response: > 200 OK > Contact: <sip:[EMAIL PROTECTED]:15060;expires=3500> > Contact: <sip:[EMAIL PROTECTED]:25060;expires=3600> > > >From UA2 point of view, it does not know which contact header it is > belong to. > > Another question is: would I use the contact header (with mapped public > address) from the register 200 OK response to put in creating INVITE > message instead of consulting the STUN server if the UA is behind NAT? > > Richard > Senior Engineer > ASTRI > > > > This message (including any attachments) is for the named addressee(s)'s > use only. It may contain > sensitive, confidential, private proprietary or legally privileged > information intended for a > specific individual and purpose, and is protected by law. If you are not > the intended recipient, > please immediately delete it and all copies of it from your system, > destroy any hard copies of it > and notify the sender. Any use, disclosure, copying, or distribution of > this message and/or any > attachments is strictly prohibited. > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
