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<enervat...@gmail.com>  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 ."<bhavesh2...@gmail.com>    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<enervat...@gmail.com>    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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs 
cr...@googlegroups.com>
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to