hi ,, how to write *1.*a dns query for the sip proxy server *2. lookup component --* which reads the bindings from the registrar.
nishant On 11/1/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > Send Sip-implementors mailing list submissions to > sip-implementors@cs.columbia.edu > > 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: Query 100rel in re-INVITE (Sarkar, Uttam) > 2. Re: Query 100rel in re-INVITE (Agrawal, Vishal) > 3. Re: Register Request ([EMAIL PROTECTED]) > 4. Handling a of re-INVITE before initial ACK is received > (Stephen Paterson) > 5. Re: Query 100rel in re-INVITE (Paul Kyzivat) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 31 Oct 2006 16:19:58 -0500 > From: "Sarkar, Uttam" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > To: "Sanjay Sinha \(sanjsinh\)" <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]>, <sip-implementors@cs.columbia.edu> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Thanks, > > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 31, 2006 4:14 PM > To: Sarkar, Uttam; [EMAIL PROTECTED]; > sip-implementors@cs.columbia.edu > Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > > First Invite in this figure is really a re-Invite. Pl. refer to the text > accompanying this figure: > > Let's assume, that in the middle of the session, A wishes to change > the IP address where it is receiving media. Figure 3 shows this > scenario. > > SDP1: A includes an offer in a re-INVITE (1) > > > >-----Original Message----- > >From: Sarkar, Uttam [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, October 31, 2006 3:56 PM > >To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED]; > >sip-implementors@cs.columbia.edu > >Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > > > >Here is that figure. I don't see any re-INVITE at all. > >Here INVITE (1) had 200 OK (7) and ACK (8). > >No further re-INVITE. > > > > > > > > A B > > > > | | > > |-------------(1) INVITE SDP1--------------->| > > | | > > |<------(2) 183 Session Progress SDP2--------| > > | *** *** | > > |--*R*-----------(3) PRACK-------------*R*-->| > > | *E* *E* | > > |<-*S*-------(4) 200 OK (PRACK)--------*S*---| > > | *E* *E* | > > | *R* *R* | > > | *V* *V* | > > | *A* *A* | > > | *T* *T* | > > | *I* *I* | > > | *O* *O* | > > | *N* *N* | > > | *** *** | > > | *** | > > | *** | > > |-------------(5) UPDATE SDP3--------------->| > > | | > > |<--------(6) 200 OK (UPDATE) SDP4-----------| > > | | > > |<-----------(7) 200 OK (INVITE)-------------| > > | | > > |------------------(8) ACK------------------>| > > | | > > | | > > > > > >-----Original Message----- > >From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, October 31, 2006 3:48 PM > >To: Sarkar, Uttam; [EMAIL PROTECTED]; > >sip-implementors@cs.columbia.edu > >Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > > > > > > > >>-----Original Message----- > >>From: Sarkar, Uttam [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, October 31, 2006 3:17 PM > >>To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED]; > >>sip-implementors@cs.columbia.edu > >>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > >> > >>I see UPDATE is used before sending 200 OK (for INVITE). I don't see > >>any re-INVITE scenario here. Am I missing something here? > > > >Yes. Pl. see sec. 13.1, Figure 3. > > > > > >> > >>-----Original Message----- > >>From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, October 31, 2006 2:56 PM > >>To: Sarkar, Uttam; [EMAIL PROTECTED]; > >>sip-implementors@cs.columbia.edu > >>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > >> > >>I think RFC 3312 has some examples where 18x is needed for > >>preconditions in a mid-call session. > >> > >>Sanjay. > >> > >>>-----Original Message----- > >>>From: Sarkar, Uttam [mailto:[EMAIL PROTECTED] > >>>Sent: Tuesday, October 31, 2006 2:05 PM > >>>To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED]; > >>>sip-implementors@cs.columbia.edu > >>>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > >>> > >>>Whole idea of 100rel is to make sure 18X message is received by the > >>>other party so that they can be sure of exchnage any media before > >>>session is established. > >>>Re-INVITE is for established session. > >>>Please correct me if I am wrong. > >>> > >>>-----Original Message----- > >>>From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED] > >>>Sent: Tuesday, October 31, 2006 1:09 PM > >>>To: Sarkar, Uttam; [EMAIL PROTECTED]; > >>>sip-implementors@cs.columbia.edu > >>>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > >>> > >>>It might be useful for QoS cases. > >>> > >>>>-----Original Message----- > >>>>From: [EMAIL PROTECTED] > >>>>[mailto:[EMAIL PROTECTED] On Behalf > >>>Of Sarkar, > >>>>Uttam > >>>>Sent: Tuesday, October 31, 2006 11:28 AM > >>>>To: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu > >>>>Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > >>>> > >>>>I still can't understand why 100rel is requiring to a > >>>re-INVITE (change > >>>>media from audio to audio and video). > >>>>In the re-INVITE it will carry the new media. Other endpoint will > >>>>respond back with final response (like 200 OK or 488 Not Acceptable > >>>>Here). > >>>>I can't imagine other end will send 18X with media and send > >>>PRACK for a > >>>>session that is already established. > >>>> > >>>>Thanks, > >>>> > >>>>-----Original Message----- > >>>>From: [EMAIL PROTECTED] > >>>>[mailto:[EMAIL PROTECTED] On Behalf Of > >>>>[EMAIL PROTECTED] > >>>>Sent: Tuesday, October 31, 2006 10:57 AM > >>>>To: sip-implementors@cs.columbia.edu > >>>>Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > >>>> > >>>> From: "Sarkar, Uttam" <[EMAIL PROTECTED]> > >>>> > >>>> 100rel does not make sense in re-INVITE as session is already > >>>> established. UAS is expected to send final response > >>>(2XX/4XX/5XX etc > >>>>). > >>>> It can send 100 trying to stop retransmission of INVITE > >while it's > >>>> preparing the final response. > >>>> It's not recommended for UAS to send 1XX response for the > >>>re-INVITE. > >>>> > >>>>One can imagine scenarios where a re-INVITE might not be > >>>instantaneous, > >>>>and so 100rel might be a useful mechanism. For instance, if one > >>>>endpoint wishes to upgrade an audio call to an > >audio-and-video call, > >>>>the other endpoint might want to ask its user before activating the > >>>>video camera. > >>>> > >>>>Dale > >>>>_______________________________________________ > >>>>Sip-implementors mailing list > >>>>Sip-implementors@cs.columbia.edu > >>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >>>> > >>>>This email and any attached files herein contain > >information that is > >>>>intended only for the use of the individual or entity to whom it is > >>>>addressed and may contain information that is legally privileged, > >>>>confidential or otherwise exempt from disclosure under > >>>applicable laws. > >>>>If the reader of this message is not the recipient, any disclosure, > >>>>dissemination, distribution, copying or other use or > >>>retention of this > >>>>communication or its substance is prohibited. > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Sip-implementors mailing list > >>>>Sip-implementors@cs.columbia.edu > >>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >>>> > >>> > >>>This email and any attached files herein contain information that is > >>>intended only for the use of the individual or entity to whom it is > >>>addressed and may contain information that is legally privileged, > >>>confidential or otherwise exempt from disclosure under > >>applicable laws. > >>>If the reader of this message is not the recipient, any disclosure, > >>>dissemination, distribution, copying or other use or > >>retention of this > >>>communication or its substance is prohibited. > >>> > >> > >>This email and any attached files herein contain information that is > >>intended only for the use of the individual or entity to whom it is > >>addressed and may contain information that is legally privileged, > >>confidential or otherwise exempt from disclosure under > >applicable laws. > >>If the reader of this message is not the recipient, any disclosure, > >>dissemination, distribution, copying or other use or > >retention of this > >>communication or its substance is prohibited. > >> > > > >This email and any attached files herein contain information > >that is intended only for the use of the individual or entity > >to whom it is addressed and may contain information that is > >legally privileged, confidential or otherwise exempt from > >disclosure under applicable laws. If the reader of this > >message is not the recipient, any disclosure, dissemination, > >distribution, copying or other use or retention of this > >communication or its substance is prohibited. > > > > This email and any attached files herein contain information that is > intended only for the use of the individual or entity to whom it is > addressed and may contain information that is legally privileged, > confidential or otherwise exempt from disclosure under applicable laws. If > the reader of this message is not the recipient, any disclosure, > dissemination, distribution, copying or other use or retention of this > communication or its substance is prohibited. > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 1 Nov 2006 09:21:48 -0600 > From: "Agrawal, Vishal" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > To: "Sarkar, Uttam" <[EMAIL PROTECTED]>, "Paul Kyzivat" > <[EMAIL PROTECTED]> > Cc: sip-implementors@cs.columbia.edu > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > A re-INVITE request allows 18X responses, right? > > The statement that re-INVITE MUST always be immediately answered with a > 200 OK response doesn't seem right. I think if a UAC wants an immediate > answer then it should send an UPDATE (if supported) request and not a > re-INVITE. If UPDATE is not supported then the UAC should remove the > "Supported: 100rel" from the re-INVITE and should ignore the 18X > responses for re-INVITE. > > A re-INVITE seems appropriate when adding/removing new/old media to/from > the existing session or other cases (as mentioned by others for QoS > etc). > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sarkar, > Uttam > Sent: Tuesday, October 31, 2006 1:05 PM > To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED]; > sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > > Whole idea of 100rel is to make sure 18X message is received by the > other party so that they can be sure of exchnage any media before > session is established. > Re-INVITE is for established session. > Please correct me if I am wrong. > > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 31, 2006 1:09 PM > To: Sarkar, Uttam; [EMAIL PROTECTED]; > sip-implementors@cs.columbia.edu > Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > > It might be useful for QoS cases. > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of > >Sarkar, Uttam > >Sent: Tuesday, October 31, 2006 11:28 AM > >To: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu > >Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > > > >I still can't understand why 100rel is requiring to a > >re-INVITE (change media from audio to audio and video). > >In the re-INVITE it will carry the new media. Other endpoint > >will respond back with final response (like 200 OK or 488 Not > >Acceptable Here). > >I can't imagine other end will send 18X with media and send > >PRACK for a session that is already established. > > > >Thanks, > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of > >[EMAIL PROTECTED] > >Sent: Tuesday, October 31, 2006 10:57 AM > >To: sip-implementors@cs.columbia.edu > >Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > > > > From: "Sarkar, Uttam" <[EMAIL PROTECTED]> > > > > 100rel does not make sense in re-INVITE as session is already > > established. UAS is expected to send final response > >(2XX/4XX/5XX etc ). > > It can send 100 trying to stop retransmission of INVITE while it's > > preparing the final response. > > It's not recommended for UAS to send 1XX response for the re-INVITE. > > > >One can imagine scenarios where a re-INVITE might not be > >instantaneous, and so 100rel might be a useful mechanism. For > >instance, if one endpoint wishes to upgrade an audio call to > >an audio-and-video call, the other endpoint might want to ask > >its user before activating the video camera. > > > >Dale > >_______________________________________________ > >Sip-implementors mailing list > >Sip-implementors@cs.columbia.edu > >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > >This email and any attached files herein contain information > >that is intended only for the use of the individual or entity > >to whom it is addressed and may contain information that is > >legally privileged, confidential or otherwise exempt from > >disclosure under applicable laws. If the reader of this > >message is not the recipient, any disclosure, dissemination, > >distribution, copying or other use or retention of this > >communication or its substance is prohibited. > > > > > > > >_______________________________________________ > >Sip-implementors mailing list > >Sip-implementors@cs.columbia.edu > >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > This email and any attached files herein contain information that is > intended only for the use of the individual or entity to whom it is > addressed and may contain information that is legally privileged, > confidential or otherwise exempt from disclosure under applicable laws. > If the reader of this message is not the recipient, any disclosure, > dissemination, distribution, copying or other use or retention of this > communication or its substance is prohibited. > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ------------------------------ > > Message: 3 > Date: Wed, 1 Nov 2006 13:28:43 +0530 > From: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Register Request > To: "Divya Sachdeva" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], > sip-implementors@cs.columbia.edu > Message-ID: > < > [EMAIL PROTECTED] > > > > Content-Type: text/plain; charset="US-ASCII" > > > Communication powers the world. > Aricent powers communications. > > FLEXTRONICS SOFTWARE SYSTEMS IS NOW ARICENT. > > > > "Divya Sachdeva" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 11/01/2006 01:01 PM > > > To > sip-implementors@cs.columbia.edu > cc > > Subject > [Sip-implementors] Register Request > > > > > > > I hve a question regarding REGISTER request Can one UA register to the > same registrar with two names in order to > redirect different users to different ports? > > [Balaji Says] > Yes... U can do it with a single register request. Check the CONTACT > header in the Register request. You can place the different name in that. > [Balaji End] > > For example register as userA for port 5060 and as userY for port 5051? In > that case should both registrations have the same call-id? > > [Balaji Says] > I think it is not possible. Since for each register (for any new request) > new Call-ID is generated. If the same Call-ID repeated then it will > consider as Retransmission of that Request (As per RFC 3261 Brach-ID > should be validated to detect the Retransmission ,But as per old RFC 2543 > the Call-ID is used to detect the retramsmission. > [Balaji End] > > > Thanks and Regards > Divya > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > *********************** Aricent-Private *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of > the individual to whom it is addressed. It may contain privileged or > confidential information and should not be > circulated or used for any purpose other than for what it is intended. If > you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of > this message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus." > > ------------------------------ > > Message: 4 > Date: Wed, 1 Nov 2006 16:40:36 -0000 > From: "Stephen Paterson" <[EMAIL PROTECTED]> > Subject: [Sip-implementors] Handling a of re-INVITE before initial ACK > is received > To: "SIP Implementors (E-mail)" <sip-implementors@cs.columbia.edu> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > > Section 14.2 of RFC 3261 states: > > A UAS that receives a second INVITE before it sends the final response to > a first INVITE with a lower CSeq sequence number on the same dialog MUST > return a 500 (Server Internal Error) response to the second INVITE and MUST > include a Retry-After header field with a randomly chosen value of between 0 > and 10 seconds. > A UAS that receives an INVITE on a dialog while an INVITE it had sent on > that dialog is in progress MUST return a 491 (Request Pending) response to > the received INVITE. > > Question is: What should the UAS do if it receives a re-INVITE after it > has sent the final response but before it receives the ACK for the initial > INVITE? > > This situation doesn't fit either of the above two scenarios and I can't > find anything elsewhere in the RFC to help. Currently our stack ignores the > second INVITE but my gut feeling is there should be some sort of 4xx > response, possibly containing a Retry-After header. > > Regards > > Steve > > Steve Paterson > Software Engineer > Aculab > Tel: +44 (0) 1908 273866 > Fax: +44 (0) 1908 273801 > Email: mailto:[EMAIL PROTECTED] > Website: http://www.aculab.com > > > > ------------------------------ > > Message: 5 > Date: Wed, 01 Nov 2006 11:55:20 -0500 > From: Paul Kyzivat <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > To: "Agrawal, Vishal" <[EMAIL PROTECTED]> > Cc: sip-implementors@cs.columbia.edu, "Sarkar, Uttam" > <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > The interesting cases come up in 3pcc. Even when supported, UPDATE > doesn't in general do the job. What one wants to do is solicit the other > party to make an offer. This can't be done with UPDATE. There is much > discussion of this in the 3pcc call flows document. > > Paul > > Agrawal, Vishal wrote: > > A re-INVITE request allows 18X responses, right? > > > > The statement that re-INVITE MUST always be immediately answered with a > > 200 OK response doesn't seem right. I think if a UAC wants an immediate > > answer then it should send an UPDATE (if supported) request and not a > > re-INVITE. If UPDATE is not supported then the UAC should remove the > > "Supported: 100rel" from the re-INVITE and should ignore the 18X > > responses for re-INVITE. > > > > A re-INVITE seems appropriate when adding/removing new/old media to/from > > the existing session or other cases (as mentioned by others for QoS > > etc). > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Sarkar, > > Uttam > > Sent: Tuesday, October 31, 2006 1:05 PM > > To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED]; > > sip-implementors@cs.columbia.edu > > Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > > > > Whole idea of 100rel is to make sure 18X message is received by the > > other party so that they can be sure of exchnage any media before > > session is established. > > Re-INVITE is for established session. > > Please correct me if I am wrong. > > > > -----Original Message----- > > From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 31, 2006 1:09 PM > > To: Sarkar, Uttam; [EMAIL PROTECTED]; > > sip-implementors@cs.columbia.edu > > Subject: RE: [Sip-implementors] Query 100rel in re-INVITE > > > > It might be useful for QoS cases. > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> Sarkar, Uttam > >> Sent: Tuesday, October 31, 2006 11:28 AM > >> To: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu > >> Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > >> > >> I still can't understand why 100rel is requiring to a > >> re-INVITE (change media from audio to audio and video). > >> In the re-INVITE it will carry the new media. Other endpoint > >> will respond back with final response (like 200 OK or 488 Not > >> Acceptable Here). > >> I can't imagine other end will send 18X with media and send > >> PRACK for a session that is already established. > >> > >> Thanks, > >> > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> [EMAIL PROTECTED] > >> Sent: Tuesday, October 31, 2006 10:57 AM > >> To: sip-implementors@cs.columbia.edu > >> Subject: Re: [Sip-implementors] Query 100rel in re-INVITE > >> > >> From: "Sarkar, Uttam" <[EMAIL PROTECTED]> > >> > >> 100rel does not make sense in re-INVITE as session is already > >> established. UAS is expected to send final response > >> (2XX/4XX/5XX etc ). > >> It can send 100 trying to stop retransmission of INVITE while it's > >> preparing the final response. > >> It's not recommended for UAS to send 1XX response for the re-INVITE. > >> > >> One can imagine scenarios where a re-INVITE might not be > >> instantaneous, and so 100rel might be a useful mechanism. For > >> instance, if one endpoint wishes to upgrade an audio call to > >> an audio-and-video call, the other endpoint might want to ask > >> its user before activating the video camera. > >> > >> Dale > >> _______________________________________________ > >> Sip-implementors mailing list > >> Sip-implementors@cs.columbia.edu > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > >> This email and any attached files herein contain information > >> that is intended only for the use of the individual or entity > >> to whom it is addressed and may contain information that is > >> legally privileged, confidential or otherwise exempt from > >> disclosure under applicable laws. If the reader of this > >> message is not the recipient, any disclosure, dissemination, > >> distribution, copying or other use or retention of this > >> communication or its substance is prohibited. > >> > >> > >> > >> _______________________________________________ > >> Sip-implementors mailing list > >> Sip-implementors@cs.columbia.edu > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > > > This email and any attached files herein contain information that is > > intended only for the use of the individual or entity to whom it is > > addressed and may contain information that is legally privileged, > > confidential or otherwise exempt from disclosure under applicable laws. > > If the reader of this message is not the recipient, any disclosure, > > dissemination, distribution, copying or other use or retention of this > > communication or its substance is prohibited. > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > End of Sip-implementors Digest, Vol 44, Issue 4 > *********************************************** > -- The history of the world is the history of few men who had faith in themselves... _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
