[SIPForum-discussion] Call Hold

[Herve Jourdain]

Hi,

 

Additional comments :

 

1)       Well, I think it's « standardized » in RFC 3264, "8.4 Putting a
Unicast Media Stream On Hold", which specifies:
"If the stream to be placed on hold was previously a sendrecv media stream,
it is placed on hold by marking it as sendonly. If the stream to be placed
on hold was previously a recvonly media stream, it is placed on hold by
marking it inactive."

2)       I agree with Donald, in theory it works like that. But I've seen
many implementations where A stops sending as well, and where B doesn't
listen - which can be an issue for Music On Hold.

3)       If re-INVITE is the one for HOLDING the call when it was previously
active, and it fails, then the call will remain ACTIVE. If it's the one for
putting the call OFF HOLD, then it will remain in HOLD condition.

4)       I agree with Donald. In theory, only after the re-INVITE has been
"accepted". But experience proves it can be different on some devices.

 

Regards,

 

Herve

 

  _____  

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Donald Lee
Sent: jeudi 10 janvier 2008 09:29
To: Halit Sakca
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Call Hold

 

Please refer to to comments inline.

On Jan 8, 2008 8:44 PM, Halit Sakca <sakcahalit at hotmail.com> wrote:
>  
> Hi, 
Hi All,

Suppose there is SIP session established between 2 SIP UA ('A' & 'B).

Now 'A' put 'B' on Hold by sending REINVITE with sendonly.

1) Please let me know , it is follow the latest standard of RFC 
# I think it has not been standarded yet. But it is a normal procedure to
Call hold.
See
http://ietf.org/internet-drafts/draft-ietf-sipping-service-examples-13.txt
for more information. There is another method is using connection parameter
in SDP as the indicator, but it's not recommended yet now.

2) In case only direction RTP stops or both ?
# B's direction is now recvonly, it doesn't send any RTP to A. For A,
sendonly.

3) In this if the internediate server(proxy server) is down during put on
hold condition, user will re-transmit re-INVITE till 31 sec. In this case
wht is the status of the call from both end. 
# re-INVITE failure doesn't teardown the dialog. remaining the hold status.

4) When user 'A' put on hold by sending INVITE , does he stop sending the
RTP packet parallely to the sending re-INVITE 
# It depends on the implementation. RTP stops after receiving the final
response of re-INVITE in theroy.

Thanks in Advance
>   
>  Also I would like to add; 
>   
>  -- gatekeeper deals with call session establishment, gateway is not able
to
> establish a sip call.
>  one exapmle;
>  A calls B,
>  A:pots client,
>  B:sip client,
>   
>  [A] --(megaco)-->[Gateway]--(SIP)--->[Gatekeeper]---(SIP)---> [B]
>  
> hopefully more clear,
>  
> Selamlar,
> Halit Sakca
> 
> 
> 
>  
>  ________________________________ 
>  From: pinakee.b at xius.com
> To: asitdash1982 at gmail.com; discussion at sipforum.org 
> Date: Tue, 8 Jan 2008 16:04:46 +0530
> 
> Subject: Re: [SIPForum-discussion] Call Hold
> 
>  
>  
> 
> Asit, 
> 
>   
> 
> These are H.323 components and not part of SIP. In H.323, Gatekeeper deals
> with registration and location. Gateway deals with Call Control and media.

> 
>   
>  
>  ________________________________
>  
> 
> From: discussion-bounces at sipforum.org
> [mailto:discussion-bounces at sipforum.org] On Behalf Of asit dash
> Sent: Tuesday, January 08, 2008 12:52 PM
> To: discussion at sipforum.org
> Subject: Re: [SIPForum-discussion] Call Hold 
> 
>   
> 
> Hi all,
>     can any one tell me the difference between gateway and gatekeeper  ? 
> ________________________________
> Tamamıyla yeni Windows Live Messenger ailesine katıl Buraya tıkla! 
> _______________________________________________
> This is the SIP Forum discussion mailing list 
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
> 
> 



-- 
BR
Donald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080110/460c0890/attachment-0002.html>