Re: [Sip-implementors] SIP phone with SCTP support
On 08/03/07 15:19, Daniel Corbe wrote: I want to completely replace my SBCs with OpenSER boxes :) I don't need them, I don't like SBCs, but others do, and indeed, I understand that they can provide some protection of your internal network. other than the fact that they provide me with a bit of fail over and redundancy with regards to media streams and call state if I ever happen to lose an entire box for some reason. Oddly enough that seems to happen often with my SBCs (go figure) and hasn't happened once yet with my registrars (my OpenSER boxes) OpenSER it just fine at doing everything else. Glad to hear that. However, back to the subject, seems that there is no much of experience with SIP and SCTP out there. Maybe over the time will show up some end-user devices with support for SCTP, it is not at all something difficult. Daniel -Daniel On Aug 3, 2007, at 6:45 AM, Daniel-Constantin Mierla wrote: On 08/03/07 12:38, Daniel Corbe wrote: See below. -Daniel On Aug 3, 2007, at 5:04 AM, Daniel-Constantin Mierla wrote: On 08/02/07 20:04, Daniel Corbe wrote: Out of curiosity are you affiliated with the OpenSER project? yes, I am, very deep involved actually, from its beginning. If so does OpenSER support SCTP? It does, since few days ago. It came as a contribution from Connecticut College, I reviewed and integrated in OpenSER and did the initial testings. Is that why you need a phone that runs over SCTP? Yes. In fact, other SIP entity with SCTP support is fine (of course, at a low cost). I would like to test with other implementation, you know, interoperability in VoIP/SIP was all the time a pain in the ... What's the purpose if you have other more reliable transport mechanisms for SIP such as TCP? TCP brings a lot of overhead, it is one-to-one communication model, while with SCTP you get one to many, as with UDP. For SIP servers able to support large number of online subscribers, TCP reduce the capacity a lot. Also, for NAT, TCP is problematic if the phone does not maintain the connection open, it is basically impossible to open the connection from server side. The problem I see with UDP is fragmentation and encryption. SCTP and TLS-SCTP overcome them. We face now big SIP messages, especially in IMPresence extensions. There's many differing opinions on this issue. With things like kqueue() and epoll() you can easily squeeze 50k or more simultaneous connections onto a single server and have plenty of processing power left over for things like TLS. More often than not its the higher layers which are the bottleneck. you are right, *poll methods increased a lot the TCP capacity. However, for a load balancer or traffic dispatcher working with TCP is a killer. The LB should be able to deal with more than 50k sessions. I do not know SCTP performances, it is first time I actually worked with, but from design seems to be a good choice. It is what I try to learn and why I am asking opinions here. I don't know how well SCTP performs under these sorts of loads but if it performs better than TCP while providing some connection-oriented services that UDP doesn't, more power to you. From my chair here; though, SCTP would have to support bindings into the 100K range per box or more before I would consider it a viable option over UDP. One other thing that it is not clear for me, is the NAT traversal, haven't seen many SOHO routers advertising SCTP in product sheet, so there might be other issues arising when using SCTP at this time. Working on increasing the capacity of your service alone does little good because then it becomes a gigantic single point of failure. I would like to see more open source projects like OpenSER support full signaling state redundancy between two boxes. Only then would I ever consider shoving 100k bindings onto a single registrar. There are different aspects and cases when the capacity matters. Nobody (I hope) goes with hosting on single hardware huge number of subscribers, there are solutions for replication and fail over. However, we don't discuss that here, load balancers, dispatchers, SBCs need to be able to deal with far more many connections at same time than a registrar. Daniel AFAIK the only thing in heavy deployment in telephony that uses SCTP is SIGTRAN and family. OK, so, then here is another question, do you think that SCTP won't make it to the end devices (e.g., phones)? I try not to make predictions because I'm wrong more than I'm right. Cheers, Daniel -DAniel On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: Hello, I couldn't find much about SIP phones with SCTP support. Are you aware of any? OpenSER introduced support for SCTP and for testing it was used: [udp] [udp] openser [sctp] [sctp] openser [udp] [udp] But using against other devices is really the
Re: [Sip-implementors] SIP phone with SCTP support
On 08/03/07 12:38, Daniel Corbe wrote: See below. -Daniel On Aug 3, 2007, at 5:04 AM, Daniel-Constantin Mierla wrote: On 08/02/07 20:04, Daniel Corbe wrote: Out of curiosity are you affiliated with the OpenSER project? yes, I am, very deep involved actually, from its beginning. If so does OpenSER support SCTP? It does, since few days ago. It came as a contribution from Connecticut College, I reviewed and integrated in OpenSER and did the initial testings. Is that why you need a phone that runs over SCTP? Yes. In fact, other SIP entity with SCTP support is fine (of course, at a low cost). I would like to test with other implementation, you know, interoperability in VoIP/SIP was all the time a pain in the ... What's the purpose if you have other more reliable transport mechanisms for SIP such as TCP? TCP brings a lot of overhead, it is one-to-one communication model, while with SCTP you get one to many, as with UDP. For SIP servers able to support large number of online subscribers, TCP reduce the capacity a lot. Also, for NAT, TCP is problematic if the phone does not maintain the connection open, it is basically impossible to open the connection from server side. The problem I see with UDP is fragmentation and encryption. SCTP and TLS-SCTP overcome them. We face now big SIP messages, especially in IMPresence extensions. There's many differing opinions on this issue. With things like kqueue() and epoll() you can easily squeeze 50k or more simultaneous connections onto a single server and have plenty of processing power left over for things like TLS. More often than not its the higher layers which are the bottleneck. you are right, *poll methods increased a lot the TCP capacity. However, for a load balancer or traffic dispatcher working with TCP is a killer. The LB should be able to deal with more than 50k sessions. I do not know SCTP performances, it is first time I actually worked with, but from design seems to be a good choice. It is what I try to learn and why I am asking opinions here. I don't know how well SCTP performs under these sorts of loads but if it performs better than TCP while providing some connection-oriented services that UDP doesn't, more power to you. From my chair here; though, SCTP would have to support bindings into the 100K range per box or more before I would consider it a viable option over UDP. One other thing that it is not clear for me, is the NAT traversal, haven't seen many SOHO routers advertising SCTP in product sheet, so there might be other issues arising when using SCTP at this time. Working on increasing the capacity of your service alone does little good because then it becomes a gigantic single point of failure. I would like to see more open source projects like OpenSER support full signaling state redundancy between two boxes. Only then would I ever consider shoving 100k bindings onto a single registrar. There are different aspects and cases when the capacity matters. Nobody (I hope) goes with hosting on single hardware huge number of subscribers, there are solutions for replication and fail over. However, we don't discuss that here, load balancers, dispatchers, SBCs need to be able to deal with far more many connections at same time than a registrar. Daniel AFAIK the only thing in heavy deployment in telephony that uses SCTP is SIGTRAN and family. OK, so, then here is another question, do you think that SCTP won't make it to the end devices (e.g., phones)? I try not to make predictions because I'm wrong more than I'm right. Cheers, Daniel -DAniel On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: Hello, I couldn't find much about SIP phones with SCTP support. Are you aware of any? OpenSER introduced support for SCTP and for testing it was used: [udp] [udp] openser [sctp] [sctp] openser [udp] [udp] But using against other devices is really the challenge. I found some references to a modified KPhone version, but no luck to get it. Thanks, Daniel -- http://www.openser.org ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further dissemination, or copying of this email is prohibited unless authorized by the sender. This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further
Re: [Sip-implementors] SIP phone with SCTP support
On 08/02/07 20:04, Daniel Corbe wrote: Out of curiosity are you affiliated with the OpenSER project? yes, I am, very deep involved actually, from its beginning. If so does OpenSER support SCTP? It does, since few days ago. It came as a contribution from Connecticut College, I reviewed and integrated in OpenSER and did the initial testings. Is that why you need a phone that runs over SCTP? Yes. In fact, other SIP entity with SCTP support is fine (of course, at a low cost). I would like to test with other implementation, you know, interoperability in VoIP/SIP was all the time a pain in the ... What's the purpose if you have other more reliable transport mechanisms for SIP such as TCP? TCP brings a lot of overhead, it is one-to-one communication model, while with SCTP you get one to many, as with UDP. For SIP servers able to support large number of online subscribers, TCP reduce the capacity a lot. Also, for NAT, TCP is problematic if the phone does not maintain the connection open, it is basically impossible to open the connection from server side. The problem I see with UDP is fragmentation and encryption. SCTP and TLS-SCTP overcome them. We face now big SIP messages, especially in IMPresence extensions. AFAIK the only thing in heavy deployment in telephony that uses SCTP is SIGTRAN and family. OK, so, then here is another question, do you think that SCTP won't make it to the end devices (e.g., phones)? Cheers, Daniel -DAniel On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: Hello, I couldn't find much about SIP phones with SCTP support. Are you aware of any? OpenSER introduced support for SCTP and for testing it was used: [udp] [udp] openser [sctp] [sctp] openser [udp] [udp] But using against other devices is really the challenge. I found some references to a modified KPhone version, but no luck to get it. Thanks, Daniel -- http://www.openser.org ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further dissemination, or copying of this email is prohibited unless authorized by the sender. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP phone with SCTP support
See below. -Daniel On Aug 3, 2007, at 5:04 AM, Daniel-Constantin Mierla wrote: On 08/02/07 20:04, Daniel Corbe wrote: Out of curiosity are you affiliated with the OpenSER project? yes, I am, very deep involved actually, from its beginning. If so does OpenSER support SCTP? It does, since few days ago. It came as a contribution from Connecticut College, I reviewed and integrated in OpenSER and did the initial testings. Is that why you need a phone that runs over SCTP? Yes. In fact, other SIP entity with SCTP support is fine (of course, at a low cost). I would like to test with other implementation, you know, interoperability in VoIP/SIP was all the time a pain in the ... What's the purpose if you have other more reliable transport mechanisms for SIP such as TCP? TCP brings a lot of overhead, it is one-to-one communication model, while with SCTP you get one to many, as with UDP. For SIP servers able to support large number of online subscribers, TCP reduce the capacity a lot. Also, for NAT, TCP is problematic if the phone does not maintain the connection open, it is basically impossible to open the connection from server side. The problem I see with UDP is fragmentation and encryption. SCTP and TLS-SCTP overcome them. We face now big SIP messages, especially in IMPresence extensions. There's many differing opinions on this issue. With things like kqueue() and epoll() you can easily squeeze 50k or more simultaneous connections onto a single server and have plenty of processing power left over for things like TLS. More often than not its the higher layers which are the bottleneck. I don't know how well SCTP performs under these sorts of loads but if it performs better than TCP while providing some connection-oriented services that UDP doesn't, more power to you. From my chair here; though, SCTP would have to support bindings into the 100K range per box or more before I would consider it a viable option over UDP. Working on increasing the capacity of your service alone does little good because then it becomes a gigantic single point of failure. I would like to see more open source projects like OpenSER support full signaling state redundancy between two boxes. Only then would I ever consider shoving 100k bindings onto a single registrar. AFAIK the only thing in heavy deployment in telephony that uses SCTP is SIGTRAN and family. OK, so, then here is another question, do you think that SCTP won't make it to the end devices (e.g., phones)? I try not to make predictions because I'm wrong more than I'm right. Cheers, Daniel -DAniel On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: Hello, I couldn't find much about SIP phones with SCTP support. Are you aware of any? OpenSER introduced support for SCTP and for testing it was used: [udp] [udp] openser [sctp] [sctp] openser [udp] [udp] But using against other devices is really the challenge. I found some references to a modified KPhone version, but no luck to get it. Thanks, Daniel -- http://www.openser.org ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further dissemination, or copying of this email is prohibited unless authorized by the sender. This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further dissemination, or copying of this email is prohibited unless authorized by the sender. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP phone with SCTP support
Viable over TCP rather than UDP considering the need for TLS support, that is. -Daniel On Aug 3, 2007, at 5:38 AM, Daniel Corbe wrote: See below. -Daniel On Aug 3, 2007, at 5:04 AM, Daniel-Constantin Mierla wrote: On 08/02/07 20:04, Daniel Corbe wrote: Out of curiosity are you affiliated with the OpenSER project? yes, I am, very deep involved actually, from its beginning. If so does OpenSER support SCTP? It does, since few days ago. It came as a contribution from Connecticut College, I reviewed and integrated in OpenSER and did the initial testings. Is that why you need a phone that runs over SCTP? Yes. In fact, other SIP entity with SCTP support is fine (of course, at a low cost). I would like to test with other implementation, you know, interoperability in VoIP/SIP was all the time a pain in the ... What's the purpose if you have other more reliable transport mechanisms for SIP such as TCP? TCP brings a lot of overhead, it is one-to-one communication model, while with SCTP you get one to many, as with UDP. For SIP servers able to support large number of online subscribers, TCP reduce the capacity a lot. Also, for NAT, TCP is problematic if the phone does not maintain the connection open, it is basically impossible to open the connection from server side. The problem I see with UDP is fragmentation and encryption. SCTP and TLS-SCTP overcome them. We face now big SIP messages, especially in IMPresence extensions. There's many differing opinions on this issue. With things like kqueue() and epoll() you can easily squeeze 50k or more simultaneous connections onto a single server and have plenty of processing power left over for things like TLS. More often than not its the higher layers which are the bottleneck. I don't know how well SCTP performs under these sorts of loads but if it performs better than TCP while providing some connection- oriented services that UDP doesn't, more power to you. From my chair here; though, SCTP would have to support bindings into the 100K range per box or more before I would consider it a viable option over UDP. Working on increasing the capacity of your service alone does little good because then it becomes a gigantic single point of failure. I would like to see more open source projects like OpenSER support full signaling state redundancy between two boxes. Only then would I ever consider shoving 100k bindings onto a single registrar. AFAIK the only thing in heavy deployment in telephony that uses SCTP is SIGTRAN and family. OK, so, then here is another question, do you think that SCTP won't make it to the end devices (e.g., phones)? I try not to make predictions because I'm wrong more than I'm right. Cheers, Daniel -DAniel On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: Hello, I couldn't find much about SIP phones with SCTP support. Are you aware of any? OpenSER introduced support for SCTP and for testing it was used: [udp] [udp] openser [sctp] [sctp] openser [udp] [udp] But using against other devices is really the challenge. I found some references to a modified KPhone version, but no luck to get it. Thanks, Daniel -- http://www.openser.org ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further dissemination, or copying of this email is prohibited unless authorized by the sender. This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further dissemination, or copying of this email is prohibited unless authorized by the sender. This e-mail (including attached documents) may contain confidential or proprietary information intended only for use by the named recipient(s). Use by persons other than the named recipient(s), further dissemination, or copying of this email is prohibited unless authorized by the sender. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP phone with SCTP support
I want to completely replace my SBCs with OpenSER boxes :) I don't need them, other than the fact that they provide me with a bit of fail over and redundancy with regards to media streams and call state if I ever happen to lose an entire box for some reason. Oddly enough that seems to happen often with my SBCs (go figure) and hasn't happened once yet with my registrars (my OpenSER boxes) OpenSER it just fine at doing everything else. -Daniel On Aug 3, 2007, at 6:45 AM, Daniel-Constantin Mierla wrote: On 08/03/07 12:38, Daniel Corbe wrote: See below. -Daniel On Aug 3, 2007, at 5:04 AM, Daniel-Constantin Mierla wrote: On 08/02/07 20:04, Daniel Corbe wrote: Out of curiosity are you affiliated with the OpenSER project? yes, I am, very deep involved actually, from its beginning. If so does OpenSER support SCTP? It does, since few days ago. It came as a contribution from Connecticut College, I reviewed and integrated in OpenSER and did the initial testings. Is that why you need a phone that runs over SCTP? Yes. In fact, other SIP entity with SCTP support is fine (of course, at a low cost). I would like to test with other implementation, you know, interoperability in VoIP/SIP was all the time a pain in the ... What's the purpose if you have other more reliable transport mechanisms for SIP such as TCP? TCP brings a lot of overhead, it is one-to-one communication model, while with SCTP you get one to many, as with UDP. For SIP servers able to support large number of online subscribers, TCP reduce the capacity a lot. Also, for NAT, TCP is problematic if the phone does not maintain the connection open, it is basically impossible to open the connection from server side. The problem I see with UDP is fragmentation and encryption. SCTP and TLS-SCTP overcome them. We face now big SIP messages, especially in IMPresence extensions. There's many differing opinions on this issue. With things like kqueue() and epoll() you can easily squeeze 50k or more simultaneous connections onto a single server and have plenty of processing power left over for things like TLS. More often than not its the higher layers which are the bottleneck. you are right, *poll methods increased a lot the TCP capacity. However, for a load balancer or traffic dispatcher working with TCP is a killer. The LB should be able to deal with more than 50k sessions. I do not know SCTP performances, it is first time I actually worked with, but from design seems to be a good choice. It is what I try to learn and why I am asking opinions here. I don't know how well SCTP performs under these sorts of loads but if it performs better than TCP while providing some connection- oriented services that UDP doesn't, more power to you. From my chair here; though, SCTP would have to support bindings into the 100K range per box or more before I would consider it a viable option over UDP. One other thing that it is not clear for me, is the NAT traversal, haven't seen many SOHO routers advertising SCTP in product sheet, so there might be other issues arising when using SCTP at this time. Working on increasing the capacity of your service alone does little good because then it becomes a gigantic single point of failure. I would like to see more open source projects like OpenSER support full signaling state redundancy between two boxes. Only then would I ever consider shoving 100k bindings onto a single registrar. There are different aspects and cases when the capacity matters. Nobody (I hope) goes with hosting on single hardware huge number of subscribers, there are solutions for replication and fail over. However, we don't discuss that here, load balancers, dispatchers, SBCs need to be able to deal with far more many connections at same time than a registrar. Daniel AFAIK the only thing in heavy deployment in telephony that uses SCTP is SIGTRAN and family. OK, so, then here is another question, do you think that SCTP won't make it to the end devices (e.g., phones)? I try not to make predictions because I'm wrong more than I'm right. Cheers, Daniel -DAniel On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: Hello, I couldn't find much about SIP phones with SCTP support. Are you aware of any? OpenSER introduced support for SCTP and for testing it was used: [udp] [udp] openser [sctp] [sctp] openser [udp] [udp] But using against other devices is really the challenge. I found some references to a modified KPhone version, but no luck to get it. Thanks, Daniel -- http://www.openser.org ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP phone with SCTP support
Can anyone tell me if the Nortel CS1000E PBX supports the SIP version of RFC3261. It is for SIP Trunking. Joseph F Muggeo Project Manager Leaden Associates, Inc Office 845-496-6677 Cell 917-841-1810 Fax845-496-6144 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Corbe Sent: Friday, August 03, 2007 8:20 AM To: [EMAIL PROTECTED] Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SIP phone with SCTP support I want to completely replace my SBCs with OpenSER boxes :) I don't need them, other than the fact that they provide me with a bit of fail over and redundancy with regards to media streams and call state if I ever happen to lose an entire box for some reason. Oddly enough that seems to happen often with my SBCs (go figure) and hasn't happened once yet with my registrars (my OpenSER boxes) OpenSER it just fine at doing everything else. -Daniel On Aug 3, 2007, at 6:45 AM, Daniel-Constantin Mierla wrote: On 08/03/07 12:38, Daniel Corbe wrote: See below. -Daniel On Aug 3, 2007, at 5:04 AM, Daniel-Constantin Mierla wrote: On 08/02/07 20:04, Daniel Corbe wrote: Out of curiosity are you affiliated with the OpenSER project? yes, I am, very deep involved actually, from its beginning. If so does OpenSER support SCTP? It does, since few days ago. It came as a contribution from Connecticut College, I reviewed and integrated in OpenSER and did the initial testings. Is that why you need a phone that runs over SCTP? Yes. In fact, other SIP entity with SCTP support is fine (of course, at a low cost). I would like to test with other implementation, you know, interoperability in VoIP/SIP was all the time a pain in the ... What's the purpose if you have other more reliable transport mechanisms for SIP such as TCP? TCP brings a lot of overhead, it is one-to-one communication model, while with SCTP you get one to many, as with UDP. For SIP servers able to support large number of online subscribers, TCP reduce the capacity a lot. Also, for NAT, TCP is problematic if the phone does not maintain the connection open, it is basically impossible to open the connection from server side. The problem I see with UDP is fragmentation and encryption. SCTP and TLS-SCTP overcome them. We face now big SIP messages, especially in IMPresence extensions. There's many differing opinions on this issue. With things like kqueue() and epoll() you can easily squeeze 50k or more simultaneous connections onto a single server and have plenty of processing power left over for things like TLS. More often than not its the higher layers which are the bottleneck. you are right, *poll methods increased a lot the TCP capacity. However, for a load balancer or traffic dispatcher working with TCP is a killer. The LB should be able to deal with more than 50k sessions. I do not know SCTP performances, it is first time I actually worked with, but from design seems to be a good choice. It is what I try to learn and why I am asking opinions here. I don't know how well SCTP performs under these sorts of loads but if it performs better than TCP while providing some connection- oriented services that UDP doesn't, more power to you. From my chair here; though, SCTP would have to support bindings into the 100K range per box or more before I would consider it a viable option over UDP. One other thing that it is not clear for me, is the NAT traversal, haven't seen many SOHO routers advertising SCTP in product sheet, so there might be other issues arising when using SCTP at this time. Working on increasing the capacity of your service alone does little good because then it becomes a gigantic single point of failure. I would like to see more open source projects like OpenSER support full signaling state redundancy between two boxes. Only then would I ever consider shoving 100k bindings onto a single registrar. There are different aspects and cases when the capacity matters. Nobody (I hope) goes with hosting on single hardware huge number of subscribers, there are solutions for replication and fail over. However, we don't discuss that here, load balancers, dispatchers, SBCs need to be able to deal with far more many connections at same time than a registrar. Daniel AFAIK the only thing in heavy deployment in telephony that uses SCTP is SIGTRAN and family. OK, so, then here is another question, do you think that SCTP won't make it to the end devices (e.g., phones)? I try not to make predictions because I'm wrong more than I'm right. Cheers, Daniel -DAniel On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: Hello, I couldn't find much about SIP phones with SCTP support. Are you aware of any? OpenSER introduced support for SCTP and for testing it was used: [udp] [udp] openser [sctp] [sctp] openser [udp]
Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Can you also attach the original INVITE call flow along with re-INVITE? That can help to compare the SDP versions, CSeq etc. Also, if everything turns out to be OK, then there may be some policy (private) based on which it might be rejecting! Somesh [EMAIL PROTECTED] wrote: Hi, I'm havin a problem sending a re-invite message to change the current SDP-Session. The Reinvite itsself causes the receiver to generate an OK message with its SDP. But after receiving the following Request ACK it just generates a BYE and ends. Does anyone see the problem? Is the Reinvite correct? Are the CSeqs ok? many thanks in advance!! Andreas packet capture: [RE-INVITE:] Session Initiation Protocol Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Message Header Record-Route: Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.0 Via: SIP/2.0/UDP 134.2.172.238;rport=22000;branch=z9hG4bKfzzdcjdi Max-Forwards: 69 To: ;tag=dyyrq From: ;tag=dochj Call-ID: [EMAIL PROTECTED] CSeq: 996 INVITE Sequence Number: 996 Method: INVITE Contact: Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO Supported: replaces,norefersub,100rel User-Agent: Twinkle/1.0 Content-Length: 305 P-hint: usrloc applied Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 100 295838384 725581350 IN IP4 134.2.172.238 Owner Username: 100 Session ID: 295838384 Session Version: 725581350 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 134.2.172.238 Session Name (s): - Connection Information (c): IN IP4 134.2.172.238 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 134.2.172.238 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8000 RTP/AVP 3 98 97 8 0 101 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute (a): * [OK, WITH SESSION DESCRIPTION] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.0,SIP/2.0/UDP 134.2.172.238;rport=22000;branch=z9hG4bKfzzdcjdi To: ;tag=dyyrq From: ;tag=dochj Call-ID: [EMAIL PROTECTED] CSeq: 996 INVITE Sequence Number: 996 Method: INVITE Contact: Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO Server: Twinkle/1.0 Supported: replaces,norefersub Content-Length: 304 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 101 1577192660 821447339 IN IP4 134.2.173.47 Owner Username: 101 Session ID: 1577192660 Session Version: 821447339 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 134.2.173.47 Session Name (s): - Connection Information (c): IN IP4 134.2.173.47 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 134.2.173.47 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8002 RTP/AVP 98 97 8 0 3 101 Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute (a): ptime:20 * [ACK]: Session Initiation Protocol Request-Line: ACK sip:[EMAIL PROTECTED] SIP/2.0 Message Header Record-Route: Via: SIP/2.0/UDP 134.2.172.241;branch=z9hG4bK61c8.85631495.2 Via: SIP/2.0/UDP
Re: [Sip-implementors] Authentication
I've checked on debug, the parameter values are the same on SIP Communicator
authentication:
//algorithm = MD5
//username_value = aryjunior
//realm_value = asterisk
//passwd = mypass
//nonce_value = 0fceb3ee
//nc_value = null
//cnonce_value = null
//method = REGISTER
//digest_uri_value = sip:localhost;transport=udp
//entity_body =
//qop_value = null
And on my UAC authentication:
//algorithm = MD5
//username_value = aryjunior
//realm_value = asterisk
//passwd = mypass
//nonce_value = 18e7217e
//nc_value = null
//cnonce_value = null
//method = REGISTER
//digest_uri_value = sip:localhost;transport=udp
//entity_body =
//qop_value = null
Except by the nonce value... the nonce value for my UAC returned by the
server on the first 404 response is no valid for timeout? I get the value
from the SipListener.processResponse(ResponseEvent responseEvent), by:
...
ClientTransaction clientTransaction =
responseEvent.getClientTransaction();
Response responseClone = (Response)response.clone();
...
ListIterator authHeaders = responseClone.getHeaders(
WWWAuthenticateHeader.NAME);
...
WWWAuthenticateHeader authHeader = null;
while (authHeaders.hasNext()) {
authHeader = (WWWAuthenticateHeader) authHeaders.next();
String realm = authHeader.getRealm();
System.out.println(Autenticando em +realm+ !!!);
}
...
authorization.setNonce(authHeader.getNonce());
...
String responseStr =
MessageDigestAlgorithm.calculateResponse(
authHeader.getAlgorithm (),
user.getUsername(),
authHeader.getRealm(),
user.getPassword(),
authHeader.getNonce(),
//TODO we should one day implement those two null-s
null, //nc-value
null, //cnonce
requestClone.getMethod(),
sip:localhost;transport=udp,
//requestClone.getRequestURI().toString(),
,
authHeader.getQop());
authorization.setResponse(responseStr);
...
And I'm sending a lite log file with the messages generated by the client
and the asterisk server... Thanks very much!!!
On 8/3/07, Pascal Maugeri [EMAIL PROTECTED] wrote:
What are the parameter values your're passing to calculateResponse() ?
I guess you know already: http://www.ietf.org/rfc/rfc2617.txt ?
-pascal
On 8/3/07, Ary Junior [EMAIL PROTECTED] wrote:
Hi, Im trying to trace the SIP Communicator code for write my own User
Agent
Client... using the same method MessageDigestAlgorithm.calculateResponse
(...)
I cant receive the Response.OK message, I ever receive the
Response.UNAUTHORIZED...
inspecting the response string generated by the MD5 algorithm, I see
that
the strings generated by SIP Communicator and my UAC are differents:
uri=sip:localhost;transport=udp,realm=asterisk,username=aryjunior,nonce=6ba75dcd,algorithm=MD5,response=9a8c664331efbe3836102c662ef133e4
uri=sip:localhost;transport=udp,realm=asterisk,username=aryjunior,nonce=426e4388,algorithm=MD5,response=145dcd605d5a9543ed76c402e2fe6192
The response string depends the value thath authHeader.getNonce() method
returns, then I replaced this value by any string and I get the same
string:
uri=sip:localhost;transport=udp,realm=asterisk,username=aryjunior,nonce=76687542,algorithm=MD5,response=241ee7aca9cb45fdc6489e6b8b88a3fd
uri=sip:localhost;transport=udp,realm=asterisk,username=aryjunior,nonce=6cae08bf,algorithm=MD5,response=241ee7aca9cb45fdc6489e6b8b88a3fd
In this situation, naturally, both UACs cant login... any suggestion?
Thanks very much!!!
--
-
Ary Junior
Sun Certified Java Programmer - SCJP 1.4
Site: http://www.powerline.com.br/~aryjr/aryjr/
-
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
--
-
Ary Junior
Sun Certified Java Programmer - SCJP 1.4
Site: http://www.powerline.com.br/~aryjr/aryjr/
-
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
