Hi Ranjit, The 100 is "100 Trying". It does not imply ringing. Most proxies return this immediately to stop the UAC from retransmitting the INVITE. It tells the UAC that the next-hop element (the proxy in this case) has received the request and is processing it. 180 is for ringing. According to bis-05, an element receiving an INVITE should respond immediately with a 100-Trying if the element knows that it will not be able to send a response within 200ms (the exact time is still being studied/debated).
cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] ----- Original Message ----- From: "Ranjit Avasarala" <[EMAIL PROTECTED]> To: "'Bob Penfield'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, November 12, 2001 6:51 PM Subject: RE: [Sip-implementors] Handling 302 at UAC > Hi Bob > > I have on query on the sequence diagram u have shown below: > > usually the response for INVITE is a 200 OK. So why r u showing 100 ? > actually 100 imlies ringing ... > > > > Regards > Ranjit > > -----Original Message----- > From: Bob Penfield [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 12, 2001 7:26 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Handling 302 at UAC > > > The text is talking about the Via header the proxy places in the new > request, not the Via one from the previous hop. You would have checked > the > Via for a retransmission before sending the request that resulted in the > 302 > response. > > UAC Proxy NH1 NH2 > | F1 INVITE | | | > |------------>| | | > | F2 100 | | | > |<------------| F3 INVITE | | > | |----------->| | > | | F4 302 | | > | |<-----------| | > | | F5 ACK | | > | |----------->| | > | | | F6 INVITE | > | |------------------------>| > > The proxy inserts a branch ID in its Via in the invite it sends to the > first > next-hop (F3). When it gets the 302 response, it sends the invite to the > second next-hop (F6). This Via in the new request must get a new branch > id > so responses to F6 are not confused with responses to F3. > > Note that the proxy may have forked the invite to multiple next-hops > (NH1s) > when it first sent it on (F3), and the 302 may have indicated multiple > contacts resulting in multiple NH2s at F6. All of these client > transactions > (one per INVITE sent at F3 and F6) are associated with the server > transaction (F1). They have the same From, To, Call-ID, and CSeq. Each > of > the client transactions must have a unique branch ID in the top Via > inserted > by the proxy. > > I hope that helps. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > [EMAIL PROTECTED] > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, November 12, 2001 1:39 AM > Subject: [Sip-implementors] Handling 302 at UAC > > > > > > > > Hi, > > The RFC bis-05 mentions that there are two > > approaches to handling a 302 received at a client. > > The first approach seems to suggest that the From, > > To, Call-id, Cseq of the new request can be kept > > the same with the addition of a new branch identifier > > in the Via field. > > > > Does this imply that proxies should examine > > the Via branch of the previous hop to determine if > > a request is a retransmission. As far as i know, a > > proxy receiving such a request will note that the > > From, To, Call-ID, Cseq has not changed and hence > > mistake this for a retransmission from the client. > > > > Or am i missing something ? > > > > Thanks in advance, > > Subhash Nayak > > > > > > _______________________________________________ > > 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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
