Take a look at RFC3842. This is the normal mechanism for MWI in SIP using SIP NOTIFY. The RFC discusses subscribing to the NOTIFY although in many actual implementations it is an unsolicited NOTIFY that is sent.
HTH, James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dorin Sent: Thursday, May 03, 2007 2:52 PM To: [email protected] Subject: [Sip-implementors] General Sip Questions..message waiting, flashing,im's , etc. Hello, I hope somebody can answer a few questions for me. 1) In general. How is a message waiting reported? Is this done through a notify? Does a UAC have to normally subscribe to this? 2) I noticed on grandstream phones that hookflash is reported through INFO messages. (Please correct me if I am wrong) Is that common? 3) If you wanted a message to show up on a LCD display, say of a grandstream phone... while a call is in progress...without interupting the current call...would you do it with: a) a MESSAGE method? b) an INVITE? c) Notify? Or some other means. Thank you, Mike it with a MESSAGE --- [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: [SIPForum-discussion] Help required > (Taduru Hariprasad) > 2. Re: REGISTER retransmission question (Rayees > Khan) > 3. Re: REGISTER retransmission question > (Reynolds, Paul) > 4. SIP T requirements (Dawn Somen-NXDR43) > 5. Regarding change logs for jain-sip nightly > builds (nabeel mohamed) > 6. Re: [SIPForum-discussion] Help required > (Broussard, Dan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 May 2007 17:06:40 +0530 > From: "Taduru Hariprasad" > <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] > [SIPForum-discussion] Help required > To: "Dawn Somen-NXDR43" <[EMAIL PROTECTED]> > Cc: [email protected], > [EMAIL PROTECTED] > Message-ID: > > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > Hi man, > > This feature called as Ring Back tone. If A is > calling B, A will here > a song instead of asusual tring tring tone. This is > completely the > Network feature. > > In Sip this will happen as follow: > > UA1 <--> Proxy1 <--> Proxy2 <--> UA2 > > Assume User Agent 1 calls UA2. A 180-Ringing message > will be formed > along with the media which need to be played as a > Ring Back tone to > UA1. > This configuration would have been done in SIP > network. > Playing these tones taken care by Media cards in the > UA1. > > And in SS7 signalling, MSC will take care in playing > the ring back tones. > > Regards > Hariprasad > > On 5/3/07, Dawn Somen-NXDR43 <[EMAIL PROTECTED]> > wrote: > > > > Hi! > > > > I am a student studying SIP and PSTN interworking > at Motorola. I tried to > > find a answer to this query but couldn't yet. > > Could you please help me with this one? > > > > My query is as follows: > > Usually it is so that we can subscribe with our > service provider of the > > cellular network for music (I mean if someone > calls us he/she can hear some > > song or music instead of the usual phone ringing) > Could you please tell me > > which device in the SIP network or PSTN network > does this music playing > > specifically and where exactly I can find more > information on this? > > > > Thanks a tonne! > > > > Regards, > > Somen > > _______________________________________________ > > This is the SIP Forum discussion mailing list > > TO UNSUBSCRIBE, or edit your delivery options, > please visit > > http://sipforum.org/mailman/listinfo/discussion > > Post to the list at [EMAIL PROTECTED] > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 3 May 2007 12:47:40 +0100 > From: "Rayees Khan" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] REGISTER > retransmission question > To: "Reynolds, Paul" <[EMAIL PROTECTED]>, > <[email protected]> > Message-ID: > > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > > I guess this is not true just in your example. This > can very well happen > in a network where a long lost REGISTER finds its > way to REGISTRAR. > Since the initial request has timed out, it is > expected that next > request received is n+1 or higher(assuming REGISTER > has Cseq n). Since > Cseq 'n' does not fit the criteria 500 error > response is good enough. > > regards > Rayees > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Reynolds, > Paul > Sent: Wednesday, May 02, 2007 6:22 PM > To: [email protected] > Subject: [Sip-implementors] REGISTER retransmission > question > > > Hi, > > I have a question regarding the correct behavior of > a registrar when > receiving a late REGISTER retransmission. > > More specifically, I have come across a UAC that, > after successfully > registering, sends a subsequent refresh request with > the same Call-ID > and CSeq values as the original (successful) > request. This second > request arrives after the initial transaction has > timed out, so is not > recognized as a retransmission. RFC3261 seems to > indicate that this > second request should fail: > > "If the Call-ID value in the existing binding > differs from the Call- ID > value in the request, the binding MUST be removed if > the expiration time > is zero and updated otherwise. If they are the same, > the registrar > compares the CSeq value. If the value is higher than > that of the > existing binding, it MUST update or remove the > binding as above. If not, > the update MUST be aborted and the request fails." > > I believe that this UAC is behaving badly, but still > desire to handle > this case in compliance with RFC3261. > > Should I: > > A) Ignore the second request > B) Send a 200 OK, but not update the registration > information > (expiration, etc) > C) Send a 200 OK, AND update the registration > D) Send a failure (and if so, what? 400?) > > Thanks for any and all input, > Paul > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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
