It doesn't matter where your client sits in the signaling path - It should be able to accept both multiple early and confirmed dialogs.
Chris. -----Original Message----- From: Shailaja P [mailto:[EMAIL PROTECTED] Sent: 10 September 2004 10:36 To: [EMAIL PROTECTED]; Brett Tate Subject: [Sip-implementors] Re: Handling Multiple Dialogs Thanks all of you for the information. In the case mentioned, User A is not doing the forking. It is the IPPBX which is doing the forking. So, on receiving the second 2xx response, should the IPPBX forward the 2xx response to User A or send a BYE by itself. Also, if User A is not doing the forking, should he still accept multiple 1xx response (from different Users forwarded by IPPBX) ? Thanks & Regards, Shailaja. [EMAIL PROTECTED] wrote: > Send Sip-implementors mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.columbia.edu/mailman/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: Handling Multiple Dialogs (Brett Tate) > 2. newbie question (Mohammed Smadi) > 3. RE: BYE message problem (Anil Bollineni) > 4. Re: newbie question ([EMAIL PROTECTED]) > 5. RE: Broadsoft Media Server (sam n) > 6. RE: Broadsoft Media Server ([EMAIL PROTECTED]) > 7. RE: Broadsoft Media Server (sam n) > 8. RE: REGISTER with a Tel uri (Pang Xiaogang-r63373) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 9 Sep 2004 13:08:16 -0400 > From: "Brett Tate" <[EMAIL PROTECTED]> > Subject: RE: [Sip-implementors] Handling Multiple Dialogs > To: "'Sip Implementors'" <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="US-ASCII" > > > IMO, User Agent of A, should create > > one more early dialogs. > > > > Create Early dialogs for both, B and C, > > > > If you receive a 2xx > > Confirm the dialog send ACK , and send > > a BYE on the other Early dialog ! > > Sending the BYE is not needed unless > an INVITE 2xx is also received for the > other dialog. This is because the forking > device is required to CANCEL the other > dialogs after receiving an INVITE 2xx > on one of the branches. > > > If you receive a non-2xx, > > ACK it and terminate the dialog, and > > send a BYE on the other Early dialog ! > > Sending the BYE is not needed unless > an INVITE 2xx is received for the other > dialog. This is because of the reason > mentioned above and because of how non-2xx > final responses get handled/queued at a > forking device. > > ------------------------------ > > Message: 2 > Date: Wed, 01 Sep 2004 14:06:23 -0400 > From: Mohammed Smadi <[EMAIL PROTECTED]> > Subject: [Sip-implementors] newbie question > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii; format=flowed > > hi; > i just signed up with this list. Is there an easy way of knowing if a > certain sip UA has implemented a given RFC or method? > > ------------------------------ > > Message: 3 > Date: Wed, 1 Sep 2004 14:41:26 -0700 > From: "Anil Bollineni" <[EMAIL PROTECTED]> > Subject: RE: [Sip-implementors] BYE message problem > To: "Charles Eckel" <[EMAIL PROTECTED]>, "jenning zhang" > <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="US-ASCII" > > The BYE is sent by the other party and that's why Contact is different > in INVITE and BYE. Is the original INVITE is generated by gateway or > proxy, because the IP in SDP and VIA IP is same. If the call is ended > prematurely on gateway side and possibly the other party is trying to > end the call this problem may happen. But unless we have complete call > flow it will be unable to predict what went wrong. > > Cheers, > Anil > > This email contains material that is confidential. The content of this > email is for the sole use of the intended recipient(s). Any review or > distribution by persons other than the intended recipient(s) without the > express permission of NetScreen Technologies, Inc. is strictly > prohibited. If you are not the intended recipient, please contact the > sender and delete/destroy all copies of this email and any related > attachments. NetScreen does not guarantee the accuracy or completeness > of third party materials or information. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Charles > Eckel > Sent: Wednesday, September 01, 2004 1:10 PM > To: jenning zhang > Cc: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] BYE message problem > > The BYE is ok and should be forward by the Proxy based on the Route > header to 24.226.0.126:5060. My guess is that the 481 is being sent by > 24.226.0.126, not the proxy. The possible reasons for this are numerous, > > but it hard to identify what the problem is without the complete call > flow. > > Cheers, > Charles > > jenning zhang wrote: > > Hi there, > > > > Could some tell me what is problem with my BYE message, the proxy > always > > returns "481 Call Leg/Transaction Does Not Exist " > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > > > > INVITE sip:[EMAIL PROTECTED]:5060;user=phone;transport=udp > SIP/2.0 > > Via: SIP/2.0/UDP > > sip2.4ztech.com:5060;branch=eb2ba54e-361b5d59-15d5b31d-4fb80d8-1 > > Record-Route: > > > <sip:[EMAIL PROTECTED]:5060;mad > dr=sip2.4ztech.com;transport=udp> > > > > Via: SIP/2.0/UDP 24.226.0.126:5060;received=24.226.0.126 > > From: <sip:[EMAIL PROTECTED]>;tag=9F8236D4-1F2E > > To: <sip:[EMAIL PROTECTED]> > > Date: Mon, 30 Aug 2004 23:16:40 GMT > > Call-ID: [EMAIL PROTECTED] > > Supported: timer,100rel > > Min-SE: 1800 > > Cisco-Guid: 2076193368-4195422680-3218703037-761164568 > > User-Agent: Cisco-SIPGateway/IOS-12.x > > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, > > SUBSCRIBE, NOTIFY, INFO > > CSeq: 101 INVITE > > Max-Forwards: 5 > > Remote-Party-ID: > > <sip:[EMAIL PROTECTED]>;party=calling;screen=yes;privacy=off > > Timestamp: 1093907800 > > Contact: <sip:[EMAIL PROTECTED]:5060> > > Expires: 180 > > Allow-Events: telephone-event > > Content-Type: application/sdp > > Content-Length: 247 > > > > v=0 > > o=CiscoSystemsSIP-GW-UserAgent 7721 7097 IN IP4 24.226.0.126 > > s=SIP Call > > c=IN IP4 24.226.0.126 > > t=0 0 > > m=audio 18240 RTP/AVP 0 101 > > c=IN IP4 24.226.0.126 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-16 > > a=ptime:20 > > . > > . > > . > > . > > . > > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<< > > > > BYE > > > sip:[EMAIL PROTECTED]:5060;tran > sport=udp > > > > SIP/2.0 > > Via: SIP/2.0/UDP 24.226.1.217:5060;branch=z9hG4bK4133B6A7 > > From: <sip:[EMAIL PROTECTED]>;tag=9F8236D4-1F2E > > To: <sip:[EMAIL PROTECTED]>;tag=A3F462D1-3G5E > > Contact: <sip:[EMAIL PROTECTED]> > > Route: <sip:[EMAIL PROTECTED]:5060> > > Call-ID: [EMAIL PROTECTED] > > CSeq: 102 BYE > > Content-Length: 0 > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > > > > SIP/2.0 100 Trying > > Via: SIP/2.0/UDP > > 24.226.1.217:5060;received=24.226.1.217;branch=z9hG4bK4133B6A7 > > Call-ID: [EMAIL PROTECTED] > > From: <sip:[EMAIL PROTECTED]>;tag=9F8236D4-1F2E > > To: <sip:[EMAIL PROTECTED]>;tag=A3F462D1-3G5E > > CSeq: 102 BYE > > Content-Length: 0 > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > > > > SIP/2.0 481 Call Leg/Transaction Does Not Exist > > Via: SIP/2.0/UDP > > 24.226.1.217:5060;received=24.226.1.217;branch=z9hG4bK4133B6A7 > > From: <sip:[EMAIL PROTECTED]>;tag=9F8236D4-1F2E > > To: <sip:[EMAIL PROTECTED]>;tag=A3F462D1-3G5E > > Call-ID: [EMAIL PROTECTED] > > CSeq: 102 BYE > > Content-Length: 0 > > > > > > > > Thank you very much > > > > > > Jenning Zhang > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > ------------------------------ > > Message: 4 > Date: Fri, 10 Sep 2004 08:39:21 +1000 > From: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] newbie question > To: Mohammed Smadi <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED] > > > Content-Type: text/plain; charset="us-ascii" > > Mohammed, > The SIP OPTIONS request can be used to query capabilities of a UA. > Section 11 of RFC 3261 describes this method. > > You can form a 'basic' OPTIONS message to receive the 200 OK > response and look at the Allow and Supported header fields (for example) > to understand the capabilities of the other UA - eg. the presence of > "timer" in the Supported header indicates that the UA is capable of > negotiating SIP Session Expires feature, currently a draft. > > Or you may wish to target a specifc query - by including a Require > header and token in the request or including a SDP offer to gauge the UA's > ability to support a certain codec. > > Regards, > > Wayne Davies > > Mohammed Smadi <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 02/09/2004 04:06 AM > > > To: [EMAIL PROTECTED] > cc: > Subject: [Sip-implementors] newbie question > > hi; > i just signed up with this list. Is there an easy way of knowing if a > certain sip UA has implemented a given RFC or method? > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > ************************************************************************ ****** > - NOTICE FROM DIMENSION DATA AUSTRALIA > This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. > > Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. > ************************************************************************ ****** > > ------------------------------ > > Message: 5 > Date: Fri, 10 Sep 2004 09:50:59 +1000 > From: sam n <[EMAIL PROTECTED]> > Subject: RE: [Sip-implementors] Broadsoft Media Server > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII > > Hi Ben, Wayne, and others > > I have been looking at the broadsoft documents entitled > > "Broadworks Access Device Interoperability Test Sample Call Flows" > and > "Broadworks SIP Access Interface Internetworking Guide" > > for information on conferencing, but they both assume that the mixing > is done by the UA, and not the Media Server. > I have traced through the logs of the Application Server when using > CommPilot CallManager and, yes you're both right regarding the > termination of various call-legs, etc etc. Upon starting a conference, > CallManager sends out a CAP message <confStart>, and from there, the > AS does the rest. It subsequently INVITES the MS several times, > terminates some call-legs, and establishes new ones. > > The only issue is that i'm only using SIP. Is there a way to achieve > similar functionality without using any XML CAP messages? > > Many thanks for your time and help. > > Regards, > Sam > > ------------------------------ > > Message: 6 > Date: Fri, 10 Sep 2004 10:30:31 +1000 > From: [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] Broadsoft Media Server > To: sam n <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], > [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED] > > > Content-Type: text/plain; charset="us-ascii" > > Sam, > Sorry but no. Initiating conference from the phone and the phone > will do the mixing, initiate conferencing through CP CallManager and the > AS will invoke the MS to do the mixing and terminate the media with > signalling intiated from the AS. The functionality you may need may have > to be provided by another device - from rel 10 Broadsoft introduced a > conferencing server and I am sure many other vendors have a similar box > that will do the function you require. > > Regards, > > Wayne Davies > > sam n <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 10/09/2004 09:50 AM > Please respond to sam n > > > To: [EMAIL PROTECTED] > cc: > Subject: RE: [Sip-implementors] Broadsoft Media Server > > Hi Ben, Wayne, and others > > I have been looking at the broadsoft documents entitled > > "Broadworks Access Device Interoperability Test Sample Call Flows" > and > "Broadworks SIP Access Interface Internetworking Guide" > > for information on conferencing, but they both assume that the mixing > is done by the UA, and not the Media Server. > I have traced through the logs of the Application Server when using > CommPilot CallManager and, yes you're both right regarding the > termination of various call-legs, etc etc. Upon starting a conference, > CallManager sends out a CAP message <confStart>, and from there, the > AS does the rest. It subsequently INVITES the MS several times, > terminates some call-legs, and establishes new ones. > > The only issue is that i'm only using SIP. Is there a way to achieve > similar functionality without using any XML CAP messages? > > Many thanks for your time and help. > > Regards, > Sam > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > ************************************************************************ ****** > - NOTICE FROM DIMENSION DATA AUSTRALIA > This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. > > Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. > ************************************************************************ ****** > > ------------------------------ > > Message: 7 > Date: Fri, 10 Sep 2004 10:55:40 +1000 > From: sam n <[EMAIL PROTECTED]> > Subject: RE: [Sip-implementors] Broadsoft Media Server > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII > > Hi Wayne, > > I asked BroadSoft this question a week ago, and didn't get a response! > Thanks for helping...looks like i'll have to start looking into some > audio frameworks that support mixing. > > Cheers, > Sam > > ------------------------------ > > Message: 8 > Date: Fri, 10 Sep 2004 09:42:56 +0800 > From: Pang Xiaogang-r63373 <[EMAIL PROTECTED]> > Subject: RE: [Sip-implementors] REGISTER with a Tel uri > To: Paul Kyzivat <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], Zhu Jacob-r62823 > <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain > > Hi Paul, > > I have doubt of the URI: <sip:[EMAIL PROTECTED];user=phone> > > Say I have 2 Uas and registered to different registrar with different phone number > > UA1: <sip:[EMAIL PROTECTED];user=phone> > UA2: <sip:[EMAIL PROTECTED];user=phone> > > If UA2 makes a call to UA1, it dials "1234", but how can it decide UA1's domain? (i.e. sip.freescale.com.) > > Regards, > David > > [EMAIL PROTECTED] > --------------------------------- > Freescale > General Business Information > Freescale Internal Use Only > Freescale Confidential Proprietary > > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 09, 2004 8:57 PM > To: [EMAIL PROTECTED] > Cc: Xiaogang Pang; [EMAIL PROTECTED]; Jacob Zhu > Subject: Re: [Sip-implementors] REGISTER with a Tel uri > > [EMAIL PROTECTED] wrote: > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] Behalf Of ext Paul > >>Kyzivat > >>Sent: 08.September.2004 22:24 > >>To: Pang Xiaogang-r63373 > >>Cc: [EMAIL PROTECTED]; Zhu Jacob-r62823 > >>Subject: Re: [Sip-implementors] REGISTER with a Tel uri > > > > > >>If you want to avoid ENUM, then you should probably avoid > >>tel: as well. > >>Instead, use sip uris with the user=phone parameter: > >> > >> REGISTER: sip:freescale.com > >> To: <sip:[EMAIL PROTECTED];user=phone> > >> From: <sip:[EMAIL PROTECTED];user=phone> > >> Contact: sip:[EMAIL PROTECTED] > > > > I don't know what value user=phone adds here. > > Its value is to say that what is in the user part is a phone number. 3261 has defined two namespaces for the user part, distinguished by the > value of the user parameter, so it is good to be clear about which > namespace is being used. > > Of course many systems don't really have two namespaces, and instead > treat them as equivalent. If so, then it doesn't matter if you specify > it or not. But unless the UA is certain about the conventions of the > registrar it is safe to be explicit. > > Paul > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 18, Issue 17 > ************************************************ _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Dear Friends of Ubiquity Software: As you may have noticed, Ubiquity Software began using the web domain ubiquity.com earlier this year in addition to the previously established ubiquity.net for our website and email communications to you. However, since that time, a dispute has emerged with respect to actual ownership of the ubiquity.com domain. As an international software company founded over decade ago, you can always reach Ubiquity Software under the website www.ubiquity.net <http://www.ubiquity.net/> and via email at @ubiquity.net. However, we have also chosen to expand our domain to the more specific www.ubiquitysoftware.com <http://www.ubiquitysoftware.com/> for web and @ubiquitysoftware.com for email communications. Please use either the historical ubiquity.net or begin to use the new ubiquitysoftware.com domain for all email communications to Ubiquity employees from now on. Thank you. Regards, Ubiquity Software www.ubiquitysoftware.com <http://www.ubiquitysoftware.com/> [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
