OK... Here we go again...
Sam puts on his complete cynic's hat and is getting ready
to go on a tirade and probably insult about half the community ... So Sam gets
on both knees and begs forgiveness before he even
starts!!!!!!!!!!!!!!!!!!!!!!!
This has been tried before............. in mmusic... Here
is a link to the expired draft. I was oneof the unfortunates that thought
bringing SIP and RTSP together was a good idea. Steve Whitehead actually
thought that about a year earlier than me!!!!
Why
did RTSP get bundled in the sdp there and not sip updates well, when you do a
trick play command you want fast response that is not bound to a 32 second SIP
timeout... or have that hop about 10 record-route headers to get
there!!!!! RTSP seemed to do the job fine and we just needed SIP as a
rendez-vous protocol to set up sessions and tear them
down....
But I
digress... I was not going to discuss anything technical
To the
authors .... let me list some reasons... why it is absolutely in-essential for
this to even happen... with tongue firmly in cheek (all capitalized words follow
RFC2119)
1. RTSP is fine by itself we dont need no stinking sip to set up
video streams...
2. If you say anything about how there are IMS networks... that may
need this -- Well Sam stands up with a phone in his hand (any phone does
not matter what kind) --- Show me one IMS(not rfc 2119) deplyed phone
that I can make a real call to!!!
My
memory fails me on the other ones we got.....
The
following are time lines that you will follow...
1. Both 1 and 2 MAY occur about the 5th or 6th IETF meeting... so
dont hold your breath till at the earliet ietf-79 in Atlanta
2. You will argue for 79, 80 and 81 and may be even
82
3. You will be asked for more real use cases around
82
4. You will go to an interim meeting between 82 and 83 and try this
again..
At
this point there are differing possibilities
1. You will get tired and cynical and say to hell with it and stuff
what ever you want at the app layer as application/xml in the body and say it
does not break SIp or any other protocol and go on your merry
way
2. You may have changed jobs and this is no longer of any relevance
to you
3. You will go to ATIS or TISPAN and define you protocol there
after politicking there... with one vote per company that
participates!!!
Geez... Have I left anybody out that I have not offended
yet???
Anyway... Good Luck in your endeavours
Sam
(Putting his flame suit on)
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Avasarala Ranjit-A20990
Sent: Friday, March 20, 2009 1:38 PM
To: SHANMUGALINGAM SIVASOTHY; sipping@xxxxxxxx
Subject: Re: Comments on ID (SIP extensions for media control )
Hi Siva
Did u have a look at http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-framework-10.txt draft?
Regards
Ranjit
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of SHANMUGALINGAM SIVASOTHY
Sent: Friday, March 20, 2009 10:52 PM
To: sipping@xxxxxxxx
Subject: Comments on ID (SIP extensions for media control )
Dear all:
We have updated
http://www.ietf.org/internet-drafts/draft-siva-sip-media-00.txt
Abstract: This draft presents a requirement and proposes a solution to integration of Session Initiation Protocol (SIP), to the Real Time Streaming Protocol (RTSP and RTSP v2) [RFC 2326 and IDRTSP] especially in the context of converged media services or IPTV services. The document develops a rationale for using SIP with streaming media applications. One service on top of IPTV service is sketched out, which required SIP optimally.
All your comments are greatly appreciated.
Best regards
Siva
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
