[sip-comm] checkout which module?


#1

hmmmm...in that case, maybe if the binding can't be resolved when
registering or boot time, then we don't retry later as it could be inside a
NAT that won't allow it(what was that symmetric nat or something). This
way, for those users, it is only slow booting up....or maybe it would be
possible to do it in another thread and not block the proceeding call....but
I am not sure that is possible. what are your thoughts?
dean

···

-----Original Message-----

From: Emil Ivov [mailto:emil_ivov@yahoo.com]

Sent: Monday, November 21, 2005 4:08 PM
To: users@sip-communicator.dev.java.net
Subject: Re: [sip-comm] checkout which module?

Dean,

Do I checkout this module....sip-communicator-1-0-draft? or is there a
newer one for pre-release 1?

Yes, sip-communicator-1-0-draft is where version 1.0 is developed.

real slow for what is an internal call and the NAT's external ip is not

needed.

SIP Communicator needs to announce a port where media is to be sent. It
therefore needs to create a binding in its NAT that would correspond to
the local port where it wishes to receive media. If done during
registration the binding would have to be kept alive so that it is still
valid when the call is received. Such behaviour was not implemented in
previous releases of sc and hence all the binding discovieries.

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#2

Hi Dean,

Doing extended firewall discovery during startup is definitely a think that we should consider for 1.0.

There are however some drawbacks. Detecting NAT/Firewall configuration could be a very complex and unreliable process. I really believe that the way to go would be a solution like ICE .... and then again I am not sure that even ICE has all it takes.

We'd need to discuss that in more detail once we get there.

Emil

Hiller, Dean wrote:

···

hmmmm...in that case, maybe if the binding can't be resolved when registering or boot time, then we don't retry later as it could be inside a NAT that won't allow it(what was that symmetric nat or something). This way, for those users, it is only slow booting up....or maybe it would be possible to do it in another thread and not block the proceeding call....but I am not sure that is possible. what are your thoughts?

dean

-----Original Message-----
From: Emil Ivov [mailto:emil_ivov@yahoo.com]
Sent: Monday, November 21, 2005 4:08 PM
To: users@sip-communicator.dev.java.net
Subject: Re: [sip-comm] checkout which module?

Dean,

> Do I checkout this module....sip-communicator-1-0-draft? or is there a
> newer one for pre-release 1?

Yes, sip-communicator-1-0-draft is where version 1.0 is developed.

> real slow for what is an internal call and the NAT's external ip is not needed.

SIP Communicator needs to announce a port where media is to be sent. It
therefore needs to create a binding in its NAT that would correspond to
the local port where it wishes to receive media. If done during
registration the binding would have to be kept alive so that it is still
valid when the call is received. Such behaviour was not implemented in
previous releases of sc and hence all the binding discovieries.

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net