[SIPForum-discussion] a question about re-invite

fanyanping fanyanping at huawei.com
Fri Jun 5 00:32:33 UTC 2009


Hi all,
 
thank you for the answer, ^_^
 
i have a question that what is  the mean of "modify the session"? just only
inlude the SDP Parameters or include the dialog Parameters and SDP
Parameters??
in my mind, session should include dialog and media,is it right??
 
 
 
 
ps :
> Moving further
> Answer to question one: 
> If I consider A,B,C are all UAC then no as because C would not be 
> ready to receive a response for the request it never generated and 
> would discard it.
 
response wil be back to A  according the Via header


  _____  

From: Anthony Orlando [mailto:avorlando at yahoo.com] 
Sent: Friday, June 05, 2009 12:35 AM
To: fanyanping at huawei.com; discussion at sipforum.org;
abhishek.chattopadhyay at wipro.com
Subject: RE: [SIPForum-discussion] a question about re-invite


Not arguing the point of using re-invite to "transfer" a call to c.  My
points are two
1.) RFC3261 chapter 14 defines the use of a re-invite to modify the session.

2.) re-invite should not be used to transfer the call.  Refer method should
be used.

--- On Thu, 6/4/09, abhishek.chattopadhyay at wipro.com
<abhishek.chattopadhyay at wipro.com> wrote:




From: abhishek.chattopadhyay at wipro.com <abhishek.chattopadhyay at wipro.com>
Subject: RE: [SIPForum-discussion] a question about re-invite
To: avorlando at yahoo.com, fanyanping at huawei.com, discussion at sipforum.org
Date: Thursday, June 4, 2009, 12:23 PM



Hello Anthony 

 

I agree that a re-invite can change the remote target URI of a dialog. But I
think it wouldn¡¯t be safe enough to assume that changing the remote target
of the dialog to such a UA which has no information of the already existing
dialog, and is expected to somehow respond to the message.

So in case A is aware then B surely is negotiating with C on behalf of A. An
SBC can be a good example of such scenarios where a UAC makes a request on
behalf of another UAC. 

 

I hope it is not difficult assume a scenario where call is intended between
A and C however A calls B and B does all the negotiations and
re-negotiations with B before passing over the session to A finally.

 

Further, till now I haven¡¯t experienced any such scenario where such a
thing happens in case you came across one, can you please forward the call
flow.

 

Thanks you

Regards 
ABHISHEK 

 


  _____  


From: Anthony Orlando [mailto:avorlando at yahoo.com] 
Sent: Thursday, June 04, 2009 9:40 PM
To: fanyanping at huawei.com; discussion at sipforum.org; Abhishek Chattopadhyay
(WT01 - Telecom Equipment)
Subject: Re: [SIPForum-discussion] a question about re-invite

 


>From RFC3261.  A re-Invite is used to modify an existing session.  If A
wants to transfer the call to C then you would user the Refer method.  Refer
(no pun intended) to rfc 3515


14 Modifying an Existing Session
A successful INVITE request (see Section 13) establishes both a
dialog between two user agents and a session using the offer-answer
model. Section 12 explains how to modify an existing dialog using a
target refresh request (for example, changing the remote target URI
of the dialog). This section describes how to modify the actual
session. This modification can involve changing addresses or ports,
adding a media stream, deleting a media stream, and so on. This is
accomplished by sending a new INVITE request within the same dialog
that established the session. An INVITE request sent within an
existing dialog is known as a re-INVITE.
Note that a single re-INVITE can modify the dialog and the
parameters of the session at the same time.
Either the caller or callee can modify an existing session.
The behavior of a UA on detection of media failure is a matter of
local policy. However, automated generation of re-INVITE or BYE is
NOT RECOMMENDED to avoid flooding the network with traffic when there
is congestion. In any case, if these messages are sent
automatically, they SHOULD be sent after some randomized interval.
Note that the paragraph above refers to automatically generated
BYEs and re-INVITEs. If the user hangs up upon media failure, the
UA would send a BYE request as usual

--- On Thu, 6/4/09, abhishek.chattopadhyay at wipro.com
<abhishek.chattopadhyay at wipro.com> wrote:


From: abhishek.chattopadhyay at wipro.com <abhishek.chattopadhyay at wipro.com>
Subject: Re: [SIPForum-discussion] a question about re-invite
To: fanyanping at huawei.com, discussion at sipforum.org
Date: Thursday, June 4, 2009, 4:21 AM

Hello Nancy ,

SIP RE-Invite method is a mechanism of refreshing the session primarily and
not changing the session itself.

Moreover if suppose A and B are in session and somehow B wants A to talk to
C then the method refer would be used.
There are other implementations where a re-invite is sent to achieve the
same objective. This depends upon implementation largely.
The fact all such cases where re-invite is used in place of refer to achieve
similar functionalities there are serious resource compromises to mitigate.

Moving further 
Answer to question one: 
If I consider A,B,C are all UAC then no as because C would not be ready to
receive a response for the request it never generated and would discard it. 
Such a scenario can be seen where A receives a Request from C and then
generates the Invite towards B on behalf of C.

Answer to question two:
Call-id, to tag, from tag are session wise unique in the space and time,
they might not be used by other clients as they would be used to identify
dialog and session between agents.


Regards 
ABHISHEK


-----Original Message-----
From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of fanyanping
Sent: Wednesday, June 03, 2009 9:38 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] a question about re-invite

Hi all£¬
my understanding of a SIP reinvite is that it modifies the media session. Is
it capable of modifying the address of the send too? for example£¬ A is
talking to B, can A send a reinvite to B with C's address instead of its own
address?
another example£¬A is talking to B£¬recorded as dialog1, C knows the
information of the dialog1,  can C sends a reinvite to B instead of the
dialog1, the dialog bewteen C and B has the same Call-ID, from-tag, to-tag
as dialog1?


Best Regards.
nancy

*******************************************************************
This email and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above.
Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons
other than the intended recipient(s) is prohibited. If you receive this
e-mail in error,
please notify the sender by phone or email immediately and delete it!
*******************************************************************



_______________________________________________
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

 

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The
company accepts no liability for any damage caused by any virus transmitted
by this email. 

www.wipro.com 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20090605/c6a5f841/attachment.html 


More information about the discussion mailing list