Hi Jean, Expires with zero is generally used for de-registration.This is a case where you receive for first REGISTER message you can silently discard and go ahead. No need to maintain the transaction. Does your 200OK has Expired header as well as Expires parameter in Contact header. If So, Contact header "expires" paramter has preference over Expires header, if expires in contact is present, it will be used else value present in Expires header will be used. Thanks & Regards, Kavitha Menneni
--- On Wed, 14/7/10, [email protected] <[email protected]> wrote: From: [email protected] <[email protected]> Subject: Sip-implementors Digest, Vol 88, Issue 9 To: [email protected] Date: Wednesday, 14 July, 2010, 2:13 PM Send Sip-implementors mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip-implementors digest..." Today's Topics: 1. Re: How long can a Dialog be in Early state. (M. Ranganathan) 2. Re: Register/Subscribe - 200 Response - Expires 0 (Pavesi, Valdemar (NSN - US/Irving)) 3. rfc 3398 or ITU Q1912.5 Annex B (Nikos Leontsinis) 4. Call for participation --- ACM IPTComm, Aug 2-3 2010, Munich Germany (Vijay K. Gurbani) 5. Re: Open Source SIP stack (Alejandro Orellana) 6. Re: Open Source SIP stack (Vinod Parameswaran) 7. How sip stack can recover from the following error condition..... (radhakrishna) 8. Re: How sip stack can recover from the followingerror condition..... (Rastogi, Vipul (Vipul)) ---------------------------------------------------------------------- Message: 1 Date: Tue, 13 Jul 2010 12:26:41 -0400 From: "M. Ranganathan" <[email protected]> Subject: Re: [Sip-implementors] How long can a Dialog be in Early state. To: "Pavesi, Valdemar (NSN - US/Irving)" <[email protected]> Cc: sip-implementors <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 13, 2010 at 12:18 PM, Pavesi, Valdemar (NSN - US/Irving) <[email protected]> wrote: > The expires header is used to refresh a created dialog ( sending another > INVITE or UPDATE) You are thinking of Session-Expires header perhaps? > > In this case INVITE/100 and UAC dies, ?all provisioning response are not > mandatory , then you can clean the context after the answer-timeout ( 90 > seconds). > > > Regards! > Valdemar > > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of ext > WORLEY, Dale R (Dale) > Sent: Monday, July 12, 2010 1:50 PM > To: M. Ranganathan > Cc: sip-implementors > Subject: Re: [Sip-implementors] How long can a Dialog be in Early state. > > ________________________________________ > From: M. Ranganathan [[email protected]] > > Does a 100 provisional response put the UAC dialog in early state? I > think not so my question was mis stated. > > The situation I was concerned about is > > UAC sends INVITE > UAS sends 100 and dies. > > In this case Dialog cleanup is not an issue because a Dialog does not > yet exist. > Transaction will expire when its Expires indicated value header times > out.. So that will take care of cleanup of the transaction. > > As for Dialog state machine, 101 -- 199 responses can push the dialog > into early state and as you state above, this must be refreshed every > 60 seconds and hence a UAC dialog can be torn down if in early state > for > 3 minutes without a 1xx refresh. > _____________________________________ > > I'm not sure of the chapter and verse, but I'm sure that the referenced > section of 3261 also permits a UAC or proxy to give up on an INVITE if > only 100 responses are received for 3 minutes. ?Similarly, it can > enforce any Expires that was present in the outgoing INVITE. > > Dale > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- M. Ranganathan ------------------------------ Message: 2 Date: Tue, 13 Jul 2010 11:31:53 -0500 From: "Pavesi, Valdemar (NSN - US/Irving)" <[email protected]> Subject: Re: [Sip-implementors] Register/Subscribe - 200 Response - Expires 0 To: "ext WORLEY, Dale R (Dale)" <[email protected]>, "Jean-Hugues Royer" <[email protected]>, <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" 200ok with Expire time=0 for REGISTER just means that there is no resource created on Server and then the client is not registered. Normally this is the way that we have to delete the old registration .(REGISTER with expire =0). 200ok with expire time=0 for SUBSCRIBE means that there is no dialog created on Server. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext WORLEY, Dale R (Dale) Sent: Tuesday, July 13, 2010 9:44 AM To: Jean-Hugues Royer; [email protected] Subject: Re: [Sip-implementors] Register/Subscribe - 200 Response - Expires 0 ________________________________________ From: [email protected] [[email protected]] On Behalf Of Jean-Hugues Royer [[email protected]] When you REGISTER/SUBSCRIBE for the first time and you receive a 200 OK response with an expiration of zero, what are you suppose to do ? _______________________________________________ If you're trying to do a poll-type SUBSCRIBE (the requested expiration was 0), then of course you are fine. In other cases, the REGISTER/SUBSCRIBE effecitvely failed, and you should proceed as such. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 3 Date: Tue, 13 Jul 2010 22:36:08 +0300 From: Nikos Leontsinis <[email protected]> Subject: [Sip-implementors] rfc 3398 or ITU Q1912.5 Annex B To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 I wonder if there is anyone who knows which mapping method is best to choose. Pros & cons. RFC3398 is a completely different mapping scheme to that of ITU and the two mapping standards are incompatible with each other. /nikos ------------------------------ Message: 4 Date: Tue, 13 Jul 2010 14:47:25 -0500 From: "Vijay K. Gurbani" <[email protected]> Subject: [Sip-implementors] Call for participation --- ACM IPTComm, Aug 2-3 2010, Munich Germany To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed ================================================================================ Call for Participation - 4th ACM Conference on Principles, Systems and Applications of IP Telecommunications (IPTComm), August 2-3, 2010, Munich, Germany http://www.iptcomm.org Advance Programme: http://iptcomm.org/IPTComm-2010-Programme.pdf ================================================================================ Early Registration (by July 21, 2010): EUR 350 We would like to invite you to attend the 4th ACM Conference on Principles, Systems and Applications of IP Telecommunications (IPTComm) taking place on August 2-3, 2010 at the Leibniz Supercomputing Center, Munich, Germany. The aim of the IPTComm conference is to serve as a platform for researchers from academia, research labs, industry and government to share their ideas, views, results and experiences in the field of IP-based telecommunication. IPTComm includes presentations of theoretical and experimental achievements, innovative systems, prototyping efforts, case studies, and advancements in technology. Confirmed keynote speeches by: - Dr. Steven Bellovin, Columbia University, New York, USA. - Dr. Anja Feldmann, Deutsche Telekom Laboratory/TU Berlin, Germany. The advance programme is available at the following URL: http://iptcomm.org/IPTComm-2010-Programme.pdf Registration is now open. Best regards, Vijay K. Gurbani and Gonzalo Camarillo, IPTComm 2010 TPC Co-chairs ------------------------------ Message: 5 Date: Tue, 13 Jul 2010 17:44:16 -0400 From: Alejandro Orellana <[email protected]> Subject: Re: [Sip-implementors] Open Source SIP stack To: Vinod Parameswaran <[email protected]> Cc: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii Hello Try pjsip pjsip.org Cheers Sent from my iPhone On Jul 13, 2010, at 2:27 AM, Vinod Parameswaran <[email protected]> wrote: > Hello list, > > As part of my telephony project on the Unix platform, I need to make use of > SIP signaling. > > Since we are trying something new at the protocol level itself within a > customized infrastructural environment, I would like to know if there is any > open source SIP stack available, which also allows download of the entire > source code. > > I am familiar with C programming, so would prefer an implementation written > in C. > > I would greatly appreciate it if any of the experts could provide me with > some guidance. > > best regards > Vin > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 6 Date: Wed, 14 Jul 2010 14:43:47 +1200 (NZST) From: Vinod Parameswaran <[email protected]> Subject: Re: [Sip-implementors] Open Source SIP stack To: sip-implementors <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=utf-8 Thank you all for your valuable inputs. regards Vin ------------------------------ Message: 7 Date: Wed, 14 Jul 2010 14:01:04 +0530 From: radhakrishna <[email protected]> Subject: [Sip-implementors] How sip stack can recover from the following error condition..... To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii Dear All, I want to know if there is any way to come out of the following problem. UAC UAS ----------------------------INV (CSEQ: 1) ------------------------> <---------------------------200 OK---------------------------------- ----------------------------ACK ------------------------------------> Attacker ----------------Update (CSEQ: 10000) ----------> <------------------- 401/407 ------------------------------ -----------------------UPDATE (CSEQ: 2) ------------------> <----------------------- 500 -------------------------------------- Now since the actual UAC is not aware of the attacker, he will keep incrementing the CSEQ every time and will try to send the request. The request would be successful only after trying for some 9999 times. How do we overcome this kind of situation? We suggest that RFC should have a way to convey the CSEQ value stored by UAS in 500 response message so that UAC can come out of the loop. Can anyone please share your opinion on this issue? Regards, RadhaKrishna ------------------------------ Message: 8 Date: Wed, 14 Jul 2010 14:13:25 +0530 From: "Rastogi, Vipul (Vipul)" <[email protected]> Subject: Re: [Sip-implementors] How sip stack can recover from the followingerror condition..... To: "radhakrishna" <[email protected]>, <[email protected]> Message-ID: <5ad1580f7bf0ac4ea6520e7157374ef2016f1...@307873ex2.global.avaya.com> Content-Type: text/plain; charset="us-ascii" To hide SIP headers, there are ways like TLS, SIP/MIME (encapsulation). May be you would like to use TLS in this particular case, which will prevent any attacker to generate accurate UPDATE message. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of radhakrishna Sent: Wednesday, July 14, 2010 14:01 To: [email protected] Subject: [Sip-implementors] How sip stack can recover from the followingerror condition..... Dear All, I want to know if there is any way to come out of the following problem. UAC UAS ----------------------------INV (CSEQ: 1) ------------------------> <---------------------------200 OK---------------------------------- ----------------------------ACK ------------------------------------> Attacker ----------------Update (CSEQ: 10000) ----------> <------------------- 401/407 ------------------------------ -----------------------UPDATE (CSEQ: 2) ------------------> <----------------------- 500 -------------------------------------- Now since the actual UAC is not aware of the attacker, he will keep incrementing the CSEQ every time and will try to send the request. The request would be successful only after trying for some 9999 times. How do we overcome this kind of situation? We suggest that RFC should have a way to convey the CSEQ value stored by UAS in 500 response message so that UAC can come out of the loop. Can anyone please share your opinion on this issue? Regards, RadhaKrishna _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors End of Sip-implementors Digest, Vol 88, Issue 9 *********************************************** _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
