Hi Shailaja, the answer is inline.
Regards Markus Shailaja P <[EMAIL PROTECTED]> schrieb am 10.09.04 11:41:41: > > Thanks all of you for the information. > > In the case mentioned, User A is not doing the forking. I think UAC never do 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. No, a 2xx is End-to-End and a proxy (IPPBX) is not able to generate a BYE or an ACK to a successful response, only ACKs to Hop-by-Hop responses (3xx-6xx) and CANCEL are generated by proxies. It's only allowed the UAC to generate an ACK and to send a BYE. In your case the 2xx must forwarded to User A which answer with an ACK and then A will send a BYE. > > 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 _________________________________________________________ Mit WEB.DE FreePhone� mit h�chster Qualit�t ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
