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
