Subject: [Sipping] Question on ReInvite procedures

From: "Hemant Agrawal" <[email-masked]>
Date: Wed, 22 Aug 2001 12:45:15 -0700

Hi all,
         I have a question on ReINVITE procedures.
   1.  Party A sends a INVITE to Party B with SDP as IP = a and port = b
       It gets a 200 OK from Party B with SDP as IP = m and port = n

   2. Party A sends a ReINVITE to Party B with SDP as IP = c and port =
d
      It gets a 200 OK from Party B with SDP as IP = m and port = o

   My questions here are:
   i. Is this behavior proper? What should be done, if Party A does not
want Party B to change its SDP port or keep the same connection? 

   ii.) If this is not a proper behavior,  the Party B should respond
with same SDP as previous with IP = m and port = n.  Than What should be
done, if Party B wants Party B to change its SDP port or open new
connection? 

  Waiting for your response!

Thanks
Hemant

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Bert Culpepper" <[email-masked]>
Date: Wed, 22 Aug 2001 17:14:31 -0400

This kind of behavior is discussed in draft-rosenberg-sip-3pcc-01.txt.
It STRONGLY RECOMMENDs that UAs do not change their address and port
assignments in responses to re-INVITEs when asked to change the address
and port they send media to.  However, if the SDP in the re-INVITE
changes the codec for a media stream, then the re-INVITE response can
contain a different address and port from that of the initial request.

This behavior on the part of UAs is required for 3rd-party call control
in SIP.  But is not required in RFC2543.  RFC2543bis touches on this in
appendix B but for a little different scenario.  That is, re-INVITE w/o
SDP, 200 with "previous SDP" (offer), and ACK with SDP (answer).  In the
first paragraph of section B.4 it states "... the offerer SHOULD offer
the same SDP it provided previously if it has no reason to change
anything."  It's up to implementers to comply with the recommendation
above for 3pcc to work.

To answer your questions given the above, A should not change any media
encoding aspects for a stream if it doesn't want B to change its
address/port.  If B wants to change its port, it should complete the
re-INVITE from A then issue its own re-INVITE.

regards,
Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Hemant Agrawal
> Sent: Wednesday, August 22, 2001 3:45 PM
> To: [email-masked]
> Subject: [Sipping] Question on ReInvite procedures
>
>
>  Hi all,

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 30 Aug 2001 14:43:00 -0400

> want Party B to change its SDP port or keep the same connection? 

Party B has the right to change its IP 
address and/or port.  However the 3PCC 
draft (and I think bis-04) recommends 
that party B not change such things 
without a reason.

If your concern is related to 3PCC,
you can use a re-invite without SDP to 
avoid an SDP change loop.