Hi Tang Xi,
In case of INVITE and re-INVITE UAC (UE) can send CANCEL message for INVITE or re-INVITE but CANCEL will have effect as long as UAS has not already given final response (2XX). More description: CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487). Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition. See section Section 14 and Section 12 of RFC 3261 for more details. Regards Manmohan Singh Bisht On Wed, 22 Nov 2006 [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: Maximum size of Header filed Value (Attila Sipos) > 2. Query cancel re-INVITE (Tang Xi) > 3. Re: Re-Invite Cseq ([EMAIL PROTECTED]) > 4. Re: Query cancel re-INVITE (Sreenath Kulkarni) > 5. B2BUA, atomic requests and UPDATE question (Dima Polsky) > 6. Re: B2BUA, atomic requests and UPDATE question > ([EMAIL PROTECTED]) > 7. Re: B2BUA, atomic requests and UPDATE question (Dima Polsky) > 8. Re: B2BUA, atomic requests and UPDATE question (Paul Kyzivat) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 21 Nov 2006 14:24:55 -0000 > From: "Attila Sipos" <[EMAIL PROTECTED]> >Subject: Re: [Sip-implementors] Maximum size of Header filed Value >To: "krishna kalluri" <[EMAIL PROTECTED]> >Cc: [email protected] >Message-ID: > <[EMAIL PROTECTED]> >Content-Type: text/plain; charset="iso-8859-1" > > > >> > >> In my implementation I can't use the dynamic buffers. So I > >> am trying to think what is the reasonable length of each > >> header filed value. The total sip message can be 64K that is > >> fine with me. > >Don't consider a "reasonable length of each header field value". >Instead, just have a scratchpad into which you store strings. > >For me, in practice, a 6k scratchpad is large enough to store >all the SIP strings I need. > >Regards, > >Attila > > > > >> -----Original Message----- > >> From: Attila Sipos > >> Sent: 21 November 2006 14:20 > >> To: 'krishna kalluri' > >> Cc: [email protected] > >> Subject: RE: [Sip-implementors] Maximum size of Header filed Value > >> > >> > >> >>Per line 78 characters + CRLF is the maximum line limit. > >> By using comma sperated list or line folding you can go up > >> to 998 characters + CRLF. > >> > >> No, you can have more than 78 because it's just a SHOULD, > >> not a MUST.... > >> (in the real-world I have seen many lines longer than 78 characters) > >> > >> - Lines of characters in the body MUST be limited to 998 > >> characters, > >> and SHOULD be limited to 78 characters, excluding the CRLF. > >> > >> >>How about if the headers are written like below. In this > >> case also the total header field value of Route header is > >> 998 or Route appears 3 times here and there is no line > >> folding. So each is 998 characters? > >> > >> (I'm not sure I understand you.) > >> Each line is as long as the text you see > >> > >> Regards, > >> > >> Attila > >> > >> > >> > >> -----Original Message----- > >> From: krishna kalluri [mailto:[EMAIL PROTECTED] > >> Sent: 21 November 2006 14:09 > >> To: Attila Sipos > >> Cc: [email protected] > >> Subject: Re: [Sip-implementors] Maximum size of Header filed Value > >> > >> > >> Hi, > >> Per line 78 characters + CRLF is the maximum line limit. By > >> using comma sperated list or line folding you can go up to > >> 998 characters + CRLF. > >> > >> How about if the headers are written like below. In this > >> case also the total header field value of Route header is > >> 998 or Route appears 3 times here and there is no line > >> folding. So each is 998 characters? > >> > >> Route: <sip:[EMAIL PROTECTED]> > >> Subject: Lunch > >> Route: <sip:[EMAIL PROTECTED]> > >> Route: < sip:[EMAIL PROTECTED]> > >> > >> In my implementation I can't use the dynamic buffers. So I > >> am trying to think what is the reasonable length of each > >> header filed value. The total sip message can be 64K that is > >> fine with me. > >> > >> Thanks > >> /Krishna > >> > >> > >> On 11/21/06, Attila Sipos <[EMAIL PROTECTED]> wrote: > >> > >> > >> OK, thinking about this again, it looks like that > >> header field can be any length but.... > >> you can't have any more than 998 characters on one line. > >> > >> This does not actually restrict the length of the header because > >> you can do line-folding. > >> > >> So, an example of line-folding: > >> Route: <sip:[EMAIL PROTECTED]>, <sip:[EMAIL PROTECTED]>, > >> <sip:[EMAIL PROTECTED]> > >> > >> But it looks like the actual length in between CRLFs in the body > >> is restricted to 998. > >> > >> Regards, > >> > >> Attila > >> > >> -----Original Message----- > >> From: krishna kalluri [mailto:[EMAIL PROTECTED] > >> Sent: 21 November 2006 10:59 > >> To: Attila Sipos; [email protected] > >> Subject: Re: [Sip-implementors] Maximum size of Header filed Value > >> > >> > >> Hi, > >> My question is about the sip header filed value so it maps > >> to the "field body" in RFC 2822. > >> > >> Eg: Route:<sip:[EMAIL PROTECTED] > .... > >> > >> So the value of the Route header filed (any sip header > >> filed) can be any length or maximum 998 characters. > >> > >> Thanks > >> /Krishna > >> > >> > >> On 11/21/06, Attila Sipos <[EMAIL PROTECTED]> wrote: > >> > >> There is no limit in header field size. > >> > >> The only limit is the total size of a SIP message which > >> can be up to 65535 bytes. > >> > >> In RFC2822, the 998 character limit is defined in the grammar: > >> > >> message = (fields / obs-fields) > >> [CRLF body] > >> body = *(*998text CRLF) *998text > >> > >> SIP however has no such restriction in the grammar. > >> > >> Note also that RFC3261 says: > >> >> (SIP allows header fields that > >> >> would not be valid RFC 2822 header fields, for example.) > >> > >> Regards, > >> > >> Attila > >> > >> > >> >> -----Original Message----- > >> >> From: [EMAIL PROTECTED] > >> >> [mailto:[EMAIL PROTECTED] > >> Behalf Of krishna > >> >> kalluri > >> >> Sent: 20 November 2006 21:08 > >> >> To: [email protected] > >> >> Subject: [Sip-implementors] Maximum size of Header filed Value > >> >> > >> >> > >> >> Hi, > >> >> I am reading the RFC 3261 and I have a question about > >> >> maximum size of header > >> >> field value. > >> >> Sip follows RFC 2822. Does this mean the maximum length of > >> >> the header field > >> >> value is 998 Characters? > >> >> > >> >> Sip header filed values can be written in different format. > >> >> Here Route header and value was written in 3 ways. > >> >> Irrespective of the way > >> >> we write the maximum length of the header filed value is 998 > >> >> characters? > >> >> > >> >> Route: <sip:[EMAIL PROTECTED]> > >> >> Subject: Lunch > >> >> Route: <sip:[EMAIL PROTECTED]> > >> >> Route: <sip:[EMAIL PROTECTED]> > >> >> > >> >> Route: < sip:[EMAIL PROTECTED]>, < sip:[EMAIL PROTECTED]> > >> >> Route: <sip:[EMAIL PROTECTED] > > >> >> Subject: Lunch > >> >> > >> >> Subject: Lunch > >> >> Route: <sip:[EMAIL PROTECTED]>, < sip:[EMAIL PROTECTED]>, > >> >> <sip:[EMAIL PROTECTED]> > >> >> > >> >> Thanks > >> >> /Krishna > >> >> _______________________________________________ > >> >> Sip-implementors mailing list > >> >> [email protected] > >> >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> >> > >> > > > >------------------------------ > >Message: 2 >Date: Wed, 22 Nov 2006 13:13:30 +0800 > From: "Tang Xi" <[EMAIL PROTECTED]> >Subject: [Sip-implementors] Query cancel re-INVITE >To: sip-implementors <[email protected]> >Message-ID: > <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Hi sip group: > >I have the following question: > >1) UAC send a re-INVITE to UAS >2) UAS answer a 18x response. > >then can UAC send CANCEL to cancel the re-INVITE? > >Thanks in advance! > > >------------------------------ > >Message: 3 >Date: Wed, 22 Nov 2006 00:28:11 -0500 > From: [EMAIL PROTECTED] >Subject: Re: [Sip-implementors] Re-Invite Cseq >To: [email protected] >Message-ID: <[EMAIL PROTECTED]> > > From: Paul Kyzivat <[EMAIL PROTECTED]> > > Brett isn't saying this strongly enough. From 12.2.2 of 3261: > > If the remote sequence number was not empty, and > the sequence number of the request is greater than the remote > sequence number, the request is in order. It is possible for the > CSeq sequence number to be higher than the remote sequence number by > more than one. This is not an error condition, and a UAS SHOULD be > prepared to receive and process requests with CSeq values more than > one higher than the previous received request. > >And RFC 3261 isn't saying it strongly enough, either: A UAS *must* be >prepared to receive and process requests with CSeq values more than >one higher than the previous received request, if it expects to >successfully interoperate with UACs. You can argue that your UAS is >standard-conformant because the above statement is only a SHOULD >requirement, but you won't be able to make your UAS work in practice. > >Dale > > >------------------------------ > >Message: 4 >Date: Wed, 22 Nov 2006 11:14:36 +0530 (IST) > From: Sreenath Kulkarni <[EMAIL PROTECTED]> >Subject: Re: [Sip-implementors] Query cancel re-INVITE >To: Tang Xi <[EMAIL PROTECTED]>, sip-implementors > <[email protected]> >Message-ID: <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ascii > >Hi, > >This is quite possible. You can send Cancel any INVITE once u receive 1XX >and before receving 2XX response. > >/Sreenath > >----- Original Message ---- > From: Tang Xi <[EMAIL PROTECTED]> >To: sip-implementors <[email protected]> >Sent: Wednesday, 22 November, 2006 10:43:30 AM >Subject: [Sip-implementors] Query cancel re-INVITE > >Hi sip group: > >I have the following question: > >1) UAC send a re-INVITE to UAS >2) UAS answer a 18x response. > >then can UAC send CANCEL to cancel the re-INVITE? > >Thanks in advance! >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > >__________________________________________________________ >Yahoo! India Answers: Share what you know. Learn something new >http://in.answers.yahoo.com/ > >------------------------------ > >Message: 5 >Date: Wed, 22 Nov 2006 03:14:32 -0600 > From: "Dima Polsky" <[EMAIL PROTECTED]> >Subject: [Sip-implementors] B2BUA, atomic requests and UPDATE question >To: <[email protected]> >Message-ID: > <[EMAIL PROTECTED]> >Content-Type: text/plain; charset="us-ascii" > >Hi, > >RFC 3261 states that - "Note that request processing is atomic. If a >request is accepted, all state changes associated with it MUST be >performed. If it is rejected, all state changes MUST NOT be >performed. " > >Now a B2BUA is described in the RFC as a concatenation of a UAC and a >UAS. If a call is established through the B2BUA, and an OPTIONS request >is received by one side of the B2BUA, can it answer the request with a >final response or should it wait for a response of the other side to the >forwarded request ? If it waits, can it process additional overlapping >requests? For example another OPTIONS or INFO? > > > >Best Regards > >Polsky Dima > > > > > >------------------------------ > >Message: 6 >Date: Wed, 22 Nov 2006 08:17:14 -0500 > From: [EMAIL PROTECTED] >Subject: Re: [Sip-implementors] B2BUA, atomic requests and UPDATE > question >To: [email protected] >Message-ID: <[EMAIL PROTECTED]> > > From: "Dima Polsky" <[EMAIL PROTECTED]> > > Now a B2BUA is described in the RFC as a concatenation of a UAC and > a UAS. If a call is established through the B2BUA, and an OPTIONS > request is received by one side of the B2BUA, can it answer the > request with a final response or should it wait for a response of > the other side to the forwarded request ? If it waits, can it > process additional overlapping requests? For example another > OPTIONS or INFO? > >It can do any of these, as the SIP transactions on one side of the >B2BUA are independent (from the SIP standard point of view) from the >SIP transactions on the other side. > >Dale > > >------------------------------ > >Message: 7 >Date: Wed, 22 Nov 2006 08:10:16 -0600 > From: "Dima Polsky" <[EMAIL PROTECTED]> >Subject: Re: [Sip-implementors] B2BUA, atomic requests and UPDATE > question >To: <[email protected]> >Message-ID: > <[EMAIL PROTECTED]> >Content-Type: text/plain; charset="us-ascii" > >Although transactions are independent the info that passes in those >transactions is related to both UA ( SDP for example, INFO, or query for >OPTIONS), let's look at mid-dialog UPDATE for a more extreme example - >it carries a new sdp offer which is of little relevance to the B2BUA but >should be forwarded from side to side. If the UAS responds to the UPDATE >request before the UAC received an answer from the other user it may >create an inconsistent state (if user declines the offer), so should he >wait? > >-----Original Message----- > From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Wednesday, November 22, 2006 3:17 PM >To: [email protected] >Subject: Re: [Sip-implementors] B2BUA, atomic requests and UPDATE >question > > From: "Dima Polsky" <[EMAIL PROTECTED]> > > Now a B2BUA is described in the RFC as a concatenation of a UAC and > a UAS. If a call is established through the B2BUA, and an OPTIONS > request is received by one side of the B2BUA, can it answer the > request with a final response or should it wait for a response of > the other side to the forwarded request ? If it waits, can it > process additional overlapping requests? For example another > OPTIONS or INFO? > >It can do any of these, as the SIP transactions on one side of the >B2BUA are independent (from the SIP standard point of view) from the >SIP transactions on the other side. > >Dale >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > >------------------------------ > >Message: 8 >Date: Wed, 22 Nov 2006 09:39:20 -0500 > From: Paul Kyzivat <[EMAIL PROTECTED]> >Subject: Re: [Sip-implementors] B2BUA, atomic requests and UPDATE > question >To: Dima Polsky <[EMAIL PROTECTED]> >Cc: [email protected] >Message-ID: <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > >Dima Polsky wrote: > > Although transactions are independent the info that passes in those > > transactions is related to both UA ( SDP for example, INFO, or query for > > OPTIONS), let's look at mid-dialog UPDATE for a more extreme example - > > it carries a new sdp offer which is of little relevance to the B2BUA but > > should be forwarded from side to side. > >While what you say may be true for some B2BUAs, it is not something that >can be asserted generally for all B2BUAs. Apparently you have in mind a >sort of B2BUA where this is the case. > > > If the UAS responds to the UPDATE > > request before the UAC received an answer from the other user it may > > create an inconsistent state (if user declines the offer), so should he > > wait? > >3261 doesn't provide any requirements for B2BUAs other than that the >each side shall follow the rules for a UA. If you want some predictable >behavior over and above that, then it is up to you, or somebody, to >specify it. > >It sounds like you are talking about the fabled "transparent" B2BUA. But >AFAIK there are no formal specifications for such a thing. (I guess >perhaps you could consider some of the IMS specifications to be such, >but they are very specialized.) > > Paul > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Wednesday, November 22, 2006 3:17 PM > > To: [email protected] > > Subject: Re: [Sip-implementors] B2BUA, atomic requests and UPDATE > > question > > > > From: "Dima Polsky" <[EMAIL PROTECTED]> > > > > Now a B2BUA is described in the RFC as a concatenation of a UAC and > > a UAS. If a call is established through the B2BUA, and an OPTIONS > > request is received by one side of the B2BUA, can it answer the > > request with a final response or should it wait for a response of > > the other side to the forwarded request ? If it waits, can it > > process additional overlapping requests? For example another > > OPTIONS or INFO? > > > > It can do any of these, as the SIP transactions on one side of the > > B2BUA are independent (from the SIP standard point of view) from the > > SIP transactions on the other side. > > > > Dale > > _______________________________________________ > > 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 > > > > >------------------------------ > >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > >End of Sip-implementors Digest, Vol 44, Issue 39 >************************************************ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
