25 May
2011
25 May
'11
2 p.m.
Hi, for those interested in MSRP protocol (instant message sessions
and file transfer for SIP) there are bad news:
Even if there are already clients and servers (MSRP relays o IM
conference servers) implementing the MSRP protocol (RFC 4975 and 4976)
the SIMPLE WG will publish a new draft [*] that breaks these RFC's
just to satisfy big vendors interested in deploying MSRP capable
SBC/ALG boxes (so instead of solving NAT issues with MSRP relays as
RFC 4976 states, they want it to be fixed in the router by doing ugly
ALG, or in a SBC). This is terrible because all the MSRP devices
should implement this new draft in order to interoperate (no backward
compatibility at all). The draft also breaks the security defined in
RFC 4975 (for example, TLS name based authentication cannot work
anymore).
For further information I recommend reading these two posts:
http://blog.tekelec.com/blog/bid/29816/More-on-MSRP-Session-Match-Extension
http://blog.tekelec.com/blog/bid/33138/MSRP-Session-Match-Backwards-Compati…
and also these very *hot* mail threads in the SIMPLE maillist:
http://www.ietf.org/mail-archive/web/simple/current/msg09227.html
http://www.ietf.org/mail-archive/web/simple/current/msg09229.html
[*] http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
25 May
25 May
10:33 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
Hello,
for me it is so clear that the newer version is far more better than the
old one since it will have a greater rfc number. Obvious! I cannot argue
against it.
Cheers,
Daniel
PS. Guys, before implementing SIP-related RFC N, where N is greater than
4000, wait until RFC N+3000 is published to see if there will be one
obsoleting it. If not, you may be safe investing time in it.
On 5/25/11 1:00 PM, Iñaki Baz Castillo wrote:
Hi, for those interested in MSRP protocol (instant
message sessions
and file transfer for SIP) there are bad news:
Even if there are already clients and servers (MSRP relays o IM
conference servers) implementing the MSRP protocol (RFC 4975 and 4976)
the SIMPLE WG will publish a new draft [*] that breaks these RFC's
just to satisfy big vendors interested in deploying MSRP capable
SBC/ALG boxes (so instead of solving NAT issues with MSRP relays as
RFC 4976 states, they want it to be fixed in the router by doing ugly
ALG, or in a SBC). This is terrible because all the MSRP devices
should implement this new draft in order to interoperate (no backward
compatibility at all). The draft also breaks the security defined in
RFC 4975 (for example, TLS name based authentication cannot work
anymore).
For further information I recommend reading these two posts:
http://blog.tekelec.com/blog/bid/29816/More-on-MSRP-Session-Match-Extension
http://blog.tekelec.com/blog/bid/33138/MSRP-Session-Match-Backwards-Compati…
and also these very *hot* mail threads in the SIMPLE maillist:
http://www.ietf.org/mail-archive/web/simple/current/msg09227.html
http://www.ietf.org/mail-archive/web/simple/current/msg09229.html
[*] http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
26 May
26 May
12:44 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
On 5/25/11 9:33 PM, Daniel-Constantin Mierla wrote:
[...]
PS. Guys, before implementing SIP-related RFC N, where N is greater
than 4000, wait until RFC N+3000 is published to see if there will be
one obsoleting it. If not, you may be safe investing time in it.
on the other hand,
I think MSRP didn't bring much value, just another
type of stream out of signaling channel. I am not that familiar with
MSRP to know really if there are real benefits, but sending instant
messaging over SIP was there from beginning and rather simple without
other components that introduce new points of failure.
Reducing the number of optional headers will make the messages also
quite small. As for path optimization, initial request creating the
dialog could get only record-routes from the SIP hops that are intended
to stay in the path (like the relay).
For file transfer, clunking the content and sending over several
requests (again with minimum number of headers) with proper cseq
incrementation will be a straightforward implementation.
SIP can be used in very simple ways, without new types of protocols and
communication channels...
Cheers,
Daniel
On 5/25/11 1:00 PM, Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi, for those interested in MSRP protocol
(instant message sessions
and file transfer for SIP) there are bad news:
Even if there are already clients and servers (MSRP relays o IM
conference servers) implementing the MSRP protocol (RFC 4975 and 4976)
the SIMPLE WG will publish a new draft [*] that breaks these RFC's
just to satisfy big vendors interested in deploying MSRP capable
SBC/ALG boxes (so instead of solving NAT issues with MSRP relays as
RFC 4976 states, they want it to be fixed in the router by doing ugly
ALG, or in a SBC). This is terrible because all the MSRP devices
should implement this new draft in order to interoperate (no backward
compatibility at all). The draft also breaks the security defined in
RFC 4975 (for example, TLS name based authentication cannot work
anymore).
For further information I recommend reading these two posts:
http://blog.tekelec.com/blog/bid/29816/More-on-MSRP-Session-Match-Extension
http://blog.tekelec.com/blog/bid/33138/MSRP-Session-Match-Backwards-Compati…
and also these very *hot* mail threads in the SIMPLE maillist:
http://www.ietf.org/mail-archive/web/simple/current/msg09227.html
http://www.ietf.org/mail-archive/web/simple/current/msg09229.html
[*] http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11
1:19 p.m.
2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
on the other hand, I think MSRP didn't bring much
value, just another type
of stream out of signaling channel. I am not that familiar with MSRP to know
really if there are real benefits, but sending instant messaging over SIP
was there from beginning and rather simple without other components that
introduce new points of failure.
Daniel, I strongly don't agree here. If you state that SIP MESSAGE is
a good way of instant messaging I must say that SIP MESSAGE is as
limited as a mobile SMS and a complete hack if we try to use it as
real IM. If I send a MESSAGE to bob, he will receive it in every
device it holds (parallel forking), regardless which device he uses to
reply my messages. There is no "session of messages" (as there is in
MSRP, XMPP, MSN, Skype or whatever decent IM protocol).
Also, don't forget that MSRP also allows file transfer along with
future extensions (desktop sharing?).
MSRP is the normal procedure for message sessions in SIP. SIP uses a
media stream for audio and video, using a new media stream for IM (and
file transfer) is the correct aproach (IMHO) and fits very well with
SIP protocol concept and existing deployments.
I do know about MSRP implementations and they work very well. The
protocol itself (which I'm implementing right now) is quite easy (just
3 RFC's), it assumes NAT exists so defines MSRP relays (RFC 4976). I'm
also coding a MSRP relay server.
MSRP is the only good added value to SIP (IMHO). Even if it's designed
by SIMPLE WG, I strongly would like to separate it from SIMPLE
PRESENCE (a full pain). It's much simpler and it's well designed.
Reducing the number of optional headers will make the
messages also quite
small. As for path optimization, initial request creating the dialog could
get only record-routes from the SIP hops that are intended to stay in the
path (like the relay).
There is no SIP dialog for MESSAGE request, so record-route doesn't
apply. If it was exist, there should be needed a way to finish the
dialog (a BYE?, a MESSAGE with a custom header "Terminate-IM: yes"?).
MESSAGE requests are like individual SMS's in mobile world.
For file transfer, clunking the content and sending
over several requests
(again with minimum number of headers) with proper cseq incrementation will
be a straightforward implementation.
I don't agree. You are mixing signalling indicators (CSeq) que
application data indicators (message offset). Any CSeq greater than a
previous one is valid (even if it's 100 times greater). The UAS could
never know wheter some other requests have been lost so it has no
information enough to reconstruct the whole message.
Also, you would send the file to all the UAS's in which the
destination user is registered.
In MSRP I send an INVITE with SDP containing MSRP to bob. He receives
the INVITE in his computer and mobile. He decides to answer/accept it
in his computer. Then I have a real IM session with him jsut between
my device and his computer.
SIP can be used in very simple ways, without new types
of protocols and
communication channels...
You know I agree with this statement for other kind of communications,
but not in case of IM. MSRP is the way to go, it's cool, it's already
defined (you are propossing a new specification in your mail) and it
works ok.
Best regards.
PS: It's sad that just a very few softphones/UA's implement MSRP, but
that doesn't mean that using MESSAGE is the way to go.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:39 p.m.
2011/5/26 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Also, don't forget that MSRP also allows file
transfer along with
future extensions (desktop sharing?).
And also, IM real conferences are already defined using MSRP and a
focus conference MSRP server (I've seen it working pretty well:
- An UAC sends an INVITE with SDP containing MSRP offer to a server
(the destination is a conference SIP AoR).
- The conference server replies 200 OK and includes a ;focus parameter
in the Contact. The IM session between the UAC and the server is
already established.
- As the 200 Contact contains ;focus parameter, the UAC can subscribe
to the server (Event: conference) and receives a NOTIFY with the
participants, and receives more NOTIFY's each time a participant is
writting or talking (you can render it in your UA screen) => RFC 4575
(valid for voice/video conferences and IM-MSRP conferences).
- New participants (or leaving participants) are notified in next
NOTIFY's from the server.
- This is cool.
I wonder how all of this could be accomplished with MESSAGE request
without producing N news specifications. Or don't we want IM
conference? do we assume that our SIP client will use XMPP for
advanced IM features? Not me.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:08 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
Hello,
On 5/26/11 12:19 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
for veterans here, we know
it was a proposal (maybe is a rfc now) where
INVITE was used to establish the IM session and them MESSAGE requests to
carry the IMs. At least M$ Windows Messenger implemented it in some
versions.
I think that is far more better approach, as it solves firewall issues
with yet another port and relaying. Just straightforward and simply
works, no new nodes in the core network to care about HA, scalability &
stuff.
on the other hand, I think MSRP didn't bring
much value, just another type
of stream out of signaling channel. I am not that familiar with MSRP to know
really if there are real benefits, but sending instant messaging over SIP
was there from beginning and rather simple without other components that
introduce new points of failure.
Daniel, I strongly don't agree here. If you
state that SIP MESSAGE is
a good way of instant messaging I must say that SIP MESSAGE is as
limited as a mobile SMS and a complete hack if we try to use it as
real IM. If I send a MESSAGE to bob, he will receive it in every
device it holds (parallel forking), regardless which device he uses to
reply my messages. There is no "session of messages" (as there is in
MSRP, XMPP, MSN, Skype or whatever decent IM protocol).
Also, don't forget that MSRP also allows file transfer along with
future extensions (desktop sharing?).
Desktop sharing works now with RTP (jitsi has
it) -- you can think of
image/video transmission. For file transfer I expressed my opinion as a
potential easy mechanism: invite-200ok-ack then what-so-ever SIPr equest
carrying the chunks, synchronized by cseq, then bye.
Since you named some protocols, does XMPP use out of band channels for IM?
A SIP network got too heavy, too many entities in the core network, the
sip router, the rtp relay, the IM relay a.s.o... while it is not really
needed more than 2.
MSRP is the normal procedure for message sessions in SIP. SIP uses a
media stream for audio and video, using a new media stream for IM (and
file transfer) is the correct aproach (IMHO) and fits very well with
SIP protocol concept and existing deployments.
It fits with the concept of making
SIP network heavy and hard to manage,
it simply adds complexity for no real benefit. SIP has the capability to
carry payloads -- like IM is. If you don't want pager mode for IM, start
a session with INVITE, then send MESSAGEs and you are set.
I do know about MSRP implementations and they work very well. The
protocol itself (which I'm implementing right now
Here is a problem: you are implementing it -- that means time and money,
for the SIP in-band the implementation requirements does not exist in
the core network and the endpoints have all the components already in
place, so it will be quite trivial (e.g.,session management with invite,
sending sip requests).
) is quite easy (just
3 RFC's), it assumes NAT exists so defines MSRP relays (RFC 4976). I'm
also coding a MSRP relay server.
MSRP is the only good added value to SIP (IMHO).
Another point of failure is not
good at all, is very bad.
Even if it's designed
by SIMPLE WG, I strongly would like to separate it from SIMPLE
PRESENCE (a full pain). It's much simpler and it's well designed.
So you look to define a new protocol instead of setting a constraint for
a specific case?
Have in mind that what I said is not specified, but it is (IMO) a much
simpler approach for everyone. So don't argue against me with what is
potentially valid in SIP right now. I know them, they can just be more
specific for particular case.
Reducing the number of optional headers will make
the messages also quite
small. As for path optimization, initial request creating the dialog could
get only record-routes from the SIP hops that are intended to stay in the
path (like the relay).
There is no SIP dialog for MESSAGE request, so record-route
doesn't
apply. If it was exist, there should be needed a way to finish the
dialog (a BYE?, a MESSAGE with a custom header "Terminate-IM: yes"?).
MESSAGE requests are like individual SMS's in mobile world.
For file transfer, clunking the content and
sending over several requests
(again with minimum number of headers) with proper cseq incrementation will
be a straightforward implementation.
I don't agree. You are mixing signalling
indicators (CSeq) que
application data indicators (message offset). Any CSeq greater than a
previous one is valid (even if it's 100 times greater). The UAS could
never know wheter some other requests have been lost so it has no
information enough to reconstruct the whole message.
Also, you would send the file to all the UAS's in which the
destination user is registered.
In MSRP I send an INVITE with SDP containing MSRP to bob. He receives
the INVITE in his computer and mobile. He decides to answer/accept it
in his computer. Then I have a real IM session with him jsut between
my device and his computer.
That's because it does not worth the time. The model is not really
bringing benefits, is just another fantasy.
Honestly I could think of just few restrictions/amendments/additions to
the base SIP RFC3261 and the next 10 following it to have very good and
simple model for im, presence, file transfer, desktop sharing a.s.o.
Think about 100 000 000 customers where you need 10 000 media relays, i
should add 10 000 IM relays? Good for vendors, they sell, bad for
operations and quality of service. Really, that's it, period.
SIP can be used in very simple ways, without new
types of protocols and
communication channels...
You know I agree with this statement for other kind of
communications,
but not in case of IM. MSRP is the way to go, it's cool, it's already
defined (you are propossing a new specification in your mail) and it
works ok.
Best regards.
PS: It's sad that just a very few softphones/UA's implement MSRP,
but
that doesn't mean that using MESSAGE is the way to go.
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
3:39 p.m.
2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
UDP is good for audio/video transmission. I don't think any other kind
of information is reliably sent via UDP/RTP. But maybe I'm wrong. I
would like to know how a big file is transferred via RTP.
Already justified that it is not suitable (IMHO).
Of course. 99% of existing SIP implementations just speak SIP and have
done mostly nothing for IM. Does it mean that they deserve a good IM
system without implementing nothing?
The very same as a RtpProxy server.
You cannot expect that during a dialog any kind of in-dialog request
should not be sent. If the UA implements SessionTimers it must
periodically send re-INVITE or UPDATE. If you put on-hold the peer,
you send an INVITE, maybe an INFO for DTMF (even if it's not a
standard). You cannot add such a constrain in the CSeq value. CSeq
value belongs to SIP signalling layer, while a IM session (as a RTP
session) belongs to core/application layer.
for veterans here, we know it was a proposal (maybe is
a rfc now) where
INVITE was used to establish the IM session and them MESSAGE requests to
carry the IMs. At least M$ Windows Messenger implemented it in some
versions.
INVITE exists for negotiating a session. Which session is being negociated here?
Even within the ÏNVITE dialog, how do you correlate received MESSAGE's? i.e:
I send 4 MESSAGE's:
1) Hello
2) Daniel
3) How
4) are you?
Message 3 is lost in some UDP path, so you receive:
"Hello Daniel are you?"
and later (retransmissions):
"How"
If you want to solve it, you would add ugly contrains to SIP
signalling protocol.
Also,
don't forget that MSRP also allows file transfer along with
future extensions (desktop sharing?).
Desktop sharing works now with RTP (jitsi has it) -- you can think of
image/video transmission. For file transfer I expressed my opinion as a
potential easy mechanism: invite-200ok-ack then what-so-ever SIPr equest
carrying the chunks, synchronized by cseq, then bye.
As explained before, using CSeq for that is wrong. If I send you 4
in-dialog request (having my initial INVITE CSeq 1) these requests can
have:
1) CSeq: 2
2) CSeq: 33
3) CSeq: 1000
4) CSeq: 999999
And they are valid. If you (UAS) receive the third in-dialog request
with CSeq 1000 you have no way to know if the network has lost any
previous message(s) (after second request with CSeq 33) or not. CSeq
cannot be used to sync application data on top of the signalling
within a dialog.
Since you named some protocols, does XMPP use out of
band channels for IM?
No, but XMPP has the concept of IM session. SIP MESSAGE has not.
MSRP is the
normal procedure for message sessions in SIP. SIP uses a
media stream for audio and video, using a new media stream for IM (and
file transfer) is the correct aproach (IMHO) and fits very well with
SIP protocol concept and existing deployments.
It fits with the concept of making SIP network heavy and hard to manage, it
simply adds complexity for no real benefit. SIP has the capability to carry
payloads -- like IM is. If you don't want pager mode for IM, start a session
with INVITE, then send MESSAGEs and you are set. I do know
about MSRP implementations and they work very well. The
protocol itself (which I'm implementing right now
Here is a problem: you are implementing it -- that means time and money, for
the SIP in-band the implementation requirements does not exist in the core
network and the endpoints have all the components already in place, so it
will be quite trivial (e.g.,session management with invite, sending sip
requests). ) is quite
easy (just
3 RFC's), it assumes NAT exists so defines MSRP relays (RFC 4976). I'm
also coding a MSRP relay server.
MSRP is the only good added value to SIP (IMHO).
Another point of failure is not good at all, is very bad. There is no
SIP dialog for MESSAGE request, so record-route doesn't
apply. If it was exist, there should be needed a way to finish the
dialog (a BYE?, a MESSAGE with a custom header "Terminate-IM: yes"?).
MESSAGE requests are like individual SMS's in mobile world.
So you look to define a new protocol instead of setting a constraint for a
specific case? For file transfer, clunking the content and
sending over several
requests
(again with minimum number of headers) with proper cseq incrementation
will
be a straightforward implementation.
I don't agree. You are mixing signalling indicators (CSeq) que
application data indicators (message offset). Any CSeq greater than a
previous one is valid (even if it's 100 times greater). Think about 100 000 000 customers where you need 10
000 media relays, i
should add 10 000 IM relays? Good for vendors, they sell, bad for operations
and quality of service. Really, that's it, period.
If you have 100 000 000 customers you could also need 10 000 RtpProxy
servers. Different kind of media sessions (RTP is UDP while MSRP is
TLS) so different kind of relay servers. I don't see the difference.
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:40 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
Inaki,
you are simply on the wrong path in this discussion, you kind of
misunderstand me.
First, I didn't know that SIP _MUST_ be over UDP only.
Try to re-think a bit the whole thing. You come to me with some examples
that are out of the purpose -- you try to demonstrate me that how SIP is
used now to do a voice call does not work for instant messaging session.
You are right, it doesn't, because that is for voice. But you can
negotiate a session that means exchange of MESSAGE requests (or if you
like better a new request type IM) within a dialog. That is session
negotiation and that is the purpose of SIP. Btw, you can force TCP if
you answer 200ok with a TCP address, moreover, TCP is mandatory in SIP
2.0 - bad implementations does not mean bad protocol.
Further, you try to tell me that MESSAGE has no notion of session,
trying to suggest that a new protocol (like MSRP) is a better approach
than defining the session for it (similar concept like for audio call
dialog, preserve call id, follow record routing). MSRP packets have
headers like SIP, just a bit fewer -- it is really bad design thinking
of they could have reused sip to specify IM sessions and file transfer.
Overall, maybe we have different understanding of simplicity.
Cheers,
Daniel
On 5/26/11 2:39 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
UDP is good for audio/video transmission. I don't
think any other kind
of information is reliably sent via UDP/RTP. But maybe I'm wrong. I
would like to know how a big file is transferred via RTP.
Already justified that it is not
suitable (IMHO).
Of course. 99% of existing SIP implementations just speak SIP and have
done mostly nothing for IM. Does it mean that they deserve a good IM
system without implementing nothing?
The very same as a RtpProxy server.
You cannot expect that during a dialog any kind of in-dialog
request
should not be sent. If the UA implements SessionTimers it must
periodically send re-INVITE or UPDATE. If you put on-hold the peer,
you send an INVITE, maybe an INFO for DTMF (even if it's not a
standard). You cannot add such a constrain in the CSeq value. CSeq
value belongs to SIP signalling layer, while a IM session (as a RTP
session) belongs to core/application layer.
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
for veterans here, we know it was a proposal
(maybe is a rfc now) where
INVITE was used to establish the IM session and them MESSAGE requests to
carry the IMs. At least M$ Windows Messenger implemented it in some
versions.
INVITE exists for negotiating a session. Which session is being
negociated here?
Even within the ÏNVITE dialog, how do you correlate received MESSAGE's? i.e:
I send 4 MESSAGE's:
1) Hello
2) Daniel
3) How
4) are you?
Message 3 is lost in some UDP path, so you receive:
"Hello Daniel are you?"
and later (retransmissions):
"How"
If you want to solve it, you would add ugly contrains to SIP
signalling protocol.
Also,
don't forget that MSRP also allows file transfer along with
future extensions (desktop sharing?).
Desktop sharing works now with RTP (jitsi
has it) -- you can think of
image/video transmission. For file transfer I expressed my opinion as a
potential easy mechanism: invite-200ok-ack then what-so-ever SIPr equest
carrying the chunks, synchronized by cseq, then bye.
As explained before, using
CSeq for that is wrong. If I send you 4
in-dialog request (having my initial INVITE CSeq 1) these requests can
have:
1) CSeq: 2
2) CSeq: 33
3) CSeq: 1000
4) CSeq: 999999
And they are valid. If you (UAS) receive the third in-dialog request
with CSeq 1000 you have no way to know if the network has lost any
previous message(s) (after second request with CSeq 33) or not. CSeq
cannot be used to sync application data on top of the signalling
within a dialog.
Since you named some protocols, does XMPP use out
of band channels for IM?
No, but XMPP has the concept of IM session. SIP MESSAGE
has not.
MSRP is
the normal procedure for message sessions in SIP. SIP uses a
media stream for audio and video, using a new media stream for IM (and
file transfer) is the correct aproach (IMHO) and fits very well with
SIP protocol concept and existing deployments.
It fits with the concept of making
SIP network heavy and hard to manage, it
simply adds complexity for no real benefit. SIP has the capability to carry
payloads -- like IM is. If you don't want pager mode for IM, start a session
with INVITE, then send MESSAGEs and you are set. I do know
about MSRP implementations and they work very well. The
protocol itself (which I'm implementing right now
Here is a problem: you are
implementing it -- that means time and money, for
the SIP in-band the implementation requirements does not exist in the core
network and the endpoints have all the components already in place, so it
will be quite trivial (e.g.,session management with invite, sending sip
requests). ) is
quite easy (just
3 RFC's), it assumes NAT exists so defines MSRP relays (RFC 4976). I'm
also coding a MSRP relay server.
MSRP is the only good added value to SIP (IMHO).
Another point of failure is not
good at all, is very bad. There is
no SIP dialog for MESSAGE request, so record-route doesn't
apply. If it was exist, there should be needed a way to finish the
dialog (a BYE?, a MESSAGE with a custom header "Terminate-IM: yes"?).
MESSAGE requests are like individual SMS's in mobile world.
So you look to define
a new protocol instead of setting a constraint for a
specific case? For file transfer, clunking the content and
sending over several
requests
(again with minimum number of headers) with proper cseq incrementation
will
be a straightforward implementation.
I don't agree. You are mixing signalling
indicators (CSeq) que
application data indicators (message offset). Any CSeq greater than a
previous one is valid (even if it's 100 times greater). Think about 100 000 000 customers where you need
10 000 media relays, i
should add 10 000 IM relays? Good for vendors, they sell, bad for operations
and quality of service. Really, that's it, period.
If you have 100 000 000
customers you could also need 10 000 RtpProxy
servers. Different kind of media sessions (RTP is UDP while MSRP is
TLS) so different kind of relay servers. I don't see the difference.
Cheers.
7:41 p.m.
2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
you are simply on the wrong path in this discussion,
you kind of
misunderstand me.
First, I didn't know that SIP _MUST_ be over UDP only.
Sure not, I meant sending data (desktop sharing as Jitsi does) via RTP (UDP).
I would not like to send a ISO image using RTP ;)
For sure, hopefully SIP _MUST_ be over TCP or TLS ;)
Try to re-think a bit the whole thing. You come to me
with some examples
that are out of the purpose -- you try to demonstrate me that how SIP is
used now to do a voice call does not work for instant messaging session. You
are right, it doesn't, because that is for voice. But you can negotiate a
session that means exchange of MESSAGE requests (or if you like better a new
request type IM) within a dialog.
Yes, I agree. What you suggest could be really useful for _small_ data
transfer (just small text messages). But, would you send a big AVI
file (50 MB) over SIP signalling? Imagine the user splitts it in 50
fragments of 1 MB and each fragment is carried within a new in-dialog
MESSAGE (as you suggested, and assuming there is some application
protocol to control de order of the chunks).
I really wonder how good is for kamailio having to deal with message
bodies of 1MB (being kamailio a SIP proxy, so theorically something
ready for handling small messages). And also note that it supposes
very high network traffic sharing SIP messages. The spirit of separing
signalling and media is broken and, honestly, I don't like it even if
it "solves" or makes NAT handling easier (if so, let's use IAX rather
than SIP+RTP).
Further, you try to tell me that MESSAGE has no notion
of session, trying to
suggest that a new protocol (like MSRP) is a better approach than defining
the session for it (similar concept like for audio call dialog, preserve
call id, follow record routing). MSRP packets have headers like SIP, just a
bit fewer -- it is really bad design thinking of they could have reused sip
to specify IM sessions and file transfer.
Some points here:
1) MSRP is not so new (2007).
2) Your suggested new protocol would be newer than MSRP :)
Overall, maybe we have different understanding of
simplicity.
Well, IAX is much simpler than SIP, and IAX is basically the same you
are propossing (mixing signalling and media in the same stream). Do
you prefer IAX over SIP? :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:13 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
On 5/26/11 6:41 PM, Iñaki Baz Castillo wrote:
If you can tell me when I sad mixing RTP and SIP, it
would be nice.
Otherwise try to re-read what I said -- the whole thing here is about
chatting. And you cannot convince me in ages that MSRP is something
bringing any benefits -- just another ugly hack for something that could
have been solved very nicely with existing specs. Like SIMPLE for
presence, while end-to-end model was simpler and works even now with
kphone (implementation of year 2001) -- missing part there is
upload/download of buddy list to server, but I may want to store it in
dropbox, so not big loss with that.
Hope people will learn from recent experiences, Skype that was pure
end-to-end (im & presence) sold for billions -- simplicity sells very
well. People in SIP specs are trying to solve insignificant problems ...
due to end-to-end nature of presence and IM, how many were concerned
about battery life or bandwidth when running skype on mobile? How much
decreased those things the price? If it would have been SIMPLE + MSRP,
do you think the price would have been double?
I think we should be pragmatic and look at reality. New (useless)
components in network cost money and overhead in HA and scalability --
MSRP does that, period.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Desktop sharing is
streaming of screenshots taken with frequency like it
is video with images taken with a frequency from camera ...
you are simply on the wrong path in this
discussion, you kind of
misunderstand me.
First, I didn't know that SIP _MUST_ be over UDP only.
Sure not, I meant
sending data (desktop sharing as Jitsi does) via RTP (UDP). I would not like to send a ISO image using RTP ;)
That can be done with payload in sip messages. Again, you look only at a
side of the coin, the one that is wrong, but gives you some reason to
continue this debate -- I haven't said everything has to be RTP, so for
example I mentioned TCP.
For sure, hopefully SIP _MUST_ be over TCP or TLS ;)
This is your assumption. Besides that we talk
about negotiation of a
communication session, where parameter as agreed. The proxy can say in
some cases when something is too big or too low (see registration time).
Try to re-think a bit the whole thing. You come
to me with some examples
that are out of the purpose -- you try to demonstrate me that how SIP is
used now to do a voice call does not work for instant messaging session. You
are right, it doesn't, because that is for voice. But you can negotiate a
session that means exchange of MESSAGE requests (or if you like better a new
request type IM) within a dialog.
Yes, I agree. What you suggest could be really
useful for _small_ data
transfer (just small text messages). But, would you send a big AVI
file (50 MB) over SIP signalling? Imagine the user splitts it in 50
fragments of 1 MB and each fragment is carried within a new in-dialog
MESSAGE (as you suggested, and assuming there is some application
protocol to control de order of the chunks).
I really wonder how good is for kamailio having to deal with message
bodies of 1MB (being kamailio a SIP proxy, so theorically something
ready for handling small messages). And also note that it supposes
very high network traffic sharing SIP messages. The spirit of separing
signalling and media is broken and, honestly, I don't like it even if
it "solves" or makes NAT handling easier (if so, let's use IAX rather
than SIP+RTP).
I suggested a new
protocol? I have the impression that you read
different content -- it is SIP, nothing else, just properly applied for
particular cases. Can you answer why presence is not on a different
protocol (communication channel)? A presence document will all tags and
extensions can easily go to quite significant size.
RTP is very good for its purpose and should stay the same. But MSRP
really looks like a poor hack to solve with bigger complexity an easier
task.
You provide arguments I can't follow, jumping randomly -- so xmpp does
IM in 'signaling', it is good because has session idea defined there
(which is a simple concept as a 'string token' representing session id),
while same concept in SIP (which exists for voice dialogs) will create a
completely new protocol if applied for MESSAGE (let's not use MESSAGE,
let's use UPDATE since it has the notion of session an can carry any
kind body, is it better?).
You don't think that is bad in xmpp, but is bad in sip, because you
_believe_ kamailio is able to work with small buffers only (would it be
hard to increase them if needed? it will just relay, no understanding of
content).
Further, you try to tell me that MESSAGE has no
notion of session, trying to
suggest that a new protocol (like MSRP) is a better approach than defining
the session for it (similar concept like for audio call dialog, preserve
call id, follow record routing). MSRP packets have headers like SIP, just a
bit fewer -- it is really bad design thinking of they could have reused sip
to specify IM sessions and file transfer.
Some points here:
1) MSRP is not so new (2007).
2) Your suggested new protocol would be newer than MSRP :) Overall, maybe
we have different understanding of simplicity.
Well, IAX is much simpler than SIP,
and IAX is basically the same you
are propossing (mixing signalling and media in the same stream). Do
you prefer IAX over SIP? :)
27 May
27 May
12:41 a.m.
2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Just to confirm: when you say TCP, do you mean SIP over TCP/TLS and
message data of file data within SIP messages body? Or do you mean
something like "RTP over TCP" for binary data transmission? (I'm 90%
sure you mean the first option, just want to confirm it).
When an audio/video session is negotiated, the SIP proxy does not
validate/constrain the "size" of the media. By passing the media (as
you suggest) through the signaling, such traffic is not end-to-end
anymore and intermediary proxies with no very good bandwitch (or
messages size constrains) would stand in the media traffic.
Honestly I like the concept of "signalling through intermediaries and
media sessions end-to-end".
Ok, let me replace "new protocol" with "new spacefication" :)
Daniel, I could agree that using SIP message bodies for carrying IM
pure text/chat sessions could make sense, sure. But I don't think that
is also suitable for file transfer or any other kind of data. Even
less if we take into account that other IM protocols also use separate
streams for file transfer.
MSRP just unifies IM sessions and file transfer in a separate stream.
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
I would not
like to send a ISO image using RTP ;)
That can be done with payload in sip messages. Again, you look only at a
side of the coin, the one that is wrong, but gives you some reason to
continue this debate -- I haven't said everything has to be RTP, so for
example I mentioned TCP. I really
wonder how good is for kamailio having to deal with message
bodies of 1MB (being kamailio a SIP proxy, so theorically something
ready for handling small messages).
This is your assumption. Besides that we talk about negotiation of a
communication session, where parameter as agreed. The proxy can say in some
cases when something is too big or too low (see registration time). 1) MSRP is not
so new (2007).
2) Your suggested new protocol would be newer than MSRP :)
I suggested a new protocol? I have the impression that you read different
content -- it is SIP, nothing else, just properly applied for particular
cases. Can you answer why presence is not on a different
protocol
(communication channel)? A presence document will all tags and extensions
can easily go to quite significant size.
Well, if we take into consideration XCAP stuff then SIP presence is
indeed a new protocol. But anyway you already know what I think about
SIMPLE presence specs. They are an IETF bug in all the terms (design,
scalability...).
You provide arguments I can't follow, jumping
randomly -- so xmpp does IM in
'signaling', it is good because has session idea defined there (which is a
simple concept as a 'string token' representing session id),
Ok, I don't think XMPP is the very best protocol in the world. It
comes from many years ago (Jabber and so). I don't consider XMPP the
example to follow.
Maybe SIP is the first protocol separating signalling and IM in
different streams. Maybe this is not the easiest approach to deal with
NAT/firewalls issues, but I like this radical concept.
while same
concept in SIP (which exists for voice dialogs) will create a completely new
protocol if applied for MESSAGE (let's not use MESSAGE, let's use UPDATE
since it has the notion of session an can carry any kind body, is it
better?).
Right. I don't say that your approach is incorrect. In fact it seems
very suitable (but IMHO just for short text messages within a session,
not for file transfer).
You don't think that is bad in xmpp, but is bad in
sip, because you
_believe_ kamailio is able to work with small buffers only (would it be hard
to increase them if needed? it will just relay, no understanding of
content).
Doesn't XMPP use gateways for file transfer?:
XEP-0095: Stream Initiation
------------------------------------------
http://xmpp.org/extensions/xep-0095.html
As the Jabber protocols are extended beyond basic messaging and
presence, the need has arisen for a generic protocol that can be used
to negotiate content streams between any two entities. Such streams
might be in-band, but more likely will be out-of-band, binary streams
used in applications such as file transfer, voice chat, and video
conferencing. This document provides a method for negotiating such
streams, including meta-information about the intended usage of the
stream.
XEP-0096: SI File Transfer
---------------------------------------
http://xmpp.org/extensions/xep-0096.html
This specification defines a profile of the XMPP stream initiation
extension for transferring files between two entities. The protocol
provides a modular framework that enables the exchange of information
about the file to be transferred as well as the negotiation of
parameters such as the transport to be used.
If we take XMPP as an example, I think the above two XEP's seem more
similar to what MSRP defines.
Well, IAX is
much simpler than SIP, and IAX is basically the same you
are propossing (mixing signalling and media in the same stream). Do
you prefer IAX over SIP? :)
And you cannot convince me in ages that MSRP is something bringing
any benefits -- just another ugly hack for something that could have been
solved very nicely with existing specs.
1:25 a.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
On 5/26/11 11:41 PM, Iñaki Baz Castillo wrote:
When an
audio/video session is negotiated, the SIP proxy does not
validate/constrain the "size" of the media.
Amazing, you found an example and it is again about voice/video! You
believe that SIP is only for those kind of communications. Btw, maybe
you know that rtp proxy can do re-sampling to avoid congestion.
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Just to confirm: when you say TCP, do you mean SIP over
TCP/TLS and
message data of file data within SIP messages body? Or do you mean
something like "RTP over TCP" for binary data transmission? (I'm 90%
sure you mean the first option, just want to confirm it).
SIP over TCP with
payload.
I would
not like to send a ISO image using RTP ;)
That can be done with payload in sip
messages. Again, you look only at a
side of the coin, the one that is wrong, but gives you some reason to
continue this debate -- I haven't said everything has to be RTP, so for
example I mentioned TCP. I really wonder how good is for kamailio having to
deal with message
bodies of 1MB (being kamailio a SIP proxy, so theorically something
ready for handling small messages).
This is your assumption. Besides that we talk
about negotiation of a
communication session, where parameter as agreed. The proxy can say in some
cases when something is too big or too low (see registration time). By passing the media (as
you suggest) through the signaling, such traffic is not end-to-end
anymore and intermediary proxies with no very good bandwitch (or
messages size constrains) would stand in the media traffic.
By initial design, sip is an end-to-end communication model. Forget
about record routing and see how the requests are flowing within dialog.
Honestly I like the concept of "signalling
through intermediaries and
media sessions end-to-end".
What keeps me to have a session negotiation of MESSAGE requests to be
sent from point A to point B?
Again, I think you haven't understood my point. MSRP defines a new
protocol, that is barely different than SIP. From MSRP RFC, here is the
very basic example:
MSRP a786hjs2 SEND
To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Content-Type: text/plain
Hey Bob, are you there?
-------a786hjs2$
MSRP a786hjs2 200 OK
To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
-------a786hjs2$
What is the benefit over all, just a bit fewer headers, but more or less the same format
as SIP messages.
Maybe it saves a bit of bandwidth (hey there is SIP compession for that :-) ), but then
new points of failure
are added in the core network unnecessary. Such nodes need to keep states, if they crash
communication drops
(like with rtp relays). It is not the case with pure sip.
I just looked quickly to some of msrp rfcs, it is practically yet
another sip-like protocol: they defiles paths set for the case of
many msrp relays (would that be like record-routing mechanism -- don't
take it literally and come back to me saying r-r has
a different purpose for audio sessions), authentication with digest,
a.s.o. Really funny!!
I am more sure now that is really poor solution, no benefits, no
effective gain.
It is time to stop here with the discussion, you loop back with out of
the context examples and I don't think you got my idea: session is
negotiated with invite-200ok-ack. The content is carried via SIP
(end-to-end or relayed through intermediate node when necessary) and
session terminated with bye-200ok. Simple as that -- when relay is
necessary, a sip proxy can do really good job in terms of performances,
no need to reinvent the wheel and have different applications in the
network.
Cheers,
Daniel
[...]
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
2:50 a.m.
2011/5/27 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Perhaps I didn't explain well. I mean that, in the case of
audio/video, the proxy does not add constrain to the media
negotiation, neither it imposes limitations in the data size (as the
data is carried over a different transport, in this case RTP).
But what you are suggesting is that other kind of media (as IM or file
transfer) could share signalling stream. In the example of file
transfer carried within chunks in MESSAGE body, you said that the
proxy could mandate a minimum/maximun data size. So in this case the
proxy takes active part in such media transmission.
Below I reply yo your suggestion of non using record-routing.
So you propose pure SIP transport for carrying data arguing that is
makes NAT/firewall scenarios easy, and now you suggest not using
record-routing which is, in fact, the reason SIP (signalling) can work
even if both endpoints are behind NAT. IMHO we all know that
record-routing is a MUST in any real scenario.
NAT. And STUN/ICE doesn't help here as TCP/TLS is supossed to be used
to carry big data in SIP message bodies.
When an
audio/video session is negotiated, the SIP proxy does not
validate/constrain the "size" of the media.
Amazing, you found an example and it is again about voice/video! You believe
that SIP is only for those kind of communications. By passing
the media (as
you suggest) through the signaling, such traffic is not end-to-end
anymore and intermediary proxies with no very good bandwitch (or
messages size constrains) would stand in the media traffic.
By initial design, sip is an end-to-end communication model. Forget about
record routing and see how the requests are flowing within dialog. Honestly I
like the concept of "signalling through intermediaries and
media sessions end-to-end".
What keeps me to have a session negotiation of MESSAGE requests to be sent
from point A to point B? What is the benefit over all, just a bit fewer
headers, but more or less the
same format as SIP messages.
Maybe it saves a bit of bandwidth (hey there is SIP compession for that :-)
), but then new points of failure
are added in the core network unnecessary. Such nodes need to keep states,
if they crash communication drops
(like with rtp relays). It is not the case with pure sip.
Right, I agree. But I still think that media (I don't mean audio/video
now) should take a different path than the signalling. Name me radical
:)
I just looked quickly to some of msrp rfcs, it is
practically yet another
sip-like protocol: they defiles paths set for the case of
many msrp relays (would that be like record-routing mechanism -- don't take
it literally and come back to me saying r-r has
a different purpose for audio sessions), authentication with digest, a.s.o.
Really funny!!
I can agree that there is too much stuff in MSRP protocol, but IMHO
people defining it has learnt the leasson of RFC 3261 (too much
flexibility). MSRP is much more specific, it mandates TLS (yes or yes)
and covers NAT scenarios from the beggining. Of course, non
implementing MSRP is still easier than implementing it :)
It is time to stop here with the discussion, you loop
back with out of the
context examples and I don't think you got my idea: session is negotiated
with invite-200ok-ack. The content is carried via SIP (end-to-end or relayed
through intermediate node when necessary) and session terminated with
bye-200ok. Simple as that -- when relay is necessary, a sip proxy can do
really good job in terms of performances, no need to reinvent the wheel and
have different applications in the network.
I like discussions as they are the best way to learn from other people :)
Obviously we don't agree but I will have in mind your opinion.
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:19 a.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
On 5/27/11 1:50 AM, Iñaki Baz Castillo wrote:
[...]Below I reply yo your suggestion of non using
record-routing.
[...]
I like discussions as they are the best way to learn from other people :)
Inaki,
you come back mixing badly everything. I expected (and even
mentioned that in previous email) you will hit the record routing thing
to argue a irrelevantly, it is what you did - that was an example of a
mechanism (e.g., compared with *-Path), but you found something you
could reply to and show it related to voice calls. The proxy is not
allowed to interfere with negotiation of the session paramters, thank
you for reminding that, and we have calls going through NAT because of
following it.
I wonder if you really read to understand or just spot 'single concepts'
to make them out of the context in order to reply something. That is
endless and topic breaker.
You admit MSRP is very much SIP (**what I said, the whole point and
therefore I am done here** -- MSRP is _useless_, no value added), but,
for example, with TLS enforcement - thank you, we need another new
protocol for that because sounds cool -- big fail, imo (note that TLS is
not part of SIP structure, it is a transport layer).
You think too much of sip at it was specified for voice calls ("an use
case"), you cannot escape that thus you cannot see how flexible it is
and what one can do with it. Perhaps same did those coming up with a new
very large set of new protocols that try to exceed PSTN list of
terms/abbreviations. RFC3261 is mainly exemplified with how to use SIP
for voice calls, but not restricted to - forget the examples in the rfc,
look at protocol architecture. But, indeed, on the other hand, it is
also more cool to say 'I am author of a protocol" than of a
"specifications for an use case".
I saw a presentation of msrp years ago, I understood it does not worth a
penny, but I didn't want to debate that since I saved time not looking
deeper at it. Decision to obsolete it confirms that -- this does not
mean that the new one is better, it means the old one is rather useless.
To end the thread, just for your reference, here is a google result of
how windows messenger did session IM, 6 years ago:
http://www.tomshardware.co.uk/forum/95300-35-messenger-sends-receiving-invi…
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
9:57 a.m.
Hi,
can't we just accept, that there are two approaches here? I personally
agree with Daniel regarding the fact, that probably using SIP for this
seems the better approach... but that doesn't mean, that there
could/should not be other ways to solve this as well.
This mail thread reminds me a little of the usual typical Windows vs.
Linux discussions....
This discussion seems to me highly emotional.
Just my $0.02,
Carsten
2011/5/27 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
On 5/27/11 1:50 AM, Iñaki Baz Castillo wrote:
--
Carsten Bock
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Office +49 40 34927219
Fax +49 40 34927220
[...]Below I reply yo your suggestion of non using record-routing.
[...]
I like discussions as they are the best way to learn from other people :)
Inaki, you come back mixing badly everything. I expected (and even mentioned
that in previous email) you will hit the record routing thing to argue a
irrelevantly, it is what you did - that was an example of a mechanism (e.g.,
compared with *-Path), but you found something you could reply to and show
it related to voice calls. The proxy is not allowed to interfere with
negotiation of the session paramters, thank you for reminding that, and we
have calls going through NAT because of following it.
I wonder if you really read to understand or just spot 'single concepts' to
make them out of the context in order to reply something. That is endless
and topic breaker.
You admit MSRP is very much SIP (**what I said, the whole point and
therefore I am done here** -- MSRP is _useless_, no value added), but, for
example, with TLS enforcement - thank you, we need another new protocol for
that because sounds cool -- big fail, imo (note that TLS is not part of SIP
structure, it is a transport layer).
You think too much of sip at it was specified for voice calls ("an use
case"), you cannot escape that thus you cannot see how flexible it is and
what one can do with it. Perhaps same did those coming up with a new very
large set of new protocols that try to exceed PSTN list of
terms/abbreviations. RFC3261 is mainly exemplified with how to use SIP for
voice calls, but not restricted to - forget the examples in the rfc, look at
protocol architecture. But, indeed, on the other hand, it is also more cool
to say 'I am author of a protocol" than of a "specifications for an use
case".
I saw a presentation of msrp years ago, I understood it does not worth a
penny, but I didn't want to debate that since I saved time not looking
deeper at it. Decision to obsolete it confirms that -- this does not mean
that the new one is better, it means the old one is rather useless.
To end the thread, just for your reference, here is a google result of how
windows messenger did session IM, 6 years ago:
http://www.tomshardware.co.uk/forum/95300-35-messenger-sends-receiving-invi…
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:40 a.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
Hi,
hope it has not lost in translation an sounded tough, really no such
intention! I know Inaki is a "deep lover" of IETF :-), ready for heavy
fights and actually we are allies here, fighting against IETF way of
developing specs, but it happens to be from different directions this time.
I expressed that I am not crying after msrp, trying to show that sip has
the _potential_ to offer same functionality, avoiding a spaghetti of
protocols. Thus I consider MSRP a failure of IETF. Inaki fights IETF
not to add yet another protocol (slightly different version of msrp with
no big benefits compared with existing one).
Looking at HTTP, when they needed file upload, they added put/delete --
they stayed in the same protocol whenever possible. In this ways the
infrastructure nodes remain the same, only higher-level applications
have to be updated. When they needed asynchronous stuff (e.g., ajax)
they found the solution there, not a new spec. In IETF and SIP WGs is
different, like a race for new protocols, not re-use of existing ones.
Web does now more real-time communication methods better than SIP,
because IETF hasn't decided the infrastructure protocol for SIP-related
networks. Defining new request method types or headers is not a change
of the protocol. This is one of the powerful tools of SIP, IETF seemed
to forget that.
Cheers,
Daniel
On 5/27/11 8:57 AM, Carsten Bock wrote:
Hi,
can't we just accept, that there are two approaches here? I personally
agree with Daniel regarding the fact, that probably using SIP for this
seems the better approach... but that doesn't mean, that there
could/should not be other ways to solve this as well.
This mail thread reminds me a little of the usual typical Windows vs.
Linux discussions....
This discussion seems to me highly emotional.
Just my $0.02,
Carsten
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
11:50 a.m.
2011/5/27 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Looking at HTTP, when they needed file upload, they
added put/delete -- they
stayed in the same protocol whenever possible. In this ways the
infrastructure nodes remain the same, only higher-level applications have to
be updated. When they needed asynchronous stuff (e.g., ajax) they found the
solution there, not a new spec. In IETF and SIP WGs is different, like a
race for new protocols, not re-use of existing ones. Web does now more
real-time communication methods better than SIP, because IETF hasn't decided
the infrastructure protocol for SIP-related networks. Defining new request
method types or headers is not a change of the protocol. This is one of the
powerful tools of SIP, IETF seemed to forget that.
Just a comment: Realtime communications in HTTP is, today, a hack as
it requires long polling or ugly solutions as Comet (the HTTP 200 body
never ends so the server can send "realtime" data over the same 200
response body).
Now IETF is defining WebSocket protocol, which is a bidirectional TCP
stream between a browser (WebSocket client mainly implemented in
JavaScript) and a server. In this way we get _real_ realtime
communication. All the world is waiting for this to become a standard
for long time, so private solutions as Flash are not needed anymore in
order to implement an ugly chat in a web page.
But WebSocket is a _new_ protocol (even it is uses HTTP
request/response for websocket stream establishment). If fact it's the
same concept as MSRP but it _can_reuse por 80. Note however that HTTP
communications are not end-to-end since a client (webbrowser) just
talks to a server, there is no user-to-user communication through HTTP
proxies.
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:29 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
On 5/27/11 10:50 AM, Iñaki Baz Castillo wrote:
[...]
Just a comment: Realtime communications in HTTP is, today, a hack
Don't make me
give examples of services with web im/presence for tens
and hundreds of millions of users, they worth billions, a reality today.
How you call it, up to you.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
12:41 p.m.
2011/5/27 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Not all of us can replicate the infrastructure of Google. Google is
capable of serving a single IP and port for every person in the world
to connect it, and make it scalable.
There are hundres of web pages offering chat services within the web,
but just Gmail (and a few others) work decently. There is more that
just specifications and protocols in the Google warden ;)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Just a
comment: Realtime communications in HTTP is, today, a hack
Don't make me give examples of services with web im/presence for tens and
hundreds of millions of users, they worth billions, a reality today. How you
call it, up to you.
12:51 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
On 5/27/11 11:41 AM, Iñaki Baz Castillo wrote:
2011/5/27 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Not all of us can replicate the infrastructure of [...]
... to believe that with such beautiful and simple options like msrp,
no-matter-what-companies today prefer the hard/ugly way to just spend
lots of money...
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Just a
comment: Realtime communications in HTTP is, today, a hack
Don't make me give
examples of services with web im/presence for tens and
hundreds of millions of users, they worth billions, a reality today. How you
call it, up to you.
11:41 a.m.
2011/5/27 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
I wonder if you really read to understand or just spot
'single concepts' to
make them out of the context in order to reply something. That is endless
and topic breaker.
Hi Daniel, that is not my aim. Let me summarize (correct me if I
minunderstood something):
1) You argued that SIP protocol (I mean just signalling) is a very
good approach as it makes easy dealing with NAT/firewalls. Of course I
agree.
2) So based on 1) (and other reasons) you suggest IM and file transfer
traveling into SIP message bodies within a SIP dialog
(INVITE/200/ACK/MESSAGE/200/MESSAGE/200/BYE/200). It could make sense,
ok.
3) I exposed that IMHO it's not good that a proxy (SIP signalling)
should deal with 1MB size SIP messages (i.e. sending a big AVI file).
I don't mean the proxy is not capable of that. But IMHO its better not
to saturate the signalling path by transferring big files over it.
4) So you argue that proxies could avoid loose-routing, just take part
in the dialog establishement and then let endpoints to talk SIP
end-to-end (as RFC 3261 allows, of course). This would solve point 3).
I just said that point 4) breaks point 1). And I consider point 1) as
important as point 3), but both are mutually exclusive.
I just meant that. I'm not spotting single concepts to make a quick
reply (it's not my aim), I'm trying to see the whole picture here.
You think too much of sip at it was specified for
voice calls ("an use
case"), you cannot escape that thus you cannot see how flexible it is and
what one can do with it.
I dream every day with SIP for any purpose but just voice. I'm bored
with SIP + just RTP :)
Perhaps same did those coming up with a new very
large set of new protocols that try to exceed PSTN list of
terms/abbreviations. RFC3261 is mainly exemplified with how to use SIP for
voice calls, but not restricted to - forget the examples in the rfc, look at
protocol architecture. But, indeed, on the other hand, it is also more cool
to say 'I am author of a protocol" than of a "specifications for an use
case".
Of course I agree on that. But I think MSRP fits well here (SIP is
used for routing and session establishement and MSRP for application
data communication). And MSRP satisfies point 3) above, which is
important IMHO.
I understand you opinion pointing out that MSRP is too much a very new
protocol on top of SIP, which indeed could be indesirable. I'd also
would like an intermediate approach in which MSRP is used just for
data transmission (chunks over TCP/TLS) and SIP is still used within
the session, not just for sending a BYE at the end).
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:44 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
The debate from my point of view was the _architecture of the
protocols_: sip vs msrp -- read it to some extent like: structure of the
messages. You go very much to specifics on existing sip for voice --
like it is unimaginable to have some requests (for content of
communication) within a dialog following different path than INVITE and
BYE (or the requests that control the session) when it is more optimal.
I provided just leads to similar mechanisms, not the specs of how it
must be done. It is nothing I should argument, what you summarized it is
what you extracted/understood, but it is not what I meant it must be.
Cheers,
Daniel
On 5/27/11 10:41 AM, Iñaki Baz Castillo wrote:
2011/5/27 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
I wonder if you really read to understand or just
spot 'single concepts' to
make them out of the context in order to reply something. That is endless
and topic breaker.
Hi Daniel, that is not my aim.
26 May
26 May
4:02 p.m.
2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
The model is not really bringing benefits, is just
another fantasy.
Honestly I could think of just few restrictions/amendments/additions to the
base SIP RFC3261 and the next 10 following it to have very good and simple
model for im, presence, file transfer, desktop sharing a.s.o.
Anyhow, you know that I'm not contrary to drop an existing protocol
and making a new one if the existing specification is a pain ;)
But in this case I just think that MSRP is the way to go.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:46 p.m.
New subject: [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11
On 5/26/11 3:02 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
I am for re-using a good
protocol like SIP instead of keep pouring
fantasy and impractical architectures/mechanisms/protocols.
I expect the next one to be PSRP (Presence ...), since presence
documents can be long in near future...
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
The model is not really bringing benefits, is
just another fantasy.
Honestly I could think of just few restrictions/amendments/additions to the
base SIP RFC3261 and the next 10 following it to have very good and simple
model for im, presence, file transfer, desktop sharing a.s.o.
Anyhow, you know
that I'm not contrary to drop an existing protocol
and making a new one if the existing specification is a pain ;)
But in this case I just think that MSRP is the way to go.
4929
days inactive
4931
days old
23 comments
3 participants
participants (3)
-
Carsten Bock -
Daniel-Constantin Mierla -
Iñaki Baz Castillo