See comments linline. -Rockson
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Koshy Thomas Sent: Tuesday, June 24, 2008 5:43 PM To: [email protected] Subject: [Sip-implementors] Query regarding termination of dialog Hi, I have 2 queries regarding termination of dialog. Suppose UAC sends INVITE and UAS responds with 100 Trying. 1) Now, if UAS wants to terminate the dialog, should it send CANCEL or 487 Request terminated? [Rockson] I think 480 or 486 might be better,actually it depent on your real release secenario. CANCEL is not allowed here for UAS, CANCEL is used only to cancel previous pending INVITE client transaction, since there's no pending INVITE client transaction in UAS side, it's not desirable here 2) Similarly, if UAS has send 180 Ringing also and then wants to terminate the dialog, should it send CANCEL or 487 Request terminated? [Rockson] same reason, whatever provisional response UAS has sent before. Can you please suggest your opinion for above queries? I know that: 1)If it was a confirmed dialog, then UAS could have sent BYE. 2)Also, in cases mentioned as queries, UAC can send CANCEL. Thanks Koshy On 6/23/08, [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: Close TCP connection is a request with amandatory header > is received? (Brett Tate) > 2. Re: REG: query related to sdp (Harsha. R) > 3. Re: REG: voice not flowing (Nitin Arora) > 4. Call on Hold (emanuele bottegoni) > 5. Re: Call on Hold (Paul Kyzivat) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 22 Jun 2008 15:08:23 -0400 > From: "Brett Tate" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Close TCP connection is a request with > amandatory header is received? > To: I?aki Baz Castillo <[EMAIL PROTECTED]>, > <[email protected]> > Message-ID: > < > [EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > > Hi, in case a server receives a TCP request without a mandatory > > header (as "From" or "Via", so response is not possible) would you > > close the connection or keep it open? > > RFC 3261 doesn't really discuss when to reclaim tcp connections. It > also doesn't provide much guidance concerning their reuse. Thus a > device can basically act however it wants. However there are NAT > traversal, capacity, and call setup delay reasons to allow a tcp > connection to remain open until it needs to be reclaimed. Aspects are > discussed within draft-ietf-sip-connect-reuse and draft-ietf-sip-outbound. > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Jun 2008 09:07:25 +0530 > From: "Harsha. R" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] REG: query related to sdp > To: [EMAIL PROTECTED] > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Some more pointers > > - Check with the media/bearer implementation team. They may have some > specific codec/transport in mind. > > - If the call is a TrFO(Transcoder Free Operation) call, then choice > of codec is determined by e2e(end 2 end) requirements. > > > > Regards > Harsha > > > ------------------------------ > > Message: 3 > Date: Mon, 23 Jun 2008 10:34:36 +0530 > From: "Nitin Arora" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] REG: voice not flowing > To: [EMAIL PROTECTED] > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > I have not seen your traces. > not even gone through this mail properly. > but just suggesting to try out a thing. > possible reasons of voice not flowing could be NAT/Firewall so please > check for those settings. > > Rgds > Nitin Arora > > On Wed, Jun 18, 2008 at 9:34 AM, <[EMAIL PROTECTED]> wrote: > > > > > Hi Baz, > > > > Please find the ethereal trace renamed to txt file. I have checked > > the media address in the offer and found they are fine. Please > > suggest me whether iam missing anything. > > > > Thanks & Regards > > Rajeswari.R > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto: > > [EMAIL PROTECTED] On Behalf Of I?aki > > Baz Castillo > > Sent: Tuesday, June 17, 2008 11:42 PM > > To: [email protected] > > Subject: Re: [Sip-implementors] REG: voice not flowing > > > > El Martes, 17 de Junio de 2008, [EMAIL PROTECTED] escribi?: > > > Hi All, > > > > > > > > > > > > I have established a call between two parities , but the voice was > > > not flowing between them even though the codecs were exchanged. > > > > > > > > > > > > Please find the attachment log2.txt which shows the trace. Please > > > suggest me what's going wrong in this case. > > > > Before it do a UDP capture (using tcpdump for example). > > And check the media address in the offer and reply SDP to know which > > IP's and ports will be used as source/destination. > > > > > > -- > > I?aki Baz Castillo > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > This e-mail and any files transmitted with it are for the sole use > > of the intended recipient(s) and may contain confidential and > > privileged information. > > If you are not the intended recipient, please contact the sender by > > reply e-mail and destroy all copies of the original message. > > Any unauthorised review, use, disclosure, dissemination, forwarding, > > printing or copying of this email or any action taken in reliance on > > this e-mail is strictly prohibited and may be unlawful. > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ------------------------------ > > Message: 4 > Date: Mon, 23 Jun 2008 12:37:00 +0200 > From: "emanuele bottegoni" <[EMAIL PROTECTED]> > Subject: [Sip-implementors] Call on Hold > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > Hello community, > > I'm trying to understand how implement the call on hold feature on a > SIP Java UA. > Surfing the web I've read several comments and I've noticed a little > bit of confusion, starting from RFC3264. > Anyone can explain to me how can I implement it? > > Thanks fo all > > > > > > > ------------------------------ > > Message: 5 > Date: Mon, 23 Jun 2008 11:54:03 -0400 > From: Paul Kyzivat <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Call on Hold > To: emanuele bottegoni <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Take a look at draft-ietf-sipping-sip-offeranswer-08, especially > section 5. That should help. > > Paul > > emanuele bottegoni wrote: > > Hello community, > > > > I'm trying to understand how implement the call on hold feature on a > > SIP Java UA. > > Surfing the web I've read several comments and I've noticed a little > > bit of confusion, starting from RFC3264. > > Anyone can explain to me how can I implement it? > > > > Thanks fo all > > > > > > > > > > _______________________________________________ > > 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 63, Issue 35 > ************************************************ > _______________________________________________ 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
