14 Apr
2004
14 Apr
'04
12:07 p.m.
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
19 Apr
19 Apr
12:01 p.m.
New subject: [Serusers] SER 0.8.12 and RFC
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.
26 Apr
26 Apr
5:02 p.m.
New subject: [Serusers] SER 0.8.12 and RFC
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
27 Apr
27 Apr
2:08 p.m.
New subject: [Serusers] SER 0.8.12 and RFC
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.
7310
days inactive
7323
days old
3 comments
3 participants
participants (3)
-
Curro -
CURRO_DOMINGUEZ
-
Jan Janak