Re: Clearing up of 486 Busy when INVITE caller dies...

>Now SIP phone A dies and never comes back.
>Furthermore, nobody is  
>available to answer C, so it keeps ringing, and
>ringing, and  ringing......

Typically UAS (of C) shall start a timer on receiving
INVITE. if C user does not answer the call within that
timer, then UAS shall send back appropriate error
response and shall stop Ringing. On receiving this
error response, UAC shall terminate the call. This
error response shall also terminate the transaction of
any stateful proxy(Proxy B in your case) in the path.

The UAC also starts a timer after initiating the call
with INVITE. If that timer expires before receiving
200 OK then it shall send CANCEL to terminate the
INVITE transaction. In fact, 487 response of INVITE
(followed by INVITE) terminates the INVITE dialog.

Therefore, depending on which timer expires first,
either A shall send CANCEL to cancel INVITE or C shall
send error response to terminate INVITE dialog in your
case.

>Now if SIP Phone A comes back up and calls C again
>(through B), we will get a 486 busy.

If UAC and UAS starts the timer as specified above,
SIP phone shall not get 486 Busy in your described

Re: Clearing up of 486 Busy when INVITE caller dies...

Thanks for your response.

Remember, in my scenario the UAC died.  Therefore,  it will not be  
having any timers that expire nor will it send any CANCELs.    
Therefore, it is completely dependent on the proxy B or UAS C to  
clean up.  (And please no responses about UAC solutions to this  
problem,  because the whole point is to test proxy/UAS scenarios with  
somewhat flaky UACs.  It "dies" because it is suppose to!:)

I can imagine that a UAS can be implemented to just let the phone  
ring and ring and ring.  Is there anywhere in any RFC that indicates  
UAS's or proxies should terminate an incoming call if it isn't  
answered within a certain time? Thinking of analog phones, as long as  
the caller doesn't hang up and the callee doesn't have answering- 
machine/voicemail,  the phone will keep ringing and ringing and  
ringing at the callee.

So...  I am definitely encountering an indefinite 486 busy response  
with a couple different SIP phones (and an analog phone connected to  
a cisco gateway).   This 486 never clears up, unless the phone is  
answered (and hung up).

Would you expect a transaction stateful proxy would cancel a call if  
it rings for so long without being answered?  I wish the answer was  
yes, but I suspect the answer is that typical UAS and proxy will just  
let the phone continue ringing.... hence anybody else calling will  
encounter a 486 busy.

This perhaps is more of a testing problem, than real-world problem.   
However, my situation is a test-setup,  hence is a real-world problem  

Query regarding 100 Trying over TCP

Hi All,

I have a query regarding 100 Trying over TCP Connection. The main purpose of
100 Trying is stop retransmissions. Over a TCP Connection anyway
retransmissions will not done.

So what is purpose of sending 100 Trying on TCP Connection?

Are there any uses of 100 Trying other than stopping retransmissions?

With Regards
Raghu

Query Regarding Target Refresh Requests

Hi All,

When a UE sends a Target Refresh Request, should UE continue to listen on
the Old Contact until it receives 1XX ( except 100 Trying ) or 2XX
Responses?

As per 3261, whenever a UAS receives a target refresh request, it MUST
replace the dialog's remote target URI with the URI from the Contact header
field in that request, if present.

So as per the above behavior should UAC continue to listen on old contact
until it receives 1XX ( Except 100 Trying) or 2XX for the Target Refresh
request.

When should it start listening on the new Contact, that it has inserted in
the Target Refresh Request?

What should be the behavior of Call Stateful proxies for Target Refresh
Requests? Should they update the Contact of the UE upon receiving Request or
should they update up on receiving 1XX or 2XX for Target Refresh Request and
use the old contact until then.

With Regards
Raghu

Re: (no subject)

rfc 3551 contains everything you need.

> Hi,
> 
> I want to ask about RTP payload size. I’m implementing validation on
> RTP/RTCP packets.
> 
> I want to validate the size of the RTP packet, so I try to figure the
> max size of an RTP packet according to the codec type.
> 
> Where can I find a helpful reference.
> 

--

