Vini,
There is no timer (I know of)for a UA being held, there are
possibly other timers running in this scenario for session refresh or RTP
timeout etc. The intermediate softswitch is a B2BUA ?(it is sending a BYE
when the B party seems unreachable ?) - more detail of the scenario would
probably help.
With B on hold the continuous INVITE sent from UA A I am assuming
is to take the UA B party off hold ?, the INVITE should be sent from UA A
at intervals of Timer A with exponential backoff - there will be a limit
in time or messages for re-transmitting the INVITE, you have stated the
request is sent 5 or 6 times (I have found that many systems use a setting
for INVITE retransmission the same as T2 for non-INVITE transactions =
4sec or = 5 INVITEs). Timer C of 64*T1 or 32sec should mean that UA A is
prepared to accept a response up to 32sec after the request. See Table 4
in RFC3261 for timer settings.
0sec: UA A -->INVITE
500msec: UA A -->INVITE
1sec: UA A --> INVITE
2sec: UA A --> INVITE
4sec: UA A --> INVITE (prepared to wait <=32sec)
+4sec: <--- BYE Softswitch
However with the call established and the INVITE being for resume
off for held state not making it to the B party will not in itself cause
the call to terminate - either the end user tries to resume the call again
(presses the hold button again in an attempt to resume the call) or they
talk but can't hear / get response from the remote end and they make a
user decision to hangup and terminate the call (BYE). The softswitch
(B2BUA ?) appears to be inserting this logic. I hope the above is
accurate.
Regards - Wayne.
Vini said:
>Hi,
>
>Is there any timer for controlling Call hold? I'm encountering the
>following problem during Call hold.
>1. UA A calls UA B.
>2. A 2 way RTP is established between them.
>3. Now UA A keeps UA B on hold. A sends INVITE messages to B
>continuosly, but there is no response. After 5 or 6 messages, A gets a
>BYE message from the intermediate softswitch.
>
>I'd like to know whether there is any timer which timesout the INVITE
mesages.
>
>Thanks & Regards,
>Vini.
_______________________________________________
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.
******************************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
