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-Compatib...
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
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-Compatib...
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
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:
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-Compatib...
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
2011/5/26 Daniel-Constantin Mierla miconda@gmail.com:
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.
2011/5/26 Iñaki Baz Castillo ibc@aliax.net:
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.
Hello,
On 5/26/11 12:19 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin Mierlamiconda@gmail.com:
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).
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.
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.
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).
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.
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,
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.
but that doesn't mean that using MESSAGE is the way to go.
2011/5/26 Daniel-Constantin Mierla miconda@gmail.com:
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.
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.
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.
Already justified that it is not suitable (IMHO).
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).
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?
) 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.
The very same as a RtpProxy server.
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).
So you look to define a new protocol instead of setting a constraint for a specific case?
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.
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.
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 Mierlamiconda@gmail.com:
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:
- Hello
- Daniel
- How
- 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.
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.
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:
- CSeq: 2
- CSeq: 33
- CSeq: 1000
- 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.
Already justified that it is not suitable (IMHO).
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).
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?
) 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.
The very same as a RtpProxy server.
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).
So you look to define a new protocol instead of setting a constraint for a specific case?
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.
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.
2011/5/26 Daniel-Constantin Mierla miconda@gmail.com:
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? :)
On 5/26/11 6:41 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin Mierlamiconda@gmail.com:
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).
Desktop sharing is streaming of screenshots taken with frequency like it is video with images taken with a frequency from camera ...
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 ;)
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).
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).
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:
- MSRP is not so new (2007).
- 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.
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).
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? :)
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
2011/5/26 Daniel-Constantin Mierla miconda@gmail.com:
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.
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).
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).
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".
- MSRP is not so new (2007).
- 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.
Ok, let me replace "new protocol" with "new spacefication" :)
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.
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.
On 5/26/11 11:41 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin Mierlamiconda@gmail.com:
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.
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 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).
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.
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
[...]
2011/5/27 Daniel-Constantin Mierla miconda@gmail.com:
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.
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.
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.
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.
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?
NAT. And STUN/ICE doesn't help here as TCP/TLS is supossed to be used to carry big data in SIP message bodies.
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.
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-invit...
Cheers, Daniel
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@gmail.com:
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-invit...
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
2011/5/27 Daniel-Constantin Mierla miconda@gmail.com:
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.
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
2011/5/27 Daniel-Constantin Mierla miconda@gmail.com:
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.
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 ;)
On 5/27/11 11:41 AM, Iñaki Baz Castillo wrote:
2011/5/27 Daniel-Constantin Mierlamiconda@gmail.com:
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.
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
2011/5/27 Daniel-Constantin Mierla miconda@gmail.com:
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.
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 Mierlamiconda@gmail.com:
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.
2011/5/26 Daniel-Constantin Mierla miconda@gmail.com:
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.
On 5/26/11 3:02 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin Mierlamiconda@gmail.com:
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.
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
-
Carsten Bock -
Daniel-Constantin Mierla -
Iñaki Baz Castillo