Hi All, I have a small query related to Precondition. Can we have a Sip Invite message with *"Require: Precondition"* and without any *sdp offer* .
Regards, Pravin On 4/3/06, [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: Repeated Headers problem (Manikarnike Sridhar-Q16946) > 2. Re: Multi homed Proxy (Kedar Karmarkar) > 3. Re: Redirected messages and Route headers (Dale R. Worley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 3 Apr 2006 20:30:47 +0800 > From: "Manikarnike Sridhar-Q16946" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Repeated Headers problem > To: <[EMAIL PROTECTED]>, <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Per draft-ietf-sipping-torture-tests-09.txt, section 3.3.8, 400 Bad > request needs to be sent. > > Regards, > Sridhar > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Manjunath Warad > > Sent: Monday, April 03, 2006 5:35 PM > > To: [email protected] > > Subject: [Sip-implementors] Repeated Headers problem > > > > > > Hi All, > > In case of repeated headers are present in the > > request/response then what must be the behaviour of the > > receiving entity(UA/Proxy)? > > For e.g., > > > > INVITE sip:[EMAIL PROTECTED] SIP/2.0 > > Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 > > To: Bob <sip:[EMAIL PROTECTED]> > > From: Alice <sip:[EMAIL PROTECTED]>;tag=1234575684 > > From: Alice <sip:[EMAIL PROTECTED]>;tag=1928301774 > > Call-ID: a84b4c76e66710 > > CSeq: 314159 INVITE > > Max-Forwards: 70 > > Contact: <sip:[EMAIL PROTECTED]> > > Content-Type: application/pkcs7-mime; > > smime-type=enveloped-data; > > name=smime.p7m > > Content-Disposition: attachment; filename=smime.p7m > > handling=required > > > > > > Please let me know the behaviour along with some supported > > statements in the RFC. > > > > Rgds, > > Manju > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listin> fo/sip-implementors > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 3 Apr 2006 09:18:16 -0400 > From: "Kedar Karmarkar" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Multi homed Proxy > To: "Niranjan Gopalakrishnan" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Perhaps there is a separation of functionality like secure > access/authentication provided in the external proxy which is not required > for the internal proxy to make calls within the local domain which can be > handled by seperating the functionality into two proxies, but also > supports > a "feature" which can run both proxies in a single instance? > > On 3/31/06, Niranjan Gopalakrishnan <[EMAIL PROTECTED]> wrote: > > > > Im working with an implementation of a Multi homed proxy - uses 2 > > interfaces, I presume one external and one internal. > > On receiving a request on one interface, it forwards it to itself on the > > destination interface, eventually adding itself twice in the > > Record-Route header (with r2 parameter) before forwarding the request. > > Response is processed similarly. > > > > Why is such a behaviour required? If this is to seperate the netowrk > > topology (external, internal) the same can be achieved by an IP gateway. > > > > I am sure there is only one instance of the Proxy running on the host. > > > > This behaviour is not affecting our functionality. But I need to > > understand the reason behind it. > > > > Any pointers appreciated. > > > > Thanks. > > Niranjan Gopalakrishnan > > Senior Engineer, Call Control, Veraz Networks. > > [EMAIL PROTECTED] > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ------------------------------ > > Message: 3 > Date: Mon, 03 Apr 2006 10:03:01 -0400 > From: "Dale R. Worley" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Redirected messages and Route headers > To: Sip-Implementors <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > On Mon, 2006-04-03 at 11:09 +0300, Fortinsky Michael wrote: > > I have a question related to redirection and Route headers. > > Assume the following scenario: > > - UA sends out an INVITE containing Route headers > > - UA receives a 3xx response with new contact information > > - UA will now send a new INVITE to the new contact > > > > What Route headers should the new INVITE contain? > > Should it include the same Route headers as in the original INVITE? > > Should it just forget about the original Route headers? > > Presumably, the Route headers in the original INVITE describe how to get > to its request-URI, so they are not relevant to the new INVITE. The > exception would be if the route headers in the original INVITE were > added due to some general policy regarding how to route INVITEs, and if > that policy applies to the new request-URI as well. > > Dale > > --- > interop.pingtel.com -- the public SIP phone interoperability test server > > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > End of Sip-implementors Digest, Vol 37, Issue 4 > *********************************************** > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
