Hello,
Klaus, Jan, thank you very much for your answers. Below is the list of RFCs I'm interested in. As Klaus says, maybe some of them don't need explicit support, because ser can route these new messages. Or maybe there are RFCs that are not fully supported. Please, let me know if this is the case and if it could be necessary writting a new module or changing SER core.
By the way, can SER initiate a session release (it means, generate a BYE) or generate a REGISTER to an application server? If not, what would be necessary from your point of view?
Again, thank you very much for your time and knowledge. I know that there are a lot of questions in this message, so thank you.
Curro
(These five RFCs are related to new messages, so I suppose Yes) RFC 2976 (October 2000): "The SIP INFO method".
RFC 3262 (June 2002): "Reliability of provisional responses in Session Initiation Protocol (SIP)". (can SER generate PRACK, besides proxying it?)
RFC 3515 (April 2003): "The Session Initiation Protocol (SIP) REFER method".
RFC 3311 (September 2002): "The Session Initiation Protocol (SIP) UPDATE method".
RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant Messaging".
RFC 3313 (January 2003): "Private Session Initiation Protocol (SIP) Extensions for Media Authorization".
RFC 3265 (June 2002): "Session Initiation Protocol (SIP) Specific Event Notification". (As far as I know, SER handles SUBSCRIBE and NOTIFY, but I want to know whether SER can act as the subscriber to the event information, it means, generate SUBSCRIBE)
RFC 3327 (December 2002): "Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts".
RFC 3325 (November 2002): "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks".
RFC 3323 (November 2002): "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
RFC 3608 (October 2003): "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration".
RFC 3486 (February 2003): "Compressing the Session Initiation Protocol (SIP)".
RFC 3455 (January 2003): "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)".
RFC 3329 (January 2003): "Security Mechanism Agreement for the Session Initiation Protocol (SIP)".
----- Mensaje Original ----- De: Jan Janak jan@iptel.org Fecha: Lunes, Abril 12, 2004 10:28 pm Asunto: Re: [Serusers] SER 0.8.12 and RFC
There is no such list. If you need it then put together a list of RFCs you are interested in and we will add yes/no to each entry in the list. Jan.
On 12-04 12:38, CURRO_DOMINGUEZ wrote:
Hello all the list
I'm looking some information about SER at www.iptel.org but I've
found
nothing. I would like to know the list of RFC that SER
implements
(related to SIP or SIP extensions), besides RFC3261.
I think it could be interesting to add this information at the
product
sheet.
Can you help me?
Thank you very much
Curro
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Comments inline.
On 14-04 12:07, CURRO_DOMINGUEZ wrote:
Hello,
Klaus, Jan, thank you very much for your answers. Below is the list of RFCs I'm interested in. As Klaus says, maybe some of them don't need explicit support, because ser can route these new messages. Or maybe there are RFCs that are not fully supported. Please, let me know if this is the case and if it could be necessary writting a new module or changing SER core.
By the way, can SER initiate a session release (it means, generate a BYE) or generate a REGISTER to an application server? If not, what would be necessary from your point of view?
No, you need a B2BUA for that.
(These five RFCs are related to new messages, so I suppose Yes) RFC 2976 (October 2000): "The SIP INFO method".
There is no special support needed in proxy servers, a proxy just relays INFO messages as any others.
RFC 3262 (June 2002): "Reliability of provisional responses in Session Initiation Protocol (SIP)". (can SER generate PRACK, besides proxying it?)
SER cannot generat PRACK, it can only relay it.
RFC 3515 (April 2003): "The Session Initiation Protocol (SIP) REFER method".
Yes, SER can either relay or generate (using a script or serweb) a REFER method.
RFC 3311 (September 2002): "The Session Initiation Protocol (SIP) UPDATE method".
SER can relay such messages properly. nathelper will probably not work correctly in this case (nobody has ever tried to make UPDATE work with nathelper).
RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant Messaging".
Yes, no special support needed in proxies. SER's module msilo can store messages for offline users and send them later when they are online.
RFC 3313 (January 2003): "Private Session Initiation Protocol (SIP) Extensions for Media Authorization".
No, there is not support for these extensions in SER.
RFC 3265 (June 2002): "Session Initiation Protocol (SIP) Specific Event Notification". (As far as I know, SER handles SUBSCRIBE and NOTIFY, but I want to know whether SER can act as the subscriber to the event information, it means, generate SUBSCRIBE)
SER cannot act as a subscriber. SER can proxy SUBSCRIBE/NOTIFY or accept SUBSCRIBE and generate NOTIFY (pa module).
RFC 3327 (December 2002): "Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts".
No ser does not support this yet.
RFC 3325 (November 2002): "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks".
Yes, in the unstable branch.
RFC 3323 (November 2002): "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
Yes, ser can test/handle Privacy header field, but it cannot act as a "Privacy Service" or Anonymizer (B2BUA needed for that).
RFC 3608 (October 2003): "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration".
No, not supported.
RFC 3486 (February 2003): "Compressing the Session Initiation Protocol (SIP)".
No, not supported.
RFC 3455 (January 2003): "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)".
No, not supported.
RFC 3329 (January 2003): "Security Mechanism Agreement for the Session Initiation Protocol (SIP)".
No, not supported.
Jan.
Hello, Thanks, Jan, for your answer. But I would like to make you (and all the list) another questions, if you don't mind ;).
I suppose that modify SER to accept new headers as described in most of these RFC's, involves modify SER parser and core, so they can't be accomplished in a new separated module. Am I wrong or a module could be enough?
I have been searching mail list to find information about B2BUA. SER doesn't store call state, only transactional state, so it can't act like a B2BUA. How much would cost, in terms of time and difficulty, add a new module to allow SER store call state and generate BYEs or SUBSCRIBEs? Maybe, SER developers are already working on this or someone could be interested.
I know that there are free B2BUA like Vovida (do you know any more?) which could be useful to attempt this task. Do you think Vovida, for instance, could be suitable? Has some of you worked with it and could give me his/her opinion?
Thank you very much for your time.
Curro
El lun, 19-04-2004 a las 12:01, Jan Janak escribió:
Comments inline.
On 14-04 12:07, CURRO_DOMINGUEZ wrote:
Hello,
Klaus, Jan, thank you very much for your answers. Below is the list of RFCs I'm interested in. As Klaus says, maybe some of them don't need explicit support, because ser can route these new messages. Or maybe there are RFCs that are not fully supported. Please, let me know if this is the case and if it could be necessary writting a new module or changing SER core.
By the way, can SER initiate a session release (it means, generate a BYE) or generate a REGISTER to an application server? If not, what would be necessary from your point of view?
No, you need a B2BUA for that.
(These five RFCs are related to new messages, so I suppose Yes) RFC 2976 (October 2000): "The SIP INFO method".
There is no special support needed in proxy servers, a proxy just relays INFO messages as any others.
RFC 3262 (June 2002): "Reliability of provisional responses in Session Initiation Protocol (SIP)". (can SER generate PRACK, besides proxying it?)
SER cannot generat PRACK, it can only relay it.
RFC 3515 (April 2003): "The Session Initiation Protocol (SIP) REFER method".
Yes, SER can either relay or generate (using a script or serweb) a REFER method.
RFC 3311 (September 2002): "The Session Initiation Protocol (SIP) UPDATE method".
SER can relay such messages properly. nathelper will probably not work correctly in this case (nobody has ever tried to make UPDATE work with nathelper).
RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant Messaging".
Yes, no special support needed in proxies. SER's module msilo can store messages for offline users and send them later when they are online.
RFC 3313 (January 2003): "Private Session Initiation Protocol (SIP) Extensions for Media Authorization".
No, there is not support for these extensions in SER.
RFC 3265 (June 2002): "Session Initiation Protocol (SIP) Specific Event Notification". (As far as I know, SER handles SUBSCRIBE and NOTIFY, but I want to know whether SER can act as the subscriber to the event information, it means, generate SUBSCRIBE)
SER cannot act as a subscriber. SER can proxy SUBSCRIBE/NOTIFY or accept SUBSCRIBE and generate NOTIFY (pa module).
RFC 3327 (December 2002): "Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts".
No ser does not support this yet.
RFC 3325 (November 2002): "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks".
Yes, in the unstable branch.
RFC 3323 (November 2002): "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
Yes, ser can test/handle Privacy header field, but it cannot act as a "Privacy Service" or Anonymizer (B2BUA needed for that).
RFC 3608 (October 2003): "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration".
No, not supported.
RFC 3486 (February 2003): "Compressing the Session Initiation Protocol (SIP)".
No, not supported.
RFC 3455 (January 2003): "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)".
No, not supported.
RFC 3329 (January 2003): "Security Mechanism Agreement for the Session Initiation Protocol (SIP)".
No, not supported.
Jan.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 26-04 17:02, Curro wrote:
Hello, Thanks, Jan, for your answer. But I would like to make you (and all the list) another questions, if you don't mind ;).
I suppose that modify SER to accept new headers as described in most of these RFC's, involves modify SER parser and core, so they can't be accomplished in a new separated module. Am I wrong or a module could be enough?
It can be done even from modules. It will be not very efficient but it is possible.
I have been searching mail list to find information about B2BUA. SER doesn't store call state, only transactional state, so it can't act like a B2BUA. How much would cost, in terms of time and difficulty, add a new module to allow SER store call state and generate BYEs or SUBSCRIBEs? Maybe, SER developers are already working on this or someone could be interested.
It's not easy to turn ser into a B2BUA, it requires a lot of coding. We have a B2BUA under a commercial license or there is the one from Vovida, some people here have been using it so they might give you a better answer. I personally don't have any experience with Vovida B2BUA.
Jan.
-
Curro -
CURRO_DOMINGUEZ
-
Jan Janak