Hi all, I wish to write my own Sip Softphone which will work on windows platform. Can anyone suggest me some references or some study material. Which SipStack is the best one to use ?
Many Thanks On 11/14/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > 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: From Tag and To Tag - regarding (zhang jw) > 2. Re: Sip-implementors] Queryon max-forwards counts > ([EMAIL PROTECTED]) > 3. Re: FW: Query on max-forwards counts ([EMAIL PROTECTED]) > 4. Re: Error in IANA assignments re:Accept-Resource-Priority > [RFC4412] (Gaurav Kheterpal) > 5. Re: From Tag and To Tag - regarding (Vivek Gupta) > 6. finding broken calls from ethereal capture (nitin arora) > 7. Re: finding broken calls from ethereal capture (Gaurav Kheterpal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Nov 2006 12:08:19 +0800 > From: "zhang jw" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] From Tag and To Tag - regarding > To: "Sarkar, Uttam" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > there maybe more than one dialogs in one session, so dialogid( call-id, > from > tag and to tag) can't identify session. > > On 11/14/06, Sarkar, Uttam <[EMAIL PROTECTED]> wrote: > > > > A dialog or session is identified by Call-ID, to tag and from tag. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Raj > > Sent: Monday, November 13, 2006 10:58 AM > > To: [email protected] > > Subject: [Sip-implementors] From Tag and To Tag - regarding > > > > Hello, > > > > Actually to identify a call, we use call-id. Can anyone > > please tell me the importance of FROM tag and TO tag in the SIP > > messages? I am really confused on the information related to tag. > > > > thanks in advance > > > > with regards > > Raj. > > > > > > --------------------------------- > > Everyone is raving about the all-new Yahoo! Mail beta. > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > 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 > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Nov 2006 09:02:47 +0100 > From: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Sip-implementors] Queryon > max-forwards > counts > To: Bin Chen <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [email protected], > [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > oh, but it is in RFC3261! > In the example the invite arrives at Proxy-B with a max-forwards=1. > The behavior of a proxy should be (according to RFC3261): > <>For all new requests, including any with unknown methods, an element > intending to proxy the request MUST: > 1. Validate the request (Section 16.3) > 1. Reasonable Syntax > 2. URI scheme > * --> 3. Max-Forwards: ... If the request contains a Max-Forwards > header field with a field value greater than zero, the check is passed. > Which will be the case in the example --> Max-forwards is 1, check is > passed!* > 4. (Optional) Loop Detection > 5. Proxy-Require > 6. Proxy-Authorization<> > 2. Preprocess routing information (Section 16.4) > 3. Determine target(s) for the request (Section 16.5) > 4. Forward the request to each target (Section 16.6) > <><> 1. Make a copy of the received request > 2. Update the Request-URI > *--> 3. Update the Max-Forwards header field : If the copy contains a > Max-Forwards header field, the proxy MUST decrement its value by one. In > the example: the max-forwards becomes 0.* > 4. Optionally add a Record-route header field value > 5. Optionally add additional header fields > 6. Postprocess routing information > 7. Determine the next-hop address, port, and transport > 8. Add a Via header field value > 9. Add a Content-Length header field if necessary > 10. Forward the new request > 11. Set timer C > <>5. Process all responses (Section 16.7) > > The UA has no intention to forward this request and it will not check > the max-forwards, but it will handle the request. > The max-forwards is one of the headers needed for *proxy processing. > *This is also stated in RFC3261(7.3.1)* :.. *However, it is RECOMMENDED > that header fields which are needed for proxy processing (Via, Route, > Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for > example) appear towards the top of the message to facilitate rapid > parsing. > > Regards, > Nadine. > > > Bin Chen wrote: > > >Hi? > >Sorry, from the RFC3261 I can find any clue that the INVITE should be > forwarded when mf = 0 on Proxy-B: > > > >If the request contains a Max-Forwards header field with a field value of > zero (0), the element MUST > >NOT forward the request. If the request was for OPTIONS, the element MAY > act as the final recipient > >and respond per Section 11. Otherwise, the element MUST return a 483 (Too > many hops) response. > > > >Could you explain this? > > > >ABAI > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] On Behalf Of Bogdan Pintea > >Sent: Tuesday, November 14, 2006 12:06 AM > >To: [EMAIL PROTECTED] > >Cc: [email protected]; [EMAIL PROTECTED] > >Subject: Re: [Sip-implementors] Sip-implementors] Queryon max-forwards > counts > > > >Correct! Only if > >- incoming request has mf=0 and > >- request should be proxied further > >must the Proxy-B generate the 483. > > > > > >[EMAIL PROTECTED] wrote: > > > > > >>Hello, > >> > >>This is not correct. As per RFC3261 chapter 16.3 bullet 3 and chapter > >>16.6 bullet 3 > >>Proxy-B will forward the INVITE with Max-Forwards on zero to UA-B. > >> > >>Best regards, > >> > >> Ben. > >> > >>[EMAIL PROTECTED] wrote: > >> > >> > >> > >> > >>>As per 3261: it should reject the request with 483. > >>> > >>>HTH, > >>>Sreeram. > >>> > >>>-----Original Message----- > >>>From: [EMAIL PROTECTED] > >>>[mailto:[EMAIL PROTECTED] On Behalf Of > >>>[EMAIL PROTECTED] > >>>Sent: Monday, November 13, 2006 5:57 PM > >>>To: [email protected] > >>>Subject: [Sip-implementors] Sip-implementors] Query on max-forwards > >>>counts > >>> > >>> > >>> > >>> > >>> > >>> > >>>>Consider the following flow: (mf=max-forwards) > >>>> > >>>> > >>>>UA-A --- INVITE (mf=2) ---> Proxy-A ---- INVITE (mf=1) ---> > >>>>Proxy-B ---- INVITE (mf=0) ---> UA-B > >>>> > >>>> > >>>>In the flow above, should Proxy-B forward the INVITE with > >>>>max-forwards=0 to UA-B or should it reject the request with 483? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>Sip-implementors mailing list > >>>[email protected] > >>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >>> > >>> > >>>The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > addressee(s) and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately and destroy all copies of this message and any attachments. > >>> > >>>WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. The > company accepts no liability for any damage caused by any virus transmitted > by this email. > >>> > >>>www.wipro.com > >>> > >>>_______________________________________________ > >>>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 > >> > >> > >> > >> > > > >_______________________________________________ > >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 > > > > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 14 Nov 2006 09:14:15 +0100 > From: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] FW: Query on max-forwards counts > To: Kasturi Narayanan <[EMAIL PROTECTED]> > Cc: ysong <[EMAIL PROTECTED]>, sip-implementors > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > No, it is NOT an unnecessary hop, if the next hop is the endpoint! The > proxy even knows that the next target is one of its own endpoints. And > this endpoint isn't going to drop the request. And even if the proxy > doesn't know the next hop, it can never be sure that the receiver will > drop the request. > > Regards, > Nadine. > > Kasturi Narayanan wrote: > > >The approach suggested by Robert Sparks solves the problem but creates an > un-necessary hop when the sender knows for sure that it going to be dropped > by the Receiver (since it is sending with mf=0). > > > >Kasturi > > > >-----Original Message----- > >From: Song, Youngsun [mailto:[EMAIL PROTECTED] > >Sent: Monday, November 13, 2006 9:22 AM > >To: [email protected] > >Subject: [Sip-implementors] FW: Query on max-forwards counts > > > >Hi, > > > >Please see the attached response from Robert Sparks regarding this > >query. (FYI, I had also sent him a separate email...) > >Per his response, Proxy-B should forward the request to UA-B. > > > >Thanks to all who has taken the time to respond to my query, > >YoungSun > > > > > > > > > >>-----Original Message----- > >>From: Robert Sparks [mailto:[EMAIL PROTECTED] > >>Sent: Monday, November 13, 2006 9:12 AM > >>To: Song, Youngsun > >>Subject: Re: [Sip-implementors] Query on max-forwards counts > >> > >>See page 95, item 3. > >> > >>You reject when you receive, not before you send. > >>You reject when you receive a max-forwards of 0, not when you > >>receive a max-forwards of 1. > >> > >>RjS > >> > >> > >> > >>>>>-----Original Message----- > >>>>> > >>>>> > >>>>From: [EMAIL PROTECTED] > >>>>[mailto:[EMAIL PROTECTED] On > >>>> > >>>> > >>Behalf Of Song, > >> > >> > >>>>Youngsun > >>>>Sent: Friday, November 10, 2006 11:19 AM > >>>>To: [email protected] > >>>>Subject: [Sip-implementors] Query on max-forwards counts > >>>> > >>>>Hi, > >>>> > >>>>I have a clarification question on the following statement > >>>> > >>>> > >>in Section > >> > >> > >>>>8.1.1.6 of RFC3261 regarding when a proxy should send a 483 and > >>>>whether the number of hops includes the destination hop. > >>>> > >>>>"The Max-Forwards header field serves to limit the number > >>>> > >>>> > >>of hops a > >> > >> > >>>>request can transit on the way to its destination. It > >>>> > >>>> > >>consists of an > >> > >> > >>>>integer that is decremented by one at each hop. If the > >>>> > >>>> > >>Max-Forwards > >> > >> > >>>>value reaches 0 before the request reaches its > >>>> > >>>> > >>destination, it will > >> > >> > >>>>be rejected with a 483(Too Many Hops) error response." > >>>> > >>>> > >>>>Consider the following flow: (mf=max-forwards) > >>>> > >>>> > >>>>UA-A --- INVITE (mf=2) ---> Proxy-A ---- INVITE (mf=1) > >>>> > >>>> > >>---> Proxy-B > >> > >> > >>>>---- INVITE (mf=0) ---> UA-B > >>>> > >>>> > >>>>In the flow above, should Proxy-B forward the INVITE with > >>>>max-forwards=0 to UA-B or should it reject the request with 483? > >>>> > >>>>Thanks for your help in advance, > >>>>YoungSun > >>>> > >>>>_______________________________________________ > >>>>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 > > > > > >_______________________________________________ > >Sip-implementors mailing list > >[email protected] > >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 14 Nov 2006 14:34:57 +0530 > From: "Gaurav Kheterpal" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Error in IANA assignments > re:Accept-Resource-Priority [RFC4412] > To: "'Rhys D Ulerich'" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > FYI ... the IANA registrations have now been corrected. > > http://www.iana.org/assignments/sip-parameters > > Regards, > Gaurav > > -----Original Message----- > From: Pearl Liang via RT [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 11, 2006 4:38 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [IANA #36866] Error in IANA assignments > re:Accept-Resource-Priority > [RFC4412] > > Dear Sir/Madame, > > Thank you for your message(s). We have corrected the mentioned SIP header > name > to Accept-Resource-Priority. > > Please feel free to let us know if you have questions. > > Best regards, > > IANA > > > -----Original Message----- > From: Gaurav Kheterpal [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 31, 2006 12:32 PM > To: 'Rhys D Ulerich'; '[email protected]' > Subject: RE: [Sip-implementors] Error in IANA assignments > re:Accept-Resource-Priority [RFC4412] > > I noticed the same mistake on IANA website a few days back. RFC 4412 > correctly mentions the registration with IANA as: > > > "The following is the registration for the 'Accept-Resource-Priority' > header field: > > RFC number: 4412 > Header name: Accept-Resource-Priority > Compact form: none" > > > I remember a similar issue being resolved by IANA by contacting them on > [EMAIL PROTECTED] > > Regards, > Gaurav > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rhys D > Ulerich > Sent: Wednesday, October 25, 2006 10:23 PM > To: [email protected] > Subject: [Sip-implementors] Error in IANA assignments > re:Accept-Resource-Priority [RFC4412] > > Hi all, > > http://www.iana.org/assignments/sip-parameters has a mistake in the Header > Fields registry. It shows > > Header Name compact Reference > ----------------- ------- --------- > ... > Accept-Resource Priority [RFC4412] > ... > > but according to a quick peek at RFC 4412, it should show > > Header Name compact Reference > ----------------- ------- --------- > ... > Accept-Resource-Priority [RFC4412] > ... > > Anyone know who to contact to get this fixed? > > - Rhys > _______________________________________ > Rhys Ulerich > WebSphere IMS/SIP SOA Enablement Developer > Email: [EMAIL PROTECTED] Office: 512-838-1428 > IBM Software Group - Austin, TX > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ------------------------------ > > Message: 5 > Date: Tue, 14 Nov 2006 15:52:17 -0800 > From: Vivek Gupta <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] From Tag and To Tag - regarding > To: Raj <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > Because of the forking, a call can have multiple dialogs and To tag > uniquely identifies the individual destinations. > > Hence a dialog is identified by the combination of to tag, from tag, and > the call-id. > > With regards > Vivek Gupta > Raj wrote: > > Hello, > > > > Actually to identify a call, we use call-id. Can anyone > please tell me the importance of FROM tag and TO tag in the SIP messages? I > am really confused on the information related to tag. > > > > thanks in advance > > > > with regards > > Raj. > > > > > > --------------------------------- > > Everyone is raving about the all-new Yahoo! Mail beta. > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 14 Nov 2006 19:26:15 +0530 > From: "nitin arora" <[EMAIL PROTECTED]> > Subject: [Sip-implementors] finding broken calls from ethereal capture > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi All, > > I am analysing the ethereal traces for SIP Calls. > I need to find out the broken calls. > > For generating the call flow diagrams I used SIP Scenario generator but > its > too difficult to point the broken calls as there are too many calls. > and only a few calls are broken. (only 10-12 out of a few thousand) > Can some body suggest me some way or some tool in which we can generate > call flow diagram of only unsuccessful calls. > > Regards > Nitin Arora > > > ------------------------------ > > Message: 7 > Date: Tue, 14 Nov 2006 20:11:13 +0530 > From: "Gaurav Kheterpal" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] finding broken calls from ethereal > capture > To: "'nitin arora'" <[EMAIL PROTECTED]>, > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Hi Nitin, > > > > You can try using SIPAnalyzer from http://ant.comm.ccu.edu.tw/sip/. It is > similar to SIP Scenario Generator. > > > > Alternatively (and a cleaner solution), you can filter Ethereal to capture > only 4xx/ 5xx (assuming these are the failed calls you are talking about). > You can set it via Ethereal Capture -> Expression > > > > & then use SIP Scenario Generator/ SIP Analyzer to draw the call flows for > the completed calls (INVITE -> 1xx -> 3xx/ 4xx). > > > > Regards, > Gaurav > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of nitin arora > Sent: Tuesday, November 14, 2006 7:26 PM > To: [email protected] > Subject: [Sip-implementors] finding broken calls from ethereal capture > > > > Hi All, > > > > I am analysing the ethereal traces for SIP Calls. > > I need to find out the broken calls. > > > > For generating the call flow diagrams I used SIP Scenario generator but > its > > too difficult to point the broken calls as there are too many calls. > > and only a few calls are broken. (only 10-12 out of a few thousand) > > Can some body suggest me some way or some tool in which we can generate > > call flow diagram of only unsuccessful calls. > > > > Regards > > Nitin Arora > > _______________________________________________ > > 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 44, Issue 23 > ************************************************ > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
