METHOD FOR EXTENDING THE USE OF SIP (SESSION INITIATION PROTOCOL)

Abstract: The present invention relates to a method for extending the use of SIP (Session Initiation Protocol), especially in a communication system wherein H.323 or SIP compliant end-points communicate with the media traffic directly between other H.323 or SIP compliant end-points, and wherein the signalling is sent to either a gatekeeper or an SIP server, and in which system the start of a conversation message in the associated SIP protocol is here called INVITE, and for the purpose of support an extension of the SIP protocol to provide better support for charging for thereby more easily to detect when a conversation is closed, it is according to the present invention suggested that extra INVITE messages are sent to said SIP server.

Description: METHOD FOR EXTENDING THE USE OF SIP (SESSION INITIATION PROTOCOL) Field of the invention The present invention relates to a method for extending the use of SIP (Session Initiation Protocol) , of the type as stated in the preamble of the enclosed patent claim 1. More specifically the present invention relates to such a method for facilitating the charging of such SIP connections . Technical Background THE PROBLEM SIP [1] is a competitive protocol to H.323 [2] to provide Multimedia applications to operate over the IP protocol. The Internet Engineering Task Force (IETF) has standardized SIP. The latest version of SIP is currently only a draft, provided by the MMUSIC WG in IETF. The SIP protocol supports most of the features from the H.323 protocol, but it is simpler in respect to number of different messages. The fact that the SIP is simpler then H.323 (at the current version an SIP only supports six different messages) makes it easier to make a SIP compliant end-point than an H.323 compliant end-point. New development tools and programming languages also makes it easier to control media-interfaces. This makes it also an easier task to make a multi-media end-point. When making an end- point it is also easy to add more logic and functionality than stated in the standard. One of the methods for performing charging for SIP or H.323 conversations is to place the charging logic inside an SIP server or gatekeeper (H.323) see Figure 1. One of the problems with SIP is that it doesn't have support for a typical "continue call" message. Another problem is that SIP compliants could send the close message di- rectly to each other instead of via an SIP server. This makes it difficult to support charging for SIP conversations . The reason for this is that because the media traffic is not sent via the gatekeeper or the SIP server, it is difficult to know when the conversation is closed. Known solutions In the H.323 standard there is support for a "continue call" message. In the Q.931 [3] part of H.323 the message is called status inquiry. In the RAS part of H.323 the IRR message can be used for the same purpose. In H.323 it is also required that the end-points send the "close conversation" message via the gatekeeper (if a gatekeeper routed call model is used) . Objects of the invention An object of the present invention is to provide a method by which the use of SIP (Session Initiation Protocol) is extended in a rational and expedient manner. A further object of the present invention is to provide a method by which it is radially observed when a conversation between two end-points are terminated. A still further object of the present invention is to provide a method by which charging for SIP conversations can be stipulated in a very accurate and expedient manner. A still further object of the present invention is to pro- vide a method by which the message "continue call" is favourably supported by a corresponding SIP server. Brief disclosure of the invention These objects are achieved in a method as stated in the preamble, which is characterised by the features as stated in the characterising clause of the enclosed patent claim 1. In other words, the present invention can be defined as an extension of the SIP protocol, the main idea of the present invention being that the missing "continue call" message is solved by sending extra INVITE messages to the SIP server. Further features and advantages of the present invention will appear from the following description taken in con- junction with the enclosed drawings, as well as from the further attached patent claims . Brief disclosure of the drawings Fig. 1 is a block diagram illustrating how the signalling is sent to either a gatekeeper or an SIP server, the media traffic being sent directly between the H.323 or SIP compliant end-points. Fig. 2 is a schematical diagram illustrating how the SIP protocol can be extended to support a "continue call" func ¬ tion, it being noted that for simplicity only the INVITE messages from the calling end-point being shown. Detailed description of embodiments As previously explained, Fig. 1 illustrates one of the methods for performing charging for SIP or H.323 conversa ¬ tions by placing the charging logic inside an SIP server or gatekeeper (H.323). This Figure shows how the signalling is sent either to a gatekeeper or a SIP server. The media traffic is sent directly between the H.323 or SIP compliant end-points . In the SIP protocol the start of conversation message is called INVITE. This message is sent to the SIP server when a SIP compliant end-point wants to initiate a conversation with another end-point, or start a conference with several end-points. The INVITE message contains information about what type of media it supports, and together with the ACK message this information is used as the method for negotiation of media streams. When an end-point wants to add or remove media streams the INVITE message is also used. When the INVITE message is used to define the set of current media streams, the CALL-ID in the INVITE message must be the same as the first INVITE message. The present invention is to be regarded as an extension of the SIP protocol. The main idea behind the present invention is that the missing "continue call" message is solved by sending extra INVITE messages to the SIP server. In Fig. 2 it is illustrated how the SIP protocol can be ex ¬ tended to support a "continue call" function. It should be noted that for the sake of simplicity only the INVITE messages from the calling end-point are shown. Most appropriately the present invention may be realised in that the extra INVITE messages are sent at regular inter ¬ vals. These INVITE messages should be equal to the last INVOKE message that was sent according to the SIP protocol. This means that the CALL-ID and the media channel described in the INVITE message must be the same. The CSeq (command sequence) field should also be the same in the extra INVITE messages as in the original INVITE message. If the SIP server doesn't receive an INVITE message during the predefined interval, it considers the SIP conversation between the end-points as closed. To inform the other end- point(s), the SIP server should send a BYE message to it. To increase robustness the SIP server should also send the BYE message to the end-point that has stopped sending INVITE messages. The reason for a stop in the sending of the INVITE message could be that the end-point has sent a BYE message directly to the other end-point, or it could be that the end-point has crashed, the physical link is broken, etc. This solution requires some extension to the original SIP protocol. This should not be a problem because it is quite easy to make SIP end-points. If, however, normal SIP end- points must be used, the solution is to add a special SIP proxy. The requirement for this proxy is that it has some knowledge about the physical layer of the normal SIP end- point. This special SIP proxy will act as a normal SIP proxy as described in the SIP standard, but it will send new INVITE messages at regular intervals to the SIP Server during the conversation. Because this SIP proxy has some knowledge about the physical layer of the normal end-point, it should stop sending new INVITE messages when it discovers that the end-point stops sending media streams. Advantages By using the idea described in the section above a robust charging mechanism can be implemented for SIP. This charging mechanism can base its charge not only on a fixed price per conversation, but also on a time component since it knows the duration of the conversation. This charging mechanism can also base it charge on a volume component since the type of media used is described in the INVITE message. Charging for volume can also be done in a normal SIP implementation. Another advantage of the idea with extra INVITE messages is that an end-point that uses this method is still totally compliant to normal SIP end-points. The normal SIP end- point will only consider the extra INVITE message as a retransmission of an old one. This is because it has the same CALL-ID, CSeq and media description. It is also said in the standard that the end-points should consider INVITE message with the same CSeq as retransmission, and it should be dropped. Broadending Another message than INVITE could be used for implementing the "continue call" function in SIP, i.e. a new message type could be used. If a new signal is used, it should operate in the same way as the extra INVITE described in the sections above. If a new message type is used it is not guarantied that it will inter operate with normal SIP end- points . References [1] Handley/Schulzrinne/Schooler/Rosenberg "SIP: Session Initiation Protocol" Internet Draft, Internet Engineering Task Force, ietf-mmusic-sip- 09.txt, September 18, 1998 [2] ITU-T Recommendation H.323 (1998), "Packet-based multimedia communication systems". [3] ITU-T Recommendation Q.931 (1993), "ISDN user- network interface layer 3 specification for basic call control"

