[Serusers] SER 0.8.12 and RFC

Curro curro_dominguez at terra.es
Mon Apr 26 17:02:04 CEST 2004


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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list