-- 
Кравченко Петр Геннадьевич
НПП "СпецСтрой Связь", НТЦ, разработчик
Тел. +7(8634)311562 доп 225
mailto: piterk <at> proton-sss.ru

rfc 3551 contains everything you need.

> Hi,
> 
> I want to ask about RTP payload size. I’m implementing validation on
> RTP/RTCP packets.
> 
> I want to validate the size of the RTP packet, so I try to figure the
> max size of an RTP packet according to the codec type.

CONFERENCE CALL

As we are aware that SIP does support multiple sessions and for  that
multiple INVITE's has to be send.  I want to know whether the SIP supports
the CONFERENCE CALL feature, and what will be the scenario.  Waiting for
reply.

Thanks & Regards.
Jafer.

RFC 2833

Can anybody tell me, what is meant with "Flash" in RFC 2833?

Thanks,
Daniela
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft
Exchange.
For more information, connect to http://www.F-Secure.com/

Re: Clearing up of 486 Busy when INVITE callerdies...

Hello Russ , 
Just check this link out ... 
There are two solutions , either the UAS can implement it's own "ring
timeout" ... Also the proxy is supposed to send a CANCEL in case timer C
expires ... 
http://bugs.sipit.net/show_bug.cgi?id=706

Regards , 
Sayan 

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Russ
Daigle
Sent: Friday, December 01, 2006 6:43 AM
To: Siddhartha Bhakta
Cc: sip-implementors <at> cs.columbia.edu
Subject: Re: [Sip-implementors] Clearing up of 486 Busy when INVITE
callerdies...

Thanks for your response.

Remember, in my scenario the UAC died.  Therefore,  it will not be  
having any timers that expire nor will it send any CANCELs.    
Therefore, it is completely dependent on the proxy B or UAS C to clean
up.  (And please no responses about UAC solutions to this problem,
because the whole point is to test proxy/UAS scenarios with somewhat
flaky UACs.  It "dies" because it is suppose to!:)

Re: [Sip] Re: Forking INVITE SIP message - regarding

Hello Raj , 
It is indeed a possibillity that you may have multiple 200 responses reaching your UAC due to forking ... 

Check out section 13.2.2.4 in RFC 3261. 
You will have to ACK each 2xx and then BYE the ones you do not need. 
If all of the dialogs(each 2xx will form a separate dialog at the UAC) establish audio sessions and you are
implementing a UE , then you may want to keep just one and BYE the rest. 
Which dialogs to BYE  is again your implementation decision, you can accept the first 200 OK and BYE the rest
if you want. 
Hope this helps. 
Regards , 
Sayan 

________________________________

From: Sreenath Kulkarni [mailto:sreenathkulkarni <at> yahoo.co.in] 
Sent: Wednesday, November 29, 2006 10:40 AM
To: Raj; SIP forum; sip <at> ietf.org; sip-implementors <at> cs.columbia.edu
Subject: [Sip] Re: [Sip-implementors] Forking INVITE SIP message - regarding

Hi Raj,

This scenario can happen only in case of parallel forking. I don't beleive that all the 2xx responces will
reach the server at the same tume. If it so then i think the server will forward the 2xx response on some
priority basis.

/Sree

----- Original Message ----

Re: Clearing up of 486 Busy when INVITE caller dies...

Russ,

Response inline.

--- Russ Daigle <rdaigle <at> musecurity.com> wrote:

> Thanks for your response.
> 
> Remember, in my scenario the UAC died.  Therefore, 
> it will not be  
> having any timers that expire nor will it send any
> CANCELs.    
> Therefore, it is completely dependent on the proxy B
> or UAS C to  
> clean up.  (And please no responses about UAC
> solutions to this  
> problem,  because the whole point is to test
> proxy/UAS scenarios with  
> somewhat flaky UACs.  It "dies" because it is
> suppose to!:)

In real world, both UAC and UAS shall start
ringing/alerting timer so that it can clear the call.
In your case, UAS (and/or stateful proxy) shall
terminate the call on that timer expiry.
You can imagine what happen if UAS dies. In that case,
timer at UAC shall help terminating the call.
Therefore, if UAC dies then UAS shall not be ringing
forever and vice-versa.