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 at
http://groups.google.com/group/android-developers?hl=en
