[SIPForum-discussion] a question about re-invite

Thu Jun 4 16:35:05 UTC 2009

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/20090604/d5330109/attachment-0002.html>