mike, is it possible that the situation where ISP changes ip of your phone differs from the situation where you manually change ip of your phone ipconfig/renew?
that is, is it possible that a phone cannot detect change of ip until next time when it tries to send something out? by the way, what is the java/android api you use to "detect" ip change? could you share a code example with me? thanks :) On May 10, 11:46 am, mike <[email protected]> wrote: > On 05/10/2010 11:24 AM, HeHe wrote: > > > when i mentioned "...not be able to receive incoming calls..", i was > > not thinking about "just server->client streaming". Mike, you knew > > it :) > > > what is your mobile service provider? the sentence "IP address changes > > are probably pretty rare" looks strange to a T-Moble user like me. at > > least i find my G1 ip frequently changes :( > > So I haven't actually tested this, and I disclaimed because I > wasn't sure :) If you're getting lots of IP address changes regardless > of what's happening at the 3gpp/l2 layer, you're probably not going > to not have a very good experience with streaming media of any kind > because once the IP address changes, the RTP stream is going to > tank regardless of SIP, RTSP, Skype, etc. > > That's why you'd need to deal with it more directly like using IP > handoffs using Mobile IP, etc. Handoffs could be done using SIP, but > it would be ugly. Which probably means that somebody has proposed it > and that the working group has taken it on :) AFAIK, mobile IP is still > not deployed widely, even though we were working on it the handoff > probelm almost 10 years ago... > > Part of the reason probably is because 3GPP's latency is really awful for > real time conversations so there's still too high an energy barrier to > actually > deal with the truly difficult problem of dealing with handoffs when TDM > still > works just fine. Maybe 4G will get rid of all that bizarre leftovers > from the > ATM/bellhead days that 3G had to live with to get standardized. > > In any case as far as SIP registration goes, it should be relatively easy to > camp on an event for when the IP address changes and quickly reregister > inside the SIP stack. It wouldn't be surprising that most of the SIP stacks > already have that feature. How bad this is on battery life is obviously > dependent on how often IP addresses are actually changing, but you have > the exact same problem with IM so at some level it's "acceptable" since > people do use IM... > > Mike > > > > > > > On May 10, 10:47 am, mike<[email protected]> wrote: > > >> On 05/10/2010 10:24 AM, HeHe wrote: > > >>> i was not thinking about media. > > >>> i guess the reason why sipdroid+TCP+pbxes can lower battery use is to > >>> enlarge sip registration expiration, eg. to 5 minutes or longer. what > >>> if mobile service provider changes phone IP earlier than 5 min when > >>> the provider finds no traffic to/from the phone? it will not be able > >>> to receive incoming calls without re-registration. > > >>> anyway, i am just guessing. do you know the usual (or by default) > >>> registration expiration between sipdroid and pbxes? > > >> Again, if this is just server->client streaming this is yet another > >> reason to avoid SIP and look at RTSP. SIP is a rendezvous protocol, > >> and all rendezvous protocols are complicated, with lots of things to > >> consider. > > >> AFAIK -- it's been a long time -- SIP registrations can be very long > >> lasting. Unless something has actually changed -- like your IP address > >> moved -- it shouldn't be a problem. I'm not entirely convinced that this > >> is a huge issue anyway because the cellular guys are probably moving > >> you around at L2 for the most part (again, it's been a long time since I've > >> paid attention to the 3gpp guys), so IP address changes are probably > >> pretty rare. I have no idea if anybody's been deploying mobile IP which > >> would more directly solve this issue. > > >> Mike, who used to like to make fun of Henning, Cullen and Jonathan and > >> many others in the SIP WG because of SIP's complexity. > > >>> On May 10, 9:32 am, mike<[email protected]> wrote: > > >>>> On 05/10/2010 09:04 AM, HeHe wrote: > > >>>>> i saw this in sipdroid project FAQ: > > >>>>> "Sipdroid now uses TCP for the signaling connection and keeps the > >>>>> corresponding port open." > > >>>>> does anyone know how peer servers of sipdroid handle scalability when > >>>>> there are a million of sipdroid clients connecting with the servers > >>>>> using TCP? > > >>>>> as i observed, T-mobile Intermittently changes IP of my G1 phone > >>>>> without any notice, which in fact tears down the TCP connection. > > >>>> Remember that SIP doesn't actually transport the media, that's > >>>> RTP which is over UDP. So losing the connection shouldn't generally > >>>> be any worse than losing a http connection generally. > > >>>> As far as scalability, I woudn't worry about that too much. UDP > >>>> based SIP suffers from a lot of problems, not the least of which is > >>>> the lack of security (unless you manage to find DTLS or are running > >>>> it over IPsec). And of course NAT's are tricky as I mentioned before. > > >>>> But I still haven't heard why RTSP wouldn't be a better choice if > >>>> this is just server->client streaming. SIP is a kitchen sink of a > >>>> protocol. > > >>>> Mike > > >>>>> On May 9, 10:14 pm, "Nandan ."<[email protected]> wrote: > > >>>>>> yaa android cod support *sip stack s*uch as mjsip, now pjsip is > >>>>>> already > >>>>>> ported in android platform. > > >>>>>> i can refer you just see sipdroid project. > >>>>>> sipdroid.org > > >>>>>> you can use rtpsender and reciver java file of sipdroid project of > >>>>>> media > >>>>>> folder. > > >>>>>> bhavesh > > >>>>>> On Mon, May 10, 2010 at 3:24 AM, mike<[email protected]> wrote: > > >>>>>>> On 05/06/2010 01:24 AM, vaibhav wrote: > > >>>>>>>> Hi > > >>>>>>>> When I went through the document > >>>>>>>> "opencore_framework_capabilities.pdf" > >>>>>>>> I came to know that Android supports RTP streaming for 3gpp format. > > >>>>>>>> After doing a anaysis I found that the data from a server could be > >>>>>>>> streamed to the android device and played back. i.e the RTP payloads > >>>>>>>> sent from the server are parsed by the Android device and sent to the > >>>>>>>> decoder for playback. > > >>>>>>>> 1. I want to know if it is possible that the PCM data captured from a > >>>>>>>> camera and then encoded using a particular encoder could be streamed > >>>>>>>> using RTP from android code i.e is RTP sender support present in > >>>>>>>> the > >>>>>>>> Android code ?. If not then can someone please mention what could be > >>>>>>>> the possible modifications required. > > >>>>>>>> 2. Does Android code support SIP stack ?. > > >>>>>>> I assume that know that RTP is the actual media payloads, and that SIP > >>>>>>> is the rendezvous protocol to facilitate setting up the RTP listeners > >>>>>>> via > >>>>>>> an SDP announcement? > > >>>>>>> That said, it sounds like you ought to look into RTSP if what you're > >>>>>>> trying > >>>>>>> to do is just stream. SIP is very, very complicated in comparison, > >>>>>>> and has > >>>>>>> all kinds of issues surrounding NAT's that are likely to just confuse > >>>>>>> the > >>>>>>> issue if all you're trying to do is Server->Client streaming. > > >>>>>>> Mike > > >>>>>>> -- > >>>>>>> You received this message because you are subscribed to the Google > >>>>>>> Groups "Android Developers" group. > >>>>>>> To post to this group, send email to > >>>>>>> [email protected] > >>>>>>> To unsubscribe from this group, send email to > >>>>>>> [email protected]<android-developers%2Bunsubs > >>>>>>> [email protected]> > >>>>>>> For more options, visit this group at > >>>>>>>http://groups.google.com/group/android-developers?hl=en > > >>>>>> -- > >>>>>> B!-!/-\\/!=$!-! > > >>>>>> -- > >>>>>> You received this message because you are subscribed to the Google > >>>>>> Groups "Android Developers" group. > >>>>>> To post to this group, send email to > >>>>>> [email protected] > >>>>>> To unsubscribe from this group, send email to > >>>>>> [email protected] > >>>>>> For more options, visit this group > >>>>>> athttp://groups.google.com/group/android-developers?hl=en > > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Android Developers" group. > >>>> To post to this group, send email to [email protected] > >>>> To unsubscribe from this group, send email to > >>>> [email protected] > >>>> For more options, visit this group > >>>> athttp://groups.google.com/group/android-developers?hl=en > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Android Developers" group. > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group > >> athttp://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