Claims: P a t e n t c l a i m s 1. Method for extending the use of SIP (Session Initiation Protocol), especially in a communication system wherein H.323 or SIP compliant end-points communicate with the media traffic directly between other H.323 or SIP compliant end-points, and wherein the signalling is sent to either a gatekeeper or an SIP server, and in which system the start of a conversation message in the associated SIP protocol is here called INVITE, c h a r a c t e r i s e d i n that extra INVITE messages are sent to said SIP server. 2. Method as claimed in claim 1, c h a r a c t e r i s e d i n that the extra INVITE messages are sent at preferably regular time intervals. 3. Method as claimed in claim 1 or 2 , c h a r a c t e r i s e d i n that the extra INVITE messages are equal to the last INVITE message that was sent according to the SIP protocol, meaning that the CALL-ID and the media channel described in the INVITE message is the same . 4. Method as claimed in any of the claims 1-3, c h a r a c t e r i s e d i n that the CSeq (Command Sequence) will be the same in the extra INVITE messages as in the original INVITE message. 5. Method as claimed in any of the preceding claims, c h a r a c t e r i s e d i n that upon receipt of no INVITE message after a predetermined time interval, the system will consider the SIP conversation between the associated end-points as closed. 6. Method as claimed in claim 5, c h a r a c t e r i s e d i n that after the receipt of no INVITE message after a predetermined time interval, said server will send a BYE message to the end-point that stopped sending extra INVITE messages. 7. Method as claimed in any of the preceding claims, c h a r a c t e r i s e d i n that the method allows communication with means which can detect the reason for stopping the sending of INVITE messages. 8. Method as claimed in claim 7, c h a r a c t e r i s e d i n that the method communicates with means for detecting whether an end-point has sent a BYE message directly to the other end-point, or for detecting that the end-point has crashed, the physical link has broken down, etc. 9. Method as claimed in claim 7 or 8, c h a r a c t e r i s e d i n that the method is adapted to correspond with a special SIP proxy, said special SIP proxy acting as a normal SIP proxy but sending new INVITE messages at regular intervals to the SIP server during the conversation. 10. Method as claimed in any of the claims 7-9, c h a r a c t e r i s e d i n that said SIP proxy is adapted to have some knowledge about the physical layer of the normal end-point, and is adapted to stop sending new INVITE messages when it is discovered that the end-point involved stops sending media streams. 11. Method as claimed in any of the preceding claims, c h a r a c t e r i s e d i n that the method allows for a charging mechanism based not only on a fixed price per conversation, but also on a time component since it knows the duration on the conversation, the charging mecha- nism possibly being based on a volume component since the type of media used is described in the INVITE message. 12. Method as claimed in any of the preceding claims, c h a r a c t e r i s e d i n that the another message than INVITE is used for implementing the "continue call" function in said SIP, said new INVITE messages being adapted to inter operate with normal SIP end-points as well as possibly adapted SIP end-points.

Inventors: CORNELIUSSEN KNUT SNORRE BACH, CORNELIUSSEN, KNUT, SNORRE, BACH
Applicants: CORNELIUSSEN KNUT SNORRE BACH, ERICSSON TELEFON AB L M, CORNELIUSSEN, KNUT, SNORRE, BACH, TELEFONAKTIEBOLAGET LM ERICSSON
Application year: 1999
Main classification: H04M3
IPC codes: H04L29, H04Q11