Rockson Li (zhengyli) wrote:
> Bharat,
>
> You are mostly correct.
> One point I want to add is you might get SDP answer in reliable response
> instead of 200, though this is seldom used in real world, but It's totally
> correct as per spec.
>
> You can also check out RFC3264 sec 8.3.1 Modifying Address, Port or Transport
Agree.
There is a window during which one can't be certain which of the
addresses will be used. Specifically, from the moment the offer is sent
there is the possibility of receiving on the offered port. But one can't
be certain until at least after receiving the answer. Even then, because
the paths are different, media may continue to arrive at the old port
for a time.
This isn't much of a problem for audio, or probably for video either.
Typically you can just stop listening on the old port and start on the
new at some point, and not worry about packets lost if you didn't get
the timing just right. A few packets don't make that much difference.
But it *can* matter for some media. For instance, if you are using an
MSRP media stream for IM, then losing *one* message can be a problem. In
that case you will need to use a "make before break" strategy and
possibly merge media between the two streams.
Paul
> FYI
>
> -Rockson
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL
> PROTECTED]
> Sent: Wednesday, August 06, 2008 1:42 PM
> To: [email protected]
> Subject: [Sip-implementors] SDP Query - reINVITE with IP Address inconnection
> info field updated.
>
> Hi all,
>
> Say we have call between Party A and Party B. When both parties are
> in call, Party A sends out a re-INVITE to Party B updating the IP Address in
> the connection information field in SDP.
>
>
>
> In the Initial SDP exchanged
>
> c: IN IP4 1.2.3.4
>
>
>
> In the re-INVITE sent
>
> c: IN IP4 5.6.7.8
>
>
>
> As far as I understand, once Party A receives a 200 OK from the Party
> B for the re-INVITE sent; there won't be any media arriving on the IP address
> 1.2.3.4. Further exchange of real time data will take place at IP address
> 5.6.7.8. Am I right? Is there any RFC/Draft that explains handling of this
> behavior?
>
>
>
>
>
> Thanks,
>
> Bharat
>
>
> 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
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
